I have a brilliant idea, why not HTML over plain sockets?
The future of web software is HTML over WebSockets
41–50 of 337 posts
Re: The future of web software is HTML over WebSockets
#42Everything 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.
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.
You just described http2
Re: The future of web software is HTML over WebSockets
#43I used to love WebSockets a lot more. At some point I got deeper into implementing HTTP servers and proxies, and realized how much of a special case WebSockets are to implement. They're cool, but I prefer Server-Sent Events on HTTP/2 whenever I can get away with it, which is pretty much always (binary data being a big exception, and even then I consider long-polling first).
I think there's value in keeping our protocols as simple as possible to accomplish the task at hand.
Re: The future of web software is HTML over WebSockets
#44I do have to laugh a bit at people being very quick to dismiss this idea when HTTP/2 is effectively the same idea--one long-lived bi-directional 'socket' to multiplex all requests. It adds a lot more niceties like the server proactively pushing assets on first load. Many folks might even be using it right now without really realizing or knowing it.
Re: The future of web software is HTML over WebSockets
#45I have thoughts, and I agree but also disagree a bit. We are in the dark-ages with respect to streaming sockets, and I am the architect of one of the worlds largest WebSocket and streaming services. First off, unseating the operational benefits provided by request response is a huge challenge. It's possible, and I've done it. One of these days, my co-authors and I will present an OSDI paper with the broad strokes. It…
I am doing something somewhat similar - I have a Postgres database and I send all the user tables to the client on connection and then stream all the updates. I use Vue and Vuex-ORM to make the client tables reactive, and put a view on that. When something changes in the database, the client UI will also update.
It is indeed a very powerful and reliable way of ensuring synced state.
Re: The future of web software is HTML over WebSockets
#46Earlier quoted context omitted.
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.
You just described http2
Wait, with http2 a webbrowser never closes the connection it has to a webserver?
Re: The future of web software is HTML over WebSockets
#47More snake oil from the Internet industry as usual. It is almost 30 years since the web came into existence and somehow people harbour this illusion that those who control the standards or are responsible for implementing them are genuinely committed to delivering technology which will help the competition (ie the rest of the world) bypasses their app stores. It makes one wonder whether those who keep blabbing on abo…
They are neither shills nor explicitly stupid, just inexperienced (mostly young people) with a great deal of enthusiasm and energy.
John Gruber has been around too long for like this to appear on his blog, but then he is not the writer of this article and probably doesn't much exercise much of an editorial influence.
Re: The future of web software is HTML over WebSockets
#48Everything 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.
At least their web page seems to work without Javascript... I hope this technology will too.
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.)
Re: The future of web software is HTML over WebSockets
#49I used to love WebSockets a lot more. At some point I got deeper into implementing HTTP servers and proxies, and realized how much of a special case WebSockets are to implement. They're cool, but I prefer Server-Sent Events on HTTP/2 whenever I can get away with it, which is pretty much always (binary data being a big exception, and even then I consider long-polling first). I think there's value in keeping our protoc…
I've used HTTP/2 SSE for TinyDev (docs.tinydevcrm.com) and I've encountered the need for a reverse proxy and the unidirectional dataflow to be kinda eh, even if it is great in theory. I haven't played around too much with WebSockets though, but IMHO money + traction carries a good deal of weight.
Re: The future of web software is HTML over WebSockets
#50Earlier quoted context omitted.
Did you learn mis en place in a kitchen, or does it have a meaning in technology circles that I'm unaware of?
Turns out if you do skilled manual labor, the concepts translates. Bob was a bike mechanic. I don't know if he used the words, but he kept harping on us for not having our shit or tools together for a task ahead of time. When you're covered in grease is not a time to be digging for a wrench.
https://en.wikipedia.org/wiki/Mise_en_place
I think it also relates to operational professionalism and having your tools and toolbox in order ala Adam Savage and Jamie Hyneman from Mythbusters. They both had very interesting relationships with order, process and tooling.
I think structuring dev teams around a professional kitchen is really powerful model. All roles are critical, the sous chef, the busser, the prep cook, the dishwasher, everything.