[blister]

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]

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]

HTMX is just as JS compute heavy. It's not magic.

[yawaramin]

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]

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]

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]

> 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

[jdiaz97]

yeah if that's a problem you can always use fixi https://github.com/bigskysoftware/fixi

[troupo]

What does that have to do with anything? Literally the same thing (only difference is size)

[rolymath]

You're saying we need magic for different js frameworks to have different performance profiles?

[stevoski]

> 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]

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]

JavaScript ?

[sevenzero]

Nah vanilla Javascript is fine as it was built to make stuff more interactive on the frontend side, which it works great for.

[albuic]

I don't agree. JavaScript was definitly not fine when it started and because of it, people had to create multiple libraries and framework to go around differences in web-browsers. They got used to libraries and big framework as they really were necessary first. Now that JavaScript is pretty good, they are still used to frameworks and libraries which are very often unnecessary.

[addaon]

> 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]

> 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]

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.

[tracker1]

FWIW, there is some decent tooling options for C# with Razor + HTMX that are worth looking at. From JetBrains and others.

[masfoobar]

Yes - with C# websites - I default to Razor (and htmx) Very fluid, imo.

[aktau]

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"

[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
  });

[sgt]

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

[mlhpdx]

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_]

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]

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_]

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]

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

[TeMPOraL]

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]

I think the legal term is a "heart attack".

[walthamstow]

It's more than double the size of a Sports Direct mug, which is about the largest cup of tea a Briton would consider

[germandiago]

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.

[scumdude]

Tell me about it. I made a joke about the store selling 'Complexity Bad' onesies, and he started selling them later that day.

https://x.com/scumitchell/status/1886825775560528069?s=20

[inigyou]

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]

Yeah I had the same thought. I was vaguely interested before, but I have no desire to own more garbage

[randallsquared]

To be clear, making clothing is not actually their business.

[inigyou]

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]

That's amazing!

[sublinear]

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

[evenhash]

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]

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]

I mean a radically different view is that the SERVER should just give you the data and process your requests, without necessarily caring much about what you are - a browser or some other automated system, or a desktop client, where each has vastly different preferences on how the content might get displayed or used.

With that approach, a clear API in the middle and a SPA on the client side makes a bunch of sense (as long as you don't make some chimera of hydration and pre-rendering and server-side components while pretending that it's still a SPA and it "just works" while your server is coupled to the client).

Of course, what you actually need depends on your circumstances and sometimes even preferences. For a bunch of internal or personal stuff, SSR can be really nice and simple!

[andy800]

You're correct that it's a matter of the developer's view, or philosophy. The issue I have with "just give you the data" is that requires the server to encode the raw data somehow, most often JSON, send it down the wire just to have the client un-encode it, store it, and populate HTML elements with it. Meanwhile server-based templating is exceptionally lightweight and fast (especially when compiled) and so converting the raw data directly to HTML on the server via templates tends to be faster and lighter and cleaner, as "state" (not counting ephemeral or stylistic attributes) is maintained in a single place.

You make a good point that different clients may represent the data differently, although again that's easy to handle on the server by using a header or other identifier of the client, and using the appropriate template.

There isnt a definitive right or wrong, both approaches can work but the reason HTMX has found a following is that lots of developers are tired of the complications and difficulties that SPA frameworks seem to introduce, and reverting back to a server-based philosophy is allowing them to be more productive.

[KronisLV]

> There isnt a definitive right or wrong

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).