> People demanded more interactive web apps, which led to more stateful UI, which led to React.

Except they didn't. 99% of web developers work on crud apps, not Figma. The users never really cared. You can achieve "good enough" results waiting for server. I still see over fetching from server instead of updating caches in most frontend apps anyway. Things like a button optimistically updating, just show a spinner and wait for the server. Devs just want to overcomplicate things just because they don't know any better.

I'm in an organization which had some extremely old, all-server-side-PHP tools.

We managed to get one section of them retooled as responsive HTML/PHP design, and then went whole hog on React.

Every single piece we replace with React seems slower and more complex. Tools that were "render it on the server as a finished page" has been replaced with "do it as an API that returns a ball of JSON and the client will render it." Most of these tasks are classic CRUD. So in the old version, you'd click a button or link and the page would reload in 5 seconds. Now, it lets you stare at a spinner for 10 seconds while it repopulates the same page. But golly, we avoided that flash of blank screen!

We were sold that splitting off an API would allow alternate implementation-- power users could bypass the UI and build their own automations. Nobody has; I don't think the API even firmed enough to be worth documenting.

I think the thing I resent most, though, is the tendency of modern Javascript to be a fantasy language. It does not exist in the wild. It's not like you can even say "here's a cool trick that works in Mozilla but not IE6" like back in the old days, it's literally zero-real-browser support. You instead need to set up an entire dev toolchain of stuff like Babel and Webpack before you can even get to Hello World. This seems like such a loss, given that the web was such an accessible platform-- get your $2 per month shared hosting, start writing a single file in PHP or raw HTML, and you can actually see useful stuff on your screen.

Both things are true: people wanted more interactive apps; at the same time, most engineers don’t work on those kinds of apps.

A frequent analogy: React raises the ceiling for the kinds of experiences you can build in a browser.

But not every app hits that ceiling. If CRUD works for you, do that. The simpler the better.

> In the case of Facebook, the motivating app was Ads Manager

Google created Flutter and its native language Dart in the process of developing AdWords. I don't know if it was the 'motivating' application for Flutter+Dart, but the first public exposure of Flutter happened less than two years before mobile AdWords was implemented with it.

I guess selling ads it a pretty complicated business if you need to create frameworks and programming languages to pull it off.

> You can’t represent that state on the server without making the UI unusably slow.

And that's why you use a client-side cache.

And once that cache is sufficiently complex, it's just a state store like redux.

Cache stays simple even for large applications. It never gets "sufficiently complex".

As the joke goes, there are two hard problems in software:

1. Naming things.

2. Cache invalidation.

3. Off-by-one errors.

Caches are tricky beasts. First, you need to update them when the server-side state changes (for example, two people editing a single Google doc). Second, writing state changes to the server and waiting for confirmation is too slow for many kinds of interactions. In these cases, it's typical to optimistically write local changes to a local store, and then try to sync those changes with server asynchronously. But if synchronization fails, then the client needs to report that.

And finally, there's the problem of partially loaded state, where the rest is loaded asynchronously on demand. That should be simple, but without some kind of framework, it also tends to have lots of subtle state-machine and null-reference bugs.

So, no, cache does not always stay simple in large applications. (Unless the app is read only, and you're OK showing stale data.)

If you are building Google doc editor by all means, design a complex state management system, it is worth it. But then don't bring that complexity into typical business applications.

It’s all true, but you missed the part where react and/or redux are talking to the server to manage the cache. Because if they aren’t, it’s unclear why tf they are holding the mic.

Theoretically, but not practically.

And that's why you need state management. Cache is state.