[stefan_]

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.

[listenallyall]

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.

[bccdee]

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.

[listenallyall]

I agree that templating is very fast and efficient, probably faster than serializing to JSON.

Read the OP's posts - he is talking about a "server" being an embedded device with 64mb of read-only storage. My assumption is that the data output format is basically hard-coded in the device's OS and doesn't even rely on JSON serialization.

[bccdee]

Oh wait, oh my god

> Three levels down and people have entirely forgotten what my post was.

I missed this reply entirely. Whoops.

That said, I do feel like you can do HTML templates on a tiny chip with 64 megs of memory. I've seen NASes with comparably tiny & terrible chips serve their web UIs this way: paper-thin html templates with <form>s for interactivity and <table>s for layout.

[ErroneousBosh]

But that's the point of something like HTMX, though.

You draw a simple web page with very basic elements, tag them with an HTMX element, and let the client side javascript turn that into something that "does stuff".

I wrote a phone directory with find-as-you-type using Django (because it's what I had lying around) and HTMX (because I read somewhere that it was cool and fun and I should try it, and I bow easily to peer pressure), and then min.css to make it not look shit.

All totally vendored, just download the appropriate .js and .css file and check them into your source control.

When you type it hits an endpoint that returns a bit of HTML that contains a table, and swaps it into a div. The querying part and the drawing part is client-side and there's nothing stopping you passing a query string to the endpoint and getting just a bare table out.

Indeed there's nothing stopping you detecting if it's an HTMX request and only returning the fragment, or if it's "bare" returning a full valid page. You know what? I should do that, I'll log a feature request on my project for it.

I've gotten a little away from the original point.

You use HTMX on the client side, to turn a plain HTML page with no interactivity into something that will pull data from a backend and swap it into the DOM. If you want to return JSON and render that with yet another library you can, but you're probably already filling in the blanks in an HTML template as it is.

[array_key_first]

My understanding is that HTML templating is often cheaper server-side than JSON serialization.

[ErroneousBosh]

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?