[HN Gopher] Why you should choose HTMX for your next web-based s...
___________________________________________________________________
Why you should choose HTMX for your next web-based side project
(2024)
Author : kugurerdem
Score : 41 points
Date : 2025-07-19 14:23 UTC (8 hours ago)
(HTM) web link (hamy.xyz)
(TXT) w3m dump (hamy.xyz)
| Finnucane wrote:
| " This feels better to the user because changes feel faster"
|
| This is debatable. Plenty of js heavy websites feel slow and
| clunky.
| flemhans wrote:
| Agreed, I'm always relieved to visit sites made the "old" way
| because they are fast.
| MountainMan1312 wrote:
| I'm toying around with HTMX for my website. It's going to be sort
| of a wiki but a little different; the public exports from my
| internal knowledgebase with some extra crap mixed in.
|
| I have lots of notes of varying types and formats. Org-mode files
| are all pretty standard, but there's like 3 different Markdowns
| and an untold number of randomly-formatted .TXT files. I want to
| generate their webpages on-the-fly and not have to worry about
| exporting it.
|
| One of the "crap mixed in" things I want is to integrate parts of
| a gitweb-like interface into the notes. I reference repos and
| commits regularly in my notes. Would be neat to mouse-over them
| and get a little popup with basic info about it.
|
| I also like that the author refers to themselves as a
| Technomancer. Personally I'm an metamagical artificer. I love
| meeting fellow adventurers.
| chistev wrote:
| If it is too much of a pain with vanilla js, just use Svelte
| ranger_danger wrote:
| I can't believe they still don't have a way to parse JSON
| responses automatically.
|
| If you combine e.g. hx-post with hx-target, then it will put the
| text from the response into the target selector... but there is
| no "hx-source" to select what part of the response to use.
|
| I'd really love to be able to set e.g. hx-source="somejsonfield"
| instead of having to manually handle the response with a custom
| function that parses/error checks the json and then sets the
| selector's text to the value of a json key. It could really save
| a lot of boilerplate code IMO.
| philipswood wrote:
| The philosophy of HTMX is not to send JSON, but HTML fragments.
| majorchord wrote:
| They didn't mention sending JSON though... and you can
| absolutely return HTML fragments in a JSON response.
| ncruces wrote:
| But why?
| majorchord wrote:
| Fetching data from APIs I have no control over, or ones
| that serve multiple purposes and use a single response
| format
| kemayo wrote:
| I guess I could see it for decoupling your need to
| control the API you're using. The case where you have an
| existing API, whether your own or someone else's, and
| just want to get a new frontend hooked up to it.
| purerandomness wrote:
| Then what's the point of using HTMX?
|
| If you're not sending just exactly the necessary HTML to
| replace the target's HTML; if you need to parse JSON, then
| even jQuery would be better suited.
|
| The whole idea of HTMX is to get rid of the extra steps.
| majorchord wrote:
| I don't always have control over the remote end or due to
| business reasons the format can't be changed.
|
| And since htmx also has template plugins, being able to
| feed JSON values into it makes sense to me... a similar
| project, EHTML has this feature.
| hungryhobbit wrote:
| HTMX seems like a solution in search of a problem.
| krackers wrote:
| That should be the tagline for their next tshirt~
|
| https://swag.htmx.org/en-usd/collections/htmx-sucks
| nine_k wrote:
| HTMX is a solution of a problem like the following: how to add
| small bits of server-based interactivity to an otherwise static
| HTML page?
|
| One way would be to go with React, Nest.js, setting up SSR and
| hydration of just the right fragments, etc. Another would be to
| take your existing static HTML page, and add very few bits in a
| specific place.
|
| An easy example: a "like" button + counter of "likes" under a
| blog post.
|
| If you need a complex SPA UI, you need a different tool.
| lvl155 wrote:
| At what point are we going to say browsers with JS is outdated
| and painful? Every few months there's some new framework. I think
| it stems from the fact that we refuse to change the browser. HTML
| was nice but all these solutions to make it modern are...ugly.
| And don't get me started on JS. I just want an elegant solution
| that's intuitive and built for modern applications.
| bnchrch wrote:
| I think your suffering from the same thing that makes 2014 feel
| like 5 years ago when its over a decade ago.
|
| The framework landscape has remained relatively entrenched in
| React since 2016. Sure theres a few new ones time to time but
| nothings ever come close to unseating it in the same way it
| took over from Angular.
|
| (Yes you could argue Nextjs but thats just react with a backend
| bolted to it)
| ChadNauseam wrote:
| Many web developers make applications that are expected to work
| on every platform, every screen size, load instantly for new
| users, sync user state between every device instantly, and work
| offline (in some cases). All this takes place in an execution
| environment that perfectly sandboxes it, allowing users to
| download and run any application without any fear of viruses.
| Yes, the stack is complicated, but it's a complicated problem.
| The fact that people are making libraries to make web
| development simpler... well, no platform other than the web has
| even attempted to achieve everything I've listed, so we don't
| really have a point of comparison.
| satvikpendem wrote:
| You might be interested in this:
| https://docs.google.com/document/u/0/d/1peUSMsvFGvqD5yKh3Gpr...
|
| It's by the Flutter team lead talking about how with WASM we
| can redo the web stack by eschewing HTML, CSS, and JS entirely.
| xdfgh1112 wrote:
| That is more or less how flutter works on the web, right?
| satvikpendem wrote:
| That is correct.
| cosmic_cheese wrote:
| I've been saying for a while now that browsers need something
| closer to a proper UI toolkit, or at minimum "batteries
| included" primitives built in for ages now. It'd be a much-
| needed paving of a desire path that's been so heavily trodden
| it's become a canyon.
|
| The WASM approach holds promise too and is interesting to me
| for opening up support for non-JS languages, but a built in UI
| toolkit would bring the advantage of not needing a compiler or
| toolchain (just like the traditional web) which can be
| advantageous and lowers the bar for entry.
| tekkk wrote:
| I got a wave of shudder reading the acronym "HAM stack". Yugh.
| MEAN, MERN, RERN-once hyped up hot air which now sounds so dated
| and hackneyed. It's cool to be excited about tech but if your
| main selling point is building "faster and cheaper", I don't know
| if picking up a minimalistic framework you know nothing about is
| faster than just re-using your trusty boilerplate.
|
| Be it React or Svelte or whatever. With serverless backend if you
| want to keep costs down. Although a server from Hetzner isn't
| that expensive and you can host multiple APIs there.
| tacker2000 wrote:
| The problem is not the server cost, the problem is maintaining
| the (multiple) APIs altogether.
| wavemode wrote:
| cute stack names have gone downhill since LAMP
| cjs_ac wrote:
| HTMX sets up an underlying network traffic pattern:
|
| 1. The user interacts with the page.
|
| 2. The page sends a request to the server.
|
| 3. The server returns one response to the client, containing
| HTML, which the client inserts into the page.
|
| 4. (Optional) If the response includes references to other
| resources, like images or fonts, the client makes more requests
| for these.
|
| The consequence of the 'one request, one response' thing is that
| the whole thing is _fast_. All the HTML arrives in one go. None
| of this request-one-thing-then-run-some-JS-on-the-client-to-
| decide-whether-to-request-another-thing nonsense that you can
| watch happening in real time that happens in an alleged
| productivity tool I have to use at my day job.
| cyanydeez wrote:
| so as long as you dont expect to scale, it works? Is the
| connection atleast long lived?
| sgt wrote:
| Htmx can scale. It's very basic and Htmx isn't the only
| technology to use that approach.
| uh_uh wrote:
| It cannot scale because it doesn't have a solution for
| reusable components. That's why I have abandoned it.
| Frameworks like React solve this in a much saner way.
| renerick wrote:
| Reusable components are prerogative of the templating
| system, such as React, or Vue, or server side templates
| that the framework of your choice uses. Htmx works with
| already rendered HTML fragments from the back end and
| doesn't do templating on its own, so there's simply no
| room for it to "solve" reusable components
| zenmac wrote:
| well now we got Web Components baked in. People don't
| want to give up React cause it is where many paying job
| is coming from.
|
| It is the age old problem between better tech or better
| pay? What is even worse younger dev come in wanting to
| learn React cause it is the one that most job post is
| looking for. We end up negative economic to tech quality.
| victorbjorklund wrote:
| You make the reuseable components in the server
| templating language. It is like saying PHP, Django, Go
| etc does not scale
| librasteve wrote:
| https://harcstack.org does components like this
| https://rakujourney.wordpress.com/2025/07/06/harc-stack-
| comp... class Counter does Component {
| has Int $.count = 0; method increment is
| controller { $!count++; self
| } method HTML { input
| :id("counter-$.id"), :name("counter"),
| :value($!count) } }
| Multicomp wrote:
| /sarcasm/
|
| Which is so much worse than the current paradigm where we have
| a client side SPA deciding to do all sorts of state syncing and
| react hooks and tracking pixels and auto pop ups all doing
| their own thing all over the place!
|
| /end sarcasm/
|
| I think for a side project, not immediately expecting your
| front end's first version to not horizontally scale to the moon
| is ok.
| exiguus wrote:
| Is it basically like Ajax?
| hmry wrote:
| Yeah it's exactly AJAX. Except instead of writing Javascript
| to send requests and insert the response into the document,
| you use declarative HTML attributes to describe what you want
| to happen.
| redwall_hp wrote:
| Yes. The cycle has completed and the old new things are new
| again. But they're still too new and unproven for the React-
| embroiled companies to switch just yet.
|
| HTMX is basically a framework for AJAX that lets you more
| quickly set up interactions in the markup instead of having
| to write scripts to manipulate the DOM yourself. It also
| tells on sending HTML fragments over the asynchronous request
| instead of JSON that has to be "rendered."
| jbreckmckye wrote:
| > But they're still too new and unproven for the React-
| embroiled companies to switch just yet.
|
| I've seen a few of HTMX projects attempted in production,
| at my previous employer. Decently sized, moderately complex
| web products for serious commercial purposes
|
| I will say though, all three were complete disasters.
| thom wrote:
| It's basically the exact type of framework you probably built
| on your third or fourth Ajax project 15 years ago -
| declarative, progressively enhanced, simple.
| rapnie wrote:
| I recently found Datastar [0], another hypermedia project. It was
| originally inspired by htmx, but they are fully on their own
| (hypermedia) course. According to the devs, who had a bunch of
| discussions with maintainers of htmx, the htmx project considers
| itself finished and no new features forthcoming. It is laudible,
| a project considering itself complete.
|
| Datastar considers its library v1.0 release [1] to be complete,
| offering a core hypermedia API, while all else consists of
| optional plugins. The devs have a hot take wrt htmx in their
| release announcement:
|
| > While it's going to be a very hot take, I think there is zero
| reason to use htmx going forward. We are smaller, faster and more
| future proof. In my opinion htmx is now a deprecated approach but
| Datastar would not exist but for the work of Carson and the
| surrounding team.
|
| When you think of adopting htmx, it may be worth making a
| comparison to Datastar as well.
|
| [0] https://data-star.dev/
|
| [1] https://data-star.dev/essays/v1_and_beyond
| ipaddr wrote:
| By the time they posted that they were deprecated and everyone
| is now on jQuery.
| AndrewKemendo wrote:
| Considering most of my side projects are web based and I loathe
| JS and prefer MPA patterns, this is very intriguing. I admit I
| haven't been keeping up with HTMX or new web frameworks.
|
| Anyone have any examples that are noteworthy?
| jbreckmckye wrote:
| As I mentioned in a comment above, I've seen a few commercial
| projects attempted. But I'm hesitant to recommend HTMX, all
| three of them were failures (and for technical reasons not
| business ones)
| librasteve wrote:
| great to see yet another H-stack
|
| so far I got HARM (Rust), HARC (Raku) and now HAM (F#) along with
| Fast HTML / htpy (Python) and GOTHH (Go)
|
| seriously, it is very good news that HTMX has uncoupled web
| development from the server side language choice
|
| now there is a blossoming of many server side stacks to fill this
| new opportunity
|
| I wrote https://harcstack.org because Raku is the natural
| successor to perl and PHP for web development due to its facility
| with text processing and multi-paradigm chops
___________________________________________________________________
(page generated 2025-07-19 23:01 UTC)