[Dangeranger]

I would like to see web apps move in the direction of server-side rendered static pages on initial load, and then progressively hydrate the app with data from the back-end on demand.

Rails does this surprisingly well using Stimulus with web sockets to mediate the exchange of events and data between the client and server layers.

Similar strategies are used in Phoenix Live View apps.

Load static markup and data -> request more data if you need -> send events and data to the server -> respond with the new state to display if different than the client’s version.

[evilduck]

At the risk of sounding rude, what you're describing has been the status quo for data-heavy SPA scenarios for a couple years. NextJS, NuxtJS, Angular Universal, Gatsby, they all allow you to preload data into a server side render and then let the client side JS take over on demand.

[cutler]

Have you actually had a look at Rails 7 with Turbo? It's nothing like what you're describing with NextJS etc. in that it aims to keep Javascript to an absolute minimum.

[evilduck]

Yes, they’re sending HTML chunks over the wire. It’s the same end result though, except you’re still not exempted from learning JS.

[cutler]

It puts rendering back on the server where it belongs. The JS is minimal.

[evilduck]

I’ve seen garbage and exemplary sites produced with both methods. Rendering HTML with data hydrated server side and assembling it with a library client side vs rendering JSON and generating the HTML client side is a weird religious stance to take.

[a5aAqU]

Some of the jamstack frameworks like Gatsby do this. They turn into SPAs after the first page of pre-rendered HTML is served.