The framework checklist[1] makes me think of Fulcro: https://fulcro.fulcrologic.com/. To a first approximation you could think of it like defining a GraphQL query alongside each of your UI components. When you load data for one component (e.g. a top-level page component), it combines its own query with the queries from its children UI components.

[1] https://overreacted.io/jsx-over-the-wire/#dans-async-ui-fram...

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?

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.

> 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.

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".

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

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().

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.

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

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