Yes, another case of old school web dev making a comeback. “HTML over the wire” is basically server-rendered templates (php, erb, ejs, jinja), sent asynchronously as structured data and interpreted by React to render the component tree.

What’s being done here isn’t entirely new. Turbo/Hotwire [1], Phoenix LiveView, even Facebook’s old Async XHP explored similar patterns. The twist is using JSX to define the component tree server-side and send it as JSON, so the view model logic and UI live in the same place. Feels new, but super familiar, even going back to CGI days.

[1] https://hotwired.dev

Reading the linked article https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi... , does this mean Next.js is the real REST?

I still can't get over how the "API" in "REST API" apparently originally meant "a website".

There is a part of my brain that is intrigued by React Server Components. I kinda get it.

And yet, I see nothing but confusion around this topic. For two years now. I see Next.js shipping foot guns, I see docs on these rendering modes almost as long as those covering all of Django, and I see blog lengthy blog posts like this.

When the majority of problems can be solved with Django, why tie yourself in to knots like this? At what point is it worth it?

> Since XHP executes on a server that emits HTML, the most that you can do relatively seamlessly is to replace parts of an existing markup with the newly generated HTML markup from the server by updating innerHTML of some DOM node.

It’s a very long post so maybe I missed it, but does Dan ever address morphdom and its descendants? I feel like that’s a very relevant point in the design space explored in the article.

I skimmed over this and imho it would be better to cut like 30% of the exposition and split it up into a series of articles tackling each style separately. Just my 2c.

I always come back to the idea that I want to render HTML where the state lives rather than shipping both a rendering engine and all the necessary data to a client.

In most cases that means rendering HTML on the server, where most of the data lives, and using a handful of small components in the frontend for state that never goes to the backend.

IMO:

1: APIs should return JSON because endpoints do often get reused throughout an application.

2: it really is super easy to get the JSON into client side HTML with JSX

3: APIs should not return everything needed for a component, APIs should return one thing only. Makes back and front end more simple and flexible and honestly who cares about the extra network requests

Really appreciate the quality you put into expressing these things. It was nice just to see a well laid-out justification of how trying to tie a frontend to a backend can get messy quickly. I'm definitely going to remember the "ungrounded abstraction" as a useful concept here.

I've represented JSX/the component hierarchy as JSON for CMS composition of React components. If you think of props as CMS inputs and children as nesting components then all the CMS/backend has to do is return the JSON representation and the frontend only needs to loop over it with React.createElement().

It reminds me of when I sent HTML back from my Java Servlets.

It's exciting to see server side rendering come back around.