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.
Grimblewald 21 hours 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 18 hours ago [-]
HTMX is just as JS compute heavy. It's not magic.
yawaramin 18 hours 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 12 hours 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
yawaramin 8 hours ago [-]
It doesn’t have its own templating syntax, it just uses server side HTML generation. It doesn’t require the backend to ‘conform’ to anything, it works with very standard HTTP forms and HTML responses. I’m afraid you’re very confused!
troupo 6 hours ago [-]
> It doesn’t have its own templating syntax
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
yawaramin 3 hours ago [-]
> What do you think hx-get and hx-trigger
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:
When people complain about this stuff, they just reveal they don’t know HTML.
> …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.
troupo 2 hours ago [-]
> Hx-attributes are not a new ‘templating syntax’,
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.
yawaramin 1 hours ago [-]
You must be joking, React Flight Protocol for RSC is literally a new RPC system that comes with its own set of brand-new vulnerabilities. But sure, adding a couple of HTTP headers, which were designed for exactly this kind of use case (adding metadata to requests and responses), is a bridge too far.
tailscaler2026 6 hours ago [-]
That's how progressive enhancement works. The website should work fine if JS is disabled. Then it's faster via htmx if JS is enabled, and more so if the backend is tuned as well.
troupo 6 hours ago [-]
None of the things HTMX adds will work. Which is easy to test by just turning off Javascript on most (any?) examples or sites using HTMX.
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.
zamalek 5 hours ago [-]
The things work, albeit with a full page load. As one of the ancestor comments said: progressive enhancement.
troupo 4 hours ago [-]
Lol. Even the hamburger menu doesn't work on htmx.org without Javascript.
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.
yawaramin 2 hours ago [-]
Hamburger menu on the htmx.org site using JavaScript has nothing to do with htmx the framework itself, they’re completely unrelated. It wouldn’t be difficult to make the hamburger menu work without any JS by just using the Popover API, which again is completely unrelated to htmx and can be used by any frontend framework.
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.
troupo 2 hours ago [-]
> Hamburger menu on the htmx.org site using JavaScript has nothing to do with htmx the framework itself, they’re completely unrelated.
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"
yawaramin 1 hours ago [-]
The htmx website is full of demos showing how htmx works. Htmx is a JavaScript framework. Unsurprisingly, some of these demos don’t work when JavaScript is turned off. This thread is getting absurd now.
tailscaler2026 5 hours ago [-]
[dead]
dang 4 hours ago [-]
It's not ok to post like this here. Since it isn't the first time you've broken the rules like this, I've banned this account.
What does that have to do with anything? Literally the same thing (only difference is size)
rolymath 16 hours ago [-]
You're saying we need magic for different js frameworks to have different performance profiles?
stevoski 1 days 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 16 hours 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 3 hours ago [-]
JavaScript ?
sevenzero 2 hours ago [-]
Nah vanilla Javascript is fine as it was built to make stuff more interactive on the frontend side, which it works great for.
addaon 17 hours 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.
hi_hi 18 hours 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”?
masfoobar 10 hours 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.
aktau 14 hours 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/, it seems like what PJAX does is item #3: "Partial page replacement"
pjax.connect({
"container": "content",
"complete": function() { MathJax.typesetPromise(); }, // Reload mathjax after a pjax load.
"autoAnalytics": false
});
sgt 1 days ago [-]
Exactly, I just released another project made with htmx and it's almost like you can't beat that velocity.
germandiago 7 hours 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.
mlhpdx 23 hours 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_ 23 hours 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 21 hours 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_ 21 hours 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.
orphereus 1 days ago [-]
Sorry, but at that size (1.25 liters) for my European brain, it's not a mug anymore, it's a barrel.
TeMPOraL 24 hours 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.
crote 24 hours ago [-]
I think the legal term is a "heart attack".
walthamstow 24 hours 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
scumdude 1 days ago [-]
Tell me about it. I made a joke about the store selling 'Complexity Bad' onesies, and he started selling them later that day.
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 22 hours ago [-]
Yeah I had the same thought. I was vaguely interested before, but I have no desire to own more garbage
randallsquared 10 hours ago [-]
To be clear, making clothing is not actually their business.
inigyou 5 hours 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.
Induane 1 days ago [-]
That's amazing!
sublinear 24 hours ago [-]
So you drink weak coffee and insist on server-side rendering in 2026?
evenhash 19 hours ago [-]
In 2026, everything is server side. Serve your DOM updates encoded in JSON if you want. Personally, I find serving them in HTML to be less of a hassle.
SpaceNoodled 20 hours 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 3 hours 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!
rpdillon 1 days ago [-]
HTMX's whole vibe is amazing. It's good tech, kept simple, useful in gobs of situations, but doesn't take itself too seriously. I've used it in professional and side projects since intercooler.js, and still love it. Here's a crazy unicorn-laser-eyes mug[0] that evokes the vibes of NROL-39[1]. I adore it.
The nrol 39 mission patch is one of my favorites. You should find the authorizing docs for that patch and read the hand written notes. They're hilarious.
antihero 1 days ago [-]
I was against it for ages but having have claude use it in a simple project and being frankly sick/bored of React, it seems nice.
Incipient 1 days ago [-]
I personally find react overly engineered for my projects - vuejs (+quasar on top) is just great. Granted a little boring perhaps, but it just works, behaves as you'd expect, and doing anything just isn't that difficult.
antihero 23 hours ago [-]
I've just found having TSX on the server and TSX on the client to be a fairly trusty abstraction, and also typesafe way to update the DOM.
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.
bel8 1 days ago [-]
Quasar is amazing. But I dislike their Material design components. Would be perfect otherwise.
no_wizard 1 days ago [-]
Wish they would decouple styling from everything else.
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
oliwary 1 days ago [-]
Can likewise mirror the support for quasar, always the first framework I reach for when starting a new project. The amount of stuff you get for free in terms of setup and content is insane.
threecheese 21 hours ago [-]
Any comments on how you’re holding it? Just “Hey Claude use htmx”?
oaxacaoaxaca 11 hours ago [-]
v4 is in beta and the source has some skills files. And for me personally I'm slowly building my own rules, like not having dialogs live hidden in the main page; instead, every button that triggers a dialog should do so via an htmx call that returns a dialog and appends it to the body. And then setting rules for how Claude should write templates, leveraging Django's new partialdef feature.
trueno 18 hours ago [-]
react based shit lost the plot so hard. i've used it quite a bit, with other beefy but impressive js libs like aggrid and stuff. i'm just tired of client-browser overwork in general that feels like such a mess. having so much of a webapps logic live in the front end feels completely preposterous to me these days. we've only ever needed front end to just.. be the front end. look nice, provide the interface, give people things to click. i very enjoy having all of the behavior determined and defined from the back next to all the code that brings in the data. feels so much more like writing good software.
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
aarondf 1 days ago [-]
I was at Big Sky Dev Con when they unveiled the GameBoy game. I kid you not my jaw dropped. I thought it was some sort of like emulator gimmick until they said "everyone can take a physical cartridge home!"
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.
ballon_monkey 1 days ago [-]
I love HTMX and use it in a few projects, but its amusing how whats old is new again. .NET Framework / Web Forms had update panels to do partial rendering of web pages back in 2005. Outside of .NET developers it got a lot of hate. But to a certain extent HTMX is a super well refined and more capable version of update panels and more.
nolok 1 days ago [-]
And even that was even taking on the solution from c#'s daddy : Delphi IntraWeb suite, all the way back in Delphi 7 and after.
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.
dbattaglia 8 hours ago [-]
Coming from asp.net originally as well, my mental model of HTMX is “UpdatePanel that always works”. Asp.net AJAX lib was an interesting take at the time but my gosh was it hella complicated once you ventured past UpdatePanel.
Even though it’s basically dead tech I can’t bear to throw out my Apress book about it. :)
In a way HTMX is similar to how we used to write websites on LAMP stacks, except with higher quality of life.
epolanski 1 days ago [-]
After developing react, angular, Vue frontends for a decade, going back to good old plain server side rendered ruby, elixir, hell even php just feels right.
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.
ballon_monkey 24 hours ago [-]
I just like being able to pick up old projects that i avoided for ages, and being able to pull in HTMX and make it a bit more modern without rewriting in react/vue etc. And it feels like a modern app, not a 90s app.
throw2ih020 1 days ago [-]
HTMX is awesome. I've replaced several OSS web apps on my home server with HTMX + Go + PostgreSQL replacements. The results are lightweight, responsive, work great on desktop and mobile alike, all with the absolute minimum complexity required. The codebases are easy to understand and modify, and so far I'm going months between updates (mostly just minor bugfixes for my applications). I fully expec my mature apps will go years if not decades between required upgrades.
nicpottier 1 days ago [-]
Are any of these open source? I've gone down the go/htmx/pg path lightly a few times and I haven't loved the feel of it, but maybe I'm doing it wrong. I think just server side templating just starts feeling icky in go so maybe I'm just missing a good pattern or library.
throw2ih020 1 days ago [-]
I don't want to ID my account but they basically look like:
- 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.
How does introducing a third layer reduce complexity?
throw2ih020 12 hours ago [-]
I'm replacing existing third-party applications which have complex JavaScript frameworks with my "in house" apps using HTMX + mostly just HTML+CSS for most pages and functionality. i.e. I'm not introducing a layer, I'm replacing one.
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.
robertoandred 6 hours ago [-]
You said you added a new Go templating layer.
yawaramin 1 hours ago [-]
No they didn’t…they replaced whatever backend they had before with a Go server, which simplified things overall.
nasretdinov 1 days ago [-]
<please don't take this too seriously>
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.
</ ... >
throw2ih020 1 days ago [-]
For some of the simpler sites sqlite would have been fine, but I do need Postgres anyway for some other stuff on my server so the overall burden of standardizing on Postgres only is less than having to do tuning for two different databases. In particular sqlite has worse defaults due to backwards compatibility, so you have to do a lot of upfront config for every table and DB.
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).
nasretdinov 1 days ago [-]
Well if you already have Postgres then yes, sounds fine. I don't really agree that SQLite needs tons of tweaking -- setting journal_mode to WAL/WAL2 is the only real thing worth doing, everything else I would consider optional.
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.
throw2ih020 1 days ago [-]
Foreign key constraints, sync frequency, busy timeout, strict typing on tables, explicit types for integer primary keys, and a convention for storing dates and times are others I would want to do up front.
Induane 1 days ago [-]
I set it to enforce foreign key constraint as well.
inigyou 1 days ago [-]
Every time I start with sqlite I outgrow it in some way, so I start with postgres now.
ffsm8 1 days ago [-]
From an engineering perspective, sqlite and PostgreSQL are equivalent.
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.
sroerick 1 days ago [-]
(Me not taking this seriously)
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
nasretdinov 1 days ago [-]
Sorry can you please clarify what you mean by having two databases? You can share the same SQLite between applications if you really want
kelnos 1 days ago [-]
I think they mean that they actually do need Postgres for some of their projects, and it's easier to just use Postgres for everything, than to use Postgres for some things and SQLite for others.
nasretdinov 1 days ago [-]
Yes, but on the other hand what I'm implying is that you might not actually need it :)
sroerick 1 days ago [-]
Yeah, I mean I guess I could technically connect to the remote SQLite server on my production server. You're right. But I've never done that and that's just not the pattern people use on SQLite
nasretdinov 24 hours ago [-]
Well, no, I don't think you should be doing that :)
rtpg 21 hours ago [-]
> Unless it's a web site that can tolerate no downtime at all during schema updates, SQLite in WAL2 mode is more than enough.
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.
Dylan16807 10 hours ago [-]
Trying to have so few blips they're invisible to bug tracking is a very expensive level of uptime. It takes a lot of convenience to add up that high, compared to ignoring errors for thirty seconds at noon.
zelphirkalt 24 hours ago [-]
What I don't like about Htmx is, that it is still a JS framework, without good automatic fallbacks for a noscript situation. This leads to web devs thinking it would be great to do all the things in Htmx, even if all they have is a static page with static content.
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.
Ralfp 13 hours ago [-]
> So now I am building my own forum completely without JS, and with Python Django doing a lot of heavy lifting.
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.
It's too bad Htmx isn't just the native behavior of HTML, implemented in a cross-platform standard, that does not need to rely on Javascript in user space code. It could just be part of the browser. It should have been part of the browser.
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.
recursivedoubts 17 hours ago [-]
we are working on this minimum viable set of changes currently:
Best wishes for getting those through and thank you!
BbzzbB 18 hours ago [-]
I recall that was the intent of HTMX? His dream being to steer HTML towards these kinds of primitives and HTMX becoming deprecated.
sixdimensional 18 hours ago [-]
Yep, you're right [1] - and the author is posting in here I believe, if he sees this - I just have to say, thank you for all you've done... maybe someday the browsers, WhatWG etc. will catch up with you...
Indeed. And the amusing/disappointing/frustrating thing is: my next.js site works if you turn off JS. Links are server-rendered as links, HTML is server-rendered as HTML. If you visit one of the tools that run on the client then they won't work, but the pages that could be static content? They're static content.
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...
I have learned that whenever anything is "X if Y" it means it is really weak at X and "if Y" is just a workaround. This has saved me a lot of grief in life by identifying my personal emotional attachment to things.
yawaramin 8 hours ago [-]
That’s great, but unless you know some secret perfect technology that the rest of us don’t, every tech you use is also full of these workarounds, you just ignore them because you like the tech.
Also, hx-boost isn’t really a workaround, it’s a fully supported and documented feature.
beepbooptheory 22 hours ago [-]
I get the point but I do feel like Htmx's whole design is a big automatic fallback... If some browsers will never be able to understand the hx-get/post/etc attribs, you can just design the initial html you send over around that.
rtpg 22 hours ago [-]
while what you're saying is true in theory, you still have to make sure that e.g. your form responses do the right thing. You might think "just return the full page!" but it's extra work that for many people is busywork, and makes it harder to reuse things ("my comment post endpoint returns the rendered comment" becomes "my comment post endpoint needs to know what page the comment is in to return the fully rendered page")
In practice I think it's very easy to make your htmx application JS-requiring.
yawaramin 18 hours ago [-]
Your comment post endpoint already knows what page the comment is in, it’s in whatever page the ‘post a comment’ form is in. When we design apps in a way that respects the conventions of REST (hypermedia and resource-oriented design), htmx slots in perfectly.
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.
gen220 1 days ago [-]
Thank you to the HTMX-folks for keeping software fun! I've been a happy HTMX user and Grug essay forwarder since it first made the rounds here on HN. This was an instant purchase :)
gawa 19 hours ago [-]
Ooh, I didn't know the creator of htmx was also the author of the Grug Brained Developer! [0][1]
TIL. Thanks! Now all the Grug references in the shop make sense, as well as the wisdom and overall vibe of the htmx project :)
Is it true that the person who authored the "Grug-brained developer" essay also created HTMX?
recursivedoubts 1 days ago [-]
yep
skrebbel 1 days ago [-]
and this comment‽
recursivedoubts 23 hours ago [-]
how deep does this rabbit hole go?
sgt 11 hours ago [-]
who is the rabbit?
solatic 6 minutes ago [-]
Spoiler alert: Dujour, leading to Trinity
homarp 1 days ago [-]
he wrote the Lulu book
recursivedoubts 1 days ago [-]
hello all, we are releasing htmx 4.0 on the Game Boy and Gameboy Color (thank you rcy for submitting)
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
Hope you find it enjoyable if you get a copy and at least find it funny if you don't :)
chrismaltby 1 days ago [-]
Oh hey, I made GB Studio, really cool to see it being used for this :) I've got some nice features in progress for the next version https://www.youtube.com/watch?v=q8UKwV1gJAI
scumdude 1 days ago [-]
Sweet - thanks for your work on GB Studio, Chris. The music, sprite and palette tools were invaluable during development.
superdisk 1 days ago [-]
Did you use the built in GB studio sound engine? If so that's my code :) Always enjoyable when it pops up in places like this. Looks like a fun project.
scumdude 1 days ago [-]
Yes, we did. It was a blast using that to make the sounds and music.
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.
Amazing, can’t wait to see the first unboxing / let’s play / review videos.
iamwil 1 days ago [-]
Is it a real physical cartridge? How do you get the source code off the cartridge at the end? Or does it give you a passcode to a git repo or…like an NFT with access to the source?
sroerick 1 days ago [-]
It's a real cartridge
There's a source code reader at the end of the game, tbd if there are transfer abilities, I haven't beat it yet
The Chromatic is an awesome experience to play. The HTMX 4 game has an auto-loader which immediately drops you into the game at your last checkpoint. Since the Chromatic has no boot screen, you're back in play within a second of powering on the system.
WD-42 19 hours ago [-]
Do they license from Nintendo or something? I thought this kind of stuff was lawyer bait.
asploder 1 days ago [-]
This is too funny, how could I not?
Klonoar 1 days ago [-]
How much did this cost to make/produce?
sroerick 1 days ago [-]
Whatever it cost, he also gave out free copies at BSDC, what an unbelievably cool and nice thing to do
zogrodea 1 days ago [-]
"Big Sky Dev Con", not "Better Software Conference" for those who were (like me) initially confused. :)
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.
I'll also say - scum gave a presentation which was actually very touching. "Love what you do, care deeply about your projects, be with your family". Combined with everything you already said - pretty awesome stuff
scumdude 1 days ago [-]
Wait - you guys got paid?
Klonoar 1 days ago [-]
Reddit is that way ->
sroerick 20 hours ago [-]
lol you're talking to the guy who coded it
Klonoar 15 hours ago [-]
Then I retract my knee-jerk reaction and label myself a moron. :)
Thanks for pointing it out, lol
andy800 23 hours ago [-]
Amazing... an HTMX thread without any haters interjecting or critics telling everyone why HTMX wont work.
Even React-aholics have to tip their hats to a Game Boy release.
sroerick 20 hours ago [-]
Crazy how much things have shifted since a few years ago
buildwrangler 1 days ago [-]
I made the switch to HTMX recently After 12+ years of building web apps with Javascript and its been nice. I always hated the build complexity of modern Javascript, so much tooling, dependencies and packages to get basic functionality.
luciana1u 1 days ago [-]
next release ships on a Tamagotchi and if you don't feed it, it deletes your DOM
scumdude 1 days ago [-]
How... how did you know?
wvbdmp 1 days ago [-]
I’m amazed at how cheap this is. How is this possible for what I’m assuming is a relatively low-volume physical product? I don’t suppose it’s produced on-demand, but also Carson Gross probably doesn’t have 1000 of these boxes at his home, or I would have seen the pics on twitter.
recursivedoubts 1 days ago [-]
we are selling it pretty cheap we got 1000 made and gave 150 away to Big Sky Dev Conf attendees
Not trying to make money on it, it’s for the lols
xupybd 1 days ago [-]
Why not both?
recursivedoubts 24 hours ago [-]
idk just seems like $25 is a good price for a fun game you know?
jbanes 23 hours ago [-]
That’s my doing. I already had a pipeline of contacts for manufacturing GameBoy games at various levels of quality and cost. Being involved from the beginning, I was able to influence development to ensure we could produce the lowest cost product that met the quality levels needed to blow up everyone’s collective minds.
pelagicAustral 10 hours ago [-]
I love these guys sense of humor in having a HTMX Sucks line in their inventory with literal nice products, like the Christmas jumper...
asdfsa32 8 hours ago [-]
It is drop shipping stuff.
sethops1 3 hours ago [-]
A true statement for virtually any piece of merch you could buy from any company.
asdf88990 22 minutes ago [-]
Hardly. The quality stuff are often not drop shipped.
novoreorx 18 hours ago [-]
In the pre agentic coding era, I was hyped about HTMX for providing a classic way of web development over React. But after not writing code for several months, all work done by claude code / codex, I find myself not caring whether the framework is HTMX or React anymore. I mean, why do you bother if you don't write the code yourself. And I'm even starting to feel React's advantages: good ecosystem, rich UI kits, reusable components… these are all where HTMX falls short. I'm surprised to see most people in this thread didn't mention any of these.
bubblebeard 17 hours ago [-]
I can understand that feeling, but remember that just because you have been handed a new powertool you mustn't always use it. Life is not about optimizing everything. It makes redundant work faster, where you fully understand from the outset how to write something, but this just frees you up to learn and explore new things, and work on stuff just for the fun of it, like this.
novoreorx 13 hours ago [-]
Agreed that life is not about optimizing everything. I do enjoy writing code by hand when the framework or language is delightful to work with， it's just that HTMX isn't that choice for me. The h-attributes model doesn't fit the way I think. Also, my original point was more that once agents write most of the code, "delightful to hand-write" stops being the main criteria for picking a framework.
yrds96 17 hours ago [-]
I don't see a relation in this. You can both use LLMs and care about your codebase design. Frameworks and libraries are still relevant, and each one has its tradeoffs.
16 hours ago [-]
asdfsa32 17 hours ago [-]
Is there any substantial web app written htmx?
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.
brutella 14 hours ago [-]
I'm using htmx in the hkknx web app to control smart home accessories.
Yeah, it is interesting that most people who promote htmx are not "insiders" (for the lack of a better word that isn't loaded like "expert").
bashZorina_09 12 hours ago [-]
Has or will the ROM be made available for online purchase? Totally understand if it'll be kept cartridge only, the novelty is fantastic haha!
hirvi74 1 days ago [-]
While I am not particularly a fan of HTMX, I do absolutely adore how Carson and the team always have such a great sense of humor with the project.
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).
hollow-moe 1 days ago [-]
Love to see new stuff on ancient platforms. Surprised I couldn't find a post about Micro Mages on HN, only comments. https://youtu.be/ZWQ0591PAxM
Spoiler, when the time will come you'll never see something like this on the play station 4.
Aachen 20 hours ago [-]
Exclusively? Htmx runs in a browser, as people in this thread are attesting with how they've been using it for years
andy800 16 hours ago [-]
The Game Boy contains source code of the upcoming HTMX 4.0
felixrieseberg 1 days ago [-]
This is beautiful, the title alone gave me a good chuckle.
vkaku 1 days ago [-]
This might be my first new Gameboy Cart in like ever. So looking forward to this HTMX release.
0gs 1 days ago [-]
htmx is so great. i feel like every week i discover some lovely way it helps things run more smoothly
dzonga 1 days ago [-]
this is the counter culture we all live for.
well done to the htmx team.
gulugawa 15 hours ago [-]
While I prefer to stay with an approach of using web components for my current work, HTMX seems like a good option to consider for future work.
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.
all2 1 days ago [-]
As a side note, anyone is welcome to add 'CEO of HTMX' to their LinkedIn profile.
...I may have done this.
dizhn 1 days ago [-]
There is one thing I don't like about htmx. It's that they like to use the HATEOAS acronym. It's a bad acronym in every conceivable way.
bogzz 1 days ago [-]
They HATEOAS because they Hain'tOAS.
kitd 1 days ago [-]
Why?
dizhn 13 hours ago [-]
- Starts with HATE
- 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.
zaydmulani 7 hours ago [-]
[dead]
dfaoidsoi 1 days ago [-]
[dead]
ai_fry_ur_brain 21 hours ago [-]
[dead]
nih567 1 days ago [-]
[dead]
thrance 1 days ago [-]
[flagged]
jbanes 1 days ago [-]
I didn’t do the art, but I did do the graphic design/layout of the box. I can assure you there was no AI used on the box. (Well, except for the CRT effect on the screenshots. ChatGPT helped out there.) I did the work in PhotoPea using the artist’s original work as a base.
recursivedoubts 1 days ago [-]
The cover art is by ash on fiverr. He also did the cover of hypermedia systems:
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.
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
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:
When people complain about this stuff, they just reveal they don’t know HTML.> …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.
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"
https://news.ycombinator.com/newsguidelines.html
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.
This was my trick for cutting back to two cups of coffee a day.
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'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.
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:
UPDATE: Reading 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. It is invoked at the end of <body>:
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.
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.
1.25 liters is way beyond even my own addiction to lightweight liquid stimulants.
https://x.com/scumitchell/status/1886825775560528069?s=20
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!
[0]: https://swag.htmx.org/collections/octohorse
[1]: https://en.wikipedia.org/wiki/USA-247
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.
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
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.
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-...
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.
- 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.
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.
https://github.com/a-h/templ
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.
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.
</ ... >
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.
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
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.
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.
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...
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.
https://triptychproject.org/
[1] https://htmx.org/essays/future/#writing-research-and-standar...
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...
Also, hx-boost isn’t really a workaround, it’s a fully supported and documented feature.
In practice I think it's very easy to make your htmx application JS-requiring.
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.
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-...
[1] https://grugbrain.dev/
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 :)
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!
There's a source code reader at the end of the game, tbd if there are transfer abilities, I haven't beat it yet
https://modretro.com/products/chromatic-tetris-bundle
you can find cheaper ones on amazon/temu too
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.
Thanks for pointing it out, lol
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 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.
https://hkknx.hochgatterer.me/
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).
well done to the htmx team.
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 may have done this.
- 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.
https://hypermedia.systems
Your client does not have permission to get URL /en-cad/products/htmx-4-the-game from this server.