> but I don't really see what sending HTML over the wire instead of JSON gets us?

HTML you can render as-is. JSON needs additional processing logic client-side.

Sure, but with HTML all I can do is render it. With a well designed JSON API I can wrangle and mangle it and use the same data in many places or different apps even.

Yep. In some cases it might be better to keep a local representation of the data and have different view and business logic all on the client to create a presentation & interaction experience for the user.

Other times, centralizing it on the server might be best.

Some apps lend themselves much more to doing a lot of interesting work on the client (Figma is an example, going so far as to implementing their own rendering engine, for instance).

You can wrangle and mangle the original data much better than whatever JSON you decided to send. And you can make different apps with your database too.

Here's a pretty good essay by Max Chernyak on why using a generic JSON api to power your application's front end is a bad idea. https://max.engineer/server-informed-ui

tl;dr:

Your JSON api has to figure out:

- How to predict and enable all possible workflows

- How to avoid N+1 requests for awkward workflows

- How to test functionality, performance, and security of every possible request

- How to change the API without breaking the existing workflows

- How to prioritize API changes between internal and community requirements

- How to document everything so that all parties can get stuff done

And on then on the front-end, you have to figure out:

- How to collect all the data needed to render a page

- How to optimize requests to multiple endpoints

- How to avoid using API data fields in unintended ways

- How to weigh the benefit of new features against the cost of new API requests

He goes on to point out that the "re-use" value of an api endpoint is extremely low. You can re-use virtually all the code that produced that endpoint to produce a different one with a different structure for precisely what you need in this new use-case.

The way around this is to have a layered approach in the backend. A business logic layer which generates some data, presumably structured in whatever way is canonical for the language you use.

Then add a layer on top of that that 'renders' the same structure into multiple formats: JSON or HTML as needed.

Expose each of these view layers as a different endpoint in your service.

The author of htmx has a lot of material on this topic: https://htmx.org/essays/

Thanks for reminding me of that page. I remember already having seen it, the memes at the bottom are hilarious, maybe I should read the essays too.

> but I don't really see what sending HTML over the wire instead of JSON gets us?

REST, instead of what we decided to start calling REST

To be fair, we already have a name for the Web, we don't need REST too for the same thing.

No definition of the Web and REST are the same.

For one thing, at one point or another you need to render HTML, why not render it once instead of rendering to json, then parsing the json to render again to html.

Also, sending json means you either need type information in two apps, OR you build without strict types in one of the ends. Either way it's more work or less resilience.

These are just two examples that focus on DX.

Another set of tradeoffs that we used to think JSON over the wire would mitigate. They, of course, brought their own tradeoffs.

Case in point for partial HTML updates: you update the backend in such a way that HTML it sends is no longer compatible with the frontends running in the browsers.

(You won’t believe how long can a page be open without a refresh.)

The naive tldr:

Render the HTML server side instead of client side, then the client is only doing DOM updates.

Client side updates via livewire type tech, or even more crazy - we might be at the time where websockets can now be used for what they were meant for.

The "JS problem" is two sided: (1) we need JS (well, not anymore, there's WASM now too), and (2) many devs do not like the DX of JS (me included).

This project, if anything, follows a JS-on-backend-and-frontend and thus is more of a promotion of JS-everywhere than a way to "get rid of it".

Simpler can be better than a more unnecessarily complex stack that could be added later anyways