[hg35h4]

Everything about this sounds terrible for mobile, lossy or even medium latency connections. Non-blocking background updates are unnoticeable, but imagine your website being jammed like a stuck video every time you click or scroll?

He describes a "please wait buffering" future of web software. No thanks.

[antihero]

Also:

> Do we really believe that every one of our users is going to have a device capable of digesting 100 kB of JSON and rendering a complicated HTML table faster than a server-side app could on even a mid-grade server?

Yes. This really isn't hard. Pretty much any smartphone can do this with blissful ease. And it scales horizontally because your server can just worry about getting stuff from the database and handing it out.

[notjustanymike]

Exactly. Our app renders highly detailed 3D anatomy on the canvas. The largest model is a 1mb json file with 57mb(!!!) Of assets. We've never had a problem with mobile devices, they're shockingly capable.

[da39a3ee]

What countries are your users in?

[g105b]

San Francisco isn't a country.

[ehayes]

Turbo[links], Stimulus, etc. ARE non-blocking background updates. It's HTML over the wire instead of JSON. [1] I don't think this is what you think it is.

[1] https://hotwire.dev/

[cpill]

since when is HTML lighter than JSON?! this use case was what propelled JSON into the mainstream.

[kawsper]

The argument is that it is lighter for the device just to receive static HTML, than it is for the device to receive JSON and build HTML templates.

[ymolodtsov]

The idea is that HTML is just slightly heavier but the advantage is you can render it on the server and don't need all that middleware and serialization layer.

[dahdum]

That was my first thought too, the word "latency" isn't even mentioned in the article.

[Asmod4n]

With this approach you can keep all of the traffic inside a WebWorker, so nothing blocks. You also get the benefit of not having to open a new connection for every request and automatic reconnects when someting goes wrong. The connection is most likely already established before you even need it.

[water8]

You just described http2

[Asmod4n]

Wait, with http2 a webbrowser never closes the connection it has to a webserver?

[jlokier]

Even HTTP/1.1 from 1999 keeps a persistent connection open, if the client and server agree.

What it doesn't do so well is lots of parallel requests and responses out of order. HTTP/2 is better for that.

Both versions will close the connection if it's been idle for a while, and automatically reconnect as needed.

[qbasic_forever]

Yes, it's a long-lived TCP connection. It's not mandatory but the whole point of the protocol is to make one connection and send/receive all your assets over it instead of making more connections (which take time to setup and slow down page rendering).

[SahAssar]

It keeps it open as long as it is used and usually a bit past that. So if you have any traffic or are making periodic requests then it won't close the connection. If you are using SSE that can also use the same shared connection for streaming realtime updates to the client.

[silon42]

At least their web page seems to work without Javascript... I hope this technology will too.

[Jtsummers]

Of these things, I've only played with LiveView (I'm a web dabbler, not a pro, but an Erlang/Elixir fan so it was interesting to me). At least through the material I've worked through, it fails to a usable mode when JS/WS themselves fail on the client side. In theory, the only required JS is the JS needed to establish the WS connection and communicate with the server and issue the updates. But if the WebSocket fails, you should end up with just a full page load instead of the diff being applied. (NB: A particular site/application may have more JavaScript, but for what LiveView offers out-of-the-box there's not much JavaScript that's included or needed.)

[ecmascript]

I had this thought as well, but having used Liveview in Phoenix this really isn't the experience. Since the updates are really small and as long as you do it only when you want updates from the backend anyway the experience is just as smooth as any SPA even on a shitty mobile connection.

[beagle3]

Isn’t this also the basis for Stadia RIP and XBox Mobile work on iPhones? That seems to deliver acceptable results for even arcade games on WiFi.

Latency seems to have been conquered.

[FridgeSeal]

> Latency seems to have been conquered.

I dare you to say that from Australia.

[beagle3]

We are not close to conquering the speed of light. Ping time NY to Australia is 100-200ms regardless of software stack.

But if you have a server in Australia then I would still say that.