23 ms·

Please just try HTMX

• coolgoose 10mo ago
  I don't get why people don't just use vue... with no build step, just including it.
• iamsaitam 10mo ago
  ..and be unemployed. The article doesn't define any target audience in specific, so there you go.
  • gear54rus 10mo ago
    yeah, I'll try htmx if he will maintain the resulting pile of goo lol
  • WolfeReader 10mo ago
    I don't think learning a new tool will cause you to be unemployed.
• politelemon 10mo ago
  The author seems to have some beef with angular, which I have found lighter and more pleasant to use compared to react.
  • mattlondon 10mo ago
    Same here. Modern angular is pretty nice to work with. Yes It has a "learning curve" but so does everything (even React). Also Angular is now about twenty thousand times simpler than it was in the past as you can use Signals for reactivity, and basically ignore Observables for 95% of things. Angular also removes the a lot of the negatives outlined in the page - no npm, no node_modules, no ecosystem fatigue, no debates on state management etc etc. Everything you need is included in one dependency you can load from a CDN. I never liked that in react you are mangling the presentation and business logic in one tsx file (separation of concerns? React ignores that lesson for some reason). Htmx feels even worse in this way because now you also have html snippets and templates in your backend code too! Nightmare! Angular let's you leave the templates as standalone files and not mushed into your typescript like react (although you can inline them into the typescript if you want to, but obviously no one does that for anything apart from the most trivial of components)
• xg15 10mo ago
  > The whole library is ~14kb gzipped That'll be item #848 in my 847 line package.json.
• TeodorDyakov 10mo ago
  what is the use case. I did not read the page. Can you tell me where stars live?
• purerandomness 10mo ago
  Please install a TLS certificate to the site so people can view the content.
  • CompuHacker 10mo ago
    The link doesn't point to an HTTPS server.
    • philipwhiuk 10mo ago
      Exactly - it's on a short leash towards being blocked by browsers. https://security.googleblog.com/2025/10/https-by-default.html https://security.googleblog.com/2025/10/https-by-default.htm...
  • DaSHacka 10mo ago
    There is a cert, it's just not signed by a CA.
    • g947o 10mo ago
      That's in some sense even worse than plain HTTP, because it gives you a false sense of security.
      • DaSHacka 10mo ago
        Not really, modern browsers warn about self-signed certificates the same as HTTP (or sometimes even more). And obviously you can in theory verify the signature's fingerprint akin to a trust-on-first-use model like SSH. May not be as standard as a CA model in the current landscape, but trust on first use has shown to be perfectly fine for SSH, and has the advantage that you're not trusting third parties to only sign valid certificates for authorized parties.
        • g947o 10mo ago
          I think you lost the context > modern browsers warn about self-signed certificates the same as HTTP So if I can read and understand those browser warning and am not a complete idiot, I will close the browser tab instead of proceed despite the warning. Which is the correct choice. So now I cannot read the website at all. Otherwise, if I do make the bad decision and accept the certificate, I don't know what will happen. But with HTTP, at least the browser says clearly that the site is unsafe. So the fact that the website does have a certificate and serves HTTPS, as suggested in the GP, is completely irrelevant and useless. > trust on first use has shown to be perfectly fine for SSH If that is MY server or a server I trust/can verify. I don't know about you, but I never SSH into someone else's server and just blindly accept the keys. GitHub, for example, provides their SSH keys: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints https://docs.github.com/en/authentication/keeping-your-accou...
• philipwhiuk 10mo ago
  The proselyting over frameworks is the worst bit of the web ecosystem. If your solution is actually good, it will get adopted eventually... Forget React, there's still stuff written in jQuery and JSP. Why the rush to convert everything - you're not a missionary on a mission, just build your stuff in stuff you like? The attack on npm is ridiculous, when (apart from introducing a permanent vulnerability in the form of a runtime dependency on a third party site), you still need npm for htmx.
  • purerandomness 10mo ago
    > If your solution is actually good, it will get adopted eventually... I wish this were true. Unfortunately, often the things that get adopted are the things hyped up the most, not the ones which are technically superior. Popularity, marketing budgets and inertia often dictate what's popular. As with all biases, we need to actively and deliberately work against these forces, if we value craftsmanship and professionalism.
    • komali2 10mo ago
      Nextjs, great example of this. I've yet to find an actually valid use case to choose it outside of "our incestor's relationship got us unlimited vercel credits for like three years."
  • dec0dedab0de 10mo ago
    You definitely don't need npm for htmx, it's one file with no dependencies.
    • jollyllama 10mo ago
      For all of the esoteric talk about hypermedia and things like this, this is the greatest advantage of HTMX, why I use and, and also why GP is dead wrong.
  • dubcanada 10mo ago
    > If your solution is actually good, it will get adopted eventually... This has never been more incorrect. The entire world of software is people using garbage solutions because the CTO is convinced Oracle/Microsoft/what ever new random software is the best thing since sliced bread. In no fashion has the best software solution ever been a factor.
• asim 10mo ago
  Man I did try htmx, and I was hopeful, right until I saw how it polluted my codebase. I can't say I have the answers, but writing a pure Go app, I'm currently using one giant css file, custom styling and inline html. And now I'm at the breaking point. So I'm planning to move to tailwind and Go templates, but honestly, i was hopeful for htmx, so I need to properly see the usecase. Which i don't know is this. It reminds me of Angular a lot...
  • yxhuvud 10mo ago
    Turbo with a small sprinkling of stimulus may be closer to what you are hoping for - turbo especially is a lot more opinionated than htmx.
  • kitd 10mo ago
    This is the thing. Htmx is great if you only consider the frontend. But it does require fixing up the backed to match. A framework like that needs to integrate the front & back ends fairly tightly to have good UX. You may be interested in Datastar which does this better IMHO https://data-star.dev/ https://data-star.dev/
    • asim 10mo ago
      Thanks I'll look into it, but on first glance I feel like I just got space blasted by the website! What happened to simple websites eh
      • kitd 10mo ago
        Lol, it's ... a feature ... I think
        • asim 10mo ago
          Well I guess part of the problem is I feel like I'm looking at the website with a magnifying glass...
      • nchmy 10mo ago
• catapart 10mo ago
  Sorry, but it's a no from me. htmx is a great idea, but it's not necessary anymore. We're very close to invokers being baseline (and even that is just an extension of the "composedPath includes -> invoke" pattern), and that will take care of plenty of what htmx was designed to do. Between features like that, and web components, I'm very happy to stick with "plain HTML" (no frameworks; my web components do not draw from a core module or anything). Also, just a suggestion because it's not technically wrong: The example of sometimes needing an auto-completing search box is probably not the best one to use. I'm sure it's meant to say "you want the results to be queried from a server/database on every input", which you would certainly need javascript for. But the specific example of just having a search box autocomplete can actually be fulfilled with a datalist element. It won't dynamically re-query results, but it will filter based on input. So it's a muddy example, at best, and that's probably not great for the point trying to be made.
  • purerandomness 10mo ago
    > We're very close to invokers being baseline Well why not have the benefits of invokers, but today - with HTMX? HTMX could eventually switch its implementation to use invokers under the hood in the future, and you'd have the convenience of using declarative behaviors on your buttons, today. > autocomplete can actually be fulfilled with a datalist element I wish that the spec would cover more use cases, but last time I tried to use it, I couldn't, because it has really bad UX, and is inconsistent across browsers. Also, like you mentioned, it only works for small data sets that you can deliver with the initial HTML, not large amounts of data which reside on the server. You could argue that these are use cases where you wouldn't require an auto-complete in the first place, because the data set is too small.
    • catapart 10mo ago
      > Well why not have the benefits of invokers, but today - with HTMX? Because I already have the benefit of invokers, today, using the composedPath method. And a map to some functions is usually less, in my experience, than 14kb of js.
  • lunar_mycroft 10mo ago
• geoffeg 10mo ago
  > After the user downloads 2MB of JavaScript, waits for it to parse, waits for it to execute, waits for it to hydrate, waits for it to fetch data, waits for it to render... yes, then subsequent navigations feel snappy. Congratulations. In my experience, a lot of SPAs transfer more data than the front-end actually needs. One team I worked on was sending 4MB over the wire to render 14kb of actual HTML. (No, there wasn't some processing happening on the front-end that needed the extra data.) And that was using graphql, some dev just plunked all the fields in the graphql query instead of the ones actually needed. I've seen that pattern a lot, although in some cases it's been to my benefit, like finding more details on a tracking website than the UI presented.
  • g947o 10mo ago
    even for "downloads 2MB of JavaScript", it is often simply because the site is badly written (e.g. not careful about managing dependency), not necessarily because "JAVASCRIPT BAD". Just look at the source code of amazon.com. It's a mess. But I bet it is more of an organizational problem than a tech stack problem, for a website worked on by literally hundreds of teams (if not more) where everyone crams their little feature in the website home page
    • otherme123 10mo ago
      > it is often simply because the site is badly written I find that some techs tend to cause badly written code. I have junior coworkers that can write clear Python after a short intro, but can't write clean R after a year using it daily. I don't know if it is caused by the philosophy behind the language, the community, the tutorials and docs...
• werdnapk 10mo ago
  I've had good success with Turbo (previously Turbolinks). The newer versions (ie. Turbo) really fixed up the shortcomings of the older versions (ie. Turbolinks) and I enjoy using it. Any big reason to use HTMX instead? Is Turbo not really discussed much because of it's association to RoR?
  • Aldipower 10mo ago
    I have fond memories of Turbo Pascal.
• deleted 10mo ago
  [deleted]
• magnio 10mo ago
  For those wanting different colored pills, there are https://justfuckingusereact.com https://justfuckingusereact.com https://justfuckingusetailwind.com https://justfuckingusetailwind.com https://www.justfuckinguserails.com https://www.justfuckinguserails.com
• g947o 10mo ago
  I am tired of people using the smallest "Hello World" example to demonstrate how something is better than React -- "See, you don't need all these things to get a website up and running!" Of course it will work. I can vibe code the most terrible web framework you have seen within 20 minutes and claim it is better than React, but what does it prove? > You write zero JavaScript > The whole library is ~14kb gzipped Oh sure, if there is nothing else in your UI, and if your Python/Go/whatever backend server has 0 dependency, which almost never happens.
  • foldr 10mo ago
    In fairness, the article has a section titled “The Numbers” which links to this: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/
    • g947o 10mo ago
      Different teams/projects have different needs and require different solutions. While it's good it worked in their favor, I am quite confident that someone else can tell a completely different story. In fact, there are some comments in this very HN discussion that detail their negative experience with htmx. I would not use one or the other to "convince" anybody to go with either solution like what this article attempts to do.
      • testermelon 10mo ago
        Disliking evangelism is something most of us can relate. I give you that. And everything you said is very reasonable. But have you tried it though? Don’t you think it’s time to give your story? Slam your needs to htmx and see what comes out of it’s ruins?
        • g947o 10mo ago
          I did something similar to htmx over a decade ago, so I know what it's about. And everything I need to say is already said by others in a more elegant way. > Don’t you think it’s time to give your story? I am afraid that's completely irrelevant to my comments here. If you read my posts carefully, you'll notice that I haven't said a single negative thing about htmx itself, because I want to very cautious in giving opinions. Everything I said was specifically about the horrible arguments in this article.
• 0x3f 10mo ago
  The thing is React is usually fine, and even if you don't have to build _this_ thing in React due to simplicity, why bother learning two paradigms when you can just use the heavier one for everything and most likely never encounter any real practical showstopping issue?
  • avisser 10mo ago
    > why bother learning two paradigms Objection. Your React is ultimately turning into HTML so you DO have to learn HTML + CSS. You just have an abstraction over it.
    • xnorswap 10mo ago
      That's like saying my C# is getting turned into CLR bytecode, so I do have to learn CLR bytecode because I have an abstraction over it. Yet I know roughly what it is, but I couldn't begin to actually write the stuff myself. Good abstractions mean you don't have to worry about the layer below. Now of course it's not really the case that React holds up to being a good abstraction, especially when it comes to CSS and styling, but I don't think it's a forgone conclusion that abstractions force you to learn the level below. Otherwise we'd all spend half our time learning assembly. I do have sympathy though for a developer who just wants to focus on the higher level paradigm and let the library maintainers worry about the innards.
      • naasking 10mo ago
        > That's like saying my C# is getting turned into CLR bytecode, so I do have to learn CLR bytecode because I have an abstraction over it. That's not a valid analogy, 99.99% of C# developers never see or touch CLR bytecode, where every React developer is still working with HTML+CSS.
        • xnorswap 10mo ago
          That's possibly true, but I wonder why react as an abstraction fails to deliver that kind of independence. In theory, react developers ought to be able to code against the react API in typescript, without seeing the "raw" HTML+JS that gets delivered to the browser. So what's failing those developers? Is it the tooling, the abstraction itself, or something else?
• ncr0 10mo ago
  So we are almost back to using XSLT (and this is a good thing)
  • kitd 10mo ago
    Sorry, I'm struggling to see the comparison
  • vaylian 10mo ago
    Does XSLT support making HTTP requests to load new content into an existing page?
    • arethuza 10mo ago
      My first reaction, having done a fair bit of XSLT in ancient times, was "I hope not". After a bit of searching all the examples I could see use JavaScript to glue the HTTP request making part and then invoke the XSLT processor so it looks like the answer is "no".
  • kstrauser 10mo ago
    No, and it wouldn’t be, respectively. (Also, I don’t think we can go back to XSLT in the same sense that I can’t go back to the moon.)
• wackget 10mo ago
  This incredibly simple text-based website doesn't work without enabling JavaScript and allowing XHR in uMatrix. Why not "just use HTML"?
  • zahlman 10mo ago
    It also doesn't appear to have an HTTPS certificate.
• ndr 10mo ago
  If you never seen HTMX it is a small js library that lets you swap some part of your dom with the responses from your webserver. This means that in theory you (as a dev) don't need (to write any) js, nor do your users need to download a full page (for any interaction) like it's 1999. Your webserver replies with fully server-renderd HTML but just for the dom node (say a div) that you want to replace. It's fun for very simple things, even great for extremely simple interactions modes. For interactive products, anything beyond simple CRUDs, it's madness. Whenever you want to sprinkle a tiny bit of interactivity you'll have to choose between the path of least resistance (a small hack on HTMX) or a proper way. State management gets out of control real fast, it's the opposite of UI=f(state). I've seen it go bad, then worse with alpine-js, and then completely ripped in favor of something where people can let the browser do browser things. [edit for clarity]
  • rkomorn 10mo ago
    > it is a small js library ... This means that in theory you don't need js I assume I'm not the only person left a little puzzled. Do you mean "don't need JS" as in like, a full-fledged JS framework?
    • lunar_mycroft 10mo ago
      They mean that you don't need to write JS, you can just add a script tag to your page
    • ndr 10mo ago
      See the quickstart from htmx.org <script src="https://cdn.jsdelivr.net/npm/htmx.org@2.0.8/dist/htmx.min.js"></script> <!-- have a button POST a click via AJAX --> <button hx-post="/clicked" hx-swap="outerHTML"> Click Me </button> When the user clicks the button the browser will take the result of the request to `/clicked` and swap the whole button dom node for whatever the server sent. As a dev you get to write HTML, and need to learn about some new tag attributes. Your browser is still running js.
    • chamomeal 10mo ago
      Sorry I know other people have responded already, but it means you don't have to write any client side javascript at all. You can just skip along with a server that returns html. Just throw the script tag in there, and you're done. The magic of this is that it's pretty easy to make SPA-like webapps with no javascript or complex client side framework. You can write your server in python, rust, clojure, whatever. If you don't need a lot of state management, it's really simple and awesome.
• hakunin 10mo ago
  For those who build in Ruby on Rails, does htmx have an advantage over Turbo/Stimulus? For me, the sense that it doesn't is why I've been avoiding it. Prefer to stick with vanilla stack unless there's a very compelling reason not to.
• allan_s 10mo ago
  I would even say that even "just html" is enough for most website/app. We've been using "just html" at my company ( rosaly.com) for 5 years, we've raised 10 million, have hundreds of customer, and nobody ever complained. And the Android/Ios applications are 234 lines of React-Native which is just embedding a webview , a bit of error screen when there's no internet connection , and intercom library for notification.
• nicole_express 10mo ago
  The big problem I have with HTMX is the same one I have with React server components and similar concepts; I really like being able to just serve static files. Plus the clear separation of server and client really makes reasoning about a lot of different problem cases a lot easier, that's not something to dismiss lightly. (It's a bit of a 'ship your org chart' case, though)
  • yawaramin 10mo ago
    Htmx has very clear separation between server and client. The server is in your backend language and framework. The frontend is HTML.
• recursivedoubts 10mo ago
  Hey, I created htmx and while I appreciate the publicity, I’m not a huge fan of these types of hyperbolic articles. There are lots of different ways to build web apps with their own strengths and weaknesses. I try to assess htmx’s strengths and weaknesses here: https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ Also, please try unpoly: https://unpoly.com/ https://unpoly.com/ It’s another excellent hypermedia oriented library Edit: the article is actually not nearly as unreasonable as I thought based on the just-f*king-use template. Still prefer a chill vibe for htmx though.
  • lagniappe 10mo ago
    I'm curious if the author of the article is an HN reader, and if yes, how this comment is received.
    • moralestapia 10mo ago
      I will never ever ever ever touch htmx after this interaction I just witnessed.
      • recursivedoubts 10mo ago
        what do you mean?
    • algallagla 10mo ago
      I'm the author of the original article. fwiw, I haven't seen anything that bothers me. And if there was originally a harsher response which I missed, well then I hope it wasn't merited. I'm pretty light-hearted about this topic! It's more fun that way.
  • naasking 10mo ago
    I didn't find it too hyperbolic, I think they were very clear on where htmx can help, eg. the section "you're not building Google docs".
• pawelduda 10mo ago
  To prove the point, author mentions company that went from React to Htmx and saw positive change in relevant metrics. When you do that, it usually means your app has matured in a sense and you can be sure that htmx will be sufficient to handle all the functionality I'm however more curious about going the other way, i.e. you start a project with Htmx which happily grows but after a while, a large feature is requested which inevitably changes the direction of the app into React use-case territory. I can't think of concrete example but you now have to work around it with htmx or commit to rewriting to React (or alternative). Wonder what are thoughts of people who had to deal with this
• wg0 10mo ago
  This evangelism around HTMX is bit misplaced. First - simple use cases sure great. But imagine you have to update some element out of the from tree. Now you need to have OOB swaps and your HTML must contain that fragment. Not just that your server template code now has to determine if it is HTMX request and only render OOB fragments if so. Even at decent size app, soon it turns super brittle. Yet to talk about complicated interfaces. Let's not go complicated just think of variants in an E-commerce admin panel. 3 variants with 5 values each these are 125 SKU rows that must be collapsed group wise. htmx can do it but it's going to be very very difficult and brittle. So it is surely very useful but it is NOT the only tool for all use cases.
  • yawaramin 9mo ago
    > Now you need to have OOB swaps and your HTML must contain that fragment. This is super simple to do if you are using a library to generate HTML in your backend programming language. > Not just that your server template code now has to determine if it is HTMX request and only render OOB fragments if so. This is literally just a function that checks for a couple of headers, chooses between two rendering options, and adds a `Vary` response header to take care of the caching. Hardly anything complicated. > htmx can do it but it's going to be very very difficult and brittle. The problem with this summary is that it misses the point–htmx is not doing backend stuff, your backend app server is. Htmx is just swapping in what the backend sends. > it is NOT the only tool for all use cases. The OP said exactly this, the htmx people have always said this, and no one ever claimed otherwise. There are people out there who don't think in absolute all-or-nothing terms.
• athrowaway3z 10mo ago
  I'm a big fan of returning html instead of json when possible and I've been htmx curious for a bit. With all the examples people keep using, I assumed it would be way smaller. 16kb minified is a lot. Looking at the docs just now the core api seems reasonable, but it a lot larger than I'd assumed.
  • naasking 10mo ago
    Look into DataStar and Alpine Ajax then, they're much smaller and more targeted.
  • recursivedoubts 10mo ago
    our minimalist version of htmx is fixi.js: https://github.com/bigskysoftware/fixi https://github.com/bigskysoftware/fixi 1181kb brotli'd (no minification)
    • yawaramin 10mo ago
      I think you mean 1181b, not kb
      • recursivedoubts 10mo ago
        whooops
  • yawaramin 10mo ago
    It's much smaller than the final bundle size that most sites will end up loading.
  • adamzwasserman 10mo ago
    Read DATAOS.software for an in depth analysis of bundle sizes and impact on performance.
  • moebrowne 10mo ago
    > 16kb minified is a lot I'd bet that almost any site which isn't intentionally bare bones will have a lot more than 16KB of JS.
• devin 10mo ago
  What are some large websites using HTMX? I'd like to check them out.
  • gatinsama 10mo ago
    This is a famous one: https://www.contexte.com/eu/ https://www.contexte.com/eu/
• tantalor 10mo ago
  The author has never heard of jQuery
• hard_times 10mo ago
  Not HTMX but Alpine.js has been a complete revelation to me. What clicked for me was that you're enhancing server-rendered HTML, not replacing it. Need a dropdown menu? Add x-data="{ open: false }" and you're done. Want to show/hide elements? x-show does exactly what you expect etc. No bundler required, no compilation step.
  • kitd 10mo ago
    Alpine even has a plugin to perform the same function as Htmx if you need it https://alpine-ajax.js.org/ https://alpine-ajax.js.org/
  • deleted 10mo ago
    [deleted]
  • CodingJeebus 10mo ago
    I worked on a large commercial AlpineJS app and grew to really, really hate it. It's great for smallish projects where the limits of the tool are known, but it is in no way a drop-in replacement for something like React (and I am no fan of React). People like to throw around how easy it is to do basic things, but building a real app using Alpine is an absolute nightmare. Alpine data objects can grow to be quite large, so you wind up inlining hundreds of lines of JS as strings within your HTML template, which often limits your editor's ability to do JS checks without additional config. State management in Alpine is implicit and nested and not a serious solution for building commercial apps IMO. And don't even get me started on unsafe-eval. If it's your hobby app and you are the developer and the product owner, go for Alpine. If you're working at a company that is asking you to build a competitive web product in 2025, use a more robust tool. Hotwire and Stimulus has scaled much better from an organization standpoint in my experience.
    • fzumstein 10mo ago
      Have you tried the CSP build of AlpineJS? It takes the code out of the template into a proper JS file, no unsafe-eval. Isn't state management mostly handled on the backend when you use AlpineJS?
    • 10mo ago
• bob1029 10mo ago
  The framework has been built into the browser for a while now. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...
  • g947o 10mo ago
    I don't know what you actually mean, but very likely you are completely misguided.
• perardi 10mo ago
  I did. My startup did. And now we’re going to rip it all out and move to a React front-end. HTMX makes response handling much more complex. Every endpoint returns 3–5 different HTML fragments. Frontend and backend must agree on every scenario — success, validation errors, system errors, partial updates, full reloads. And HTMX is still a fairly obscure library. The documentation and examples are lacking, there isn’t a real set of established best practices at scale, and not for nothing, LLMs aren’t great at it. React is mature, used at scale, provides separation of concerns, and is great for agentic AI coding. HTMX has its place for simple projects, but for anything non-trivial, it’s a no for me.
  • naasking 10mo ago
    > Frontend and backend must agree on every scenario When is this not the case?
    • samtheprogram 10mo ago
      When an API returns JSON, your JS framework can decide what to do with it. If its returning HTML that's intended to go in a particular place on a page, the front-end has far less flexibility and pretty much has to put it in a specific place. Hence why they said endpoints can return 3-5 different versions of HTML.
      • naasking 10mo ago
        > When an API returns JSON, your JS framework can decide what to do with it. The JS framework is the frontend, so you're still coordinating. > If its returning HTML that's intended to go in a particular place on a page, the front-end has far less flexibility and pretty much has to put it in a specific place. Well yes, because presumably that's what the app is supposed to do. If it's not supposed to put it in that place, why would that be the specified target? If this kind of static assignment of targets is not flexible enough for some reason, then use OOB updates which lets you replace fragments by id attribute. That lets you decouple some of these kinds of decisions. Although "endpoints can return 3-5 different versions of HTML" is also a bit of a red flag that you're not using htmx correctly, generally endpoints should be returning 1, maybe 2 fragments in unusual cases. In any case, you might find DataStar more to your liking, it's partway between React and htmx.
• furyofantares 10mo ago
  > "I'm not a fucking saint" You're not a fucking person, this is LLM output. It starts with the overdone sweary thing then mentions it's overdone and says it's not gonna do it, and it's almost enough to make me think the article is going to offer someone's point of view. But once again the LLM has erased any point of view the author may have had going in (or prevented them from developing it) and replaced it with a mediocre infodump. I think this is the 5th slop I've seen atop HN in 24 hours. > This site made by me, with tongue firmly in cheek. Well, the LLM ruined it, and you didn't even tell us it participated.
  • nicolaslem 10mo ago
    I don't think this is straight LLM, it's probably an homage to a line of websites like https://thebestmotherfucking.website https://thebestmotherfucking.website
    • furyofantares 10mo ago
      For sure the author had an idea and went to the LLM to produce the post. And I'm aware of those prior sites (some of which are linked at the bottom.) I mean nothing is straight LLM, you must prompt them and people are putting their ideas in and linking to other sources and getting stuff like this out. And hopefully editing or iterating, but not enough it would seem most of the time. I'm saying their perspective doesn't shine through the crap and I'm sick of reading mediocre infodumps from LLMs.
      • algallagla 10mo ago
        I get it. Sorry if I wasted your time.
        • furyofantares 10mo ago
          Hey, thanks for adding a link* to a making-of video at the end of the post. Your perspective shines through when you explain the motivation in that first half, and my complaint is really that leaning on LLM writing makes this hard or impossible to see. The second half of the video is great too, I love seeing the actual prompts that go into the LLM. And I don't think you wasted my time, I'm sorry if "you're not a person" came off directed at you, when my complaint is really that I couldn't find you through all the tokens. I'm glad the video remedied that. * https://youtu.be/2P0CZPZzoZg https://youtu.be/2P0CZPZzoZg
• rdtsc 10mo ago
  > The ecosystem is why your node_modules folder is 2GB. The And every months a few of those modules try to exfiltrate your credentials…
  • yawaramin 10mo ago
    And execute commands remotely on your server, for example to install crypto miners...
• __MatrixMan__ 10mo ago
  I liked the idea that htmx is good for those middle of the road cases where you're not doing anything fancy but I didn't end up using it very often though because if I'm not doing something fancy then I'm not going to ask my user to leave their terminal anyhow.
• kitd 10mo ago
  Ofc if you really want to lose bloat, there's always Htmz https://leanrada.com/htmz/ https://leanrada.com/htmz/
  • nymanjon 10mo ago
    I took that idea and made it actually usable. https://github.com/jon49/htmz-be https://github.com/jon49/htmz-be It's amazing how much further you can go when you flip the server as the one deciding where what should be updated on the page. This was originally conceived by datastar and nomini also implements it this way. And HTMX 4.0 will have this as a first class citizen.
• johnfn 10mo ago
  > When you click it, HTMX POSTs to /clicked, and whatever HTML the server returns replaces the button. No fetch(). No setState(). No npm install. No fucking webpack config. Can someone explain something to me? To my view, the single best idea React has is that it forces you to encapsulate the full set of states in your component - not anywhere else. For instance, if you have a "Comment" button that becomes "Submitted" after you click it, you must include that state inside the comment component. You can't hide it somewhere else (i.e., in the input field after you press cmd-enter). This is a huge thing for managing complexity - if you spread state updates to a number of different places, it becomes significantly harder to reason about how the button works. Replacing the button with whatever the server responds with may sound simple, but it really makes it hard to answer the question of "what are all the states this button could be in". I mean, what if the server returns another button... which hits another API... etc? The weird thing is that HTMX talks about Locality of Behavior (yay!), but doesn't seem to practice it at all? BTW, one other thing: > The ecosystem is why your node_modules folder is 2GB. The ecosystem is why there are 14 ways to style a component and they all have tradeoffs. The ecosystem is why "which state management library" is somehow still a debate. > HTMX's ecosystem is: your server-side language of choice. That's it. That's the ecosystem. Really? Python is my ecosystem. You know that people add stuff to their node_modules because they need it, right? It's not like we do it for fun. Where am I going to find a date-time picker in Python? Am I going to build it from scratch? Where is an autocomplete component in Python? Or mentions?
  • chamomeal 10mo ago
    To your last point: If you're making an HTMX app, you're probably using built-in browser inputs instead of custom JS-based ones like react-select. If you NEED react-select, you probably should just use react. But if your site is mostly just displaying data with html and updating that data with forms, htmx will work great with much less complexity and effort. I've only toyed around with htmx, but it really is refreshing. Of course you can't do everything that you can do with a fully-fledged client side framework. But once you try it out, you realize that more of the web is just markup + forms than you realized. I wouldn't build a live chat app with htmx, but I would totally build a reporting dashboard.
  • 10mo ago
• karmakaze 10mo ago
  > Any HTML element can make an HTTP request > The server just returns HTML (not JSON, actual HTML) I like to separate presentation HTML from the data (returned from HTTP request). Some like to make backends that do nothing but serve the (singular) frontend, even running templates to make the HTML they return for easy consumption. That's not where I draw the line.
  • yawaramin 10mo ago
    You know, there was a time when returning Hypertext Markup Language over Hypertext Transfer Protocol was considered a normal thing.
• mythz 10mo ago
  I keep seeing articles religiously pushing htmx, what I'm not seeing are sophisticated examples or apps written with it, just more basic example and interaction examples. I personally prefer UIs with great encapsulation/composition, which used to be Vue, but with AI starting to write more of my UIs now I've switched to React/Next.js for new non-progressive UIs.
• grugdev42 10mo ago
  Ultimately the complexity does have to live somewhere. The idea that HTMX removes all the complexity is false. However it does remove some of it, and moves the rest onto the backend. I find the backend easier to work with, so that's a win for me. And a batteries included framework (like Laravel or Django) makes HTMX even more appealing. They already have everything you need! :)
• simpleui 10mo ago
  SimpleUI helps address the endpoint issue by autogenerating routes for HTMX. It's like a simulation of the frontend running on the backend. https://simpleui.io https://simpleui.io
• simultsop 10mo ago
  As the op may read along the other comments, we are tired trying the new shiny thing. Now it is AI's turn to get tired or never. Dx resources must aim AI's attention having enormous technical documentation and be AI efficient in order to become mainstream. I believe no other shiniest thing will ever make cognitive nest in humans. We are overloaded.
• delbronski 10mo ago
  My main use of HTMX is to hack the Django Admin here and there. It works great for that. I’ve tried to use it in a moderately complex app and it became such a mess so quickly. I’m sticking with React for frontend stuff for now. Works well enough and I’m used to it now.
• liampulles 10mo ago
  I like HTMX, I use it on my blog. But I will say, in the niche where I need some dynamic DOM changes without needing a full-blown SPA, raw JavaScript with some basic utilities like jQuery is not so bad. The issue with htmx is that it is fairly prescriptive of how one should go about building dynamic interactions, and it becomes complex quickly if the dynamic interaction is more than trivial. I don't disagree with its philosophy at all (as I say, I use it for my own site) but it becomes an issue when my product owner tells me that I need to do some funny dynamic thing because it will make the business or clients happy (for some reason), and then it becomes a mission to wrangle it with htmx attributes. And I have to follow that, because as much as it pains me to say it, making stuff pretty and dynamic on the UI is an easy way to score points. It is one of those areas of enterprise software development which seems like a huge upgrade to non-technical people whilst not requiring too much effort. The one thing raw JavaScript is quite well suited for is hacking together some DOM manipulation. I dislike JavaScript in every other domain except this - its in this arena where its leniency is very useful.
  • Exoristos 10mo ago
    > it becomes an issue when my product owner tells me that I need to do some funny dynamic thing Okay, but on the other hand maybe you should do the right thing and say no.
    • liampulles 10mo ago
      I agree that one should push back, but I suspect we have different notions of when to do that (which is fine, my approach here is not fixed in stone). Making a page needlessly dynamic would be a concern for me if it violates business rules or for whatever reason harms the overall system. But if it doesn't do that, and it genuinely does make the business and users happy, then I'm happy to do it and then get a bit of leverage to take some time to tackle tech debt that needs addressing on the backend.
      • yawaramin 10mo ago
        > it genuinely does make the...users happy But you have no idea if it does that, you just have the word of the PO who's not actually building anything, they're at best just copying what others are doing (ie being derivative) or at worst just doing guesswork. How about offering an alternative: a UI/UX that takes the web as it is, a primarily document-based format with navigation and data entry? A lot of cool stuff can be built on top of that.
• jacobsenscott 10mo ago
  I haven't used htmx, but I've given turbo a fair shake. I've only worked on server side rendered apps for my whole career, and they are generally they way to go. But just like react, or anything else, you throw enough engineers at it and it becomes a mess. But also you'll only find a handful of engineers who understand it compared to react, so that makes it worse. I think the bottom line is creating web UI is just as unsolved today as it was 20+ years ago, and nobody can make any headway - it suggests the fundamentals are totally wrong - after all - this isn't what http and html were even built for. Given sufficient time and money (20+ years, and billions (trillions?) of dollars - which is what we've thrown at web apps) you could build GUI apps using the IRC protocol, but it will never work well. LLM generated code probably tips the scales toward using react though. You can have the bots churn through all that boiler plate, it won't be any worse than what human react devs write, and keep the bots away from your mission critical code because it isn't all munged together like in a SSR app.
  • SoftTalker 10mo ago
    > this isn't what http and html were even built for Ding! Ding! You win the prize. Absolutely correct.
• throwaway613745 10mo ago
  > Junior devs losing their minds over why useEffect runs twice Oh now now, even senior devs do this too :)
• embedding-shape 10mo ago
  <button hx-post="/clicked" hx-swap="outerHTML"> You know, I see logic/"programming" inside of templates and I'm out, gave up that life many years ago and never have I been eager to go back to it. No, I'll keep using hiccup and similar things that are just data and nothing more, no syntax, just functions and built-in data structures, then give me HTML as a string which consumers can do whatever with, and we're golden.
  • recursivedoubts 10mo ago
    how do you feel about this mixing of control logic and display information: <a href=“/clicked”>click me</a>
    • g947o 10mo ago
      we call that HTML standard, and (in principle) works in any browser without the need to use JavaScript.
• superjose 10mo ago
  Datastar has been garnering my attention https://data-star.dev/ https://data-star.dev/
  • dweldon 10mo ago
    My company makes a few products - one of them is just forms, lists, and links. When the codebase was really small we tried using htmx, then alpine ajax, then datastar. We stuck with datastar and I really enjoy it for projects that don't have a highly complex client state. Overall it's a really simple build and deploy process. I find it easier to secure and to reason about. Additional bonus: I'm able to lint the whole thing with biome since it's just typescript and jsx templates.
  • fud101 10mo ago
    My read is htmx is now evolving towards datastar. It tells me datastar will become irrelevant soon as htmx eats its babies.
• bontaq 10mo ago
  I'm a big fan of it for building micro websites with LLMs, since it can keep pretty much the entire thing in context (even including the docs) it seems to perform pretty well.
• bjord 10mo ago
  please just try TLS
• bargainbin 10mo ago
  > That's HTMX. I didn't write JavaScript to make those work. I wrote HTML attributes. Well you didn’t write standard HTML attributes, you wrote custom attributes that are picked up by a JS framework, so potentially the worst of both worlds depending on your problem space. Having tried HTMX a few times, the problem is firmly in creating a backend that feeds it properly. It’s a disjointed experience for anything more complicated than updating content.
  • AlienRobot 10mo ago
    HTMX sounds like it works best when you are fetching data from endpoints that would serve HTML already, like <frame>-based sidebar navigation.
• zero0529 10mo ago
  What I don’t like with HTMX and the like is that you basically don’t get any help in the backend. It also introduces implicit coupling between the frontend and backend which is very much the worst kind of coupling you can have. While this is fine for small to medium projects it is terrible in the long run. To be honest this might be a skill issue or something I haven’t understood properly with these frameworks.
• H1Supreme 10mo ago
  > But sometimes—and here's where it gets uncomfortable—you actually do need a button that updates part of a page without reloading the whole damn thing. You do need a search box that shows results as you type. You do need interactivity. You can do this with plain old Javascript. Make a request, swap out the [inner | outer]HTML with the result. If you want a nice visual transition, wrap the swap in a startViewTransition(). Obviously, you need to be extra careful if you're using user-submitted HTML. Otherwise, it's fairly straight forward.
• davidhariri 10mo ago
  HTMX is a great choice for an app that only needs forms, validation and partial template rendering, though CSS view transitions are making partials less relevant for server side web applications. For things with heavy interaction (drag and drop, chat etc.), I find the code to make it work with HTMX is just too clumsy to work with as a mental model.
  • yawaramin 10mo ago
    That's exactly what the article is saying.
  • adamzwasserman 10mo ago
    multicardz is heavy drag-drop ui. totally based on htmx (I still need to get data from a backend, I use htmx to do it for a number of reasons.)
• adamzwasserman 10mo ago
  Even if you do have complex client-side state: dataos.software
• otikik 10mo ago
  Isn't this what html-over-the-wire/turbo/stimulus is? [1] [1] https://hotwired.dev/ https://hotwired.dev/
• mrinterweb 10mo ago
  HTML over the wire frameworks like HTMX, Hotwire (rails), LiveView (phoenix), Livewire (laravel), LiveView (django), etc. They all have the same basic idea with differences in how they achieve it. I feel this approach is overlooked, and it drives me crazy. There is a huge complexity cost attached with JS frontend app + backend that everyone seems to have accepted as reality. HTML over the wire (really need a catchy acronym maybe HotW) can greatly simplify and speed up development with pretty much the same end user experience as a react app.
  • ChocolateGod 10mo ago
    Using JSON over the wire means you can re-use your backend between multiple frontends (like with mobile apps).
    • mrinterweb 10mo ago
      Not all web applications need to be have an API that serves other clients. Often web apps are enough.
    • yawaramin 10mo ago
      You can also reuse your backend if you server HTML, thanks to content negotiation. The frontend sends a header that indicates what type of content it accepts, and the backend serves the according type. Also, mobile apps often have different API needs than webapps, so they end up getting different APIs anyway.
    • Lio 10mo ago
      You could use Hotwire Native for that. Also backends like Rails give you JSON APIs for free if you want them.
      • mrinterweb 10mo ago
        Hotwire Native would be a great option, but I will argue that I've never felt that I got JSON APIs for free with rails. Thousands of my rails dev hours spent writing APIs would say otherwise.
• dana321 10mo ago
  _another fucking framework_
• 65 10mo ago
  Do not use HTMX for anything other than very simple CRUD apps. The vast majority of the time you'll be wishing you had client side two way data binding and state management. If you want "simple and not React", just use Alpine.js. It has way better ergonomics and features than HTMX and can do essentially everything HTMX can do.
  • url00 10mo ago
    This matches my experience. State management is the key thing - you end up needing to put way more on the backend then you'd otherwise like to. Quick example: something like a multi-step "wizard" is far more difficult to express in HTMX than with any SPA-ish pattern.
    • adamzwasserman 10mo ago
      Check out DecisionMe.com. 100 percent wizard pattern, htmx based nav and validation.
      • g947o 10mo ago
        Eh.. this does not contradict the previous point? Unless we can see the backend code and do some comparison with a reference implementation, it does not disprove "far more difficult to express". "can be done with htmx" != "easy/easier to do with htmx"
        • adamzwasserman 10mo ago
          True, but it is not my code to that with. so... If I ever open source one of my backends I will try and remember to flag it in a reply here.
• littlecranky67 10mo ago
  Can we see a styled date-time picker in htmx?
  • yawaramin 10mo ago
    Yeah, https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/datetime-local https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
    • adamzwasserman 10mo ago
      took the words out of my mouth!
    • littlecranky67 10mo ago
      I can tell you, it is neither styled, nor does it work on Firefox (as in, properly works). And the mobile UX is horrible.
      • yawaramin 10mo ago
        Perhaps Firefox should focus on shipping a good native datepicker instead of trying to put AI in the browser.
        • littlecranky67 10mo ago
          True, but completely unrelated to the original thread and issue at hand.
          • yawaramin 10mo ago
            This should be the issue at hand. Browsers shipping unfinished, sub-standard UI widgets should be a bigger concern for everybody than the random Joe Framework of the week not re-implementing the same widgets.
• ctvo 10mo ago
  No. Why the hell would I use Angular 1.x style directives in 2026? For the simple contact form and todo apps, why would I even use client side scripting? Go away.
• Kinrany 10mo ago
  Are there any server-side frameworks that look like HTMX in the browser but allow writing functional-style code for managing all that HTML mutating itself?
• fassssst 10mo ago
  Latest iOS Safari: the viewport jumps around on all those demos. Really hurts your case.
  • yawaramin 10mo ago
    iOS Safara user here. The viewport jumped for me only on the active search demo and only the first time when the result content was initially loaded. This can be easily fixed by having a fixed-size results box loaded from the beginning.
  • adamzwasserman 10mo ago
    my htmx apps have 0 cls. You just have to care enough to do something about it.
• bobjordan 10mo ago
  I’ve been a fan of this philosophy since the Intercooler.js days. In fact, our legacy customer portal at bomquote.com still runs on Intercooler. I spent the last year building a new version using the "modern" version of that stack: Flask, HTMX, Alpine, and Tailwind. However, I’ve recently made the difficult decision to rewrite the frontend in React (specifically React/TS, TanStack Query, Orval, and Shadcn). In a perfect world, I'd rewrite the python backend in go, but I have to table that idea for now. The reason? The "LLM tax." While HTMX is a joy for manual development, my experience the last year is that LLMs struggle with the "glue" required for complex UI items in HTMX/Alpine. Conversely, the training data for React is so massive and the patterns so standardized that the AI productivity gains are impossible to ignore. Recently, I used Go/React for a microservice that actually has turned into similarly complex scale as the python/htxm app I focused on most of the year, and it was so much more productive than python/htmx. In a month of work I got done what took me about 4-5 months in python/htmx. I assume because the typing with go and also LLM could generate perfectly typed hooks from my OpenAPI spec via Orval and build out Shadcn components without hallucinating. I still love the HTMX philosophy for its simplicity, but in 2024/2025, I’ve found that I’m more productive choosing the stack that the AI "understands" best. For new projects, Go/React will now my default. If I have to write something myself again (God, I hope not) I may use htmx.
  • placebo 10mo ago
    This got me thinking: I am not about to fight windmills and the future will unfold as it will, but I think the idea of "LLM as a compiler of ideas to high-level languages" can turn out to be quite dangerous. It is one thing to rely on and not to be able to understand the assembly output of a deterministic compiler of a C++ program. It is quite another to rely on but not fully understand (whether due to lazyness or complexity) what is in the C++ code that a giant nondeterministic intractable neural network generated. what is guaranteed is that the future will be interesting...
    • bobjordan 10mo ago
      The way I'm keeping up with it (or deluding myself into believing I am keeping up with it) is by maintaining rigorous testing and test standards. I have used LLMs to assist me building C firmware for some hardware projects. But the scale of that has been such that it can also be well tested. Anyway, part of the reason I was so much slower with python is I'm an expert at all the tech I used, spending literal years of my life in the docs and reading books, etc., and I've read everything the LLM wrote to double check it. I'm not so literate with go but its not very complex, and given the static nature, I just trusted the LLM more than I did with python. The react stack I am learning as I go, but the tooling is so good, and I understand the testing aspects, same issue, I trusted the LLM more and have been more productive. Anwyay, times are changing fast!
• rambambram 10mo ago
  Just use the CHAMP stack. Like it's 2005 again. CSS, HTML, Apache, MySQL and PHP.
• npn 10mo ago
  This is a retarded advice. Author clearly never tried to develop any serious web development. > the build time is over 30 seconds! that's silly. 30 seconds building time is nothing compare to the accumulated time you wait for micro changes to your frontend. for typical web development using react/vue/svelte you have hot code reloading, which can reload the current website < 1 seconds after you hit [Save] on your favorite editor. for htmx to update, you have to wait for your whole server to reload (which can be way slower even you use interpreted languages like ruby or python, due to complexity of the framework you use). not to mention it does not keep any state of the current website, make debugging way more troublesome compare to a js mature framework. only people who never have to improve their website incrementally think htmx is a viable option. or insane people. obviously, for some small websites with minimal interactions or no need to change the content very often, then htmx can be good, but for that case, vanilla js also works, and they do not need 14kb of excess baggage.
  • Aldipower 10mo ago
    Thanks for this advice. I will never ever try HTMX now. I hate waiting. This makes me sick.
  • 0xblinq 10mo ago
    This. Only backend developers that think frontend is trivial and we’re all just idiots think that HTMX is the solution. They saw it working in their hello world side project and think they discovered gold.
• bondarchuk 10mo ago
  >The "server" (mocked client-side for this demo Hmmm.... I wonder why that is......
  • lkbm 10mo ago
    I mean, I guess it's fine to mock stuff here, but when I tried clicking the button, I first opened the network tab of devtools, and was confused by the lack of any request being made. (The console explained, showing "[HTMX Demo Mock] fetch: POST /demo/clicked" and "[HTMX Demo Mock] Returning mock for: POST /demo/clicked") Your demo shouldn't have explicit lies, such as "It worked. That was an actual HTMX POST request. The "server" returned this HTML and HTMX swapped it in." I mean, I guess maybe it made an HTMX POST request, not an HTTP POST request? But this does reduce my trust in the article.
    • bondarchuk 10mo ago
      I don't think it's fine, if even the "just fucking use htmx" page can't be arsed to just actually fucking use htmx then something must've gone wrong somewhere.
• on_the_train 10mo ago
  But how to actually manage non trivial state? URLs get big pretty fast
  • adamzwasserman 10mo ago
    that is why I wrote DATAOS.software. It is a paper/cookbook that answers that question.
• pwmanager 10mo ago
  No huge JS frameworks, no build steps, no state hell
• wetpaws 10mo ago
  [dead]
• boredumb 10mo ago
  please, just use html/css and some javascript where applicable.
• srfrog 10mo ago
  I'm the CEO of HTML. I approve of unpoly. A+++++
• mvdtnz 10mo ago
  I haven't used HTMX but the author doesn't make a very convincing case. On the one hand they say, > "But what about complex client-side state management?" > You probably don't have complex client-side state. You have forms. You have lists. You have things that show up when you click other things. HTMX handles all of that. On the other hand, > I'm not a zealot. HTMX isn't for everything. > Genuinely complex UI state (not "my form has validation" complex—actually complex) But my interpretation is that any UI which displays the same data in just two places (like a "new notification" indicator as well as bolding new messages in an inbox, or a list of articles which can change dynamically as well as a count of the number of articles) is "complex" enough that you'll need client side state.
  • yawaramin 10mo ago
    Nope, in that case all you need is an htmx out-of-band swap to update two different parts of the page.
• deleted 10mo ago
  [deleted]
• herpdyderp 10mo ago
  Was hoping for a sandbox so I could actually try it!
• boobsbr 10mo ago
  Mitrhil.js is 8.8 kB gzipped. And you can just return JSON from your API. And you can add JSX later if you want.
• czhu12 10mo ago
  > Most teams don't fail because they picked the wrong framework. They fail because they picked too much framework. HTMX is a bet on simplicity, and simplicity tends to win over time. I've built enough stuff in my time to know this is hyperbole at best and an outright lie at worst. I've never seen a team fail due to complexity. Team fails because the thing they built was wrong. You should spend 99% of your time paranoid that the thing you're building is useful enough to justify its existence. Whatever tool you use along the way makes up the last 1%
• ericarogulski 10mo ago
  [dead]
• n4pw01f 10mo ago
  I have used HTMX extensively with AI agents. It is fantastic for dynamic views. Agent one: handles the request and does tool calls Agent two: reads the result and decides on quality vs a re-drive if it’s low quality Agent three: decides how to present the information to the user, creates a collection of HTMX elements HTMX hx-get is reliably, and beautifully rendering the result of the Agentic Workflow without any react, etc. Very happy and passing quality gates. I love not having security alerts every week to patch because of some buried react dependency library
• robinhood 10mo ago
  Yet another thread of React vs the rest of the world. Each has its use case, and most of the time, React/Vue are largely overkill. Personally, I would never, ever, ever start another React project again. The nightmare of the horrible JS ecosystem, build steps and tooling is behind me. All my projects now use either HTMX or Alpine Ajax - and for web apps that are actually pretty large. It works perfectly fine. Add Turbo to the mix and you almost have the feeling of using a real SPA, without the headache and large bundled JS files. Feels refreshingly simple. Still have to figure out the no-build step so I can completely drop Bun/Yarn/Npm, and life will be a wonderful thing.
• some_guy_in_ca 10mo ago
  I would recommend https://data-star.dev https://data-star.dev instead.
• lvl155 10mo ago
  To be honest, none of these new-ish frameworks are good because there’s not enough data to train LLMs. React/NextJS is great because I can 80% get there with LLMs.
• gloosx 10mo ago
  This fucker didn't even bother showing us some real POST requests. And he actually wrote JavaScript to make those work. Why would you mock it on the client-side if HTMX makes it so simple??
• lbreakjai 10mo ago
  It feels like the worst of both worlds, what am I missing? I get server-side rendering. I can boot my server, and everything is there. If my model changes, I can update the view. It's cohesive. I get client-side rendering. The backend returns data, the frontend decides what to do with it. It's a clear separation. The data is just data, my mobile app can consume the same "user" endpoint. This seems like a worst-of-both-worlds paradigm, where the backend needs to be intimately aware of the frontend context. Am I not getting it or is there a massive implicit coupling? Now if I need to display the same "user" data twice, in different formats, on my website. Say, as a table in "My account", and as a dropdown in the menu bar. Do I need to write two endpoints in the backend, returning the same data in two different formats?
  • recursivedoubts 10mo ago
    Yep. And that’s a good thing: https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/
    • lbreakjai 10mo ago
      Splitting application API and generic data API is orthogonal to HTMX. You still have issues compared to plain JSON, don't you? Imagine you need firstName/email in once place, firstName/email in another, and firstName/D.O.B in another. In a plain JSON world, I'd craft a single "user" endpoint, returning those three datapoints, and I would let the frontend handle it. My understanding is with HTMX, I'd have to craft (and maintain/test) three different endpoints, one per component. I feel like you would quickly end up in a combinatorial explosion for anything but the simplest page. I really don't get the appeal at all. Of course everything can be very simple and lightweight if you hide the complexity under the bed!
      • recursivedoubts 10mo ago
        ¯\_(ツ)_/¯ any factoring you do on the front end you can do on the back end too, there's nothing magic about it and you don't need different end points: that can be a query parameter or whatever (if it's even a request, in most hypermedia-based apps you'd just render what you need when you need it inline with a larger request) it's a different way of organizing things, but there are plenty of tools for organizing hypermedia on the server well, you just need to learn and use them
• some_guy_in_ca 10mo ago
  I would recommend https://data-star.dev https://data-star.dev over htmx. It is more complete. But it depends on what you are building. Datastar does everything that htmx can do and much more.
  • nchmy 10mo ago
    its also smaller and faster
  • yawaramin 10mo ago
    It doesn't have history support out of the box. I consider that essential for hypermedia apps. When I'm loading fragments into my page I need to push the URL of the fragment I just loaded so the user can reliably come back to that specific resource later.
• didip 10mo ago
  I love HTMX. It felt like a rebirth of PJAX. Server side template rendering is simply the best. Too bad that the world insists on going nuts with JS everything. Oh as a plus, AI agents are a lot more productive when dealing with server side logic.
  • recursivedoubts 10mo ago
    huge fan of pjax, interviewed @defunkt here: https://htmx.org/essays/interviews/chris-wanstrath/ https://htmx.org/essays/interviews/chris-wanstrath/
• ramon156 10mo ago
  > Option B: React (or Vue, or Svelte, or Angular if you're being punished for something). > And suddenly you've got: > A package.json with 847 dependencies > A build step that takes 45 seconds (if the CI gods are merciful) > State management debates polluting your pull requests > Junior devs losing their minds over why useEffect runs twice > A bundle size that would make a 56k modem weep No? React is surprisingly small, and if you're in dependency hell then fix that. The alternative is another idiom.
  • hu3 10mo ago
    React only renders. You need a lot more than that for an app. And if you glue packages together you're basically reinventing frameworks. This can be a good thing or a bad thing. Regardless of your choice between glueing libs or a framework, you'll end up with tons of dependencies for most non-trivial projects anyway.
• Ciunkos 10mo ago
  There is inherent risk of such low level frameworks over React, that is they allow you to easily blow your foot off, by injecting raw unsanitized HTML back for dynamic execution. A thing that would not work in React apps by default. Even on those demos, you can XSS yourself with the simplest payload, confirming my point.
• mircerlancerous 10mo ago
  You don't need React or HTMX; just put onclick= on your element and make your call with vanilla javascript. Use these frameworks if you want, as they're both neat, but frankly I think people forget that there are other options
• themafia 10mo ago
  No, I'm sorry. Life is too short to write code inside of HTML attributes.
• weiliddat 10mo ago
  Has anyone tried using HTMX + some realtime query layer like Convex?
• hmans 10mo ago
  [dead]
• knallfrosch 10mo ago
  > Or are you building another dashboard, another admin panel, another e-commerce site, another blog, another SaaS app that's fundamentally just forms and tables and lists? Install an open source admin panel and call it a day.
• ohelm 10mo ago
  No
• epolanski 10mo ago
  > You do need a search box that shows results as you type. You do need interactivity. You can use JavaScript for it. I've been trying lately ruby templates with some occasional JS for this and it works great. Or implement a straight forward web component.
• Aldipower 10mo ago
  This guy lives in extremes! His option 1 is pure HTML the only other option 2 is React! But it seems he never heard about VanillaJS to drive a button click.
• delfugal 10mo ago
  What you need is more f-bombs in your article.
• chaosharmonic 10mo ago
  > Honor obliges me to admit this is not literally true. bettermotherfuckingwebsite.com is a fucking pedagogical masterpiece and reshaped how I built my own site. But let's not spoil the bit... > Inspired by (and in joyful dialogue with) motherfuckingwebsite.com, justfuckingusehtml.com, bettermotherfuckingwebsite.com, and justfuckingusereact.com. Extremism in defense of developer experience is no vice! This site made by me. Does this all sound a bit like shallow slop? Yup, please help make it better. I agree with you, and wrote a similar one for Markdown that you might enjoy. Same overall naming scheme. (Note: open the comments before you judge the use of a Web Component for rendering purposes.)
• wewewedxfgdf 10mo ago
  I would say please just try Web Components. They are standard, they work, they're great.
• danpalmer 10mo ago
  I did. I found it to have quite a few problems with bugs, docs, and web page lifecycle. I switched to Hotwire/Stimulus and found it to be a significantly better implementation of the same core concepts. I'd highly recommend checking them out.
• falldrown 10mo ago
  14kb gzipped file? sorry no.
  • nymanjon 10mo ago
    fixi.js, nomini.js, data-star, htmz-be. All have smaller footprints. All work just fine, depending on your needs.
• aembleton 10mo ago
  > The server just returns HTML (not JSON, actual HTML) Thats the thing I don't like. I don't want parts of the structure of my page coming from the backend server. I just want that to send data, as JSON and for the front end to handle that into whatever structure it deems suitable. That way all of the front end code is in one place.
  • turtlebits 10mo ago
    In the simplest web server, the server returns HTML. Having the backend return JSON is where you're adding complexity. Your front end code won't even work without some base HTML.
    • aembleton 10mo ago
      Having the html stored both on a static html site that can be cached and in the code base of a backend server is more complex to me than keeping these concerns separate.
      • yawaramin 10mo ago
        That's why you just have the HTML in the backend server codebase...which can also make sure it's cached properly with HTTP caching techniques like last modification time, ETag, and so on.
  • wvbdmp 10mo ago
    But the front end code is in one place, and that place is the server. It is true, though, that the experience greatly benefits the easier it is to manage and return partials from backend code. Some frameworks make it harder than others.
    • aembleton 10mo ago
      I'd rather have the often loaded static html running on a server that is optimised for that job, or served from a cache close to the user. The backend can then just serve up the dynamic content and be optimised for that job.
• bryanhogan 10mo ago
  Can highly recommend HTMX with Astro[1] for pages that are mostly static. [1]: https://astro.build/ https://astro.build/
• jeffjeffbear 10mo ago
  I just don't like having to send HTML and have the backend deal with what are really frontend problems. Sending JSON is great since you can serialize most reasonable data types into it and then the backend has no responsibility for how it is rendered which helps for having mobile apps use the same backend as the website. Sending HTML just seems nuts since if you change your design you would have to change the backend too.
  • internet_points 10mo ago
    if you require a backend/frontend split, you're maybe not in the htmx use case if you can imagine having just one "end", maybe you can use htmx
  • yawaramin 10mo ago
    See this subthread https://news.ycombinator.com/item?id=46315559 https://news.ycombinator.com/item?id=46315559
• roncesvalles 10mo ago
  But I don't want SSR, period. My backend is an HTTP API that speaks JSON. My frontend is whatever thingimajig can talk to an HTTP API in JSON. That's it. I love it this way and see no reason why I should blur the lines between frontend and backend.
• beders 10mo ago
  Can someone who's adapted HTMX for a larger app report about front-end-server costs? HTMX serves fully baked HTML that needs to be created on the back-end (or front-end-facing servers) That is more processing than sending the raw data to the front-end and baking the HTML there. It is also more bandwidth (unless the JSON is more verbose than the HTML generated). Lastly, I can generate different HTML fragments on the front-end from the same client-side state with the data only being transported once. How is that working out?
  • listenallyall 10mo ago
    > That is more processing Not necessarily. Often it is less. Template engines can be very, very efficient and fast. Returning JSON almost always requires data/object serialization on the server, this is often slower than direct data/object -> template rendering. Further, it's not your server but keep in mind the client must de-serialize JSON and render some HTML every time. Modifying layouts as a result of non-persistent state (light/dark mode, sorting, etc) can usually be handled relatively easily with styles and data- attributes and sprinkles of JS. HTMX works very well with Alpine.JS and similar libraries for more complex situations. HTMX isn't for every scenario, but it works very very well in many scenarios.
• amluto 10mo ago
  The Demo 3 Live Search example has really nasty scroll jank issues. I’m guessing it’s caused by the results being inserted inline in the document (and thus redoing the layout of much of the page) instead of being placed in some sort of overlay.
• dev_l1x_be 10mo ago
  > No fetch(). No setState() Just pure eval(). [1] 1. htmx.config.allowEval: defaults to true, can be used to disable htmx’s use of eval for certain features (e.g. trigger filters)
• kgeist 10mo ago
  I've used HTMX on a personal project of mine. Other than HTMX itself, it used Go templates + Tailwind for CSS. As a backend dev with almost no professional frontend experience, I was able to replicate a fairly large and feature rich React app (which I was inspired by) using htmx in a matter of weeks in free time. The main problem for me was storing/passing state between too many fragments. At some point some pages can become too complex to be manageable by HTMX, unfortunately. Lots of little fragments depending on each other, I began struggling to maintain a clear mental map of what was going on. I'd say if React is more like functional programming, HTMX sometimes feels like GOTO programming.
• Havoc 10mo ago
  Threads like these make me glad I’m not a frontend dev. Just looking at the comments it’s clear there is no cohesive view or vision or agreement. One giant Tower of Babel
  • hu3 10mo ago
    I think it's because the ground in frontend dev is shaky. Browsers keep changing along with people's expectation of what a website or app should be capable of. Meanwhile on the backend land, the same MVC framework from 2 decades ago can still deliver acceptable results.
  • yawaramin 10mo ago
    There is a cohesive view, vision, and agreement in web dev: HTML, CSS, and JavaScript. There are web standards, web APIs, and accessibility requirements. Everybody builds on top of that.
• michaelyin 10mo ago
  [dead]
• elif 10mo ago
  I always thought the GWT->react branch of the webdev family tree was an inbred, unecessarily cumbersome compromise bred from JavaScript and performance metrics rather than descending from the beautiful code family we used to have with Rails and Django. The only reason react seems to look beautiful is because it's compared to custom JavaScript state management rather than the server-state paradigm that probably makes most sense for over 90% of apps. The only real place it makes sense is when you're Google or Facebook and those 15 milliseconds actually translate to quantifiable lost user attention. If your app is actually useful and not just an attention farm, those 15ms are almost never worth your engineering team's sanity.
• synergy20 10mo ago
  htmx led to spaghetti code for me. react is too much to learn. using vuejs these days.
• swyx 10mo ago
  i tried it, its great if you want a jquery replacement, but if you are AT ALL used to react svelte etc you are going to be SORELY disappointed at how much ui manipulation and state management coordination you are going to need to reinvent from scratch. not worth it
• zeroq 10mo ago
  Call me grumpy but 20 years ago we were making fun of smarty - a template engine made in a template engine - and now everything looks like a solution looking for a problem.
• codedokode 10mo ago
  I looked at the code examples and instantly saw something familiar. I remember, there was a library that intercepted link clicks, made AJAX requests and updated DOM with response, so that the page would update without reloading. If for any reason the code failed, there was just standard link navigation so you could access the content any way. I think it was pjax library. It made the site look like a SPA without having to write any extra code. How cool is that. HTMX resembled me this library. But it seems very narrow cased, there are only so many attributes and their values and you cannot implement anything else. While pjax is generic: you can attach it to any site which has links. Also you cannot replace Vue (don't use React) with HTMX. For example, if you are making a diagram editor, HTMX won't be useful.
• csomar 10mo ago
  If you don't need React, you probably don't need a framework anyway. The reason I use React is to create components that can exist on their own (and can be constructed/visualized on a StoryBook) and these components will then play nice with other React components. And then use JSX to make reasoning about the code simple. That's not what htmx is. > htmx is a library that allows you to access modern browser features directly from HTML, rather than using javascript. From React website: > React lets you build user interfaces out of individual pieces called components. Create your own React components like Thumbnail, LikeButton, and Video. Then combine them into entire screens, pages, and apps. Apples and Oranges.
  • yawaramin 10mo ago
    One would think so, except we are constantly seeing people creating React apps that should have been a few simple HTML files and some JS.
• tommica 10mo ago
  > If you hate it, you've lost a weekend. But you won't hate it. You'll wonder why you ever thought web development had to be so fucking complicated. This part is said really well, and applies to anything. "It's just a single weekend" is a cure to the whole "wasting time" argument/excuse that I guess a decent amount of people have - at least I know I do. Really well written article, having both when to use and when not to use, is a nicely balanced view.
• insane_dreamer 10mo ago
  Love it! The reality is that I don't need an overly complicated SPA. I'm totally fine with AJAX requests like JQuery was still in style. The ability to do this with HTMX is awesome.
• lcnmrn 10mo ago
  This reminds me of Subreply (subreply.com), a tiny text-only social network that keeps things extremely simple and fast—worth checking if you like minimalism in apps.
• Daril 10mo ago
  I used Turbo + Stimulus with a CodeIgniter PHP backend. Later, I used an HTMX bot with CodeIgniter and GoLang. Now, I have migrated my second brain web app (Brainminder) from HTMX to Unpoly. I really liked HTMX, and I thank the authors for this marvelous library! I switched from Turbo to HTMX because the latter is much more flexible, and I try to avoid Node.js as much as possible, only using it to compile some JavaScript code for Stimulus. I finally moved from HTMX to Unpoly for the following reasons: 1. Layer support: Unpoly makes it easy to create layers and modal overlays, saving a lot of time and JavaScript code. You can achieve the same functionality with HTMX, but you have to write more code. 2. JavaScript code is better organized thanks to up.compile hooks. 3. HTMX and Unpoly treat fragments slightly differently. With HTMX, you have to use an out-of-band feature to update multiple fragments together. With Unpoly, you can easily add them to the response (and declare them in the front end, of course). In my opinion, Unpoly has a better-organized approach to everything. On the other hand, apart from the official documentation, it is difficult to find examples for some edge-case features.
• fithisux 10mo ago
  Maybe, I say maybe, native HTMX by default maybe the key for Gemini to become a viable alternative to the hell we are in.
• moggers123 10mo ago
  What's the grug brain method of "live updating list with a search bar". I tried htmx sse but it turned out to be not that great. I was hoping I could model it as a single request/response cycle like a traditional page post, with the astericks that the single response is actually a stream of responses. Clicking search or whatever again "just" axes the old request and sends another one with the updated parameters. Perhaps the form being dirty would actually be what axes the stream.
  • yawaramin 10mo ago
    https://htmx.org/examples/active-search/ https://htmx.org/examples/active-search/
• auct 10mo ago
  If you are purist, try uajax and uajax button. Imo it will cover 90%+ projects.
• joeevans1000 10mo ago
  Weird, Safari reloads the page on the demo button clicks and Chrome does not. UPDATE: the second visit to the page on Safari didn't have the issue. It's interesting to note that some people might have that effect though... reloads on Safari occasionally for whatever reason. Or it could be something rare on my end.
• JohnMunsch 10mo ago
  False dichotomy. Your only options aren't HTMX or React/Vue/Svelte when web standards like custom elements have been here for years, are smaller, faster, and work with all your browsers (including the ones on your phone).
• JimmaDaRustla 10mo ago
  I'm using Inertia
• nymanjon 10mo ago
  HTMX and related libs work just fine as offline apps. I've been doing it with my personal apps I make for myself for a long time. Also, morphdom/idiomorph get you a long way even when you have highly interactive pages, especially if you have to hit the back end anyways. If you don't need to hit the back end then a front end lib is fine. But even then, the simpler pattern of hypermedia-driven applications can be better. See https://github.com/jon49/Soccer https://github.com/jon49/Soccer as an example of this.