The problem a lot of developers have with SPA is that they literally shove the entire app into 1 page load. Which is where most of their problems come from. If you use a hybrid approach. Have the data you need to show the page right away cached in the html and then load any other data after while that page is being used. And you break the app up into multiple pages. It works perfectly fine. It actually makes it super easy to hand out work to a team of devs and minimizes stepping on each other.
The future of web software is HTML over WebSockets
51–60 of 337 posts
Re: The future of web software is HTML over WebSockets
#52I 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.
Isn't HTTP/2 SSE being deprecated?
Re: The future of web software is HTML over WebSockets
#53Earlier quoted context omitted.
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.
Isn't HTTP/2 SSE being deprecated?
I sure hope not. Are you thinking of HTTP/2 server push?
Re: The future of web software is HTML over WebSockets
#54As an alternative that still relies on REST instead of web sockets is intercooler.js. It's a nice little framework for annotating html to give it more power. This little library seemed to have some buzz at the time it was first released, but I haven't seen it brought up in years. I decided to look it up and Intercooler is still supported, but there is a successor now called htmx. I have not shipped anything with eith…
htmx is great, it's come up a few times on HN and has good commentary. There's a small set of web folks that look at all the ridiculous complexities of react, virtual DOM, etc. and nope right out back to good old server side rendering. htmx is perfect for primarily server rendered stuff. And ironically, now we see react going full circle back to investigate a server side approach with their recent react server component experiments.
Re: The future of web software is HTML over WebSockets
#55We 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.
Mostly just the intuitiveness of the architecture. I don't need bi-directional if I'm mostly just showing you some forms in a CRUD app, and client-initiated request/response is simpler to reason about.
Bi-directional gives you more power, but you also have to think harder about the protocol and application state once the server is also pushing events to the client unprompted.
Re: The future of web software is HTML over WebSockets
#56I 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.
Why do you require a reverse proxy, and are those requirements unique to SSE for some reason?
I guess I'm not seeing what the alternative setup would be, even with WebSockets.
Re: The future of web software is HTML over WebSockets
#57Earlier quoted context omitted.
Well, it is an opinion piece
Clearly I arrive at this piece without the expectation of it defining the future-- I know better than to expect a pop tech piece to deliver to me a view of the future. format: blatantly unoriginal content: not persuasive, underdeveloped effort: very low value: very low "The future of" is a very bold statement. The more cliche it becomes, the more I expect an author to actually outline, in a bold, cohesive, relatively…
But he could be right
Why does it annoy you so much?
Re: The future of web software is HTML over WebSockets
#58Earlier quoted context omitted.
You just described http2
Wait, with http2 a webbrowser never closes the connection it has to a webserver?
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).
Re: The future of web software is HTML over WebSockets
#59Earlier quoted context omitted.
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 co…
You can't scale without delegating. And in a crunch is not the time to work out procedures. You do that between. Yeah, it's not a bad model, and you can stretch it pretty far until it breaks.
Re: The future of web software is HTML over WebSockets
#60I have a brilliant idea, why not HTML over plain sockets?
To a local server running in a Wasm env? Yes please!
And by local, I mean running in the same page.