Make it HTML over WebRTC data channels and then we're talking about something special--totally P2P decentralized web browsing. Beaker Browser is working on stuff like this: https://beakerbrowser.com/
The future of web software is HTML over WebSockets
21–30 of 337 posts
Re: The future of web software is HTML over WebSockets
#22Does anyone still use ASP.NET Web Forms?
Re: The future of web software is HTML over WebSockets
#23Everything 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.
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.
Re: The future of web software is HTML over WebSockets
#24We are heavy into REST and HATEOAS. This, coupled with React SPAs has worked really well for us. The HATEOAS client we use/build has an cache/event system that will emit to subscribers (via react hooks) when a resource is stale, and needs to be refreshed. After putting this all in place, I realized that now I just need the server to emit those 'stale' events via Websockets, and suddenly my SPA + API is a real-time mu…
Coming from a game networking side, why wouldn't you want to embrace a WebSockets world for everything? The upsides seem so incredibly intuitive for someone looking at it from the outside of traditional web development.
Scaling is almost always the answer.
Re: The future of web software is HTML over WebSockets
#25We are heavy into REST and HATEOAS. This, coupled with React SPAs has worked really well for us. The HATEOAS client we use/build has an cache/event system that will emit to subscribers (via react hooks) when a resource is stale, and needs to be refreshed. After putting this all in place, I realized that now I just need the server to emit those 'stale' events via Websockets, and suddenly my SPA + API is a real-time mu…
Coming from a game networking side, why wouldn't you want to embrace a WebSockets world for everything? The upsides seem so incredibly intuitive for someone looking at it from the outside of traditional web development.
[deleted]
Re: The future of web software is HTML over WebSockets
#26Another "The future of is what says it is" without much more than a few paragraphs of explanation. No diagrams. I don't see much of a comparison between costs/benefits of alternatives. Nice hypothetical. I didn't read it, because I've seen the format before and I'm getting a bit bored of it. Whereas if it cited some other engineers/technologists, some studies, some academics, etc., then perhaps I'd be more inclined t…
Well, it is an opinion piece
Re: The future of web software is HTML over WebSockets
#27We are heavy into REST and HATEOAS. This, coupled with React SPAs has worked really well for us. The HATEOAS client we use/build has an cache/event system that will emit to subscribers (via react hooks) when a resource is stale, and needs to be refreshed. After putting this all in place, I realized that now I just need the server to emit those 'stale' events via Websockets, and suddenly my SPA + API is a real-time mu…
Coming from a game networking side, why wouldn't you want to embrace a WebSockets world for everything? The upsides seem so incredibly intuitive for someone looking at it from the outside of traditional web development.
Traditional SQL databases aren't very streaming-friendly, so you more or less end up building an entire secondary push system just to figure out when to send what updates to who.
Re: The future of web software is HTML over WebSockets
#28Earlier quoted context omitted.
Coming from a game networking side, why wouldn't you want to embrace a WebSockets world for everything? The upsides seem so incredibly intuitive for someone looking at it from the outside of traditional web development.
Scaling is almost always the answer.
Scaling not just technically either, it's also the engineers. Most Web engineers have had their minds bent to the request response model with databases.
The key reason is that a game lasts... minutes to hours (ignoring most MMOs), so the state machine makes sense and the risk of failure low. Web devs have to use a database which has state for years.
Re: The future of web software is HTML over WebSockets
#29This seams really optimistic and kind of glosses over the subject of scaling out websocket connections apart from this. Anecdotally, the typical single Rails server process seems to be perfectly happy supporting nearly 4,000 active connections. And you can easily swap in the excellent AnyCable to bump that up to around 10,000+ connections per node by not relying on the built-in Ruby WebSocket server. That's not a lot…
Sure, it's server-side validation – which is great, and works well. And now it works without a full page submit and reload. That's a huge benefit.
Which you can do already for over a decade with AJAX.
Re: The future of web software is HTML over WebSockets
#30This seams really optimistic and kind of glosses over the subject of scaling out websocket connections apart from this. Anecdotally, the typical single Rails server process seems to be perfectly happy supporting nearly 4,000 active connections. And you can easily swap in the excellent AnyCable to bump that up to around 10,000+ connections per node by not relying on the built-in Ruby WebSocket server. That's not a lot…
Sure, it's server-side validation – which is great, and works well. And now it works without a full page submit and reload. That's a huge benefit.
Ever since xmlhttprequest (and even before that with images) we've been able to do server-side validation without a full page reload.
This "solution" completely ignores the purpose of client-side validation which is to a) reduce load on server-side resources, b) validate faster without the network latency and c) validate more securely and privately by not sending the content to the server.