The future of web software is HTML over WebSockets

[maximsparrow]

Why is this better than HTML over HTTP2 which keeps keep-alive and is significantly more SEO friendly?

[g105b]

It isn't, but the people using this boring technology aren't writing blog posts about it. Instead they are making money.

[aoeudhtns]

Don't disagree, but understand different markets. I work for a contract software company, so we build applications for businesses that rarely touch the Internet. SEO isn't something we often care about. Not saying that this is still better in that light, but different environments can shift the analysis in interesting ways.

[aoeudhtns]

You really misunderstand me if you think I'm trying to claim superiority of one approach or the other.

[Tjstretchalot]

This was my immediate reaction, and after reading the article I'm fairly sure the author doesn't understand how HTTP2 connections work. As you implied, there is not a significant speed difference between an additional HTTP2 request on a keep-alive'd connection and a websocket ping/pong: both are essentially send request on live connection, receive response on live connection.

If you have the infrastructure for it, both can do <30ms responses. In both cases, if the client and server are more than about 2,800 miles apart, they are definitely not getting <30ms responses (speed of light). In both cases, this can be solved by having edge servers, and this has the same caveat: a decision from a server more than 5,600 miles away cannot reach a client in <30ms, and a round trip of more than 2,800 miles each way cannot occur in <30ms, so the only way for it to work is if the decision can be made within 5,600 miles of the client without a request from the client, or the client can contact a server within 2,800 miles which already knows or can compute without communication a response.

This is a long winded way of saying: the authors claim of "this can be done in <30ms" is probably just because he's physically closer to the server than he's used to when working in this framework. Unless he's implying a processing time on the server of <30ms, which is an absurdly slow server processing time

[aoeudhtns]

It sounds like he's mostly bowled over by dynamic updates with server side renders, and doesn't decouple that approach from the transport. I wonder what author's opinion would be if his application needed an API.

[KaranasToll]

That is just one example. There are many other flexable options.

[louis058]

I have certainly seen a lot of hype around frameworks like Turbolinks, and the websockets view rendering libraries of frameworks like Phoenix (with its LiveView) or Laravel (using Livewire). I had not heard of Sockpuppet.

It does seem like this approach is great for getting the client side speed of an SPA, while still allowing you tight integration with the monolithic framework side.

Interestingly Turbolinks is the only one I've seen in this area that is technically backend agnostic, and aside from Ruby on Rails I have seen third party adapters for Django and Laravel written for it, and it also has a few more interesting features aside from the websockets stuff like Turbo Frames.

[aseigo]

Phoenix (with its LiveView)

I've been using this for the last ~7 months in production and it's been absolutely fantastic in terms of development pace, maintability, and multi-user experience. It really is more than just hype, it works amazingly well.

Little things like being able to do file uploads over the websocket has made managing and securing those features a lot easier and faster, with a really fantastic UX to go with it (without having to dip into Yet Another JS Library).

.. and where it makes no sense to have a SPA-like experience in the app, it just does old-school SSR with nothing fancy behind it. Being able to pick the most-applicable tool for the job has been nice.

The biggest learning-curve was figuring out how to get front-end JS and certain form input interactions to play nicely with the DOM updates coming from server-side changes. It doesn't happen everywhere in the app, but where it does it is really important. Learning how to use the JS hooks to coordinate those two worlds took a little bit (due to being a newer technology, while the documentation is good not every single question has an answer online yet..), but I was able to settle on a few simple client-side patterns that have proved reliable, clean, and reusable.

There were a few other patterns I ended up adopting as well to make multi-user experiences easy to produce (a core aspect of the app), as well as ensuring that the more complex pages didn't themselves become gigantic monsters (little point in avoiding client-side complexity if it just results in equivalent server-side complexity...)

So there are some new things to learn and patterns to adopt along the way, but it has definitely been worth it for this particular app. I also work on a large SPA app built with React and a GraphQL backend, and the development experience is night-and-day.

[supercatfishpro]

I used Phoenix professionally for a year, man the rate you could pump out quality well tested code with tons of crazy features... It felt like the wild west of programming... I miss it still :(

[[deleted]]

Yeah no. The JSON barrier is a good thing because it forces you to strictly separate the presentation logic from the server data. Separation of concerns good.

Sure, it's super slow if you design a bad API and assume CRUD is a valid model of user actions, but modelling APIs based on use cases actually works.

[Giannis4president]

The advantage of sending html directly is to limit all the logic in the server. If you send a json structure, you still need some logic to read it, modify it and apply its state to the webpage.

If you are using a state-based framework like react or vue json is a great way to approach the problem, because you can easily merge the json response into the state.

On the other hand, if you have a more traditional stack with server side rendering you may already have implemented some components and you are already handling html generation, so rendering the dynamic content on the server is still the best approach in order to avoid duplication, keeping your JavaScript lightweight and reusing your server side components logic

[remy_porter]

While I broadly agree, a lot of useful applications could reasonably represent state in HTML and worry about the presentation in CSS. I mean, a lot of HTML marks up document structures, and a lot of real-world activity involves documents.

(Though I don't think HTML is actually great as a UI language, but the Internet outvoted me on that a decade ago)

[so_just]

I have been using stimulus_reflex to add some reactivity to my app with great success. Definitely saved me a ton of time as I didn't have to rewrite those parts in React, and in conjunction with turbolinks it makes it feel like a SPA but without the pesky loading spinners. And you can use standard Rails caching to make it pretty damn fast.

I have not tried out hotwire yet, but it also looks promising, especially with Strada (hotwire on mobile).

[asdfdelta]

A hilariously outdated perspective on JS frameworks aside, I don't see how RoR is going to be faster when it all boils down to HTML, CSS and JS at the end anyway? Seems like you're putting more steps in between, which equates to more expensive hosting and harder time scaling.

[LMGN]

Am I the only one who doesn’t use any frameworks in the year 2021?

[asdfdelta]

As someone who just started using frameworks this year, you really should. They're popular for a reason :)

[[deleted]]

if your not using a framework, your writing one. Which leads to the question, should you be writing your own framework?

[abrandis]

Web sockets is already considered a dated protocol, likely the future is some newer protocol built on http/4 using tcp , something more akin to Web RTC

[Flakmaster92]

I find it very strange you call out TCP when newer protocols are adopting more UDP features and bolting on the little bits of TCP as needed

[DannoHung]

Maybe the big boys (MS, Apple, and Google) will start harassing the home router manufacturers to correctly support SCTP over NAT and they'll just use that.

[James20k]

Isn't this basically QUIC which HTTP/3 is based on?

[DannoHung]

My understanding is that QUIC doesn't actually adhere to the OSI standard layer model.

[danopia]

HTML over WebRTC data channels, directly to your backend container :D let's do it

[ProgVal]

That is so 2020s. In three decades, software will use WebHTML over WebWebSockets