[thebean11]

> If your request to fetch new data and patch the DOM takes 5ms

Even in the US people are still dealing with pretty bad internet in a lot of places. Even with the best internet, and assuming it takes 0ms to handle the request, 5ms sounds insanely optimistic. I'm in a big city and my ping (to my ISP's datacenters in the same city) is 10-20ms...

[ericb]

So, latency is certainly one locus of optimization.

Another locus of optimization might be development speed and cost. An SPA is really two apps, a front-end, and a back end.

It costs 2x to do an SPA, and all things being equal, features come out 1/2 as fast.

Which wins the app with latency, or the app that gets features twice as fast?

[thebean11]

It doesn't cost 2x. Yes you go from two apps to one, but that one app is more complex than either of the original two.

[ericb]

I agree, it doesn't cost 2x. An SPA probably costs more like 3-4x.

Coordinating two apps is much harder than one app.

A reference for this topic is the Mythical Man Month, which concludes that communication overhead is what is expensive. When you have two apps, the humans, and the software both need to communicate and coordinate.

When there's two apps, you have an OR condition where if either app is broken or in disagreement about the expected API, both are broken. You have two sets of build processes, sets of tests, sets of files to serve, caches to manage, state to manage, versions to manage, and they all need to coordinate.

Instead of one thing to test, with an SPA, there's really 3! The server side app in isolation, the client side app in isolation, and the combination of the two.

[yurishimo]

Sure. I'm being super optimistic there, but it's also worth noting that Phoenix uses a websocket so some of the latency in the handshake is negated for subsequent requests.

Still, 50ms would probably be fast enough for a lot use cases, and if it's not, it's easy to configure debouncing.