5 ms·
Everything about this sounds terrible for mobile, lossy or even medium latency connections. Non-blocking background updates are unnoticeable, but imagine your
by hg35h4 6y ago
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.
- dahdum 6y agoThat was my first thought too, the word "latency" isn't even mentioned in the article.
- antihero 6y agoAlso: > 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 6y agoExactly. 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.
- ehayes 6y agoTurbo[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/ https://hotwire.dev/
- cpill 6y agosince when is HTML lighter than JSON?! this use case was what propelled JSON into the mainstream.
- ymolodtsov 6y agoThe 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.
- kawsper 6y agoThe 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.
- silon42 6y agoAt least their web page seems to work without Javascript... I hope this technology will too.
- Jtsummers 6y agoOf 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.)
- Asmod4n 6y agoWith 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 6y agoYou just described http2
- Asmod4n 6y agoWait, with http2 a webbrowser never closes the connection it has to a webserver?
- qbasic_forever 6y agoYes, 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 6y agoIt 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.
- jlokier 6y agoEven 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.
- ecmascript 6y agoI 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 6y agoIsn’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 6y ago> Latency seems to have been conquered. I dare you to say that from Australia.
- beagle3 6y agoWe 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.