That's a fair point.
But I think that the real point that /u/andersmurphy was trying to convey was that hypermedia is VERY performant because immensely talented C++ engineers have optimized precisely this, for decades. The notion that "frontend" devs have that the DOM can and must be managed via JS is simply ridiculous, and is one of the primary things that datastar and hypermedia approaches in general are trying to combat.
In fact, he openly states elsewhere how the sites' backends are actually done in a deliberately dumb, unperformant way, where the backend streams the ENTIRE DOM with each sse message, which gets morphed into the DOM. He could have done something more granular, like streaming only the checkboxes that have changed, but it wasn't at all necessary because the dumb way worked well.
Moreover, the SSE streams benefit from immense compression ratios because somehow the compression window overlaps across messages. Something like 95+%, IIRC.
> The notion that "frontend" devs have that the DOM can and must be managed via JS is simply ridiculous
The idea that UI state should be managed locally is ridiculous now?
Its interesting, and telling, that that's the only part of my comment that you replied to...
Anyway, browsers are built specifically to render HTML. And html/hypermedia is specifically meant to manage and transfer state. The web has lost its way. If you want to read more about this, this free book is a great start: https://hypermedia.systems/book/contents/
Or the essays at HTMX https://htmx.org/essays/
Good luck to you
I don’t feel the rest was really worth engaging with. SSE is a really interesting technology but again, it’s frontend agnostic. You can build a great SSE solution with any other framework.
I read about approaches like this and I still don’t see the reason to do them, beyond “because you can” and “JavaScript is bad”. The separation of data and display logic between server and client is a sensible separation of concerns. It’s the way any non-web solution does it and I don’t really see what would make the web so special that a different approach is worth it.
The entire point of frameworks is so that you dont have to engage with lower level things... D* makes it exceptionally easy to work with SSE and all sorts of web APIs.
that's fine that you dont see any reason to use the web as it was designed to be used. But I dont see any reason for me to engage any further with you.
You do it to reduce complexity.
The problem with JS heavy frontend is you now have TWO applications. The real application, on the backend, which makes all the decisions, and the frontend application.
You have TWO states which are being mutated independently that you now have to sync.
reducing complexity is important but is hardly the fundamental reason to choose between server side or client side rendering or state management. that just depends on the nature of the problem and the context it has to be solved in. sometimes it doesn't matter, then you have a choice.
you guys are furiously arguing (and not really listening) about this or that hammer being good enough to treat every problem as a nail, like ssr was the "holy hammer". well, it isn't and not every problem is a nail, and while datastar looks excellent to me i simply would have no use for it if i needed client side logic or state for whatever reason.
I agree, but the kicker is that most websites can be server side rendered trivially. Most web "apps" are not applications. They are forms and pages.
The client side logic is, usually, just to make the developers happy because developers love complexity.
Obviously there are many exceptions. But not every application is exceptional. We all hate to admit we're working on simple or trivial things but... We are. Often.
Why? What's stopping you putting some state on the client with datastar. Just because it's discouraged doesn't mean you can't.
It has a whole client side signal system.
interesting! i wasn't aware of that, thanks for pointing it out.
to be clear, my point was that where the state has to be managed is more often than not an architectural decision given by the requirements, and the choice of tools should be a consequence of that, not a precondition.