[atoav]

I program for roughly two decades now and I never got warm with frontend frameworks. Maybe I am just a backend guy, but that can't be it since I am better in vanilla JS, CSS and HTML than most frontend people I have ever met.

I just never understood why the overhead of those frameworks was worth it. Maybe that is because I am so strong with backends that I think most security-relevant interactions have to go through the server anyways, so I see JS more as something that adds clientside features to what should be a solid HTML- and CSS-base..

This kind of guide is probably what I should look at to get it from first principles.

[edflsafoiewq]

The basic problem is when some piece of state changes, all the UI that depends on that state needs to be updated. The simple solution presented in the link is to write update functions that do the correct update for everything, but as the dependency graph becomes large and keeps changing during development, these becomes very hard to maintain or even check for correctness. Also the amount of code grows with the number of possible updates.

Reactive view libraries basically generate the updates for you (either from VDOM diffing, or observables/dependency tracking). This removes the entire problem of incorrect update functions and the code size for updates is now constant (just the size of the library).

[skydhash]

But what if your dependency graph never becomes large (HN, Craiglist,...)?

I believe a lot of web applications can go without any reactive framework as using one is a slippery slope. You start with React and 80% of your code is replacing browser features. Imperative may not be as elegant, but it simpler when you don't need that much extra interactivity.

[edflsafoiewq]

Then you don't need it. Same for if you can do everything (or most everything) with page reloads, or if you don't have any reactivity at all. But the problem is still real, even if people use frameworks when they don't really have to.