:quality(85)/https://andros.dev/media/thumbnails/kier-in-sight-archives-Sbxf5Dbyerk-unsplash.jpg)
Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- > Simple, elegant and fast.
Until someone bombs your websocket server and you then have nothing at all.
by doublerabbit - > that loose back-and-forth over HTTP weighs more than an always-open WebSocket
This is definitely true for HTTP/0 and /1. Is it still true under HTTP/3, or has the underlying ‘single conduit, many channels’ model improved things if used correctly?
by altairprime - Absolutely not, even on HTTP1.1.
Our webapp is achieving 800:1 to 5000:1 compression ratios pushing down the entire HTML page over brotli and zstd. The first render is about 20:1 compression, every interaction after that is 800-5000:1.
We are using datastar with the recommended "fat morph" approach where we re-render the entire HTML page from scratch on every request. Our typical RTT is <100ms including rendering, then the brotli / zstd compression window cuts down the wire size to literally _bytes_.
This is SO much more efficient than our previous reactjs & graphql render waterfalls with state duplication in the client side. All states lives on the server, all renders are authoritative, and we need to maintain roughly half the code size for better first-render and massively better interactive performance. Appserver and DB pressure is massively reduced too.
(This is a medical device with a highly interactive UI, image viewers, editors, not a boring old static website.)
by Aeolos - Just wanted to mention that in PHP besides Laravel Livewire there's also Symfony Live Components[0]
[0] https://symfony.com/bundles/ux-live-component/current/index....
by conradfr - Livewire existing and working so much simpler than the status quo really deserves attention.by j45
- Something else that I think is interesting here is the new HTML streaming APIs in Chrome: https://developer.chrome.com/blog/declarative-partial-update...
These mean that you can for example have a websocket serve just the new HTML, and then let native browser code figure out inserting it into the DOM, without any dependency. I’m guessing things like LiveView could eventually migrate to this if it becomes standard, and eliminate more of their JS bundle.
by mcintyre1994 - > Place the HTML where it belongs
Well, some drawbacks are not accounted for when replacing HTML parts: input elements lose focus, if some view was scrolled, then it gets unscrolled, jumping under user's pointer etc.
by deepsun - I don't recall encountering these issues. What framework was that on?by cmoski
- things like datastar handle this automatically for youby sudodevnull
- Love how DHTML, ASP.NET Ajax, JSF Ajax kind of keeps being re-invented.by pjmlp
- Exactly dear Lord we went the spa route for a reasonby noopydoopy
- Indeed, “The initial learning curve is steeper than dropping in a <script>”. Maybe for you, but I was doing that basic thing in a mix of Django around 2010. It was getting away from traditional form POST and reload the page while still taking advantage of Django’s templating system. I keep trying to find the best answer to this approach across the things available as it feels like it would make vibe coding easier to manage and understand as well.by tclancy
- I like the Vue/React/Svelte model of the DOM being a function of the data. For example, in a shopping cart, I add two chocolates, the number against the chocolate, the count at top and a banner encouraging me to reach X total all center around a data structure.
I use Django Ninja, Zod, InertiaJS+Vue and its as easy as using Django's templating engine, but static typing ensures my view doesnt emit unrepresentable data, my TS doesnt accept unrepresentable data, Vue+TS dont allow logic errors in template. AI makes it effortless. Again, the loaded page is a function of the data supplied at the view.
With HTMX, I'm writing several server-side functions to mutate the DOM imperatively and using HTML attributes to call them. Its great for forms but that shopping cart example needs code scattered across multiple functions and templates.
by aitchnyu - Yes I don’t see the appeal of HTMX in most cases. Vuejs has less footguns than React, and LLMs can produce it decently well to at least get started and then refactor.
- > With HTMX, I'm writing several server-side functions to mutate the DOM imperatively and using HTML attributes to call them. Its great for forms but that shopping cart example needs code scattered across multiple functions and templates.
That's a weird way to use htmx. I've built a number of large apps with htmx over the last few years and never done this. Seems a great way to have a bad time.
by wild_egg - A lot of the people who oppose this technique don't understand context: The right solution to your problem often involves understanding the problem you're trying to solve!
In my case, I work on two Blazor websites: One is standard in-browser WASM with Restful JSON (and some CSV) over http; the other is server-side Blazor that uses the websocket technique that this article describes.
The server-side Blazor approach is for an internal web application that has a lot of quick-and-dirty pages that replace what used to be ad-hoc database queries and ad-hoc scripts. It's not an "industrial strength" web application that requires high scalability, because it's only a handful of employees who use it. It's also a joy to work with. To be specific, we don't need to go through the exercise of designing an API, making sure that contracts serialize, ect, ect, just to slap a UI around what used to be a script.
The WASM page that uses Restful JSON (and csv) is our customer-facing web application: JSON (and CSV) help with debugging; but the cost of making an API is very high. Development on the customer-facing web site moves much more slowly, but it's "worth it" for an industrial-strength site.
Would I build a highly scalable website using HTML over a websocket? Maybe. The issue is time to market: Because you don't have to build an API, you can move faster; but I don't know if scalability issues will arise.
by gwbas1c - I also use blazor server for internal web apps. It is fun to work with and development is quick for a C# dev.by avgDev
- Which kind of proves the point I made elsewhere about ASP.NET Ajax, as Blazor in spirit is a kind of WebForms 2.0/Silverlight.by pjmlp
- Close but htmx with SSE and dom swaps and morphing gets you there without reinventing any wheels.
Pretty much every web app I build has this pattern in it from day 1, as they all quickly expand to have a realtime inbox and notifications subsystem to support workflows and agents.
by nzoschke - HTMX only does GET, doesn't to expo backoff, etc. Let alone the fact you need more extensions. Try it before claiming victory maybe?by sudodevnull
- now check out datastar for a smaller, faster, more extensible, more powerful version of thatby nchmy
- A good response to this postby nchmy
- God damnby whitemoonx
- Definitely a well reasoned counter point to choosing websockets over SSE.by pseudosavant
- Excellent article. More compelling than TFA being discussed. Thanks for sharing!by chrisweekly
- The soap opera continues here: https://en.andros.dev/blog/bd74e61a/were-fighting-over-the-w...by andros
- Funny he mentioned Chris McCord as the originator of this technique with Liveview. The reality however predates that with Sync in Rails that you guessed it... was also Chris McCord's doing. Rails at the time didn't have the capacity to handle it so it was just a tech demo then and a big reason why Chris McCord moved to Phoenix. He was once a prolific Rails developer. That guy is helping the web move forward.by xutopia
- Was predated by Microsoft with web forms.by noopydoopy
- We were also doing this at Booking.com many years earlier, using morphdom and custom templating libraries. I think I wrote the first version in 2014-2015.by ricardobeat
- > The quick rule: if you need bidirectional, low-latency communication (chat, collaboration, games), WebSocket; if you only push from the server, SSE is simpler and cheaper to operate.
For most apps just use SSE and the built-in code for making HTTP requests (Fetch) instead of hacking up your own client side JS to make requests over a WebSocket. The latency is the same because modern browsers multiplex HTTP requests over a single TCP connection that is left open.
Maybe if you are making many client requests per second there is an advantage to not sending full headers/cookies/etc... on each request but not if you're sending requests in response to user clicks/touches.
Any sufficiently complicated SPA contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Fetch.