Htmx 4.0, the first JavaScript library to release exclusively on the Game Boy
swag.htmx.org
swag.htmx.org
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.
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.
1.25 liters is way beyond even my own addiction to lightweight liquid stimulants.
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!
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.
As someone who struggled with the downright problematic lifecycle of complex JSF/PrimeFaces apps and now is in a year-long-with-no-end-in-sight migration to a SPA, I will say that the SPA wins out in quite a few development/maintenance/convenience facets, second order system effect or not. As with all migrations, it's slower than you'd expect but the pace of creating new stuff is far more promising (especially if you fight off pixel pushers) and the experience of maintaining SPAs has been good in other projects, especially given that the old JSF/PrimeFaces setup has been around for like a decade (and performed poorly throughout that time, with plenty of footguns that a wide roster of developers kept tripping over).
On the other hand, I will completely admit that SPA can bring additional complexity (especially if you end up with one of those needlessly complex solutions like Next.js or Vuex, when all you need is under 100 components across maybe a number of views on the same order of magnitude), but one also has to consider that some of the traditionally SSR solutions eventually strive to have more reactivity and often create mechanisms for partial updates, except across the board they end up being harder to debug and customize compared to some JS/TS calling a vaguely RESTful API over HTTP(S).
I unironically liked it way more when "web app" meant some PHP returning pages with forms and some Bootstrap on top, even some light jQuery (but we all know how badly the "light" bit held up).
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.
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.
Yes, it's smaller than some other frameworks, but let's stop with "doesn't require JS" nd other bullshit
What do you think hx-get and hx-trigger="input changed delay:1s" are? Standard browser attributes? Standard browser functionality and behaviour? Standard events syntax?
> It doesn’t require the backend to ‘conform’ to anything,
Just one of the quotes from the docs: "You would need to check on the server side for the HX-Request header to differentiate between an htmx-driven and a regular request, to determine exactly what to render to the client."
> I’m afraid you’re very confused!
I'm afraid I'm not
Because none of that is standard, none of that is understood by browsers, and requires HTMX to work.
Which is also besides the point of discussing whether or not HTMX invents its own templating, DSL, and requires the server to be aware of HTMX to to work properly.
I'll let you find any working examples yourself.
Most sites won't work or will be broken, too. Obviously You have to actually try and work on progressive enhancement, and not rely on marketing blurbs and promises of magic.
I wonder if people blindly defenfing their favorite thingd actually know anything about them.
I assure you I know quite a bit more than you when it comes to htmx and progressive enhancement, having built multiple progressively enhanced htmx apps that work almost exactly the same without JS.
Yup, the unworking hamburger menu on the website preaching about progressive enhancement and built entirely with this framework "has nothing to do with htmx".
All examples on HTMX site that we're told will just work "with full page reload" and that don't work also have nothing to do with HTMX.
HTMX is magical progressive enhancement "The things work, albeit with a full page load" somehow are broken on HTMX site itself and on most sites built with it, but all this also has nothing to do with it. Because "things just work"
And now you're repeating what I already said and somehow pretending it's an argument with something I didn't say.
>> Which is also besides the point of discussing whether or not HTMX invents its own templating, DSL, and requires the server to be aware of HTMX to to work properly. reply
> The things work, albeit with a full page load. As one of the ancestor comments said: progressive enhancement.
Oh. It turns out things don't work, neither on HTMX's own site, nor on most sites built with it.
Why do you keep arguing theory when reality is right there for anyone to see?
> Your criticism is basically that it’s not perfect, so it’s worthless.
No. My criticism is that HtMX authors and proponents keep presenting HTMX as something it objectively isn't despite actual verifiable reality.
I literally said what I mean in my first comment which started this pointless thread.
As I said in a sibling comment:
At this point I'm tired of pointless arguing with reality-denying people. Adieu.
Good luck with your confirmation bias fallacies though.
Hx-attributes are not a new ‘templating syntax’, they’re custom attributes with a simple DSL for describing triggers and swaps. You can prefix them with ‘data-‘ if you want and they will be 100% standards-conformant. HTML itself is full of these little in-attribute DSLs–look up the standard ‘autocomplete’ attribute:
<textarea autocomplete="shipping street-address"></textarea>
> …from the docs: "You would need to check on the server side for the HX-Request header…
Yes, this is how HTTP content negotiation works. The client sends headers to the server describing what it wants and the server sends headers describing what it gives. I hope you’re not suggesting that htmx invented this technique. It’s kinda funny to suggest that htmx forces servers to ‘conform’ to something when most of today’s JS frameworks do server-side rendering only on JavaScript server runtimes.
They are. If you look at how they are processed by HTMX itself.
> they’re custom attributes with a simple DSL
At least you agree that it's a custom DSL
> You can prefix them with ‘data-‘ if you want and they will be 100% standards-conformant.
It doesn't matter if they are "standards compliant". The browser has literally no idea what they are, and what that DSL is. HTMX parses them, parses the DSL etc.
Turn off Javascript and whatch how this beautiful standard-compliant stuff turns inert (or doesn't even load).
> Yes, this is how HTTP content negotiation works. The client sends headers to the server describing what it wants
That's not how content negotiation works. Standard content negotiation does not require custom headers, or the client needing to parse this header and be aware of anything to differentiate requests.
There's are literal Content-Type and Accept standard headers. And yet HTMX invents its own flavor.
> most of today’s JS frameworks do server-side rendering only on JavaScript server runtimes.
Most of which AFAIR don't require custom headers.
https://docs.solidjs.com/concepts/control-flow/conditional-r...
https://vuejs.org/guide/essentials/template-syntax.html
https://angular.dev/guide/templates#differences-from-standar...
None of which work with JavaScript turned off (unless you have a JavaScript backend and you wire it up to serve HTML).
The criticisms I’m seeing here are all things that are accepted without question in other frameworks but when htmx does it, suddenly it’s too much.
Who said they are accepted without question?
> when htmx does it, suddenly it’s too much.
No, when HTMX and its proponents claim things that are objectively provably false, it's too much.
Me: HTMX requires the server to be compliant with its DSL to work properly
You: no it doesn't. It's literally how content negotiation works! <Thus admitting HTMX requires server to conform to HTMX to work properly>
Me: there are literal standard headers for content negotiation
You: but what about React, and other frameworks.
Are we talking about React? Or other frameworks? We are talking about HTMx and your and others' claims about it.
Me: HTMX is custom templates and custom DSL.
You: no it's not!
Me: yes, it is
Me: It's standards compliant custom attributes and custom DSL. Why don't you look at all these other frameworks.
At every step of your "argument" you keep confirming every word I'm saying while somehow presenting it as an argument.
Try to actually learn something about tech you so fervently defend and to see how uour claims rarely differ from marketing bullshit (that marketing bullshit is often peddled by HTMx itself, most other frameworks are much more honest).
At this point I'm tired of pointless arguing with reality-denying people.
Adieu.
Also I pointed out that HTML already has custom DSLs in many of its attributes, this is not some new thing that htmx invented.
Finally, it says directly on the htmx landing page that it uses attributes for its functionality, and directly shows examples of common ones. This is right on the landing page. You have to dig into the special syntaxes of the other frameworks I mentioned to understand the differences they introduce. So I firmly refute your claims of marketing bullshit and dishonesty :-)
Try re-examining your own biases, you are in strong reality-warping mode :-)
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”?
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).
[1]: The library is at 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
});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.
This was my trick for cutting back to two cups of coffee a day.
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.
Have a default you can import? Absolutely, that makes sense
But styling by default they you have to make complicated overrides for? That’s the part that gets me
The thing that is frustrating me about HTMX so far is: How do I build typesafe templates on the server? I'm trying out Aksama and it seems ok, is there something similar for JS?
Also the SPA abstraction of "your website is just a client that connects to a an API" is nice.
It seems to be pretty niche, but I've only ever heard good things about it.
with that im very enjoying the challenge of scaling ssr stuff like this. i am very tempted to throw months of my life away building out a full fledged framework that means no npm / node toolchains, an easier to customize component model thats more performant and doesn't feel like... abstractions of abstractions, compile time tree shakedowns. for all of it. streamlit showed me the beauty of a declarative api that kinda went and did the rest but it missed a ton of marks with its top to bottom runs and it's just awkward.. a little too opinionated, terrible performance, perhaps the dumbest state management ive ever seen in my life... nicegui improved on that, but python just doesn't fit the bill for what i want to do. something that's go and its fully reactive and gives you full control. i genuinely think the hardest part of doing this is designing a framework api that is approachable and easily-rememberable. golang actually makes this hard, python wins with kwargs and stuff. i also suppose i could just start using wasm
i think where this might all be headed.. it's a touchy subject if im being honest. our guy at work is an amazing person super candid and honest. he says it kinda hurts seeing the front end stack he's been in pretty much his entire career start to lose developer interest. we've talked in depth about how the entire history of things like react came to be out of necessity, a product of its time with all the historic constraints that used to exist.. it led to educational curriculums, bootcamps and full blown careers.. but it's really hard to get behind what feels like an overly complex workaround that spans well over a decade at this point. people have invested a lot in their frontend-frameworks and toolchains and workflows and other pieces of knowledge and understandably are ready to defend it the entire existence of "make the client browser do a lot of work work" model. but hey, I've used both heavily and for what it's worth I think server-side and a general programming language are really the path forward here and it feels like something that corrects one of computing histories biggest weird sidequests. i genuinely think everyone will have a deeper and better understanding of computing in general approaching from this angle, and i think ssr is a very valuable path to explore that can really open the doors to understanding what makes good software as you're forced to contend with the most important design pattern: if you're going to make the server do most of the work, what is needed to do it well & scale to many clients. it naturally leads you into some really exciting possibilities. i personally love where this is headed because it completely nerfs the need for such abominations such as graphql & it's supporting infra. i can just rawdog sql, the most goated query language of all time.
highly performant data grids imo are the gold standard of components. i'm okay with a blend of client and server side work to make this a reality, aggrid is a good example of a very sick front end lib that does this. but i look forward to seeing if anyone's going to do something new here that is performant as hell and served up from the backend, some kind of tanstack demonchild or satanic wasm data grid 9000
One of the most delightful little swag stunts I've ever seen, and emblematic of the HTMX crew just how much they care about craft and delight in everything they do.
This whole concept died because of styling and that era of everyone having their pixel perfect psd turned into a html table or a flash applet and you couldn't reconcile both, but sometime out there you can still find an old IntraWeb business app and you realize they had the components, events and everything figured out long before it became cool again.
I always wish for some RAD tool to show up for modern web stack again, but I guess it moves too fast to be worth it, and nowadays front and backend are properly separated disciplines.
Especially nowadays where AI changes how you interact with ugly languages like php, but benefit from their deep ecosystems, speed and super fast "build" times.
In fact, despite me being unable to look at php syntax much without vomiting, and finding languages without proper static types nauseating..I'm just more productive in those than in spa slop land.
The web and browser technologies has also moved a lot. The "client side rendering so users don't see a refresh and have an app like experience" is basically a 2010 thing.
Even though it’s basically dead tech I can’t bear to throw out my Apress book about it. :)
https://www.barnesandnoble.com/w/foundations-of-aspnet-ajax-...
https://github.com/gsxhq/gsxui
https://github.com/jackielii/structpages is what I might call a framework that GSX sits nicely in.
Also one ai haven't tried: Templ.
- OpenAPI API spec and using https://github.com/oapi-codegen/oapi-codegen/ to generate the types, server interface, and client library
- Standard library http package for the API server implementation
- Standard library template/html package for generating the dynamic parts of the webpage content
- Static web content is embedded within the Go binary (https://pkg.go.dev/embed) and served through server routes
- api served from /api route, htmx webpage served from /
- no ORM, mostly using standard library database/sql package for DB transactions, maybe reaching for a query builder library for more complex queries like complex search functionality
- Local S3 compatible object store for dynamic binary data like user-uploaded images and video. Local filesystem can be fine for small scale stuff.
For my home server I have authn/authz happening at the OS/infra layer, but if you need multitenancy you can pretty easily integrate an OAuth/OpenID authn/authz middleware for login with Google or whatever.
That's great but I believe it's still over-engineered. Unless it's a web site that can tolerate no downtime at all during schema updates, SQLite in WAL2 mode is more than enough. Moreover, in Postgres version upgrades can't be done without significant downtime (or setting up replication and performing a complex dance), so even that isn't so cut and dry.
</ ... >
The difference is only in the deployment/maintenance.
And considering the context he stated, zero downtime really doesn't seem like something he's worrying about.
I personally find Postgres WAY easier than SQLite simply because of the deployment story. I do a lot of hotfixes and dangerous stuff on personal projects, and having two databases complicates that tremendously. I like being able to run hot code on prod.
For the record, this is not the same reason I like postgres for actual production code
Postgres version upgrades are basically painless, at my workplace our upgrades complete in so little time our users don't notice, and we have more data than probably 99.9999% of companies out there (mature company in aerospace industry).
Version upgrades for SQLite are basically a no-op though, that's kinda one of the reasons why it's so great to run in production (and deployment a maintenance being mostly a no-op as well, apart from setting up backups I guess).
I don't actually suggest that everyone should run their production on SQLite, but it's genuinely worth considering especially for small-ish projects.
I do think that people really underestimate how quickly a system starts being "please, no downtime" (or its weaker cousin, "please, don't make your ops people do rollouts at 1AM").
Like obviously it's not the end of the world but the default assumption of "the system is up" makes a loooooot of things downstream of that easier.
Having to do operational bug triage on systems that routinely have blips in availability is unfun.
I still think there are lines (I have to begrudgingly accept that downtime for PG upgrades is still basically worth it because the effort to not downtime there is so high but the frequency is so low), and it's a spectrum. But I've found that this particular flavor of tech debt tends to hurt quite a lot even with fairly low activity systems
Why not just use html without HTMX you ask? With HTMX I don't have to reload the entire page to navigate, which is especially helpful for making the app responsive even on low bandwidth connections like a bad cell signal.
TIL. Thanks! Now all the Grug references in the shop make sense, as well as the wisdom and overall vibe of the htmx project :)
[0] https://www.infoworld.com/article/2336201/complexity-bad-an-...
Just recently I looked at hosting an old school forum. I don't want to load all the PHP and MySQL baggage on my server or even run it in docker, so I looked for Python solutions. Found PunkwebBB. Was happy for a short time with it, until I tested it more in depth with no scripts. Unfortunately, while it has some good fallbacks in some places, it doesn't have them everywhere and some buttons just don't do anything without JS. It also uses Htmx. Completely unnecessary JS, considering the function of the buttons.
I considered forking it. But the amount of work to remove the needless JS, and repair it ...
So now I am building my own forum completely without JS, and with Python Django doing a lot of heavy lifting.
Turbo comes from a progressive-enhancement philosophy: start with proper HTML and add richer behaviour on top. HTMX is a JavaScript library in much the same sense that React is. There is nothing inherently wrong with that, but it makes this anti-pattern easier to fall into.
Honestly, “the site should work without JavaScript” is no longer the strongest argument. Server-rendered, semantic HTML matters more for accessibility, SEO, and increasingly for LLMs and other automated tools.
Of course, you can write excellent HTML with HTMX. It just requires more discipline—or enough experience to recognize when you are quietly building a JavaScript application in HTML attributes.
Or at least they were, until I started using cache components the other week, and I'd not noticed they'd regressed. That's frustrating. Give me a few minutes...
In practice I think it's very easy to make your htmx application JS-requiring.
It's awesome, I'm not criticizing Htmx at all to be clear, I am criticizing our seemingly inability to advance the core web technology of HTML in browsers to include this kind of tech natively.
If somebody from the WhatWG, e.g. Apple, Google, Microsoft, Opera, and Mozilla, etc. wants to embrace and support the creators of Htmx and wrap this into the browser natively, I will proudly retract my comment.
[1] https://htmx.org/essays/future/#writing-research-and-standar...
1) PUT, PATCH, and DELETE methods: Logical and obvious extension, no extra syntax, but easy to get around today by just using POST for everything.
2) Buttons actions without forms: Just syntax nicety to avoid a single form tag, unconsequential and just adds implementation complexity.
3) Partial page replacement: Would completely revolutionize js-free html capabilities, but the draft is unfinished..
It would seem to me that the author should have just made the thrid proposal, and not wrapped it in a project of two much less consequential proposals?
Also, hx-boost isn’t really a workaround, it’s a fully supported and documented feature.
Later this year I will be releasing Misago 0.40, which is a near complete rewrite from React.js to HTMX, with rest of features to follow in 2027. And yes, noscripy support is part of it.
https://misago-project.org/t/removing-reactjs-from-the-codeb...
Release will come soon, still some things baking.
I used HTMX in a few projects, and the library worked well enough for what I needed, but I found it to be a bit too limiting compared to accomplishing the same task in Vanilla JS (my go-to).
it is a real, honest-to-goodness mario-bros inspired GameBoy game with four levels over three biomes ending in a slop factory where you battle final boss warren buffering (an online character I beef with, we are friends)
if you beat him it unlocks the source code for htmx 4.0
game was written by Stephen Mitchell (aka scum) by hand, using GBStudio w/heavy customizations, hoping to get an essay by him up soon talking about the creation of the game
carts were produced w/the expertise of Jarason Banes who also did the cover design. Cover art is by Ash (https://www.fiverr.com/ae1996/) who also did the soft-cover art for https://hypermedia.systems
Hope you find it enjoyable if you get a copy and at least find it funny if you don't :)
Thanks for pointing it out, lol
Someone commented in the past few days that the most impressive demo they saw in a conference was LibreOffice running on Fil-C, and I agreed.
However, this took the #1 spot from it (leaving that previous demo in #2) in my opinion. Very impressive, and nostalgic too.
There's a source code reader at the end of the game, tbd if there are transfer abilities, I haven't beat it yet
Got really good at using it by the end of the project. You can listen to the trailer music here. Let me know what you think.
https://www.youtube.com/live/9ubSJGyB21Q?si=sz-8pxPs6zxVYMfY...
Love HTMX, can't wait for my https://brickboy.xyz/ to arrive so I can get to work!
https://modretro.com/products/chromatic-tetris-bundle
you can find cheaper ones on amazon/temu too
Even React-aholics have to tip their hats to a Game Boy release.
Not trying to make money on it, it’s for the lols
I think the design of HTMX acts as a complexity limiter by encouraging less JS. One can make the argument that manually writing JS instead of HTMX would be easier and more maintainable. However, I've found that JS code often trends towards becoming increasingly complex over time.
Also, I'm glad to see that htmx can be installed without npm. I think the ability to install npm packages can incentivize too many dependencies.
I find htmx ideal for things that should be static to begin with, and for things that are dynamic, I fail to see how it can handle synchronisation?
I believe Github is using similar technology and their notifications indicators and counter are almost always broken and out of sync.
well done to the htmx team.
- It's way too long and not catchy. What it refers to is a convoluted long thing too.
- This is the killer: it's not so mainstream that everybody knows it. People kind of took "REST" and left the rest. Even REST isn't usually real REST in practice. It just means json api nowadays.
...I may have done this.
Your client does not have permission to get URL /en-cad/products/htmx-4-the-game from this server.