6 ms·

Sounds like this app wasn't a good fit for htmx. I have added it to the "On The Other Hand" section on the htmx website: https://htmx.org/essays/#on-the-other

Sounds like this app wasn't a good fit for htmx. I have added it to the "On The Other Hand" section on the htmx website: https://htmx.org/essays/#on-the-other-hand https://htmx.org/essays/#on-the-other-hand Regarding the default swap behavior of "innerHTML": https://htmx.org/quirks/#the-default-swap-strategy-is-innerhtml https://htmx.org/quirks/#the-default-swap-strategy-is-innerh... Our proposal to merge htmx functionality into the HTML spec uses outerHTML: https://alexanderpetros.com/triptych/ https://alexanderpetros.com/triptych/ Also consider datastar, it was written from an SSE-first perspective by a go engineer: https://data-star.dev/ https://data-star.dev/

pabe 1y ago
If only more people were like you <3
alex-moon 1y ago
Oh wow! This is a huge honour, thank you so much! I definitely started writing a "lol HTMX is shit" post, but it just wasn't honest. HTMX is incredibly powerful - I am a fan of what you all have done with it. This attempt on my part to try and write something server-side rendered wouldn't have happened without the kick up the butt HTMX gives me (and all of us).
- recursivedoubts 1y ago
  No problem at all. There are aspects of htmx that are good and bad depending on context and experience, and I like having different perspectives on it available for people to read, so thank you for taking the time to put together an in depth essay on it.
- stronglikedan 1y ago
  I can't help but to think "lol HTMX is shit" may have beat out "htmx sucks" for first place on that list!
bccdee 1y ago
Yeah, in my (limited) experience, htmx works best to grease the wheels of an oldschool multi-page app. I tried building something with SPAish drag-and-drop interactivity using htmx, and my ultimate conclusion was that functionality like that should either be totally encapsulated as one big htmx swap unit or be written as js "islands" outside htmx.
- all2 1y ago
  For my projects that require a distinct unit of functionality, I typically reach for a JS library that I can include as a payload (no npm, no deps, just a JS file). SortableJS is a good example, so is MarkdownJS if I want the browser to handle MD rendering. This only goes so far, though. At some point, an app developer might want to integrate these distinct units of functionality, and I'm not sure how I would go about that. I haven't gotten to that point.
  - bccdee 1y ago
    I think I'd try a lightweight framework like preact or vue that I can use without a build step. Keep components as separate & stateless as possible; let them live as little islands of javascript, notifying other parts of the frontend of updates through custom DOM events and talking to the server directly with fetches.
    - Atotalnoob 1y ago
      You could consider using web components
- vlad1719 1y ago
  [dead]
imiric 1y ago
I find your honesty and pragmatism refreshing. The first principles thinking of projects like htmx and Datastar is sorely needed in web development. The field has been led astray far too long by blindly following trends that were poorly designed to begin with.
- nawgz 1y ago
  You're so right - React is overwhelmingly popular despite its horrid design of running things on the client. No one should ever do that. Make the server do all the work!
  - gloryjulio 1y ago
    Tbf, app vs server side website are distinct use cases. React is for apps. It's overkill for htmx use cases. Just like what the htmx author did, react can also have an on the other hand section
andersmurphy 1y ago
+1 for datastar. It lets you do really dumb push based streaming html stuff where HTMX isnt quite fast enough (great for multiplayer apps).[1] Super excited about triptych too! Thanks for pushing that. - [1] https://checkboxes.andersmurphy.com https://checkboxes.andersmurphy.com
- stepbeek 1y ago
  Your recent post on using datastar with SSE to power game of life [1] was excellent. Thanks for writing it! [1] https://andersmurphy.com/2025/04/07/clojure-realtime-collaborative-web-apps-without-clojurescript.html https://andersmurphy.com/2025/04/07/clojure-realtime-collabo...
  - andersmurphy 1y ago
    Thank you! I've been meaning to write one on the nitty gritty of virtual scroll, hopefully I'll find some time next month.
    - nchmy 1y ago
      That would be great to see. Likewise more details about your custom compression settings.
- HiPhish 1y ago
  I was quite excited for Datastart until I saw that they keep a good chunk of the functionality behind a proprietary license [1]. It's not even about the price (it is a bit steep though, but I guess if you use it in a commercial project it will pay for itself), it's the proprietary part. [1] https://data-star.dev/reference/datastar_pro https://data-star.dev/reference/datastar_pro
  - andersmurphy 1y ago
    A "good chunk of functionality" is a mischaracterisation. I don't use anything from pro and I use datastar at work. I do believe in making open source maintainable though so bought the license. The pro stuff is mostly a collection of foot guns you shouldn't use and are a support burden for the core team. In some niche corporate context they are useful. You can also implement your own plugins with the same functionality if you want it's just going to cost you time in instead of money. I find devs complaining about paying for things never gets old. A one off life time license? How scandalous! Sustainable open source? Disgusting. Oh a proprietary AI model that is built on others work without their concent and steals my data? Only 100$ a month? Take my money!
stanfordkid 1y ago
[flagged]
- imiric 1y ago
  https://htmx.org/essays/htmx-sucks/#no-front-end-back-end-split https://htmx.org/essays/htmx-sucks/#no-front-end-back-end-sp...
- recursivedoubts 1y ago
  idk sometimes it turns out to be a pretty good approach for some problems: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/
  - crackrook 1y ago
    Just reacting to the executive summary: where are the tradeoffs? The port decreased memory usage on the client significantly, by how much did the server's burden increase? How have their hosting costs changed now that less work is being offloaded to the clients?
    - recursivedoubts 1y ago
      idk they didn’t say, but the server side delta of JSON generation vs HTML generation is small in the overall scheme of things and HTML-style apps tend to be less chatty because they push you towards the one-request-per-view ideal
- FartinMowler 1y ago
  I've been doing IT for decades. Many times I've come across something that seems stupid yet also has a non-trivial number of supporters. When this happens (and it will many times), don't just continue to think it's stupid. Question if you are stuck on some paradigm or mindset that makes the thing seem stupid to you. That might call for a good head shake, a walk in the park, or a weekend-long bender to open your mind to new ideas. You don't have to jump on their bandwagon, but at least you'll increase your understanding and strengthen your position.
endofreach 1y ago
> Sounds like this app wasn't a good fit for htmx Might be beneficial to think the other way around, and rather think htmx was not a good fit for the app.
cookiengineer 1y ago
Regarding your proposal: I would love to see cross browser support for forms encoded as application/json instead of url encoded. Additionally making name attributes in forms a query path selector to be able to nest JSON data structures would go a very long way. Regarding web components and htmx: I kind of disagree with the server sided rendering approach there because I believe in local first web apps that use JSON or other data formats to communicate, but I'm pretty stubborn like that. Don't have much to prove it yet, but I'm working on gooey, my bindings and components library for WebASM. Hopefully I'll get there in the next months, though Go has a couple of limitations due to how the type system works. [1] https://github.com/cookiengineer/gooey https://github.com/cookiengineer/gooey
- jcgl 1y ago
  > I would love to see cross browser support for forms encoded as application/json instead of url encoded. Additionally making name attributes in forms a query path selector to be able to nest JSON data structures would go a very long way. This would be simply amazing. Would so drastically reduce the JavaScript truly needed for basic CRUD stuff. Could even eliminate it if you don’t need variable-length arrays. Just the simplicity of POSTing forms…
scuff3d 1y ago
Stupid question, why have innerHTML as the default for HTMX but outerHTML for the spec merge?
- recursivedoubts 1y ago
  innerHTML was the default of htmx for historical reasons, Alex pointed out that anything that can be achieved with innerHTML (or the other swap styles) can also be achieved with outerHTML (albeit with more violence to the DOM) so we felt that was the simplest option for a more general proposal.
throwaway7783 1y ago
Do you think apps like this are not a good fit for HTMX? Drag drop interactivity?
- recursivedoubts 1y ago
  Well, I don't know. Reorder-style drag and drop works OK: https://htmx.org/examples/sortable/ https://htmx.org/examples/sortable/ But if you really want a component-based system then htmx can be a battle. I outline when I think htmx is a good fit here: https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/

pabe 1y ago

If only more people were like you <3

alex-moon 1y ago

Oh wow! This is a huge honour, thank you so much! I definitely started writing a "lol HTMX is shit" post, but it just wasn't honest. HTMX is incredibly powerful - I am a fan of what you all have done with it. This attempt on my part to try and write something server-side rendered wouldn't have happened without the kick up the butt HTMX gives me (and all of us).

recursivedoubts 1y ago
No problem at all. There are aspects of htmx that are good and bad depending on context and experience, and I like having different perspectives on it available for people to read, so thank you for taking the time to put together an in depth essay on it.
stronglikedan 1y ago
I can't help but to think "lol HTMX is shit" may have beat out "htmx sucks" for first place on that list!

bccdee 1y ago

Yeah, in my (limited) experience, htmx works best to grease the wheels of an oldschool multi-page app. I tried building something with SPAish drag-and-drop interactivity using htmx, and my ultimate conclusion was that functionality like that should either be totally encapsulated as one big htmx swap unit or be written as js "islands" outside htmx.

all2 1y ago
For my projects that require a distinct unit of functionality, I typically reach for a JS library that I can include as a payload (no npm, no deps, just a JS file). SortableJS is a good example, so is MarkdownJS if I want the browser to handle MD rendering. This only goes so far, though. At some point, an app developer might want to integrate these distinct units of functionality, and I'm not sure how I would go about that. I haven't gotten to that point.
- bccdee 1y ago
  I think I'd try a lightweight framework like preact or vue that I can use without a build step. Keep components as separate & stateless as possible; let them live as little islands of javascript, notifying other parts of the frontend of updates through custom DOM events and talking to the server directly with fetches.
  - Atotalnoob 1y ago
    You could consider using web components
vlad1719 1y ago
[dead]

imiric 1y ago

I find your honesty and pragmatism refreshing. The first principles thinking of projects like htmx and Datastar is sorely needed in web development. The field has been led astray far too long by blindly following trends that were poorly designed to begin with.

nawgz 1y ago
You're so right - React is overwhelmingly popular despite its horrid design of running things on the client. No one should ever do that. Make the server do all the work!
- gloryjulio 1y ago
  Tbf, app vs server side website are distinct use cases. React is for apps. It's overkill for htmx use cases. Just like what the htmx author did, react can also have an on the other hand section

andersmurphy 1y ago

+1 for datastar. It lets you do really dumb push based streaming html stuff where HTMX isnt quite fast enough (great for multiplayer apps).[1] Super excited about triptych too! Thanks for pushing that. - [1] https://checkboxes.andersmurphy.com https://checkboxes.andersmurphy.com

stepbeek 1y ago
Your recent post on using datastar with SSE to power game of life [1] was excellent. Thanks for writing it! [1] https://andersmurphy.com/2025/04/07/clojure-realtime-collaborative-web-apps-without-clojurescript.html https://andersmurphy.com/2025/04/07/clojure-realtime-collabo...
- andersmurphy 1y ago
  Thank you! I've been meaning to write one on the nitty gritty of virtual scroll, hopefully I'll find some time next month.
  - nchmy 1y ago
    That would be great to see. Likewise more details about your custom compression settings.
HiPhish 1y ago
I was quite excited for Datastart until I saw that they keep a good chunk of the functionality behind a proprietary license [1]. It's not even about the price (it is a bit steep though, but I guess if you use it in a commercial project it will pay for itself), it's the proprietary part. [1] https://data-star.dev/reference/datastar_pro https://data-star.dev/reference/datastar_pro
- andersmurphy 1y ago
  A "good chunk of functionality" is a mischaracterisation. I don't use anything from pro and I use datastar at work. I do believe in making open source maintainable though so bought the license. The pro stuff is mostly a collection of foot guns you shouldn't use and are a support burden for the core team. In some niche corporate context they are useful. You can also implement your own plugins with the same functionality if you want it's just going to cost you time in instead of money. I find devs complaining about paying for things never gets old. A one off life time license? How scandalous! Sustainable open source? Disgusting. Oh a proprietary AI model that is built on others work without their concent and steals my data? Only 100$ a month? Take my money!

stanfordkid 1y ago

[flagged]

imiric 1y ago
https://htmx.org/essays/htmx-sucks/#no-front-end-back-end-split https://htmx.org/essays/htmx-sucks/#no-front-end-back-end-sp...
recursivedoubts 1y ago
idk sometimes it turns out to be a pretty good approach for some problems: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/
- crackrook 1y ago
  Just reacting to the executive summary: where are the tradeoffs? The port decreased memory usage on the client significantly, by how much did the server's burden increase? How have their hosting costs changed now that less work is being offloaded to the clients?
  - recursivedoubts 1y ago
    idk they didn’t say, but the server side delta of JSON generation vs HTML generation is small in the overall scheme of things and HTML-style apps tend to be less chatty because they push you towards the one-request-per-view ideal
FartinMowler 1y ago
I've been doing IT for decades. Many times I've come across something that seems stupid yet also has a non-trivial number of supporters. When this happens (and it will many times), don't just continue to think it's stupid. Question if you are stuck on some paradigm or mindset that makes the thing seem stupid to you. That might call for a good head shake, a walk in the park, or a weekend-long bender to open your mind to new ideas. You don't have to jump on their bandwagon, but at least you'll increase your understanding and strengthen your position.

endofreach 1y ago

> Sounds like this app wasn't a good fit for htmx Might be beneficial to think the other way around, and rather think htmx was not a good fit for the app.

cookiengineer 1y ago

Regarding your proposal: I would love to see cross browser support for forms encoded as application/json instead of url encoded. Additionally making name attributes in forms a query path selector to be able to nest JSON data structures would go a very long way. Regarding web components and htmx: I kind of disagree with the server sided rendering approach there because I believe in local first web apps that use JSON or other data formats to communicate, but I'm pretty stubborn like that. Don't have much to prove it yet, but I'm working on gooey, my bindings and components library for WebASM. Hopefully I'll get there in the next months, though Go has a couple of limitations due to how the type system works. [1] https://github.com/cookiengineer/gooey https://github.com/cookiengineer/gooey

jcgl 1y ago
> I would love to see cross browser support for forms encoded as application/json instead of url encoded. Additionally making name attributes in forms a query path selector to be able to nest JSON data structures would go a very long way. This would be simply amazing. Would so drastically reduce the JavaScript truly needed for basic CRUD stuff. Could even eliminate it if you don’t need variable-length arrays. Just the simplicity of POSTing forms…

scuff3d 1y ago

Stupid question, why have innerHTML as the default for HTMX but outerHTML for the spec merge?

recursivedoubts 1y ago
innerHTML was the default of htmx for historical reasons, Alex pointed out that anything that can be achieved with innerHTML (or the other swap styles) can also be achieved with outerHTML (albeit with more violence to the DOM) so we felt that was the simplest option for a more general proposal.

throwaway7783 1y ago

Do you think apps like this are not a good fit for HTMX? Drag drop interactivity?

recursivedoubts 1y ago
Well, I don't know. Reorder-style drag and drop works OK: https://htmx.org/examples/sortable/ https://htmx.org/examples/sortable/ But if you really want a component-based system then htmx can be a battle. I outline when I think htmx is a good fit here: https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/