26 ms·

The Future of Htmx

• deleted 2y ago
  [deleted]
• xvinci 2y ago
  I am still trying to get HTMX adopted in a ~ 800 employee software development company. And while we do not yet have a project using HTMX in production, I like to use it a lot in thought experiments with mentees: Could you do it with HTMX / Fragments? If yes, how would you design it? Do we REALLY need an SPA? Kudos to the developers.
  • graypegg 2y ago
    I do think "use HTMX" is a tough sell for a 800 employee company, just because it doesn't really solve issues on it's own. (Imagining the pitch is "add HTMX to an existing project") Going all-in on hypermedia definitely means the service that serves your application needs to be more than just a JSON parrot. Templating HTML and sending the right chunks back is hard to do if those services aren't built around being hypermedia services. I really like turbo-rails [0] (the ruby gem that Rails 7+ bundles in for turbo support, meaning helpers that make turbo frames/responses a native "thing" rails understands) because it's a complete solution. There's at least some obvious structure to build off of, and I'm not stuck trying to build up my own framework on the BE for my newly simpler FE. django-htmx [1] also fits in this case too. I feel like any honest pitch of HTMX should involve some BE solution as well. [0] https://github.com/hotwired/turbo-rails https://github.com/hotwired/turbo-rails [1] https://github.com/adamchainz/django-htmx https://github.com/adamchainz/django-htmx
    • xvinci 2y ago
      I dont intend it to be an all-in, but I do believe it could do the job in 50% or more cases just as well as any SPA framework. A lot we do is "just crudl" with some sprinkles on top. A large chunk of our business comes from Spring Boot, so we are experimenting with JTE - looks decent so far (Thymeleaf feels just old nowadays). My sell is pretty simple: You have regulations coming up in europe which will require you to keep applications up-to date and secure. Extending your SBOM by 1k NPM libraries is a huge cost. I want to get rid of that.
  • kgeist 2y ago
    I tried to get HTMX adopted for a new project but the unanimous response was "what is this? why not React? everyone knows React. period" and most of my arguments for HTMX were ignored, because to most people, HTMX looked like some obscure, yet another JS framework created last week, with questionable future.
    • frde_me 2y ago
      To be fair, it's not an unfair response. Being able to hire for a technology, and having a large community around the tech stack you use has tangible value. HTMX might not be something that will vanish in a week, but it's also nowhere close to a mainstream framework.
    • wg0 2y ago
      Very anti React person went for Svelte but the kind of modularity React offers, HTMX can't hope to match especially on larger projects. Modern React is too simple. A component is just a pure function taking arguments and returning UI as JSX. The only other thing you need to know is few hooks.
      • The_Colonel 2y ago
        > Modern React is too simple. A component is just a pure function React is simple only in some mathematical theoretical sense, but not for understanding by human minds which fundamentally operate imperatively ("if I click on this, load data X from the server and show them to the user..."). You can get some hello world example relatively easily, but you hit the complexity wall quite quickly (need to know "some hooks" - some, like useEffect() are very complex, yet often needed for basic things). The worst of all is debugging with stacktraces making no sense with it all being from the React itself, not your code, not tracking some logical pathway. (I'm saying that as someone who generally likes React and would choose it for a new project)
        • wg0 2y ago
          useEffect is simple. If I recall correctly, with no arguments it is like onMount and with the dependent variables listed in array, it would be executed every time any of the listed variables change.
  • jjk7 2y ago
    I built an HTMX fragment framework for Django. It allows you to render a fragment, and automatically serves the fragment separately for live-updates. I'll open source it tonight and post back. In my opinion, HTMX + custom elements does everything React does but better, and is a billion times cleaner.
    • WD-42 2y ago
      Sounds great!
    • weikju 2y ago
      > I'll open source it tonight and post back. Would be interested in seeing this
• whinvik 2y ago
  Is jquery something people start projects with today? If so, what is the motivation?
  • michaelcampbell 2y ago
    Start? Not generally I don't think. That said, back in the day it provided functionality that JS just didn't, or was quite cumbersome. With recent JS versions, JS can do a lot of what JQ did for it, but JQ's API or "surface area" is still syntactically smaller and (IMO) more sane than those JS improvements.
  • BoredPositron 2y ago
    Wordpress Themes/Plugins are still all over it.
    • recursivedoubts 2y ago
      ~43% of the internet runs on WordPress[1] while ~75% of the internet uses jQuery[2], so even if you took out every website that used jQuery due to being built on WordPress, the number of websites using jQuery would be over six times higher than the number of sites built using react. [1] - https://colorlib.com/wp/wordpress-statistics/ https://colorlib.com/wp/wordpress-statistics/ [2] - https://w3techs.com/technologies/overview/javascript_library https://w3techs.com/technologies/overview/javascript_library
  • Gys 2y ago
    You saw 'jquery' in the second sentence of the text, immediately closed the link and started a comment with this question?
  • pelagicAustral 2y ago
    I have, many times in the last 2 or 3 years... I still do... It's cheap and easy to implement, it's easy to use and it ads just as much cruft as I'm willing to tolerate. I build boring software, average CRUD applications for government departments, people in this line of work don't give a shit about millisecond delays or reactivity, hell, they don't even care about responsiveness... jQuery facilitates high speed development, provides neat functionality that doesn't get in the way, it's easy to maintain, and keeps people happy.
• andrewstuart 2y ago
  Off topic but the other day I tried again to build a vanilla JS application. By the end of the day having built quite a lot I then converted the entire thing to react within half an hour stopped wasting my time and got in with the job of building the thing. I like to try library free JS every now and then and yet again it was not competition for react. I know react, it makes sense to me, I find it easy and powerful, I know how to fix most issues and probably most importantly Claude is able to write react for me almost without me intervening at all. I’m not saying react is for everyone but for me it’s a power tool that I know and the AI knows very well and it gets big stuff built quick.
  • wordofx 2y ago
    That’s great for you. But every single react project I’ve seen or inherited has been a steaming pile of shit. All these new front end developers who jumped in on react with no other experience have no idea how web works are struggle to build without react. Anyone competent in web development prior to react could build with htmx or even vanilla js just as fast without react as they could with react. Won’t stop the brainwashed react devs coming out defending their only source of income tho.
    • robertoandred 2y ago
      That's the fault of bad developers, not React. There are bad developers for each and every language, library, framework, and stack.
      • wordofx 2y ago
        There are no good react developers because react encourages you to abstract things into 1000s is tiny files.
    • phist_mcgee 2y ago
      Isn't that like saying that a "competent" woodworker has to know how to use handtools first before trying to build anything with power tools? What's the problem with starting from an elevated starting point?
• tbatchelli 2y ago
  I value the hard stance on stability and backwards compatibility over the constant churn that some JS libraries/frameworks have. I understand the need both approaches, but this is a breath of fresh air. I also happen to think that most web apps have no business being so complex, and that too much work goes into dealing with the added complexity of running SPAs where an SPA is not needed.
  • robertoandred 2y ago
    Why is the added complexity of running HTMX better than the complexity of an SPA?
    • rednafi 2y ago
      Because then I can keep the bulk of the logic in a language that’s better designed than JS. Not having to write JS is a huge feature. The added complexity of HTMX is abstracted behind a single library, and the bulk of the logic stays in a better-designed language—Go, Python, Java, Kotlin, Rust, Zig, C#, anything.
      • robertoandred 2y ago
        None of those languages can do anything in the browser.
        • preisschild 2y ago
          With HTMX they can, because they make server rendered pages more viable.
          • robertoandred 2y ago
            When someone swipes a carousel, how will C# update the dom attributes and labels on the fly?
            • 2y ago
• evolve2k 2y ago
  I’m very grateful for how htmx by focussing on a very specific part of “interactive JavaScript on the page” was able to shift a whole bunch of similar JavaScript actions into an elegant abstraction that rested so neatly on all the existing work that had/has gone into developing html. And even for having the clarity to name it as such. In a way it’s a bit of a lesson in managing complexity, rather than seek to be “the next JavaScript framework to replace all the others with its theory of the universe”, it instead carved off a smaller slice and said these Thich are related, we’re just for dealing with these thing, nothing more. In one swoop a whole raft of manual developer programming workload was packed up with a new easier to understand abstraction. Kudos to the team, I’m grateful for the considered way you’ve developed this tool for the rest of us.
  • swyx 2y ago
    how do you feel about its adoption in things like https://fastht.ml/ https://fastht.ml/ ? i was open to the idea at first esp with jeremy howard's endorsement, but once you start updating multiple things on a page at once i felt like i was fighting htmx rather than it helping me. components are a really neat paradigm and just bc react is currently in a complexity upswing doesnt mean we want to throw the baby out with bathwater
    • mejutoco 2y ago
      You can build your own python component implementation on top of htmx, like in the example you show. That is not a failing of htmx IMO.
      • swyx 2y ago
        thats not what the js world traditionallyunderstands as a component - eg - it doesnt take an argument that, when the argument value changes, the component rerenders. you still have to wire all that up with htmx (again, as far as i undersatnd it, having spent a week with htmx)
        • WickyNilliams 2y ago
• _tom_ 2y ago
  I feel this article makes the same mistake many technical articles make. What does it do? After reading a large chunk of the article, I have no idea. No, wait it "enables behavior". Maybe it's only relevant to people that are already familiar with it. But it would seem that a hacker news front page would be a great opportunity to let more people know about your product.
  • recursivedoubts 2y ago
    i would recommend the homepage & docs: https://htmx.org https://htmx.org https://htmx.org/docs https://htmx.org/docs and if you want a more in depth treatment, our book (free online): https://hypermedia.systems https://hypermedia.systems
  • ggregoire 2y ago
    > But it would seem that a hacker news front page would be a great opportunity to let more people know about your product. It's on the front page every other week… https://hn.algolia.com/?query=htmx https://hn.algolia.com/?query=htmx
  • bdcravens 2y ago
    Why should every article on a site restate the premise of the project? After all, this article doesn't tell me what React is: https://react.dev/blog/2024/10/21/react-compiler-beta-release https://react.dev/blog/2024/10/21/react-compiler-beta-releas...
  • ecshafer 2y ago
    This isn't an announcement of a project. This is more a statement of their philosophy and what they are doing. This is targeted towards people familiar with the project.
• eawgewag 2y ago
  As a React developer, I love that HTMX is trying to aim for stewardship and "No new features as a feature". IMO, page router NextJS is perfect (and in line with the original API it pitched), and the bifurcation to app/page router has been complicated. Yes, I am fully aware that NextJS works with both app/page. I just find it mentally confusing to wrap my head around both worlds. I feel this way about base React too, including -- functional/class components, hooks/non-hooks, and more recently, RSCs/Client components. Although I'm more willing to see React as an evolving research project, as contradictory as this may sound.
  • WD-42 2y ago
    I’ve been bitten so many times with the app/page router thinking I was looking at docs for one but I was actually looking at them for the other. So annoying.
• logankeenan 2y ago
  I really wish htmx would use fetch rather than xhr, and now it looks like that won’t happen. Fetch is easier to proxy, so it would open up a lot more possibilities for backends, like ones running in browser or a native process. I had to hack together a xhr fetch proxy to make this happen. https://github.com/logankeenan/xhr-fetch-proxy https://github.com/logankeenan/xhr-fetch-proxy
  • recursivedoubts 2y ago
    we've looked at doing it but unfortunately fetch() doesn't fire upload events which would make implementing some events triggered by htmx possible it's too bad the two APIs have overlapping but not contained functionality.
    • logankeenan 2y ago
      Are the upload events specifically used for files or for most server interactions. I haven’t noticed any issues with my proxy yet…
• kmos17 2y ago
  Greatly appreciate this philosophy and what htmx brings to the table. It is very simple and quick to pick up, and the longterm stability and simplicity are major advantages for web development.
• jilles 2y ago
  I've created a Django application using HTMX. Usually I'd jump to React or Vue. It was a great exercise and I can see where HTMX would be a great fit. 1. If you consider yourself a "backend developer" only and want to write the minimum amount of JS/TS. 2. If your application is simple. Yes you can do more complicated interactivity with oob swaps, but you end up with more complexity than you chose HTMX for. For my next projects, I will still use Django but with React/Vue for pieces that need interactivity. As an example in my HTMX app, I wanted to add a profile image uploader. Lots of great frontend libraries exist to resize / modify your image before even uploading it to your server. Finally, HTMX is just not testable the same way modern frontend libraries are. I've managed to write some decent tests using beautifulsoup, but it's night and day compared to vitest or jest.
  • igortg 2y ago
    IMHO one of the biggest advantages of using HTMX is not having to maintain three layers of test suites (backend, frontend, end-to-end). You just need to test that your endpoints return the right HTML piece. You don't need unit testing the frontend since you don't have that much logic there. Just rely on end-to-end tests as a complementary tool to check small pieces of logic on the HTMX code.
    • The_Colonel 2y ago
      That honestly sounds like a downside. Having to verify HTML as an output (in comparison to e.g. JSON) is brittle since it will often change just for presentation reasons. Having a clear and somewhat stable API (which is a boon for testing) is IMHO a strong reason for the SPA model.
      • recursivedoubts 2y ago
        htmx moves the data -> html transformation to the server side and thus should be more testable
      • eddd-ddde 2y ago
        Not really unstable since you generate it and there's no browser modifying it. However you'd still lack client functionality testing.
• stevoski 2y ago
  Love this. The attitude of the htmx developers is highly commendable.
• bravura 2y ago
  "Today many web developers consider jQuery to be “legacy software.” With all due respect to this perspective, jQuery is currently used on 75% of all public websites, a number that dwarfs all other JavaScript tools." This argument is that jQuery is still very popular compared to JS frameworks like React, etc. What about vanilla JS? As someone who isn't that experienced with JS, my understanding is that modern vanilla JS is "about as good as" jQuery. i.e. if you don't need much JS these days, just choose vanilla JS.
  • recursivedoubts 2y ago
    That may or may not be the case (see https://youmightnotneedjquery.com/ https://youmightnotneedjquery.com/) but the fact remains that jQuery is used on 75% of all public websites.
    • gjsman-1000 2y ago
      Notice how the “modern” is almost always more verbose than JQuery. JQuery might as well be a shorthand JS library.
      • recursivedoubts 2y ago
        it's a good API! and consistent!
      • matharmin 2y ago
        I view JQuery as similar to C in some ways: It's been around forever, it's mature, and it works. It gives a good experience to get something up and running quickly: it's lightweight and simple. But if you're working on bigger projects: It is possible, but have have to be very principled in how you use it, otherwise you're going to end up with either a massive spaghetti codebase and lots of edge cases in your app that breaks. Alternatives like React and Rust may add more complexity upfront, but the improved structure and safety it gives has big benefits in all but the smallest projects.
        • 2y ago
• kweingar 2y ago
  I'd love to use HTMX at work. Sadly the security folks would probably balk at checking in JS code that uses eval(), even though you can disable eval at runtime in the HTMX config. I thought about writing a script to remove all references to eval (and all tests relying on eval), but at that point it would probably be easier to just rewrite the library.
  • recursivedoubts 2y ago
    eval can be disabled at the CSP level, which is much better than at the source level (which can always be obfuscated, missed in a version update, etc)
    • viraptor 2y ago
      It can be, but then you discover how marketing added lots of gtag and other content which is already full of eval ;)
      • recursivedoubts 2y ago
        oof
• jmull 2y ago
  > ...you can use as much or as little of it as you like... Stability as a Feature... No New Features as a Feature... This is the way. Having lived the alternative, I won't consider building anything significant on top of an abstraction that doesn't credibly promise these. When the abstraction you've built on changes or fails, the thing you built breaks. When you choose an unstable abstraction, you're creating future bugs you'll have to spend future time on to resolve (and if it wraps the lower layer rather than sitting beside it, you have fewer options to fix them). These aren't concerns for things that will be short-lived, or are small enough to replace if needed. But I've seen plenty of small and temporary things turn into large and permanent things when they end up being useful.
  • game_the0ry 2y ago
    > ...you can use as much or as little of it as you like... Stability as a Feature... No New Features as a Feature... Given my experience with node ecosystem, react, and nextjs, I am inclined to agree.
    • jmull 2y ago
      I agree about react and nextjs. But the node ecosystem includes essentially everything that touches on javascript, both the bad and the good. I don't think there are very many ecosystems that are guaranteed to have only good stuff. Regardless of ecosystem, the developer has to examine what is available and make wise choices.
      • klabb3 2y ago
        I think the culture is so prevalent that I have to defend parent’s statement. Node itself, and npm which is a node project, are some of the worst offenders. It’s had abysmal stewardship imo, and one could argue this sets the tone for the ecosystem at large. Hack upon hack, config files of doom. There are exceptions, but at this point the verdict is clear. It’s like the meme about Java being enterprisey and over-abstracted with factories. As far as stereotypes go, it’s true. (Or was, haven’t used it in forever) I’m not even against JS, and much less the web. I think it’s the 7th wonder of the world. But the developer practices makes me want to tear my hair off.
• fermigier 2y ago
  Good. For a couple of seconds, I feared something like "The next step of our wonderful journey...".
  • baobabKoodaa 2y ago
    The creator of HTMX likes to periodically troll people on Twitter like this.
    • recursivedoubts 2y ago
      troll? wdym?
• uludag 2y ago
  > No New Features as a Feature No new features is such an underrated feature. It's funny sometimes when people see some Common Lisp or Clojure library with no commits in the last X period of time, and people immediately come to the conclusion that something must be wrong. In the world of AI tooling, "completed" should have a huge advantage over libraries with lots of churn. Maybe a positive side-effect of new AI tooling is that there will be competitive pressure for libraries to reach a completed, no-new-features state.
• buryat 2y ago
  This is just people's subconsciousness fighting against the rolling progress. It's trying to avoid learning new things and trying to preserve the status quo where you can keep rolling using the already acquired knowledge. It's anti-thetical to being a hacker. The modern way is to use LLMs to auto generate all this code and do some small corrections in the process. So you wouldn't have to worry about the underlying tech and would only be concerned about the core functionality and actual mechanics of the product rather than being interested and spending efforts on memorization of the specific instructions for the machine. The whole evolution of the programming languages is a process in that direction and new technologies that were embraced by the newer generation like React and Vue.js is the way to go. You can't run geosites forever.
  • lemonwaterlime 2y ago
    The philosophy of a tool like htmx encourages the opposite of "avoiding learning new things". The reality is that there is not often anything that is truly novel. We waste time by failing to recognize patterns and abstractions that persist over long periods of time and in many cases that are even foundational knowledge. A foundational fact by definition does not need to be constantly scrutinized as if it were not. Rather it is something that can be relied upon stably until such a time that a change in a core assumption forces us to reevaluate the foundation if and when that scenario occurs.
  • peebeebee 2y ago
    It’s about using the right tools for the job. FAANG and developer advocates made the web needlessly complex for most people. The over-engineered tools and frameworks became the “default” way of programming for the web, loosing some strong key features that were good about it: simplicity, transparency, and speed.
  • brushfoot 2y ago
    > It's trying to avoid learning new things and trying to preserve the status quo Well, yeah. Sometimes the status quo is good. Sometimes you don't want to learn how to do simple async page updates for the thousandth time. Because many of us here have been there, done that. Over dozens of years. With dozens of libraries. It's a hamster wheel. It's boring. It's pointless. In the end, if your website/app does what HTMX is good at, just use it. I learn dozens of new things every day as a solopreneur SaaS guy. I don't want to relearn how to make async page updates ever again, unless there is a very, very compelling reason to do so.
• lemonwaterlime 2y ago
  I am a fan of this approach. About to launch a SaaS now and htmx powers much of the interaction so far. Tools like htmx make it easier for solo founders and small teams who don't have the bandwidth or the desire to manage all the churn. Keep the dependencies tight and ship!
• ksec 2y ago
  >In particular, we are trying to push the ideas of htmx into the HTML standard itself, via the Triptych project. In an ideal world, htmx functionality disappears into the web platform itself. I have been calling for this for a very long time even during pjax era. I hope that is not only an ideal but a realistic pathway forward. Chrome / Blink or Safari / Webkit. If we could just get one of them to implement it as experimental feature. How could we push this forward? JPEG XL and HTMX in HTML, along with some sort of basic rich text editor for everyday writing is what I want browser to be included by default.
  • recursivedoubts 2y ago
    you can support and publicize the triptych project: https://alexanderpetros.com/triptych/ https://alexanderpetros.com/triptych/ https://github.com/alexpetros/triptych?tab=readme-ov-file https://github.com/alexpetros/triptych?tab=readme-ov-file
• AbraKdabra 2y ago
  I've been a Vue user for years, I do automations and glue code mostly, and most of the times using Vue is a bit too much, for my last project I used https://github.com/guyroyse/htmx-tailwind-vite https://github.com/guyroyse/htmx-tailwind-vite and been delighted about it, it's exactly what I need.
• BrenBarn 2y ago
  People are commenting about "no new features as a feature", and I agree, but even better is this: > People shouldn’t feel pressure to upgrade htmx over time unless there are specific bugs that they want fixed Frickin A! Nice to see somebody pushing back against the trend of "if you haven't updated your software in the last five minutes you're on an unsupported configuration".
  • ofrzeta 2y ago
    So if you have a project that uses a (even small) number of libraries, how to you keep track of being affected of some specific bug of some library?
    • itishappy 2y ago
      You submit a bug report and (assumedly) get a fast response because they explicitly prioritize fixing bugs over adding new features.
      • ofrzeta 2y ago
        I guess in most cases you will be affected by bugs that you did not notice let alone report.
        • itishappy 2y ago
          More reason to prefer a more deliberate release cycle! Focusing on security and stability restricts the area available to bugs significantly more than chasing hot new features all the time.
          • EasyMark 2y ago
            And also helps make for minimal changes when you ultimately find you need to move on from your current version. Probably why a lot of people stick with emacs/vim/whatever over every new fangled editor that comes out
    • 2y ago
• simonw 2y ago
  Anyone got a good feel for the htmx accessibility story at the moment? I'm interested in using it more, but I want to be 100% confident that I understand how to get htmx sites to work well with screen readers. I worry about things like fetching new data into a page not altering the screen reader user in the same way as refreshing a page completely would. I'm not interested in whether or not htmx uses the correct ARIA attributes - I want to be confident that those ARIA attributes (or similar) do the right thing. My ideal is still to use JavaScript libraries where the documentation not only describes how they work with screen readers, but is accompanied by video evidence showing the experience a screen reader user gets for different problems solved by that library.
  • 1propionyl 2y ago
    Handling ARIA attributes is out of scope for HTMX. It is your responsibility to include ARIA attributes on the HTML you return and swap/transclude. As for handling dynamic content for screen readers, focus management is already a thing, and is in the scope of browser standards and the HTML your backend returns. As before, it's your responsibility to manage this. HTMX will neither help you nor get in your way. HTMX merely extends hypertext functionality to its (mostly) natural conclusion. It is not a component library, or a framework for building components, or a site building framework, or... You can use other tools to enhance and audit accessibility, but their use is orthogonal to HTMX. I think web developers in general are very used to frameworks abstracting a ton of complexity, but HTMX is not a framework so much as a standardized set of tools for specific low level problems, it is not a one stop shop.
    • simonw 2y ago
      In that case it would be great if the HTMX documentation included worked examples and guidance for how to do this. Leaving accessibility up to the end developer feels like a genuine missed opportunity for me here. One of the great things about NOT using a JavaScript library is that you can rely on the browser's default accessibility features for forms and links. Those benefits are the thing I care most about when considering HTMX or jQuery or React or Vue or similar.
• liendolucas 2y ago
  I'm huge a supporter of the HTMX philosophy. I highly recommend reading Hypermedia Systems especially for people that are just beginning doing web development. I've purchased the book and it was a wonderful read especially for its explanations and pragmatism.
• deleted 2y ago
  [deleted]
• rglover 2y ago
  If you like this approach but want a full-stack JS solution, check out Joystick [1] (the philosophy [2] page echoes a lot of the same sentiments here). [1] https://cheatcode.co/joystick https://cheatcode.co/joystick [2] https://docs.cheatcode.co/joystick/philosophy https://docs.cheatcode.co/joystick/philosophy
• chimen 2y ago
  i love frontends like shadcn/ui too much to go away from react - AS MUCH as I'd love to do it since I hate npm cancer to death
• drdaeman 2y ago
  Htmx always sounded nice and I always wanted to give it a try - yet, paradoxically, I always had my reservations about it on the conceptual level. With something like Elm, I'm basically thinking of the frontend as a state machine (composed of smaller state machines). I always know what's [supposed to be] going on exactly, and assuming that all the underlying machinery is working as expected and that I haven't messed up anywhere, I can be sure that everything is consistent. Basically, things are data-driven. Htmx feels like a step back in this regard. Let's say https://htmx.org/examples/delete-row/ https://htmx.org/examples/delete-row/ - something back in my mind yells at me that I don't really know what I'm presenting in that table. The state is in DOM, all "inverted" as the frontend is not really aware what it's displaying (it can figure it out by introspecting the DOM, but that's exactly what feels off). I'm just concerned that it'll end up like my ancient Delphi or Visual Basic projects, where it was impossible to understand what's going on, because everything got tangled up in a ball. This is opposite of data-driven approach that I don't really know a name for... "shape-driven"? I look at examples like https://htmx.org/examples/sortable/ https://htmx.org/examples/sortable/ and I just can't shrug off the feeling that with such design the frontend has no idea about what's going on, and while it's fine if all I ever need is a small sorted list (that I can pull back from DOM - which acts like a weird pseudo-database), if it grows it becomes error-prone, difficult to comprehend and maintain. I suspect this is because HTML was always about documents, and never about interactive applications, so there's this fundamental impedance mismatch when one tries to build an application in a browser. I thought the solution was to build a new abstraction replacing HTML - with things like React being intermediate steps, still using HTML/CSS for rendering, and canvas-based GUIs being the way to go, unburdened by the document-based foundations anymore. In other words, I'm not really convinced that Hypermedia is a suitable foundation for a lot of the things people actually build online. Htmx surely has appeal in simplicity, but doesn't this simplicity brings back all the complexity people tried to get rid of all this time? Is there something I'm missing? Should I possibly think of the frontend as a terminal-like system that can run small programs but is not an application so it's never aware of what's going on? Or is it something else? My apologies for the confusion, or if I wrote something weird (I sure babbled a lot). I'm just trying to keep up with the world and understand it. (And, of course, no doubt, one can write crappy incomprehensible mess of a codebase using any technology. Maybe all my issues is that I have no idea how to write good Htmx code that wouldn't bloat and rot over time?)
• mtrovo 2y ago
  It is clear that htmx has a growing community, but it still feels a bit too backend-minded to convince frontend developers to adopt it. I tried it in a prototype, and it was quite pleasant until I realised I needed to account for additional state management and backend wrangling to be able to provide some dynamic features. That was the moment I realised htmx is not a fully fledged product but rather a core feature that sits neatly atop a traditional server-driven setup. That's why I think their roadmap looks right. I believe the way to broader adoption is to improve tooling, encourage standardisation, and integrate htmx more closely with well-known frameworks. That's the only way I can see dev teams buying into the paradigm change and htmx jumping into mainstream usage.
  • rednafi 2y ago
    The idea is to have fat backends and dumb clients. It’s definitely a different way of building things and not everyone’s cup of tea. For me, the biggest selling point is getting to write less JS. Writing the bulk of the logic in Go, Python, Kotlin, Rust, or Zig is a huge plus, as I consider them better-designed languages with easier maintainability.
• danpalmer 2y ago
  I’ve just completed a port from HTMX to Hotwire (Stimulus, Turbo). HTMX is a great idea, but in my experience it’s a poor execution. It’s really quite buggy, in my experience it plays poorly with fundamental web and browser features (relative links are broken in at least 2 ways, I fixed a third way). One of the events just stopped working at all in the most recent release. The docs are lacking. And where it promises to let you write less JS, if you ever do need to write some JS you’re on your own in structuring that, and you’ll be fighting against HTMX (who gets to update the DOM, maintaining event handlers, etc). As a (brief) contributor to HTMX, I also feel like these issues were all inevitable. It’s a single 5k line file with 190 top level functions in it meaning it’s pretty impenetrable to get up to speed on. When proposing a bug fix the maintainers weren’t sure if it would have other consequences. Tests didn’t cover the functionality. I’ve been mostly a backend engineer in my career, and I empathise with not wanting the complexity of a modern frontend, but that doesn’t mean we can’t have some basic organisation of the code to make it approachable and more obvious whether changes will work or not. After porting to Turbo and Stimulus I have a more reliable code base, I have significantly less JavaScript, and I have a JS code base that much easier to reason about. I really wanted to like HTMX but the execution is not there. A focus on stability is a great fit for the project, but it’s most certainly not there yet and has quite a way to go in my experience.
  • mring33621 2y ago
    Last time i tried it, i couldn't get hotwire to work with a non-ruby backend. HTMX had no issue, tho
    • danpalmer 2y ago
      It’s definitely documented as Rails first, but so far I’ve had no compatibility issues using it with my Swift backend.
      • mring33621 2y ago
        no doubt there was something small that i was missing, but i was doing a rapid, time-boxed experiment and didn't have time to get deeper into it, at the time
• seanwilson 2y ago
  Anybody have any thoughts on if the View Transition API is going to replace a lot of HTMX usage? This multi-page demo is decent, where each click is actually loading a new page: https://view-transitions.chrome.dev/stack-navigator/mpa-prerender/ https://view-transitions.chrome.dev/stack-navigator/mpa-prer... https://developer.chrome.com/docs/web-platform/view-transitions https://developer.chrome.com/docs/web-platform/view-transiti... > The View Transition API gives you the power to create seamless visual transitions between different views on your website. This creates a more visually engaging user experience for users as they navigate your site, regardless of whether it's built as a multi-page application (MPA) or a single-page application (SPA). Typical situations where you would use view transitions include: > A thumbnail image on a product listing page that transitions into a full-size product image on the product detail page. > A fixed navigation bar that stays in place as you navigate from one page to another. > A grid with items moving positions as you filter through. So this would cover a few uses of HTMX? Recent Safari and Chrome now have decent support. Sounds like Firefox are working on it but I couldn't find an expected release date.
  • recursivedoubts 2y ago
    i think the transition API, when it is broadly available for MPAs, could replace a fair number of simple UI use cases of htmx. The main feature it would likely obsolete is the `hx-boost` feature: https://htmx.org/attributes/hx-boost/ https://htmx.org/attributes/hx-boost/ There are already people, including people on the core htmx team, who think that hx-boost isn't a great feature: https://htmx.org/quirks/#some-people-don-t-like-hx-boost https://htmx.org/quirks/#some-people-don-t-like-hx-boost If that goes away, htmx will be useful for smaller transclusional features at a lower level of complexity, so the two should complement one another in my opinion.
    • seanwilson 2y ago
      > If that goes away, htmx will be useful for smaller transclusional features at a lower level of complexity Thanks! Any examples here to help understand where View Transition doesn't help?
• robertoandred 2y ago
  I've found Htmx to be smug and misleading. "Look how simple it is! No JavaScript! Ignore the fact that you need a complex backend in a separate language and environment to generate your html."
  • mixmastamyk 2y ago
    If you eliminate most of the frontend, of course you're going to need a backend. Otherwise you have no app. Intelligent post there.
  • rednafi 2y ago
    Separate language is fine for those of us willing to write anything but JS. As long as it means writing less JS, a separate backend isn’t that big of a deal.
    • robertoandred 2y ago
      Not everyone is so scared of JS that we need separate silos for rendering in the browser and rendering on the server.
      • andybak 2y ago
        Consider it might not be fear but a strong dislike based on solid philosophical and/or aesthetic reasons. Some of the people you're dismissing have probably been using JavaScript for a lot longer than you have.
        • robertoandred 2y ago
          There's nothing philosophically or aesthetically good about <button hx-get="/confirmed" hx-trigger='confirmed' onClick="Swal.fire({title: 'Confirm', text:'Do you want to continue?'}).then((result)=>{ if(result.isConfirmed){ htmx.trigger(this, 'confirmed'); } })"> Click Me </button> or about <div hx-get="/clicked" hx-trigger="click[ctrlKey]"> Control Click Me </div> or <form id="example-form" hx-post="/test"> <input name="example" onkeyup="this.setCustomValidity('') // reset the validation on keyup" hx-on:htmx:validation:validate="if(this.value != 'foo') { this.setCustomValidity('Please enter the value foo') // set the validation error htmx.find('#example-form').reportValidity() // report the issue }"> </form> Htmx's own examples push you to code that is unorganized and inaccessible.
• lakomen 2y ago
  Overhyped, back to 20 years ago. No proper framework in any language. And no it's not the new jquery. You can't do real time time tickers. You can't call client side functions. It's hyped by entry level web devs, because they don't know any better. You get all the baggage with it, that you hoped to be rid of with the separation of data provider and client consumer. Session management, path parsing and matching, flash messages, complicated nested if else blocks. Argh. Search engines can crawl js nowadays. It's like going back to sysinit when you have systemd only worse. But HN never fails to hype bs tech
  • rednafi 2y ago
    I’ve heard this kind of pushback from k8s wranglers whenever a small-scale alternative is proposed. The big win here is writing less JS and more of a language that’s better designed (aka not JS).
    • lakomen 2y ago
      Idk why writing JS is such a big deal.
  • recursivedoubts 2y ago
    Really, back 30 years if you think about it.
  • yawaramin 2y ago
    But tell us how you really feel.
  • jiriknesl 2y ago
    No, it's hyped by people like me, who were writing web applications more than 25 years ago. We want to do backend because a big part of frontend is complex for no good reason.
    • lakomen 2y ago
      But it's not complex when you use the right tools. I did PHP professionally for 11 years and I waa bored out my mind of it. The repetition, the boilerplate, the stupid dogma and OO fetishism. And everyone in their freshman year suddenly knew better and tried to preach what they learned in Uni. "But that's not SOLID and not OOP". But it's simple and does the job. I moved to Go and AngularJS. That was 2013. I did full backend aka full ssr with Go, and it's a PITA. I did try htmx with a jinja like template language in Go, with templ and in Rust and ... I forgot the library, it's the go to library in Rust for htmx. All the annoyances are still there. Session management, service oriented design, if else blocks between and inside html tags. Path parsing and comparison. Template macros. And now also fragments. Now I use a graphql backend for data, and react consumes it while the ide supports intellisense for queries. It's more simple than writing your queries by hand on the backend. You have interactivity for free. And you let the client worry about how the data is displayed. Also you let the oidc server worry about users. Concerns are separated. I have authz middleware on the graphql backend, easily written. Everything has layers and there's order and a clean structure. As a plus I don't have to annoy my users with captcha. And I have reduced infrastructure costs as well as traffic. I'm 50. My internet journey began 1995. I did enough of the old way to hate it and to know when something is better. I have met my share of fanatics, of language and framework Nazis. You have to stay curious. I have tried htmx multiple times and found it inadequate, not good enough, too limited. Like I wrote there are no frameworks in any language for it. It's just JS hidden behind html attributes, claiming it isn't JS. I hate deception, the zealots are deceptive as all zealots in any language, package or framework are. Angular Nazis holy crap. Or React retards where you mention how Vue has simple SSR adaption and Rract doesn't, and are labeled as a React hater. I'm pragmatic. I like clean structure and efficiency as well as simplicity. Sometimes you have to learn a bit of complexity to have it simple and efficient in the long run. I have tried many things. Ruby on Rails, Elixir. You know what, I have started programming at the age of 11 on the cpc 464 in basic, at 12 I cracked c64 games and wrote cracktros in asm. I'm one of the first cheat creators for MMORPGs ever. I don't consider myself super smart, but I have seen a lot and tried a lot. I also struggle with learning new things. But you have to. Htmx is not the way. It's a step back. It's only for simple things. I do believe the hype when it's reasonable. Like with MVC. It was the natural way to write SSR websites. This is the way. But then something better came along and it took a while to solve the inadequacies it had. But now it's at a point where SPA + graphql + oidc = awesomeness. And it's going to become better. And I'm not talking about the Nextjs crap, those fake backend libraries that are hugely overcomplicated.
• ijidak 2y ago
  > No New Features as a Feature > We are going to be increasingly inclined to not accept new proposed features in the library core I deeply wish the C# team recognized the value of this.
  • StressedDev 2y ago
    Why? C# has added a lot of good features over the years including lamda functions, generics, private functions, string interpolation, LINQ, etc.
• jakubmazanec 2y ago
  > This means accepting and documenting the quirks of the current implementation. If you're planning no new features as a feature, why not first remove those quirks? Why keep them around? > People shouldn’t feel pressure to upgrade htmx over time unless there are specific bugs that they want fixed Truly, there exists a middle path: you can make breaking changes and user still can upgrade at their own pace (using future flags, codemods, etc.), you don't have to refuse progress - it's just a "more" work for the creator.
  • recursivedoubts 2y ago
    That's true but we're doing it this way instead.
    • andybak 2y ago
      Are you tired, distracted or answering on the go? A couple of your replies in this thread have seemed a little half-hearted. Sometimes it's better not to reply at all - or to reply at a later date.
      • recursivedoubts 2y ago
        I do have a pretty bad knee injury I'm dealing with. Maybe that's distracting me.
  • yawaramin 2y ago
    > why not first remove those quirks? Why keep them around? To preserve backward compatibility. > there exists a middle path:...it's just a "more" work for the creator. I think you just answered your own question. Unpaid maintainers of a free open source software project are trying to reduce their maintenance burden. This is normal and actually a good thing if it means they will be able to stick around for the longer term. Consider that you are asking a guy who has been maintaining open source projects for more than a decade, with some degree of success. So his strategy is probably working for him.
    • 2y ago
• rsyring 2y ago
  I have used and like HTMX. But I think Unpoly is more batteries included, in a good way: https://unpoly.com/ https://unpoly.com/ It has more built-in functionality that most web applications are going to need.
  • recursivedoubts 2y ago
    Unpoly is a great library that I try to signal boost frequently: https://x.com/search?q=from%3Ahtmx_org%20unpoly&src=typed_query https://x.com/search?q=from%3Ahtmx_org%20unpoly&src=typed_qu... I interviewed the creator here: https://htmx.org/essays/interviews/henning-koch/ https://htmx.org/essays/interviews/henning-koch/
  • zareith 2y ago
    Also: https://mizu.sh/ https://mizu.sh/ It embraces a more structured and composable approach and I love that it embraces web-components.
• paxys 2y ago
  I see so many people praising the "no new feature as a feature" part, but hasn't semantic versioning already solved that problem? If you are on version 3.x.x of a library, why do you care if 4.x or 5.x or 6.x is launched, other than FOMO? Just keep using whatever version you want and let others have shiny new things. There are so many sites out there using 4-5+ year old versions of React, and they all work perfectly fine. There's no compulsion to upgrade if you don't want to.
  • reshlo 2y ago
    Because your potential dependencies will require 5.x as a peer dependency, so you have to use 5.x. Because your current dependencies will fix bugs or introduce features that you need in versions that upgrade their peer dependency to 5.x, so you have to use 5.x. Because the package itself will fix certain bugs that exist in 3.x but will only fix them in 5.x, so you have to use 5.x.
    • Drew_ 2y ago
      You can always submit a PR upstream or just fork the dependency. Ignoring the problem or new feature works too.
      • reshlo 2y ago
        At the vast majority of companies, if you said to your colleagues “just fork the dependency”, they would look at you like you must be high.
        • Drew_ 2y ago
          Forking JS packages is easy so I would say those engineers lack passion. Not uncommon unfortunately.
          • reshlo 2y ago
            Forking JS packages and maintaining those forks is sometimes technically easy, but it is usually not institutionally easy. Your bosses who actually decide whether you have permission to create and maintain the fork have no regard for your passion when making that decision.
• mlekoszek 2y ago
  I'm so in love with the philosophy of this project. It's one of the few frameworks that I feel can do no wrong.
• morganherlocker 2y ago
  Everything listed here is a great pitch for vanillajs with zero framework at all.
• shagbag 2y ago
  Even better: https://leanrada.com/htmz/ https://leanrada.com/htmz/
  • yawaramin 2y ago
    Let's talk when it sends a request header marking requests for partial HTML fragments and supports history push ;-)
• cush 2y ago
  This is so refreshing to read
• scoofy 2y ago
  I've built https://golfcourse.wiki https://golfcourse.wiki with heavy use of htmx. Yes, my site appears a bit clunky (this is intentional), but as a solo, full stack developer working on a personal project, I wanted things to be stipped down and focus on having a solid backend and significant tests. Htmx is perfect for this. Is it elegant? Yes and no. Is it ideal? No. But what it does very well is let me focus on the code I'm writing (python/flask), without having to put three different hats on (frontend, backend, and interactive js), and it lets me code in the language I love (python) without forcing me into a gigantic javascript platform I don't actually want to be in. I'm not getting paid for this, and I won't actually spend my time coding if I'm not excited about the way I'm working. Htmx let's me code the way I want to code and that's why I'm a big fan.
  • azemetre 2y ago
    This is a great site, honestly the only thing to push it to the next level is to just polish up the styling. Aside from that it loads instantly and never had an issue clicking around. Great work!
    • scoofy 2y ago
      Thanks! Like I said, yes, the style could easily be improved, but it's really difficult to spend time on that when I'm working so hard on the backend. It's a low priority, even if it's a bad first impression for some people. For example, the most recent update completely changed the way the index page loads, as I reverted it from Leaflet -> Maplibre so that I could use OpenFreeMap, saving $20+ per month in hosting costs, and allowing for vector maps to be used: https://openfreemap.org/ https://openfreemap.org/ Thanks hyperknot: https://news.ycombinator.com/item?id=41635592 https://news.ycombinator.com/item?id=41635592 In that same update, I was able to add the "most recent week/month/year" for new and updated courses. After that update, I was overloading my flexible server instance with too much memory (oh, those for-loops and large lists). So, I then rewrote a significant section of the caching system! The important thing is the "recent updates" lets people know the site is active. I got more than a few emails about whether it was a dead site in the last year (followed by random middle-man advertising pitches). The reason why I think the styling is a low priority is that the site is targeted (for content creation) at older, non-computer literate folks at small clubs that would like to share their knowledge for posterity. It's also targeted at Wikipedians who justifiably know that this kind of detail about golf is inappropriate for Wikipedia, but still love golf. I'm not sure either demo cares too much about a site being super pretty. The information ideally is targeted at golf nerds, but mainly junior golfers, looking for available information about relatively unknown course that they will be playing on in tournaments (hence the printable course guides).
• dminik 2y ago
  I don't want to bring politics into this, but I find the hype behind HTMX eerily similar to the populist vibes I get reading what their voters write. There's this vague general sense that the "Web used to be simple" and that "Everything is so complex now". There's even an enemy that can be pointed at: React and various other frameworks/libraries and JS tools. Sometimes even JS itself isn't safe from this. Though I can never find myself agreeing with the arguments (if any get presented at all). There's a reason we're writing web APPS instead of web SITES now even if you might dislike it. Just as there's a reason the world itself is now more complex now. Ultimately I don't hate HTMX or the people who want to use it. Though to me the experience of actually using it is awful. I would ask people that they don't pretend that the backend ecosystem is any different from JavaScript. By the time you've chosen the language, debated the backend framework/chosen your templating solution and DB library and build system you could have gotten through the decision paralysis for JS too.
  • sensanaty 2y ago
    As a fullstack dev doing roughly 50/50 of both, massive agree. At least in JS land it's just JS, in the backend you even have to choose between entirely different languages sometimes, all of which have similar complexities to deal with. By comparison, especially these days, making something like a Vue or React app couldn't be simpler. You run a single command and get everything generated for you, then you point it to one of a million free hosting sites out there and boom presto, you're live. I feel like people are just afraid/cocky to admit they're too lazy to think about the frontend for whatever reason. All the arguments I've ever heard have been quite shallow and easily disproven if you spend, like, 5 minutes reading through some docs.
  • recursivedoubts 2y ago
    Glad to hear that ultimately you don't hate htmx or the people that use it. htmx is a good choice for some types of applications: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ it isn't right for everything, as I try to outline here: https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ i think i've been open and honest about when the hypermedia approach is appropriate and when it isn't and I've been open about posting bad experiences with the library: https://htmx.org/essays/#on-the-other-hand https://htmx.org/essays/#on-the-other-hand populist or not, i think the htmx website holds up pretty well when compared with other libraries/frameworks with respect to honestly outlining its pros and cons
• memhole 2y ago
  It could be my inexperience, but something that helps manage state would be awesome. I’ve found myself having to do some pretty wild things to maintain a certain UI state server side. It could be that’s just the way it is too. Otherwise, I’ve used htmx a decent amount and really like it.
• dec0dedab0de 2y ago
  I did stuff with intercooler a while ago and loved it, I never got around to htmx, maybe now is the time
• malteg 2y ago
  I briefly evaluated htmx with a go backend - and for simple navigation etc it works quite well. where I struggle is using more advanced web-components like datepickers etc. - as I dont want reimplement it from scratch. any advise from others how they handle complex client side components?
  • yawaramin 2y ago
    My current thought on this is to use Web Components but with a very simple server-rendered approach. Ie, render the custom element and all the markup it needs on the server, and have some JavaScript that loads the definition of the custom element so that it becomes interactive once rendered in the browser. I am planning to create some server-rendered custom elements in this style for my framework.
  • maddalax 2y ago
    I'm the creator of https://htmgo.dev https://htmgo.dev and I'll say that is definitely the biggest issue I've run into with htmx. It's definitely not an overall replacement, you will have to either rebuilt the date picker from scratch in js, or find a vanilla js library so unfortunately the major downside I see so far is it's fairly hard to find good open source vanilla js libraries for things, as most things seem to be written for react. other examples include: - virtualized list - combobox
    • malteg 2y ago
      Iam using templ https://templ.guide/ https://templ.guide/ in combination with htmx. I rebuilded various of html components of https://www.patternfly.org/components/all-components/ https://www.patternfly.org/components/all-components/ - but as you mentioned, I also couldnt find good vanilla JS libraries for more complex components - and I dont feel I am capable to build a e.g. battle tested datepicker from scratch. How others handle this? P.S. I have seen some people using e.g. flowbite, but I havent tried it out: https://github.com/themesberg/flowbite/issues/812 https://github.com/themesberg/flowbite/issues/812
• darcwader 2y ago
  i used htmx to write a full b2b insuretech app with customers in 15 days. thats concept to live production grade, enterprise financial app. i can tell you that it fits so so perfectly for finance apps with lots of forms and data. we have a very sophisticated quote page which also with oob was a breeze.
• atsjie 2y ago
  From the article; > Today many web developers consider jQuery to be “legacy software.” With all due respect to this perspective, jQuery is currently used on 75% of all public websites, a number that dwarfs all other JavaScript tools. I feel that is misleading. I worked on a lot of websites and none of them included jQuery willingly or sometimes even knowingly. Either it's shipped as a peer dependency or we're talking about wordpress and the like which use it (and drives much of the web!). I've seen it frequently shipped because of scripts embedded into a larger frontend codebase. Stuff they really don't want there to begin with. I do not for a second believe that 75% of frontend dev work is in jQuery. In fact, I'd be surprised if it's more than 5% of all frontend engineering work is using jQuery. Obviously some people might still use it for whatever reason; but those are a tiny majority (and probably quite vocal about it / over represented if they still prefer it). So yes, to all intends and purposes I would claim jQuery is legacy software. Current usage (wherever they got that number from) does not mean it's still the preferred choice for the majority of web developers.
  • n144q 2y ago
    That number definitely needs some clarification. My guess is that if a single page uses jQuery on a domain, it counts, even though very little of the functionality depends on it. For a large organization with decades of legacy content, it's not hard to imagine jQuery is still used here and there.
• nprateem 2y ago
  I use alpine and htmx. God above I have no idea how the more complex pages work. They're a maintainability nightmare. Still, Claude can write both and it works, soo...
• exabrial 2y ago
  > the front end world in particular, which has comical levels of churn Unbelievably so
• metafeather 2y ago
  I'd love to see the single `htmx.js` source file annotated and displayed like the classic `backbone.js` documentation[1] [1]: https://backbonejs.org/docs/backbone.html https://backbonejs.org/docs/backbone.html [2]: https://github.com/jashkenas/backbone/blob/master/backbone.js https://github.com/jashkenas/backbone/blob/master/backbone.j... [3]: https://github.com/bigskysoftware/htmx/blob/master/src/htmx.js https://github.com/bigskysoftware/htmx/blob/master/src/htmx....
  • yawaramin 2y ago
    That kinda reminds me of this https://aantron.github.io/dream/ https://aantron.github.io/dream/
• 0xblinq 2y ago
  I will never understand how is it possible that htmx has become more popular than Unpoly, when Unpoly exists since a long time ago, has been very stable, has a lot more features, it has a nicer API, better docs, etc. I just don’t get it.
  • recursivedoubts 2y ago
    yeah unpoly is a great library i interviewed Henning Koch, the creator, here: https://htmx.org/essays/interviews/henning-koch/ https://htmx.org/essays/interviews/henning-koch/