[Tade0]

> SvelteKit/NuxtJS/NextJS are literally reinventing server side rendering for the client to then call the actual server to get data ... to render HTML.

It's all done in one call - at least in Svelte. You can even render all this into a fully static site.

Meanwhile htmx and the like is the same idea that was popular 15-ish years ago, which died for good reasons.

[recursivedoubts]

the reason it, that is the idea of hypermedia, died was because you weren't able to achieve the same level of interactivity as you could with javascript-based applications, even back in 2005

this was due to the fact that HTML stopped advancing as a hypermedia, as I say in my original comment

htmx and other libraries are attempting to address that by pushing HTML forward as a hypermedia, which allows you to implement more sophisticated user interfaces purely in hypermedia terms:

https://htmx.org/examples/

the hypermedia idea itself is extremely innovative and interesting and, at some level, today's javascript applications are new iterations of an even older idea: client-server based RPC applications, as we built back in the 1980s

[DeathArrow]

>the reason it, that is the idea of hypermedia, died was because you weren't able to achieve the same level of interactivity as you could with javascript-based applications, even back in 2005

But I neither want nor need much interactivity in Web sites. Interactivity is for applications and applications are much better on desktop or mobile than on the Web.

[codethief]

> HTML stopped advancing as a hypermedia

Nitpick: "media" is plural. The singular is "medium".

[cassepipe]

Curious about those good reasons. Care to elaborate ?

[Tade0]

The chief reason was organisational - you needed full-stack developers for just about anything and they had to specialize in your stack - especially the language used on the backend.

While there's no shortage of frameworks on the frontend, it's all still JS/TS, so everyone is using the same idioms.

Other problems:

1. 1:1 mapping of endpoints to presentation. Common cases where this blows up:

A. A list of items which looks different depending on the context or has different styles of presentation switchable via buttons.

B. Two or more different data sources, combined in different ways.

Now you need endpoints for each context(A) or combination(B), which makes a mess in your cache. You also send way more data this way - especially if your users tend to fidget(A).

2. Inherently slow. You either replace whole parts of the DOM - which triggers a massive reflow or you make smaller changes by comparing new and old HTML in which case you need to parse both versions and deduce what changed and how.

Unfortunately since this is all just HTML you don't have object references to the data that was used, so you can't employ some of the neat performance tricks modern frameworks use, like detecting a row swap.

3. HTML elements with state, e.g. a canvas, video/audio, file upload input or even a textarea with a selection. You have to store this state somewhere, but sometimes (like with a "tainted" canvas) you can't access it at all due to security reasons, so now you have to cut around it when you're updating.

Selection is especially a piece of work, because browser implementations differ significantly to this day.

[malloryerik]

Maybe what was a "good reason" 15 years ago isn't anymore, namely the lack in those days of WebSockets and, if I'm correct, widespread Server Sent Events?

[seydor]

I don't think the reasons were good