Have a look at how Phoenix(Elixir) does it with LiveView. You simply write everything as a server rendered view and the framework pulls things apart and sends just what changed over a web socket. Its mind blowing how fast it is (can be. Latency is real)

I have no doubt that this style of front-end management is going to be a game changer in the next few years. Of course full-on SPA frameworks will still have their place. But if you aren’t writing the next Google Maps clone, maybe you don’t need all that. It’s made me love web dev again after hating the complexity explosion of recent years.

https://m.youtube.com/watch?v=8xJzHq8ru0M

What worries me (I write Django, Rails, Phoenix web apps - different customers at the same time) is that I'll have to learn yet another three different ways to do the same thing. What I'm doing now is either creating HTML pages (the 3 ways are pretty much the same, Django a little bit more set apart) or a JSON backend (basically the same everywhere.)

But to be fair it's fear of the unknown: I read about all of these approaches but the only new project started with a SPA and the other ones will never move from backend generated HTML.

The concept is absolutely fantastic, I am very intrigued, thanks.

> API returning [...] HTML

The endpoints that return endpoints are not API endpoints, they are UI endpoints like `/index.html` or `/login` or `/Results.aspx?id=3984272`. Now you can have `/login/email` or `/login/google` and switch between them like <https://htmx.org/examples/tabs-hateoas/>.

As for the machine-consumed API, you have quite a few options. e.g.: The server that serves these resources may serve JSON to the same URLs through content negotiation, or the API may be separate, or you can have a generic API that is consumed by mobile app, desktop app and HTML-producing server (as opposed to JS app delivered by static file server or framework SSR).

The UI runs on the server, using REST to change client state over a stateless protocol similarly to how a React app may use Redux.

Not really, as long as you keep your HTML-driven interactions from becoming too fine grained.

For example, if you have a search page that provides management of contacts + active search & click to load functionality, it might look like this:

  GET /contacts - get a list of contacts + search & click-to-load functionality
  POST /contacts - create new
  GET /contacts/:id - get the details for the contact
  PATCH /contacts/:id - update the contact
  PUT /contacts/:id/archived - archive the contact
  DELETE /contacts/:id - remove the contact
  

All pretty reasonable and all can reuse the same few templates and sub-templates for rendering responses.

Thank you. To continue this conversation, how would one implement searching and filtering? My use case is an online ecommerce store (think amazon.com or newegg) where you sell multiple different categories of items. For example, if someone searches for SSD, we should show a list of checkboxes to filter by capacity such as 1 GB or below, up to 127GB, ... (based on inventory and other business requirements). How would I do that?

In your example, we can say something like if you could grab lists of by contacts by some common trait such as employer or domain of email address?

You'd have category pages with different filters. E.g. for the 'Storage' category you'd have, among others, the 'capacity' filter. HTMX doesn't take over your entire render like a SPA. It affects targeted areas of the page. E.g. when you would select the '<1GB' checkbox and click 'Filter' on the left panel, that's where HTMX would step in, to swap in the response of calling the 'search' endpoint with the current filter params, e.g. '/search/storage?capacity=<1GB'.

I think you can get pretty far by having good conventions and not over-thinking it, but remember also that this is all about being pragmatic instead of taking a one-size-fits-all approach — if you found yourself doing a _ton_ of highly-granular requests, that might be a clue that you're not in the sweet spot and an API client might be a better fit.

The trade-offs in terms of how granular to go will always exist -somewhere-, whether here, or in terms of react/etc. components, or template include directives.

I suspect 'template include directives, except with some client smarts' may be a good (approximate) model to use to initially get a mental feel for how stuff like htmx plays out in practice.

You can also render a full page and htmx to will intelligently update the current page where things match up.