[bob1029]

To me, the more fundamental problem is the fact that we spread state across multiple computers.

If you only mutate state on the server and simply send views back down to the clients, nearly all of "modern" web development practices can be safely ignored.

Clearly, there are difficult engineering challenges with the approach of "all state on the server all the time", but anything worthwhile is never easy. Down this path you might not obtain Netflix-tier webscale directly out of the box, but that doesn't mean we throw our hands up and have all our clients drown in multiple megabytes of angular11+ dependency trash either.

How many internet users are more than 50ms away from a Cloudflare/Microsoft/Google/Netflix CDN in 2021? How many cores can you get in a 1U server now? Distributed state machines for client UIs have been a massive mistake.

[ngrilly]

I mostly agree, but having used Linear.app which has a crazy good and fast UI based on a local database synced with their cloud database, I'm not sure anymore: https://youtu.be/WxK11RsLqp4?t=2170.

I think it's important to define early in a project if the app is "cloud-based" or "local-based". If it's cloud-based, then only the server mutates state and sends views to the clients, as you wrote. Everything is simple. If it's local-based, then all data are available locally and mutated locally. The cloud is only used as mirror/backup and can support for some advanced features like full-text search. That's also a very clear architecture. That's how Linear works.

Things become hairy and unnecessarily complex when no clear choice is made between those two options, then it's not clear where the state is.

[dehrmann]

> there are difficult engineering challenges with the approach of "all state on the server all the time"

There are real world challenges. There's no internet access on the NYC subway. Latency can spike for no apparent reason. Making a webapp a dumb client really only works for wired connections on an intranet.

[bob1029]

> ... but anything worthwhile is never easy.

When I was working in South Korea, their subway system had excellent reception to cellular and even satellite TV networks. They explicitly engineered a solution to this problem in direct, first order terms.

This is precisely the type of approach we should be taking in my opinion. Make the networks robust, not the client-facing web apps. We are spending engineering resources in largely the wrong places.

This would be like arguing for a car that can hover, but only for an ambiguous/non-specific amount of time, simply because the roads are occasionally total shit.

[gherkinnn]

But it's two very different groups of making those decisions.

I try my best to build robust apps but have no bearing on my countries infrastructure plans. And have the government reallocate my resource to setting up antennae in tunnels is dystopian.

[gherkinnn]

> To me, the more fundamental problem is the fact that we spread state across multiple computers.

I completely agree. Sharing a layer of an application between client and server is a nightmare and will fly in your face.

That said, it is possible to cleanly handle more involved interaction on the FE and have a clean separation of responsibilities. When well done, the results are very snappy and robust. Of course, it isn't always necessary, and most RoR applications beat that 5mb Angular behemoth.