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.
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?
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.
If you combine e.g. hx-post with hx-target, then it will put the text from the response into the target selector... but there is no "hx-source" to select what part of the response to use.
I'd really love to be able to set e.g. hx-source="somejsonfield" instead of having to manually handle the response with a custom function that parses/error checks the json and then sets the selector's text to the value of a json key. It could really save a lot of boilerplate code IMO.
we do have a json extension for handling JSON responses, but it's a step away from the hypermedia architecture:
I have lots of notes of varying types and formats. Org-mode files are all pretty standard, but there's like 3 different Markdowns and an untold number of randomly-formatted .TXT files. I want to generate their webpages on-the-fly and not have to worry about exporting it.
One of the "crap mixed in" things I want is to integrate parts of a gitweb-like interface into the notes. I reference repos and commits regularly in my notes. Would be neat to mouse-over them and get a little popup with basic info about it.
I also like that the author refers to themselves as a Technomancer. Personally I'm an metamagical artificer. I love meeting fellow adventurers.
so far I got HARM (Rust), HARC (Raku) and now HAM (F#) along with Fast HTML / htpy (Python) and GOTHH (Go)
seriously, it is very good news that HTMX has uncoupled web development from the server side language choice
now there is a blossoming of many server side stacks to fill this new opportunity
I wrote https://harcstack.org because Raku is the natural successor to perl and PHP for web development due to its facility with text processing and multi-paradigm chops
One way would be to go with React, Nest.js, setting up SSR and hydration of just the right fragments, etc. Another would be to take your existing static HTML page, and add very few bits in a specific place.
An easy example: a "like" button + counter of "likes" under a blog post.
If you need a complex SPA UI, you need a different tool.
If it were a blog, or a corporate info page, I'd rather use a CMS. That way I don't write HTML at all. It would just hand me minimal interactivity.
If it were a shopping site, I'd probably want more interaction than just a single "like" button. I'd want to filter results, sort them, edit a shopping cart, etc.
It doesn't sound appropriate for visualization. It might be useful for a dashboard, but the more people expect to interact with the dashboard, the more likely it'll tip over into SPA territory.
I'm sure there's a niche, but it feels kind of narrow. It's complicated enough to require programming, but not complicated enough to require an SPA.
