7 ms·

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, i

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
  - inopinatus 2y ago
    I’m curious about your Swift backend stack, if you’re willing to describe it. I’ve become quite fond of the language after writing a few small desktop apps & command-line tools with Swift.
    - danpalmer 2y ago
      I love the language. I'm using Vapor+Fluent+Leaf, but I've had a few issues with them, I think they're fine, but if I was making decisions again I'd probably choose something else. I think the problem is that Vapor is trying to be a Django/Rails style, batteries-included framework as opposed to a Flask-style library (if those terms help you at all), but they've not quite nailed it to the Django/Rails level yet. For my project I'd have been better off with less framework, as most of my code is not strictly web code. I've ended up changing the Vapor application architecture a bit and pulling lots out into non-web-specific Swift Modules. If I were choosing again I'd give consideration to Hummingbird. Library availability has mostly not been a problem for me, there are some really high quality libraries, particularly open source ones from Apple. Quality is high compared to other ecosystems. I'm targeting Linux/Docker for deployment and while I don't have the project running in production yet, I've been running CI builds and it so far seems fine. It's fairly clear when things are Linux compatible and when they're not. Most things you'd expect to be are compatible. Some third-party libraries are accidentally not Linux compatible, but it hasn't been much of a problem for me. The new Swift Testing library is really nice, and I'm using that for all my server tests with no real problems. Vapor could have more testing support (Django's is excellent and my bar for comparison), but it all works. Overall it's just a lovely language to work in, and I'm enjoying server side development with it.
      - inopinatus 2y ago
        Thank you, gives me some ideas on what to try, it's appreciated!
- Sander_Marechal 2y ago
  Symfony (PHP) and it's UX packages are all based on Stimulus
- dalenw 2y ago
  I use it at work with asp.net MVC, no issues either. I did have to use Webpacker though...
srameshc 2y ago
I have had a great experience with Astro and HTMX. When the first time I tried, I didn't think much about HTMX and thought it was an Astro thing, about a year or over. But this time, I had a great experience and I understand the power of htmx and native web only JS, no framework when building simple sites is much refreshing.
alexpetros 2y ago
Hey Dan, htmx maintainer here. I would love to know in what other two ways relative links are broken, and which event stopped working, so we can get those fixed. With respect to the fix you PRed (thank you, by the way), we did get that merged very quickly, and would love to do the same for whatever is broken here, even (especially) if you are no longer interested in doing the fix yourself. [0] As for the DX of making changes to htmx: absolutely true! The single file is a DX we've chosen, and it has both costs and benefits, which we've written about in "Why htmx doesn't have a build step". [1] [0] https://github.com/bigskysoftware/htmx/pull/1960 https://github.com/bigskysoftware/htmx/pull/1960 [1] https://htmx.org/essays/no-build-step/ https://htmx.org/essays/no-build-step/
- everybodyknows 2y ago
  Maybe I'm missing something here, but JS modules do not require a build step. * Note to non-JS hackers: JS module symbol scope is per-source file.
  - recursivedoubts 2y ago
    JS modules can't be imported with a plain script tag.
    - throw5959 2y ago
      Script type=module doesn't work?
      - rob 2y ago
        Not if you want to support the 0.2% market share that IE 11 has.
        danpalmer 2y ago
        That's true, but also a trade-off that is a perfectly valid engineering choice for many or even most teams.
deleted 2y ago
[deleted]
pkkkzip 2y ago
I wanted to use Hotwire but it felt like it was made for Rails as backend? This probably needs to be fixed because if the DX is as good as you say then its disservice to be tied to Rails. Which leads to the appeal of HTMX. It promises no other dependence. It just does exactly what it advertised. I'm not sure whether your issues were due to implementation or specific known bugs in HTMX not covered. I am curious to know more about Hotwire, I'm just worried about state management and this is greatly overlooked when it comes to adding application logic beyond just hydration of specific components on page. So far I have not seen anything that competes with Sveltekit.
- danpalmer 2y ago
  Hotwire is designed for good integration with Rails, but Rails is not required. In a similar way, HTMX works better with various server-side libraries, but none are required. Personally I'm using Hotwire (was using HTMX) with a Swift backend with no issues.
urronglol 2y ago
Backend dev here. Give yourself a break and use sveltekit
- ribadeo 2y ago
  Full stack polyglot dev here, the relentless pressure to use Sveltekit that has utterly destroyed plain Svelte docs, IMO, coupled with the koolaid kult around v5 is why i finally ditched svelte. I have backend solutions and existing databases and existing backends. I would never consider a Js backend in a production app to begin with, despite the benefits an isomorphic approach offers. I dislike when physical actual boundaries in code execution contexts are obfuscated, for one... But not everyone is building SPAs, and my dev server is my actual backend, thanks
  - ribadeo 2y ago
    Remember Meteor?! Yeah, Svelte5 said "away with these pesky svelte users, lets market to React devs and make everyone realize that Vue3 has a bigger ecosystem, since you are gonna have to do a rewrite anyway " Basically the opposite of this principled stance here on this htmx missive Frontend framework churn costs money and lives
    - homebrewer 2y ago
      It doesn't have to, you can just start using a piece of technology 5-10 years after everybody else, you know. We started using react a couple of years after hooks were introduced when there were millions of ready libraries, all major design patterns were established, tons of docs were written, etc., and although there's still major churn, it's nothing like it was when react first came out. I looked at svelte when the hype circle started and decided to postpone using it for at least five years — these comments show it was a right decision. It saves money and time to be conservative with these things.
- yawaramin 2y ago
  Fun fact: Svelte doesn't allow the <title> tag to have any attributes: https://github.com/sveltejs/svelte/issues/5198 https://github.com/sveltejs/svelte/issues/5198
werdnapk 2y ago
Just a note to other readers, Turbo doesn't require Stimulus... I use Turbo mainly with AlpineJS and it works just as well since Turbo is the just tag driven side of things.
arresin 2y ago
> It’s a single 5k line file with 190 top level functions in it That's interesting. Do some people prefer this style? If yes, how come?
- quesomaster9000 2y ago
  If you look at the end-user API documentation[1] it's pretty good. But the htmx.js file itself seems to struggle from a certain type of internal naming scheme that will take a while to get up to speed with and doesn't really lend itself to being easy to context switch in & out of it, where you might simply forget that things exist and end up re-writing or inlining these fragments. This naturally stems from a very organic development process, where something starts out as a quick prototype, then the functions get too big so you split fragments out into things like `shouldProcessHxOn` and `processHXOnRoot` which absolutely make sense at the time where you're avoiding duplication, and trying to turn it into something 'more proper' with 'better abstractions' would actually cause the code to balloon in size and make it much bigger and much more like object spaghetti. On the whole though, a large amount of the file is type documentation, e.g. `/* @param {Node} start */` which is more a failing of JavaScript itself than anything else, and honestly a 5k self-contained file with good public documentation of what's user-facing vs internal is pretty easy to grok if it's something you work with frequently. If you were to rewrite this in a saner language like Python with a more functional style, you could probably condense it down to 1000 lines or less. [1]: https://htmx.org/api/ https://htmx.org/api/
- internet_points 2y ago
  I do. I've always felt that I'm doing something wrong when I do this, but I much prefer not having to switch files all the time and navigate folders etc. looking for things. With everything in one file, I can just use regular within-file search (and M-x occur in emacs which is a bit like clickable (and editable) grep). If I need "focus", I just use narrowing in Emacs (shows only the highlighted part of the buffer, with handy shortcuts for narrowing to current function/class). If I need to see something side-by-side, just split or clone the buffer. I loathe working on those java etc. projects where you have a zillion classes each in their own file, many with maybe a handful of members each; whenever I switch files I feel like I'm losing context.

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
- inopinatus 2y ago
  I’m curious about your Swift backend stack, if you’re willing to describe it. I’ve become quite fond of the language after writing a few small desktop apps & command-line tools with Swift.
  - danpalmer 2y ago
    I love the language. I'm using Vapor+Fluent+Leaf, but I've had a few issues with them, I think they're fine, but if I was making decisions again I'd probably choose something else. I think the problem is that Vapor is trying to be a Django/Rails style, batteries-included framework as opposed to a Flask-style library (if those terms help you at all), but they've not quite nailed it to the Django/Rails level yet. For my project I'd have been better off with less framework, as most of my code is not strictly web code. I've ended up changing the Vapor application architecture a bit and pulling lots out into non-web-specific Swift Modules. If I were choosing again I'd give consideration to Hummingbird. Library availability has mostly not been a problem for me, there are some really high quality libraries, particularly open source ones from Apple. Quality is high compared to other ecosystems. I'm targeting Linux/Docker for deployment and while I don't have the project running in production yet, I've been running CI builds and it so far seems fine. It's fairly clear when things are Linux compatible and when they're not. Most things you'd expect to be are compatible. Some third-party libraries are accidentally not Linux compatible, but it hasn't been much of a problem for me. The new Swift Testing library is really nice, and I'm using that for all my server tests with no real problems. Vapor could have more testing support (Django's is excellent and my bar for comparison), but it all works. Overall it's just a lovely language to work in, and I'm enjoying server side development with it.
    - inopinatus 2y ago
      Thank you, gives me some ideas on what to try, it's appreciated!
Sander_Marechal 2y ago
Symfony (PHP) and it's UX packages are all based on Stimulus
dalenw 2y ago
I use it at work with asp.net MVC, no issues either. I did have to use Webpacker though...

srameshc 2y ago

I have had a great experience with Astro and HTMX. When the first time I tried, I didn't think much about HTMX and thought it was an Astro thing, about a year or over. But this time, I had a great experience and I understand the power of htmx and native web only JS, no framework when building simple sites is much refreshing.

alexpetros 2y ago

Hey Dan, htmx maintainer here. I would love to know in what other two ways relative links are broken, and which event stopped working, so we can get those fixed. With respect to the fix you PRed (thank you, by the way), we did get that merged very quickly, and would love to do the same for whatever is broken here, even (especially) if you are no longer interested in doing the fix yourself. [0] As for the DX of making changes to htmx: absolutely true! The single file is a DX we've chosen, and it has both costs and benefits, which we've written about in "Why htmx doesn't have a build step". [1] [0] https://github.com/bigskysoftware/htmx/pull/1960 https://github.com/bigskysoftware/htmx/pull/1960 [1] https://htmx.org/essays/no-build-step/ https://htmx.org/essays/no-build-step/

everybodyknows 2y ago
Maybe I'm missing something here, but JS modules do not require a build step. * Note to non-JS hackers: JS module symbol scope is per-source file.
- recursivedoubts 2y ago
  JS modules can't be imported with a plain script tag.
  - throw5959 2y ago
    Script type=module doesn't work?
    - rob 2y ago
      Not if you want to support the 0.2% market share that IE 11 has.
      - danpalmer 2y ago
        That's true, but also a trade-off that is a perfectly valid engineering choice for many or even most teams.

deleted 2y ago

[deleted]

pkkkzip 2y ago

I wanted to use Hotwire but it felt like it was made for Rails as backend? This probably needs to be fixed because if the DX is as good as you say then its disservice to be tied to Rails. Which leads to the appeal of HTMX. It promises no other dependence. It just does exactly what it advertised. I'm not sure whether your issues were due to implementation or specific known bugs in HTMX not covered. I am curious to know more about Hotwire, I'm just worried about state management and this is greatly overlooked when it comes to adding application logic beyond just hydration of specific components on page. So far I have not seen anything that competes with Sveltekit.

danpalmer 2y ago
Hotwire is designed for good integration with Rails, but Rails is not required. In a similar way, HTMX works better with various server-side libraries, but none are required. Personally I'm using Hotwire (was using HTMX) with a Swift backend with no issues.

urronglol 2y ago

Backend dev here. Give yourself a break and use sveltekit

ribadeo 2y ago
Full stack polyglot dev here, the relentless pressure to use Sveltekit that has utterly destroyed plain Svelte docs, IMO, coupled with the koolaid kult around v5 is why i finally ditched svelte. I have backend solutions and existing databases and existing backends. I would never consider a Js backend in a production app to begin with, despite the benefits an isomorphic approach offers. I dislike when physical actual boundaries in code execution contexts are obfuscated, for one... But not everyone is building SPAs, and my dev server is my actual backend, thanks
- ribadeo 2y ago
  Remember Meteor?! Yeah, Svelte5 said "away with these pesky svelte users, lets market to React devs and make everyone realize that Vue3 has a bigger ecosystem, since you are gonna have to do a rewrite anyway " Basically the opposite of this principled stance here on this htmx missive Frontend framework churn costs money and lives
  - homebrewer 2y ago
    It doesn't have to, you can just start using a piece of technology 5-10 years after everybody else, you know. We started using react a couple of years after hooks were introduced when there were millions of ready libraries, all major design patterns were established, tons of docs were written, etc., and although there's still major churn, it's nothing like it was when react first came out. I looked at svelte when the hype circle started and decided to postpone using it for at least five years — these comments show it was a right decision. It saves money and time to be conservative with these things.
yawaramin 2y ago
Fun fact: Svelte doesn't allow the <title> tag to have any attributes: https://github.com/sveltejs/svelte/issues/5198 https://github.com/sveltejs/svelte/issues/5198

werdnapk 2y ago

Just a note to other readers, Turbo doesn't require Stimulus... I use Turbo mainly with AlpineJS and it works just as well since Turbo is the just tag driven side of things.

arresin 2y ago

> It’s a single 5k line file with 190 top level functions in it That's interesting. Do some people prefer this style? If yes, how come?

quesomaster9000 2y ago
If you look at the end-user API documentation[1] it's pretty good. But the htmx.js file itself seems to struggle from a certain type of internal naming scheme that will take a while to get up to speed with and doesn't really lend itself to being easy to context switch in & out of it, where you might simply forget that things exist and end up re-writing or inlining these fragments. This naturally stems from a very organic development process, where something starts out as a quick prototype, then the functions get too big so you split fragments out into things like `shouldProcessHxOn` and `processHXOnRoot` which absolutely make sense at the time where you're avoiding duplication, and trying to turn it into something 'more proper' with 'better abstractions' would actually cause the code to balloon in size and make it much bigger and much more like object spaghetti. On the whole though, a large amount of the file is type documentation, e.g. `/* @param {Node} start */` which is more a failing of JavaScript itself than anything else, and honestly a 5k self-contained file with good public documentation of what's user-facing vs internal is pretty easy to grok if it's something you work with frequently. If you were to rewrite this in a saner language like Python with a more functional style, you could probably condense it down to 1000 lines or less. [1]: https://htmx.org/api/ https://htmx.org/api/
internet_points 2y ago
I do. I've always felt that I'm doing something wrong when I do this, but I much prefer not having to switch files all the time and navigate folders etc. looking for things. With everything in one file, I can just use regular within-file search (and M-x occur in emacs which is a bit like clickable (and editable) grep). If I need "focus", I just use narrowing in Emacs (shows only the highlighted part of the buffer, with handy shortcuts for narrowing to current function/class). If I need to see something side-by-side, just split or clone the buffer. I loathe working on those java etc. projects where you have a zillion classes each in their own file, many with maybe a handful of members each; whenever I switch files I feel like I'm losing context.