I also am baffled by the return to server side rendering as the new thing. It’s like people forgot that’s how it used to be.

I’m sure they’ll claim it’s different now because… hydration or something or another.

As a former PHP developer who spent a lot of time both working on server rendered pages and converting server rendered pages to be API/JS (render the core in HTML+JS and use APIs with two way data binding to update the UI), I can’t believe we’re going back that way, but with wildly more complicated patterns than we had before.

Yeah, I've witnessed the entire arc also as an ex-ex-ex PHP developer from the early 00s, and I literally recall the original justification for this whole exodus that lead to the creation of React and a slew of other things was "jquery bad".

I just wish we had skipped all the in-between stuff and just arrived at htmx back in 2011 instead of now. Maybe I'd still be doing frontend stuff and not burying my head as far into backend as humanly possible while I wait for a workflow that doesn't require a package.json and a 3 GB node_modules folder so I can make the same frontend widget I could make with 50 lines of js in 2007.

> I just wish we had skipped all the in-between stuff and just arrived at htmx back in 2011 instead of now.

We kind of did (well, 2013), but it just wasn't backed by a massive developer marketing effort.

I started in 2010 with Java and JSP and initially thought the same thing. But after reading more about it, I see it as like foldable phones. We’re back to using foldable phones, but it’s totally different than before.

Also, I recall heavily using jQuery and Ajax to update parts of the page before Spa’s came along.

SSR is different I think because it can perform better, but given the state of most sites on the internet I think 2003 style rails is sufficient for most sites. And I haven’t met a JS-ey UI I have enjoyed using as much as a vanilla HTML one for most online stuff (drawing, games, 3D etc. excepted).

The RSC stuff seems to just add a vast amount of complexity with little benefit.

It feels like the end state here is going to be HTML+CSS with JS for interactivity using APIs, which is exactly what I was doing in 2006.

And turbolinks on modern rails apps literally feels like those fancy JS-ey UIs anyway in terms of responsiveness. Not to mention things like phoenix liveview..

Did you have a look at SvelteKit? It does that "hydration" magic, first page loads completely from server, then it can work like a SPA, only fetching required data.

It’s all JS, which we know from the frontend, all that "magic" is done by the framework in the background. You write it once, it works both ways automatically.

We already build 3 webapps using SvelteKit, still happy for the ease of use, or great "DX" as some call it.

> I also am baffled by the return to server side rendering as the new thing. It’s like people forgot that’s how it used to be.

People want that back, but they also like React, and their existing component libraries, and they want to generate the backend pages with React. It's not that strange.

And you can (I think) pretty seamlessly have part of the page rendered on the server, and parts still function on the client.

Yea but why do I need to use React for that?

Is it because these devs can only do React and nothing else, so we will shoehorn everything into it?

I mean, more power to them, if they want to do it and have 10x the complexity and take 10x longer than learning and using normal, already available tools.

> I mean, more power to them, if they want to do it and have 10x the complexity and take 10x longer

The server side components didn't seem to me at a glance significantly less convenient then say a normal PHP server stack.

React and Server Components are also normal, available tools.

To clarify, I mean other server side tools that have been available a long time and had bugs ironed out. React Server stuff just came out recently, and still has a long way to go i guess.

How much experience do you have with RSC and Next.js?

I remember writing PHP and JSF back in the 90s and 00s, and the experience of both writing RSC and Next.js as well as using websites built with these technologies is simply not comparable.

No we didn't come full circle. I always wanted a server side rendered SPA where the server template is the same as the client template. With PHP/JSP you have to switch context to say jQuery for interactivity. With an SSR rendered React SPA you continue where you left as the page gets hydrated.

I think there is a difference this time round and it isn't just to do with where the pages are rendered. There's a yearning for simplicity. In days of yore, "simple" SSR (eg JSP, ASP, etc) came with a selection of "helpful" design patterns and frameworks (Struts, Stripe et al) that all added to the complexity, not reduced it.

Modern SSR implies just do simple rendering on the server and hook it up with simple tools like Htmx, Turbolinks, etc.

Keep the complexity accessible on the outside, like the Pompidou Centre.