I'm toying around with HTMX for my website. It's going to be sort of a wiki but a little different; the public exports from my internal knowledgebase with some extra crap mixed in.
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.
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 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.
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.
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.
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.
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
Phoenix LiveView also solves this. One request sends a lightweight event message over web socket, and the web server responds with only the new html (or the new content to insert into specific places in the template).
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.
15 comments
[ 2.8 ms ] story [ 35.3 ms ] threadThis is debatable. Plenty of js heavy websites feel slow and clunky.
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.
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.
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.
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
Anyone have any examples that are noteworthy?
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
https://vorticode.github.io/solarite