HTMX sets up an underlying network traffic pattern:
1. The user interacts with the page.
2. The page sends a request to the server.
3. The server returns one response to the client, containing HTML, which the client inserts into the page.
4. (Optional) If the response includes references to other resources, like images or fonts, the client makes more requests for these.
The consequence of the 'one request, one response' thing is that the whole thing is fast. All the HTML arrives in one go. None of this request-one-thing-then-run-some-JS-on-the-client-to-decide-whether-to-request-another-thing nonsense that you can watch happening in real time that happens in an alleged productivity tool I have to use at my day job.
Which is so much worse than the current paradigm where we have a client side SPA deciding to do all sorts of state syncing and react hooks and tracking pixels and auto pop ups all doing their own thing all over the place!
/end sarcasm/
I think for a side project, not immediately expecting your front end's first version to not horizontally scale to the moon is ok.
Wat would prevent a HTMX frontend from scaling horizontally? Maybe the backend, if it cannot scale horizontally. Otherwise, a million pages can be served the same way as a dozen. (A million is actually not so much, one average API box could suffice.)
Where HTMX would run into trouble is complicated frontend logic, where updates of one area may trigger changes in another, etc.
Yes. The cycle has completed and the old new things are new again. But they're still too new and unproven for the React-embroiled companies to switch just yet.
HTMX is basically a framework for AJAX that lets you more quickly set up interactions in the markup instead of having to write scripts to manipulate the DOM yourself. It also tells on sending HTML fragments over the asynchronous request instead of JSON that has to be "rendered."
It's basically the exact type of framework you probably built on your third or fourth Ajax project 15 years ago - declarative, progressively enhanced, simple.
Yeah it's exactly AJAX. Except instead of writing Javascript to send requests and insert the response into the document, you use declarative HTML attributes to describe what you want to happen.
I recently found Datastar [0], another hypermedia project. It was originally inspired by htmx, but they are fully on their own (hypermedia) course. According to the devs, who had a bunch of discussions with maintainers of htmx, the htmx project considers itself finished and no new features forthcoming. It is laudible, a project considering itself complete.
Datastar considers its library v1.0 release [1] to be complete, offering a core hypermedia API, while all else consists of optional plugins. The devs have a hot take wrt htmx in their release announcement:
> While it’s going to be a very hot take, I think there is zero reason to use htmx going forward. We are smaller, faster and more future proof. In my opinion htmx is now a deprecated approach but Datastar would not exist but for the work of Carson and the surrounding team.
When you think of adopting htmx, it may be worth making a comparison to Datastar as well.
I like using both for different things. The only real complaint I have with Datastar is that its progressive-enhancement capabilities are not as nice/simple/well-defined as htmx.
I loooooooove HTMX. Most of the sites I build are small in scope and requirements. Using HTMX gives me a way to add a little tiny bit of interactivity at almost no cost - same templates and HTML and shit as a MPA but magically delivered as a SPA. Plus it can gracefully degrade into a normal website, which is good for everyone.
I got a wave of shudder reading the acronym "HAM stack". Yugh. MEAN, MERN, RERN–once hyped up hot air which now sounds so dated and hackneyed. It's cool to be excited about tech but if your main selling point is building "faster and cheaper", I don't know if picking up a minimalistic framework you know nothing about is faster than just re-using your trusty boilerplate.
Be it React or Svelte or whatever. With serverless backend if you want to keep costs down. Although a server from Hetzner isn't that expensive and you can host multiple APIs there.
At what point are we going to say browsers with JS is outdated and painful? Every few months there’s some new framework. I think it stems from the fact that we refuse to change the browser. HTML was nice but all these solutions to make it modern are…ugly. And don’t get me started on JS. I just want an elegant solution that’s intuitive and built for modern applications.
I think your suffering from the same thing that makes 2014 feel like 5 years ago when its over a decade ago.
The framework landscape has remained relatively entrenched in React since 2016. Sure theres a few new ones time to time but nothings ever come close to unseating it in the same way it took over from Angular.
(Yes you could argue Nextjs but thats just react with a backend bolted to it)
I’ve been saying for a while now that browsers need something closer to a proper UI toolkit, or at minimum “batteries included” primitives built in for ages now. It’d be a much-needed paving of a desire path that’s been so heavily trodden it’s become a canyon.
The WASM approach holds promise too and is interesting to me for opening up support for non-JS languages, but a built in UI toolkit would bring the advantage of not needing a compiler or toolchain (just like the traditional web) which can be advantageous and lowers the bar for entry.
Many web developers make applications that are expected to work on every platform, every screen size, load instantly for new users, sync user state between every device instantly, and work offline (in some cases). All this takes place in an execution environment that perfectly sandboxes it, allowing users to download and run any application without any fear of viruses. Yes, the stack is complicated, but it's a complicated problem. The fact that people are making libraries to make web development simpler... well, no platform other than the web has even attempted to achieve everything I've listed, so we don't really have a point of comparison.
we've been saying it for ages. We even got everyone under the banner and came up with all sort of fixes and said "we will use transpilers till then", and javascript was supposed to change for the better.
But then microsoft took everything and ran with it. And now people believe typescript is good because their text editor lies to them.
Considering most of my side projects are web based and I loathe JS and prefer MPA patterns, this is very intriguing. I admit I haven’t been keeping up with HTMX or new web frameworks.
As I mentioned in a comment above, I've seen a few commercial projects attempted. But I'm hesitant to recommend HTMX, all three of them were failures (and for technical reasons not business ones)
Interesting. It seems like an easy way to get JS to interact with HTML bits on the client side (if I understand it correctly).
Maybe it could be useful alongside HTMX even: client-side HTML manipulation for simple things and server-side HTML hydration and rendering for complex things.
Readit News
1. The user interacts with the page.
2. The page sends a request to the server.
3. The server returns one response to the client, containing HTML, which the client inserts into the page.
4. (Optional) If the response includes references to other resources, like images or fonts, the client makes more requests for these.
The consequence of the 'one request, one response' thing is that the whole thing is fast. All the HTML arrives in one go. None of this request-one-thing-then-run-some-JS-on-the-client-to-decide-whether-to-request-another-thing nonsense that you can watch happening in real time that happens in an alleged productivity tool I have to use at my day job.
Which is so much worse than the current paradigm where we have a client side SPA deciding to do all sorts of state syncing and react hooks and tracking pixels and auto pop ups all doing their own thing all over the place!
/end sarcasm/
I think for a side project, not immediately expecting your front end's first version to not horizontally scale to the moon is ok.
Where HTMX would run into trouble is complicated frontend logic, where updates of one area may trigger changes in another, etc.
HTMX is basically a framework for AJAX that lets you more quickly set up interactions in the markup instead of having to write scripts to manipulate the DOM yourself. It also tells on sending HTML fragments over the asynchronous request instead of JSON that has to be "rendered."
Datastar considers its library v1.0 release [1] to be complete, offering a core hypermedia API, while all else consists of optional plugins. The devs have a hot take wrt htmx in their release announcement:
> While it’s going to be a very hot take, I think there is zero reason to use htmx going forward. We are smaller, faster and more future proof. In my opinion htmx is now a deprecated approach but Datastar would not exist but for the work of Carson and the surrounding team.
When you think of adopting htmx, it may be worth making a comparison to Datastar as well.
[0] https://data-star.dev/
[1] https://data-star.dev/essays/v1_and_beyond
Be it React or Svelte or whatever. With serverless backend if you want to keep costs down. Although a server from Hetzner isn't that expensive and you can host multiple APIs there.
That's the whole point of HTMX: Going back to what works: trusty old HTML attributes, but giving them intuitive interactions.
Instead of learning the microframework du jour, you just add some attributes into your HTML templates, and get your desired result.
The framework landscape has remained relatively entrenched in React since 2016. Sure theres a few new ones time to time but nothings ever come close to unseating it in the same way it took over from Angular.
(Yes you could argue Nextjs but thats just react with a backend bolted to it)
The WASM approach holds promise too and is interesting to me for opening up support for non-JS languages, but a built in UI toolkit would bring the advantage of not needing a compiler or toolchain (just like the traditional web) which can be advantageous and lowers the bar for entry.
It's by the Flutter team lead talking about how with WASM we can redo the web stack by eschewing HTML, CSS, and JS entirely.
But then microsoft took everything and ran with it. And now people believe typescript is good because their text editor lies to them.
This is debatable. Plenty of js heavy websites feel slow and clunky.
Anyone have any examples that are noteworthy?
https://htmx.org/essays/#on-the-other-hand
https://vorticode.github.io/solarite
Maybe it could be useful alongside HTMX even: client-side HTML manipulation for simple things and server-side HTML hydration and rendering for complex things.