we do have a client-side template extension:

https://htmx.org/extensions/client-side-templates/

however, I would encourage most folks to use HTML as the network format: it typically isn't much more CPU to generate the equivalent HTML string that corresponds to a JSON string (sometimes even less, as with tables)

for pure client-side, htmx is largely hands off. We support an `hx-on` attribute to address the fact that HTML doesn't support general `on*` attributes, but that's it

it does, however, emit a large number of events that you can hook into to extend things:

https://htmx.org/reference/#events

And it plays well w/ scripting solutions like Alpine.js or, our our own scripting solution, _hyperscript: https://hyperscript.org

Another benefit of using HTML is ease of progressive enhancement. If the default behavior of the server is to render a full HTML page, anyone hitting that URL directly will get the full HTML from the server with no additional back-end work. Additionally, if JS is disabled in the browser, links still work as traditional links.

Thanks for the thoughtful reply, and the thoughtful architecture.

Generating some HTML instead of JSON isn't that much data/CPU. But doing all that in the browser might have a big impact on UX performance-wise.

This doesn't make sense. Can you elaborate? If it's not much work for the server, why would it be work for the browser?

Mobile phones have less powerful CPUs. Parsing large json objects and then building up a corresponding html structure may be more difficult than on the server (where you already have it loaded into memory anyway).

> Mobile phones have less powerful CPUs

True - but not by much

> Parsing large json objects and then building up a corresponding html structure may be more difficult than on the server

I doubt it. And you'd only be doing "large JSON objects" for a desktop web app, where CPU differences vs web servers are even smaller

> where you already have it loaded into memory anyway

Likely not true if implementation uses streaming semantics

> true - but not by much.

False. https://infrequently.org/2022/12/performance-baseline-2023/

I always see these claims but isn't network the more limiting factor?

Or do people study this while thinking about IoT which may use more limited resources while still relying on the internet?

Especially since a server has to handle multiple request concurrently, it doesn't seem to be remotely the same workload that a single device CPU would see anyway?

I can't speak to any kind of general principle here, but viewing any standard modern web page e.g. Twitter, Discord in a Web browser reliably takes more CPU and memory than running a late-game Factorio save.

I will allow that it is probably theoretically possible to do client-side rendering in a CPU-efficient way, but it sure isn't the standard.

JavaScript is single-threaded, so whatever CPU work is going on will compete with the UI responsiveness. Even mobile apps, which run a dedicated thread for each, probably won't do one single clean UI update in response to the server-response.

Nolan Lawson demonstrated using a web worker to perform virtual DOM updates in 2015. Sad it hasn't caught on in any of the major frameworks. https://pocketjavascript.com/blog/2015/11/23/introducing-pok...

It's not enough to be a novel approach. It also has to be demonstrably better from a performance standpoint, a developer experience standpoint, or arguably both.

Frameworks like SolidJS and Svelte simply got rid of the virtual DOM and reaped massive performance wins from it. I find it hard to believe that adding a worker and a virtual DOM back would end up making them faster. Quite the opposite in fact.

Then there's the dev experience. Would it be easier for a developer to work out what to do in a separate thread and post messages back into the UI thread? Seems like extra cognitive overhead to me.

Ideas are great. They move the state of the art forward. But if your idea doesn't comport with positive results from testing, it's not useful. Intriguing, to be sure, but not useful.

Very fair assessment, though not everyone is using, or will use, Svelte or Solid. Including people who are using htmx.

I meant to suggest that frameworks might be able to take this approach internally and make the DX transparent. I actually had a go at this using Mercury back in the day, but didn't have the motivation to finish it properly.

I'm not the GP but I'd say it's not "just" doing that render-blocking work on a single thread on a potentially under-powered mobile device, it's also introducing significant latency to fetch, parse and execute the code that will render to the DOM.