Ooh this looks interesting. I feel like I've re-invented totally half-arsed versions of this a few times because the json api approach just didn't sit right with me, but I've never had the vocabulary to clearly state why and what the alternative could/should be.
Some shortcomings in larger Projects that maybe my imaginary problems:
- You cannot have reusable components. If you want that, you need to combine server side templating.
- Because rendering HTML is OK and HTML is the UI, if not disciplined enough, your app would be generating shards and shreds of application UI that are highly contextual and not as repeatable or reusable.
- A client other than browser can't consume HTML as easily such as a cron job or Flutter/Android/iOS app .
But other than that, I think htmx is innovative enough that it should be part of the browser natively.
> A client other than browser can't consume HTML as easily such as a cron job or Flutter/Android/iOS app
what you do is to return a json representation of the data if the 'Accept' header is json from the client (which, you control or can direct them to send right?).
this is actually less complex than the "standard" react frontend frameworks to produce a UI imho.
This is basically the good old days of server side rendering, and html fragments, and you'd used to use jquery to just wholesale replace portions of the dom with the returned value from the server via an ajax request.
it's always less complex when you look at a toy example. Then you get more complex requirements that make the html templates unmanagable or even impossible in html. Then you have to drop some javascript anyway, then more and more of them. Then you wonder why cling on to the futile effort of "programming" in html anyway.
There have been many cycles of doing "everything on the server", then "everything on the client", and back again. Right now, it's swinging back to the doing everything on the server. First it was mainframes, then PCs, then Citrix, then laptops, HTML, client-side rendering, server-side rendering, etc...
Server-side rendering has a huge advantage though: it needs one less "layer". With client-side rendering you have code in the browser, code on the server, and code in the database. You need defined protocols between every layer. With three layers and two hops, that's effectively 5 things you need to develop.
With HTML-based development, the client side code basically doesn't exist any more. You don't need to send the browser JSON via an API to be decoded and converted to HTML. You just send the HTML as-is. Just write the web server and the database, connect them, and you're done. That's 3 things you need to develop.
I've watched developer after developer start trivial web pages -- not even really apps -- with stacks like Angular and get bogged down in the complexity of things like client-side authentication protocols, multi-API security, making sure JSON APIs don't leak information inadvertently, having to batch queries with GraphQL, and on, and on, and on...
None of that is necessary with HTML being generated by the server.
