appreciate that. ive been given the progressive enhancement spiel a few times. its obviously a judgement call that will be the right call for some people. but i think many people underestimate how requirements grow over time because our UI standards have gone up over time, even for basic sites that you dont traditionally think of as SPAs. data drives everything, you want your UI to be a function of data.

for the other stuff, the growing browser stdlib has basically replaced most of jquery's usecases. so (in the most non condescending or negative way possible) htmx occupies a very awkward sliver between "The Platform" and Frameworkland and after giving it some time I have yet to see the benefit from keeping any of it in my head

I'm obviously in the minority, but I breathe a sigh of relief every time I encounter a website that works workout JS, don't hijack basic browser functionality, don't make dozens of AJAX requests in the background, and overall just focuses on presenting the data I want.

I don't think you are in the minority.

At all.

Every time web sites reimplement basic browser behavior, which they invariably do these days, they get worse, often significantly, because they never get it right.

> i think many people underestimate how requirements grow over time because our UI standards have gone up over time

I think you are overestimating how much 'UI standards' have gone up over time, actually. Nobody except for a small 'extremely online' set of people and control-freak designers care about all those complex UI/UX requirements. Users certainly don't care. They want fast-loading, responsive pages that get out of the way and don't drain their batteries or clog up their connection.

The other thing here is that approximately no one can actually tackle the complexity introduced by SPA frameworks and 'UI standards', and it's far more likely that they bungle it up and make giant, wasteful, UX pitfall-ridden apps. With server rendered pages, plain old HTML, and progressive enhancement, we at least have a better chance of producing something usable.

> You can then optionally send less HTML by just sending the parts that you expect to have actually changed, your "islands".

And then you end up with modern SSR frameworks that do the bookkeeping for you.

yes but mostly the island architecture is only dominant in the javascript world

we can basically get the benefits of spa without having to learn js / use minimal js using htmx in some sense

https://github.com/donseba/go-htmx check this out

If you render HTML on the client you still have to render a transport format (usually JSON) on the server side. Sending HTML just lets you skip the transport format and the client side rendering.

And letting your framework do the bookkeeping for you lets you skip the whole issue. I don't know the exact specification of React Server Component Payload, but I know that it somehow changes stuff on the client-side when the client interacts with the server. (It sends something like `["$","p",null,{"children":["a child","another child"]}]`)

It's still one server side template, you just render different parts depending on what is calling it. By default render a full page, if you want to get precious about a few dozen KB from sending a full page over the wire you can toggle some blocks off.