Comment by bccdee
24 days ago
> It has to load HTML templates into memory and insert strings into them.
In practice, I doubt this is much slower than serializing JSON. Keeping a couple kilobytes of HTML templates in memory is nothing. Conversely, running a whole vdom on the frontend (typically more resource-constrained than the server) is a much bigger performance issue.
Three levels down and people have entirely forgotten what my post was. My "server" is some anemic ARM core built into real physical hardware with 64M of read-only storage. I don't want it spending its time "hydrating" some DOM, I don't want to bring any of this frontend insanity on there at all. No code hosted on npm shall ever run on that processor or I can't go to sleep in peace.
So how do we still get a fancy SPA website? Build it all down to a simple zip bundle, the ARM can serve those static files just fine. The SPA talks to the ARM via a few JSON APIs. Very nice clean boundary.
Yes, if your server is a weak, limited processor, you want to keep the demands on it as low and lean as possible, and let the client do the heavy lifting. HTMX is not a good fit for this scenario, just like PostgreSQL is not a good database to embed on your devices.
This isn't a controversial idea and nobody would try to sell you on HTMX for your use case.
1. No, templating strings is actually quite cheap. I'm doubtful that you could benchmark any substantial difference between templating html and serializing json.
2. Who has a server with a weak, limited processor? HTML templates power Django, Rails, and PHP. This paradigm worked fine on the servers of 20 years ago, in the slowest languages we use. I could serve a Django app on my phone and see reasonable performance.
3 replies →
My understanding is that HTML templating is often cheaper server-side than JSON serialization.
What's npm got to do with it?
Why can't your code fill in the blanks in some HTML template instead of filling in the blanks in some JSON?