11 ms·

I've been using htmx for three years now, and it's completely unlocked new ways of building software for the web, especially if you use a server-side templating

by blister 2mo ago

I've been using htmx for three years now, and it's completely unlocked new ways of building software for the web, especially if you use a server-side templating language. But more importantly (as this "Game Boy" option reveals), the head honcho is really responsive with the items in the store. I had purchased a coffee mug a few years back and complained on Twitter that they need to sell larger mugs instead of only offering little tiny baby mugs that only hold ~8 ounces of liquid. The next day, he added giant 48-ounce monsters to the store and I've been drinking out of that mug every day since.

scumdude 2mo ago
Tell me about it. I made a joke about the store selling 'Complexity Bad' onesies, and he started selling them later that day. https://x.com/scumitchell/status/1886825775560528069?s=20 https://x.com/scumitchell/status/1886825775560528069?s=20
- Induane 2mo ago
  That's amazing!
- inigyou 2mo ago
  This implies it's all dropshipped print-on-demand, of course. Which is fine if you're just considering it a donation incentive rather than a worthwhile product in its own right.
  - cure_42 2mo ago
    Yeah I had the same thought. I was vaguely interested before, but I have no desire to own more garbage
  - randallsquared 2mo ago
    To be clear, making clothing is not actually their business.
    - inigyou 2mo ago
      Yes, but you might guess they've done some work to find a supplier and test the quality of their supplied products and have a box of T-shirts they know are good. Which they don't - they're basically just plugging your order into a slop fulfilment company. Which is fine if you don't actually care too much about the merch.
sgt 2mo ago
Exactly, I just released another project made with htmx and it's almost like you can't beat that velocity.
stevoski 2mo ago
> I've been using htmx for three years now, and it's completely unlocked new ways of building software for the web, especially if you use a server-side templating language. Likewise. 3 or 4 years ago, I ripped out two-thirds of all the JS in my B2B SaaS by using htmx with server-side templating. So much simpler. The ethos of allowing a return to a simpler way of building a web app resonates with me.
- sevenzero 2mo ago
  This should be the way. For some reason, over time, it became harder and harder to build web apps. Tech should be about making things easier though. I don't know where we went wrong.
  - albuic 2mo ago
    JavaScript ?
    - sevenzero 2mo ago
      Nah vanilla Javascript is fine as it was built to make stuff more interactive on the frontend side, which it works great for.
      - albuic 2mo ago
        I don't agree. JavaScript was definitly not fine when it started and because of it, people had to create multiple libraries and framework to go around differences in web-browsers. They got used to libraries and big framework as they really were necessary first. Now that JavaScript is pretty good, they are still used to frameworks and libraries which are very often unnecessary.
orphereus 2mo ago
Sorry, but at that size (1.25 liters) for my European brain, it's not a mug anymore, it's a barrel.
- crote 2mo ago
  I think the legal term is a "heart attack".
- TeMPOraL 2mo ago
  Right. People look at me funny for drinking my tea from a 500 ml thermal mug, courtesy of USS Defiant replicators, and it's not because of the Starfleet delta on it (people don't even recognize it, philistines). 1.25 liters is way beyond even my own addiction to lightweight liquid stimulants.
- walthamstow 2mo ago
  It's more than double the size of a Sports Direct mug, which is about the largest cup of tea a Briton would consider
sublinear 2mo ago
So you drink weak coffee and insist on server-side rendering in 2026?
- SpaceNoodled 2mo ago
  The server SHOULD do the rendering. It's a SERVER, not a give-me-a-bunch-of-bloated-junk-and-make-me-do-it-myself-er.
  - KronisLV 2mo ago
    I mean a radically different view is that the SERVER should just give you the data and process your requests, without necessarily caring much about what you are - a browser or some other automated system, or a desktop client, where each has vastly different preferences on how the content might get displayed or used. With that approach, a clear API in the middle and a SPA on the client side makes a bunch of sense (as long as you don't make some chimera of hydration and pre-rendering and server-side components while pretending that it's still a SPA and it "just works" while your server is coupled to the client). Of course, what you actually need depends on your circumstances and sometimes even preferences. For a bunch of internal or personal stuff, SSR can be really nice and simple!
    - andy800 2mo ago
      You're correct that it's a matter of the developer's view, or philosophy. The issue I have with "just give you the data" is that requires the server to encode the raw data somehow, most often JSON, send it down the wire just to have the client un-encode it, store it, and populate HTML elements with it. Meanwhile server-based templating is exceptionally lightweight and fast (especially when compiled) and so converting the raw data directly to HTML on the server via templates tends to be faster and lighter and cleaner, as "state" (not counting ephemeral or stylistic attributes) is maintained in a single place. You make a good point that different clients may represent the data differently, although again that's easy to handle on the server by using a header or other identifier of the client, and using the appropriate template. There isnt a definitive right or wrong, both approaches can work but the reason HTMX has found a following is that lots of developers are tired of the complications and difficulties that SPA frameworks seem to introduce, and reverting back to a server-based philosophy is allowing them to be more productive.
mlhpdx 2mo ago
Likewise, I started using HTMX with AWS Step Functions as the backend and it’s been difficult but also a joy. Sfn these days makes for a weird and wild text templating engine. I’ve been thinking about working on DSL overlay to smooth the bumps a bit.
- _jackdk_ 2mo ago
  That is not a use cases I would've expected Step Functions to handle; I'm intrigued. You're using express ones, I assume, but how are you wiring them up and why?
  - mlhpdx 2mo ago
    API Gateway direct integration to Step Functions. Unlike Lambda, there is not automatic transform for requests so I just wrote one and copy/paste it to each method integration (via a preprocess script; one of the ugly bits). Yes, EXPRESS state machines. I’ve found they have better tail latency behavior, and of course they involve zero patching/dependency updates which is nice. The state machines use JSONata for the sweet, sweet power vs JSONPath. Generally I have a Parallel state that splits the different parts of the page and Map states for data driven repetition (usually some data pulled from DDB). I have a simple JSONata method for replacing placeholder values (aka data binding). Zero Lambda at the cost of come copy paste. I’m not unhappy with it despite the warts.
    - _jackdk_ 2mo ago
      Thanks for replying, that's an interesting architecture. The idea of using a high-up parallel state seems particularly neat as a way to ensure every part of the page render stays independent, and to burst up the compute serving the response.
Grimblewald 2mo ago
It's been massive for me as well. I would say my web developmemt is best described as dabbling in web development, and I mostly do so for websites that cater to academic interests and conference / society managment and organising. So, relativly niche. However, I think HTMX is a beauty. Fast, simple, and doesnt come with all the bloat and BS a JS heavy / JS first deployment comes with. I can quikckly build fast and responsive sites that cost visitors very little to use/interact with. websites have less compatability issues now, load extremely fast (google web speed score from 60-80 to flat 100), and have fewer points of failure. Debugging is a breeze. Websites are no less pretty or useful for it. In fact, they look better now because time otherwise wasted on Js BS is now free to use to tinker with / improve aesthetic, or add new features. I'm in love with HTMX. It feels like what the web should have always been. There's absolutly zero reason a random website, without my knowledge or consent, should be running extremely heavy compute and analytics on my own device. That should never have been possible/permissible in the first place.
- robertoandred 2mo ago
  HTMX is just as JS compute heavy. It's not magic.
  - yawaramin 2mo ago
    How is htmx ‘just as JS compute heavy’? It’s doing way less than your average SPA. Have you seen the sizes of the JS bundles of popular SPAs? They make htmx look microscopic in comparison.
    - troupo 2mo ago
      It's a 14kb library that invents its own templating syntax and DSL and also requires the backend to conform to its DSL. Yes, it's smaller than some other frameworks, but let's stop with "doesn't require JS" nd other bullshit
      - jdiaz97 2mo ago
        yeah if that's a problem you can always use fixi https://github.com/bigskysoftware/fixi https://github.com/bigskysoftware/fixi
hi_hi 2mo ago
> it's completely unlocked new ways of building software for the web, especially if you use a server-side templating language. Could you please expand on this point. As a “greybeard” web dev from the 2000’s era, I’d like to understand if your “unlocking” is my “that’s how it originally worked, get of my lawn”?
- aktau 2mo ago
  I have the same question. It seems like a decent amount of posters here don't require (non-standard) interactivity. Plain HTML+CSS (perhaps via static site generators) would work. It made me think about the Javascript present on my blog. The site works fine without JS (syntax high-lighting is pre-baked server-side). There is some optional JS enhancement: - MathJax is used for turning LaTeX expressions into nice graphics on the client-side. A search reveals this could be done on the server-side, but I'd need to deal with the node.js ecosystem. - PJAX is enabled [1]. This is completely optional, but it noticeably made page navigation faster (feel instant), especially when navigating between pages already visited (forwards/backwards). UPDATE: Reading https://triptychproject.org/ https://triptychproject.org/, it seems like what PJAX does is item #3: "Partial page replacement" [1]: The library is at https://www.aktau.be/js/pjax-standalone.js https://www.aktau.be/js/pjax-standalone.js. It is invoked at the end of <body>: pjax.connect({ "container": "content", "complete": function() { MathJax.typesetPromise(); }, // Reload mathjax after a pjax load. "autoAnalytics": false });
- masfoobar 2mo ago
  Yes - how you likely built websites in 2000's era (possibly with Classic ASP or PHP4 .. maybe Perl?) is the sort of websites we are addressing with HTMX. It's bringing us back to that sort of web development but with modern tools and technology. For the server side, we can use modern languages with better templating for html. For the client, with htmx, you can do a lot of javascript such as ajax calls (load, trigger, etc) without writing javascript. With htmx you specify what you want to do inside html attributes. So my actual javascript code ends up minimal. I have been doing website dev since 2008. I've worked with PHP, C# (WebForms, MVC), a bit of python... not to mention maintaining an old website in Classic ASP. 2008-2010 I used C# WebForms. I didn't like it, but we still kept it simple, returning data from server side to html. 2010 I started to enjoy jQuery and saw potential returning data. Opened the door to provide more options for webdev. Around 2014, I've started disagreeing with "modern website development" learning knockoutjs, requirejs, to eventually angularjs, npm's, etc. Sure, I learned and pushed forward but websites seemed to become more a chore and bloat overtime. Personally, I've not really invested in React. I was starting to go round full circle to the 'old ways' just with modern tech. To me, htmx just makes webdev even more smoother.
addaon 2mo ago
> The next day, he added giant 48-ounce monsters to the store and I've been drinking out of that mug every day since. This was my trick for cutting back to two cups of coffee a day.
germandiago 2mo ago
Please I am all ears. I have right now a landing page and a NiceGUI dashboard with websockets (but only need SSE, though I need charts). I am all the time looking at htmx and used to "desktop-like" workflows for UI authoring. So I went with NiceGUI. But I wonder if or what tasks I could sinolify. My sites are low/middle-traffic. I do not need any API backend at all, just final user presentation.

by blister 2mo ago

scumdude 2mo ago

Tell me about it. I made a joke about the store selling 'Complexity Bad' onesies, and he started selling them later that day. https://x.com/scumitchell/status/1886825775560528069?s=20 https://x.com/scumitchell/status/1886825775560528069?s=20

Induane 2mo ago
That's amazing!
inigyou 2mo ago
This implies it's all dropshipped print-on-demand, of course. Which is fine if you're just considering it a donation incentive rather than a worthwhile product in its own right.
- cure_42 2mo ago
  Yeah I had the same thought. I was vaguely interested before, but I have no desire to own more garbage
- randallsquared 2mo ago
  To be clear, making clothing is not actually their business.
  - inigyou 2mo ago
    Yes, but you might guess they've done some work to find a supplier and test the quality of their supplied products and have a box of T-shirts they know are good. Which they don't - they're basically just plugging your order into a slop fulfilment company. Which is fine if you don't actually care too much about the merch.

sgt 2mo ago

Exactly, I just released another project made with htmx and it's almost like you can't beat that velocity.

stevoski 2mo ago

> I've been using htmx for three years now, and it's completely unlocked new ways of building software for the web, especially if you use a server-side templating language. Likewise. 3 or 4 years ago, I ripped out two-thirds of all the JS in my B2B SaaS by using htmx with server-side templating. So much simpler. The ethos of allowing a return to a simpler way of building a web app resonates with me.

sevenzero 2mo ago
This should be the way. For some reason, over time, it became harder and harder to build web apps. Tech should be about making things easier though. I don't know where we went wrong.
- albuic 2mo ago
  JavaScript ?
  - sevenzero 2mo ago
    Nah vanilla Javascript is fine as it was built to make stuff more interactive on the frontend side, which it works great for.
    - albuic 2mo ago
      I don't agree. JavaScript was definitly not fine when it started and because of it, people had to create multiple libraries and framework to go around differences in web-browsers. They got used to libraries and big framework as they really were necessary first. Now that JavaScript is pretty good, they are still used to frameworks and libraries which are very often unnecessary.

orphereus 2mo ago

Sorry, but at that size (1.25 liters) for my European brain, it's not a mug anymore, it's a barrel.

crote 2mo ago
I think the legal term is a "heart attack".
TeMPOraL 2mo ago
Right. People look at me funny for drinking my tea from a 500 ml thermal mug, courtesy of USS Defiant replicators, and it's not because of the Starfleet delta on it (people don't even recognize it, philistines). 1.25 liters is way beyond even my own addiction to lightweight liquid stimulants.
walthamstow 2mo ago
It's more than double the size of a Sports Direct mug, which is about the largest cup of tea a Briton would consider

sublinear 2mo ago

So you drink weak coffee and insist on server-side rendering in 2026?

SpaceNoodled 2mo ago
The server SHOULD do the rendering. It's a SERVER, not a give-me-a-bunch-of-bloated-junk-and-make-me-do-it-myself-er.
- KronisLV 2mo ago
  I mean a radically different view is that the SERVER should just give you the data and process your requests, without necessarily caring much about what you are - a browser or some other automated system, or a desktop client, where each has vastly different preferences on how the content might get displayed or used. With that approach, a clear API in the middle and a SPA on the client side makes a bunch of sense (as long as you don't make some chimera of hydration and pre-rendering and server-side components while pretending that it's still a SPA and it "just works" while your server is coupled to the client). Of course, what you actually need depends on your circumstances and sometimes even preferences. For a bunch of internal or personal stuff, SSR can be really nice and simple!
  - andy800 2mo ago
    You're correct that it's a matter of the developer's view, or philosophy. The issue I have with "just give you the data" is that requires the server to encode the raw data somehow, most often JSON, send it down the wire just to have the client un-encode it, store it, and populate HTML elements with it. Meanwhile server-based templating is exceptionally lightweight and fast (especially when compiled) and so converting the raw data directly to HTML on the server via templates tends to be faster and lighter and cleaner, as "state" (not counting ephemeral or stylistic attributes) is maintained in a single place. You make a good point that different clients may represent the data differently, although again that's easy to handle on the server by using a header or other identifier of the client, and using the appropriate template. There isnt a definitive right or wrong, both approaches can work but the reason HTMX has found a following is that lots of developers are tired of the complications and difficulties that SPA frameworks seem to introduce, and reverting back to a server-based philosophy is allowing them to be more productive.

mlhpdx 2mo ago

Likewise, I started using HTMX with AWS Step Functions as the backend and it’s been difficult but also a joy. Sfn these days makes for a weird and wild text templating engine. I’ve been thinking about working on DSL overlay to smooth the bumps a bit.

_jackdk_ 2mo ago
That is not a use cases I would've expected Step Functions to handle; I'm intrigued. You're using express ones, I assume, but how are you wiring them up and why?
- mlhpdx 2mo ago
  API Gateway direct integration to Step Functions. Unlike Lambda, there is not automatic transform for requests so I just wrote one and copy/paste it to each method integration (via a preprocess script; one of the ugly bits). Yes, EXPRESS state machines. I’ve found they have better tail latency behavior, and of course they involve zero patching/dependency updates which is nice. The state machines use JSONata for the sweet, sweet power vs JSONPath. Generally I have a Parallel state that splits the different parts of the page and Map states for data driven repetition (usually some data pulled from DDB). I have a simple JSONata method for replacing placeholder values (aka data binding). Zero Lambda at the cost of come copy paste. I’m not unhappy with it despite the warts.
  - _jackdk_ 2mo ago
    Thanks for replying, that's an interesting architecture. The idea of using a high-up parallel state seems particularly neat as a way to ensure every part of the page render stays independent, and to burst up the compute serving the response.

Grimblewald 2mo ago

It's been massive for me as well. I would say my web developmemt is best described as dabbling in web development, and I mostly do so for websites that cater to academic interests and conference / society managment and organising. So, relativly niche. However, I think HTMX is a beauty. Fast, simple, and doesnt come with all the bloat and BS a JS heavy / JS first deployment comes with. I can quikckly build fast and responsive sites that cost visitors very little to use/interact with. websites have less compatability issues now, load extremely fast (google web speed score from 60-80 to flat 100), and have fewer points of failure. Debugging is a breeze. Websites are no less pretty or useful for it. In fact, they look better now because time otherwise wasted on Js BS is now free to use to tinker with / improve aesthetic, or add new features. I'm in love with HTMX. It feels like what the web should have always been. There's absolutly zero reason a random website, without my knowledge or consent, should be running extremely heavy compute and analytics on my own device. That should never have been possible/permissible in the first place.

robertoandred 2mo ago
HTMX is just as JS compute heavy. It's not magic.
- yawaramin 2mo ago
  How is htmx ‘just as JS compute heavy’? It’s doing way less than your average SPA. Have you seen the sizes of the JS bundles of popular SPAs? They make htmx look microscopic in comparison.
  - troupo 2mo ago
    It's a 14kb library that invents its own templating syntax and DSL and also requires the backend to conform to its DSL. Yes, it's smaller than some other frameworks, but let's stop with "doesn't require JS" nd other bullshit
    - jdiaz97 2mo ago
      yeah if that's a problem you can always use fixi https://github.com/bigskysoftware/fixi https://github.com/bigskysoftware/fixi

hi_hi 2mo ago

> it's completely unlocked new ways of building software for the web, especially if you use a server-side templating language. Could you please expand on this point. As a “greybeard” web dev from the 2000’s era, I’d like to understand if your “unlocking” is my “that’s how it originally worked, get of my lawn”?

aktau 2mo ago
I have the same question. It seems like a decent amount of posters here don't require (non-standard) interactivity. Plain HTML+CSS (perhaps via static site generators) would work. It made me think about the Javascript present on my blog. The site works fine without JS (syntax high-lighting is pre-baked server-side). There is some optional JS enhancement: - MathJax is used for turning LaTeX expressions into nice graphics on the client-side. A search reveals this could be done on the server-side, but I'd need to deal with the node.js ecosystem. - PJAX is enabled [1]. This is completely optional, but it noticeably made page navigation faster (feel instant), especially when navigating between pages already visited (forwards/backwards). UPDATE: Reading https://triptychproject.org/ https://triptychproject.org/, it seems like what PJAX does is item #3: "Partial page replacement" [1]: The library is at https://www.aktau.be/js/pjax-standalone.js https://www.aktau.be/js/pjax-standalone.js. It is invoked at the end of <body>: pjax.connect({ "container": "content", "complete": function() { MathJax.typesetPromise(); }, // Reload mathjax after a pjax load. "autoAnalytics": false });
masfoobar 2mo ago
Yes - how you likely built websites in 2000's era (possibly with Classic ASP or PHP4 .. maybe Perl?) is the sort of websites we are addressing with HTMX. It's bringing us back to that sort of web development but with modern tools and technology. For the server side, we can use modern languages with better templating for html. For the client, with htmx, you can do a lot of javascript such as ajax calls (load, trigger, etc) without writing javascript. With htmx you specify what you want to do inside html attributes. So my actual javascript code ends up minimal. I have been doing website dev since 2008. I've worked with PHP, C# (WebForms, MVC), a bit of python... not to mention maintaining an old website in Classic ASP. 2008-2010 I used C# WebForms. I didn't like it, but we still kept it simple, returning data from server side to html. 2010 I started to enjoy jQuery and saw potential returning data. Opened the door to provide more options for webdev. Around 2014, I've started disagreeing with "modern website development" learning knockoutjs, requirejs, to eventually angularjs, npm's, etc. Sure, I learned and pushed forward but websites seemed to become more a chore and bloat overtime. Personally, I've not really invested in React. I was starting to go round full circle to the 'old ways' just with modern tech. To me, htmx just makes webdev even more smoother.

addaon 2mo ago

> The next day, he added giant 48-ounce monsters to the store and I've been drinking out of that mug every day since. This was my trick for cutting back to two cups of coffee a day.

germandiago 2mo ago

Please I am all ears. I have right now a landing page and a NiceGUI dashboard with websockets (but only need SSE, though I need charts). I am all the time looking at htmx and used to "desktop-like" workflows for UI authoring. So I went with NiceGUI. But I wonder if or what tasks I could sinolify. My sites are low/middle-traffic. I do not need any API backend at all, just final user presentation.