7 ms·

Is anyone using htmx in a large project? Seems like it could be great for small things, but unmaintainable at scale, and that all the praise is based on the for

by Kiro 3y ago

Is anyone using htmx in a large project? Seems like it could be great for small things, but unmaintainable at scale, and that all the praise is based on the former. Something tells me that the backlash will be enormous.

karmarepellent 3y ago
There is the occasional tech talk on YouTube where some kind of migration from React to HTMX in a large project is discussed. You will have to search though as I do not have any links at the ready. However I have not seen anything really substantial either that confirms that HTMX works in large projects just as well as in smaller ones. I plan to use HTMX in another larger, upcoming project though as I want to gain some insights on the side too. That being said I am aware that it might turn out to be a mess. But I would be content with the fact that HTMX is generally very useful for smaller projects and just put it in my respective imaginary toolbox to keep in mind for those kinds of projects.
- rob 3y ago
  Link, from 2022: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ Every time this is brought up (use in larger projects), people usually only mention this article/video and nothing else, so I'm not sure if that's a good or bad thing.
  - karmarepellent 3y ago
    Yes, that is exactly my point! I think the lack of real world examples of large HTMX projects is a little telling. But it might just be large projects usually happen in large companies where you aren't necessarily allowed to disclose project details to the community. Again, I think at this stage the best way to determine if HTMX is a viable option for large projects is to try and ideally share your insights. To be honest I am looking forward to the day when we can put all the HTMX/React whatever debates to rest and it will just be another great tool amongst other tools.
    - Woshiwuja 3y ago
      to be fair unless you are doing a complete rewrite it doenst make much sense to swap frontend. I bet we will see later this year htmx getting used because of people getting confortable with it
      - cqqxo4zV46cp 3y ago
        htmx’s growth trajectory isn’t as steep as you’re making out with that expectation. I remember seeing conference talks about it ages ago. It’s ostensibly getting more interest now sure, if not legitimate adoption, but it does feel like more of the early starters would have something to share by now. For the record, I hope that it succeeds.
        recursivedoubts 3y ago
        finished a close second behind react and ahead of svelte, vue, vue2, vue + vue2, angular, solidjs, quick: https://star-history.com/#bigskysoftware/htmx&bigskysoftware/_hyperscript&Date https://star-history.com/#bigskysoftware/htmx&bigskysoftware... idk what a steep growth trajectory is to you, but this has felt pretty steep to me: https://star-history.com/#bigskysoftware/htmx&bigskysoftware/_hyperscript&Date https://star-history.com/#bigskysoftware/htmx&bigskysoftware...
        Woshiwuja 3y ago
        also: https://star-history.com/#bigskysoftware/htmx&facebook/react&Date https://star-history.com/#bigskysoftware/htmx&facebook/react...
        recursivedoubts 3y ago
        sure, but click "align timelines" and then consider I'm a one man shop in montana, and facebook is, well, facebook: https://star-history.com/#bigskysoftware/htmx&facebook/react&Timeline https://star-history.com/#bigskysoftware/htmx&facebook/react... not saying htmx is gonna replace react any time soon, but c'mon, it finished #2 right behind react in rising stars, that's pretty good
  - boringuser2 3y ago
    >The effort took about 2 months (with a 21K LOC code base, mostly JavaScript) That isn't a very large codebase for frontend, I'd expect one person to be able to do that in less than one month if they're actually trying.
- zer00eyz 3y ago
  >> that confirms that HTMX works in large projects Define large? By size of project or volume of users. HTMX is more targeted for the latter, not the former. THere is a continuum. Static pages, SSG's on one side, and SPAs/react all the way at the opposite end. They both do VERY different things. HTMX is some where in the middle, think content heavy PAGES that need lightweight public facing interaction (email/contact, validation loops, a form or two, maybe some dynamic conversions, a carrousel) Static home page for cache performance, html for sales contact cycle, react for the app you sell ... all three can and should be coexisting!
sli 3y ago
In theory it seems like it should scale like a variation on a pretty standard full stack application that does the HTML work on the backend -- as opposed to a SPA -- but instead sends fragments instead of entire pages. I'm also be curious to see how it plays out in practice, since it's been pretty neat for my small projects and I'm intrigued by it, generally.
davedx 3y ago
I doubt it. I think it's like svelte, but a bit earlier in the hype cycle. The "State of JavaScript" survey is illuminating for these kinds of technologies. They often follow a trajectory towards "more liked", while remaining consistently and firmly in the "not used" quadrant. Everyone thinks they look amazing and refreshing, and maybe some people have even actually written some small apps in them, but (almost) nobody is using them at scale. It's not a bad thing really, but the hype can be annoying
- caseyf 3y ago
  Everyone using modern Rails/Hotwire (including 37 signals) is using basically the same architecture, does that count?
  - polycaster 3y ago
    I wouldn't categorize Hotwire as a well-established technology simply because it's included with Rails. Its prominence isn't solidified even with support from notable figures – as all tech trends have their advocates. In my perspective, it's somewhat analogous to htmx: The cool kids are using it for smaller, manageable use cases, but it's far apart, like magnitudes, from the adoption React has.
  - davedx 3y ago
    I've used Rails for small-medium sized projects and overall have a good impression of it (I'd even argue it did a lot to drive web development forwards) and I know there are still orgs out there using it regularly, but is Rails honestly still being used to build large scale apps (excepting the ones that have already been around forever like Github)? Every org I've worked at since the last Rails project I worked on around 2014 has built JavaScript heavy thick clients on top of API's. That's not really where Rails shines, and I've not seen it around at all for newer projects since roughly that time. It's anecdotal, but it's my experience that the industry has largely settled on the SPA + API's architecture, and the technologies every org I've worked at use to build those SPA's are either React, Angular, Vue, or very occasionally for niche cases their own JavaScript framework. I understand that some people on Hacker News still dislike the complexity of modern front ends, and I get it, I really do. But I haven't seen any real alternatives that have been seriously used in anger to build an actual commercial application since React, Angular (and Vue) took over.
HackerThemAll 3y ago
Majority of apps are small, yet they load tens of megabytes of javascript and it's becoming the unwanted norm. You can't browse many blogs without enabled javascript for no other reason than personal data harvesting needs.
- zdragnar 3y ago
  Those are very different issues. React, Angular, Ember and co don't help you with your data harvesting one bit.
  - spinningslate 3y ago
    Agree they're different, but it's important not to miss the first point: > Majority of apps are small I'd like to see some data on it, but intuitively that resonates. The lighthouses of UI frameworks - notably React & Angular - emerged from the needs of big apps, with 100s of people, and structures that delineate front-end and back-end teams. The organisations behind the frameworks - Google, Meta - are very influential in setting industry direction. So those frameworks become "the way to do UI". That doctrine spreads through the community, and the context of origin and use is occluded. If htmx or similar drives a re-think then that's healthy to me. My own experience is with lots of comparatively small apps. Plain old server-side rendering hits the 80/20 for most, and something like htmx might move that indicatively to ~90/10. Which is attractive because it means 1 tech stack and comparatively less requirement for hard delineation of skills in dev teams. It's not saying "throw away React/Angular/..., you never need them". There are clearly situations where they're a good fit. Where fit means both organisational and technical. But they're not a good fit in every case.
    - zdragnar 3y ago
      React actually wasn't built for SPAs; Facebook built it for widgets on a server-rendered page. That is why it has no built in SPA features, like routing, data management, data fetching or other batteries a SPA or PWA might want. Conveniently, it provided a very nice set of primitive and composable APIs so that all of those features can be added on in a way that fits naturally, such as react-router and the rest of the ecosystem. That's all driven by the community, not the "lighthouse", so to speak. AngularJS likewise didn't require using the router, and in fact can just as easily run multiple instances on a single page. I haven't used Angular in years, so I don't know the story there. Same goes for Vue, but that's hardly backed by a "lighthouse". I don't disagree that there's no use for HTMX or server rendering of html. Not everything needs to be a SPA. The problem is the argument is a whole lot less convincing when presented with a lot of incorrect facts
naasking 3y ago
> Seems like it could be great for small things, but unmaintainable at scale, and that all the praise is based on the former Why does it seem that way? There are plenty of talks on youtube of commercial projects that switched from React to htmx and found considerable benefits.
- beanjuiceII 3y ago
  where? I would love to see a big project in htmx, maybe our definition of big is different though.
  - naasking 3y ago
    For example: https://www.youtube.com/watch?v=3GObi93tjZI&pp=ygUJaHRteCB0YWxr https://www.youtube.com/watch?v=3GObi93tjZI&pp=ygUJaHRteCB0Y...
    - elvennn 3y ago
      21k LOC ...
      - beanjuiceII 3y ago
        yea 21k lines of code is like a tinymicro project :|
    - DrammBA 3y ago
      Do you have any other project besides 2022 example from the htmx website that everyone shares every time?
  - deleted 3y ago
    [deleted]
recursivedoubts 3y ago
https://htmx.org/essays/does-hypermedia-scale/ https://htmx.org/essays/does-hypermedia-scale/
jbergens 3y ago
I don't see any reason why it shouldn't scale. It also allows you to use any backend language. If you write messy code in php and think it is the language 's fault then you can use something else. Rust, Go, Java, C#, Elixir. Everything should work. Just don't write messy code.

by Kiro 3y ago

karmarepellent 3y ago

There is the occasional tech talk on YouTube where some kind of migration from React to HTMX in a large project is discussed. You will have to search though as I do not have any links at the ready. However I have not seen anything really substantial either that confirms that HTMX works in large projects just as well as in smaller ones. I plan to use HTMX in another larger, upcoming project though as I want to gain some insights on the side too. That being said I am aware that it might turn out to be a mess. But I would be content with the fact that HTMX is generally very useful for smaller projects and just put it in my respective imaginary toolbox to keep in mind for those kinds of projects.

rob 3y ago
Link, from 2022: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ Every time this is brought up (use in larger projects), people usually only mention this article/video and nothing else, so I'm not sure if that's a good or bad thing.
- karmarepellent 3y ago
  Yes, that is exactly my point! I think the lack of real world examples of large HTMX projects is a little telling. But it might just be large projects usually happen in large companies where you aren't necessarily allowed to disclose project details to the community. Again, I think at this stage the best way to determine if HTMX is a viable option for large projects is to try and ideally share your insights. To be honest I am looking forward to the day when we can put all the HTMX/React whatever debates to rest and it will just be another great tool amongst other tools.
  - Woshiwuja 3y ago
    to be fair unless you are doing a complete rewrite it doenst make much sense to swap frontend. I bet we will see later this year htmx getting used because of people getting confortable with it
    - cqqxo4zV46cp 3y ago
      htmx’s growth trajectory isn’t as steep as you’re making out with that expectation. I remember seeing conference talks about it ages ago. It’s ostensibly getting more interest now sure, if not legitimate adoption, but it does feel like more of the early starters would have something to share by now. For the record, I hope that it succeeds.
      - recursivedoubts 3y ago
        finished a close second behind react and ahead of svelte, vue, vue2, vue + vue2, angular, solidjs, quick: https://star-history.com/#bigskysoftware/htmx&bigskysoftware/_hyperscript&Date https://star-history.com/#bigskysoftware/htmx&bigskysoftware... idk what a steep growth trajectory is to you, but this has felt pretty steep to me: https://star-history.com/#bigskysoftware/htmx&bigskysoftware/_hyperscript&Date https://star-history.com/#bigskysoftware/htmx&bigskysoftware...
        Woshiwuja 3y ago
        also: https://star-history.com/#bigskysoftware/htmx&facebook/react&Date https://star-history.com/#bigskysoftware/htmx&facebook/react...
        recursivedoubts 3y ago
        sure, but click "align timelines" and then consider I'm a one man shop in montana, and facebook is, well, facebook: https://star-history.com/#bigskysoftware/htmx&facebook/react&Timeline https://star-history.com/#bigskysoftware/htmx&facebook/react... not saying htmx is gonna replace react any time soon, but c'mon, it finished #2 right behind react in rising stars, that's pretty good
- boringuser2 3y ago
  >The effort took about 2 months (with a 21K LOC code base, mostly JavaScript) That isn't a very large codebase for frontend, I'd expect one person to be able to do that in less than one month if they're actually trying.
zer00eyz 3y ago
>> that confirms that HTMX works in large projects Define large? By size of project or volume of users. HTMX is more targeted for the latter, not the former. THere is a continuum. Static pages, SSG's on one side, and SPAs/react all the way at the opposite end. They both do VERY different things. HTMX is some where in the middle, think content heavy PAGES that need lightweight public facing interaction (email/contact, validation loops, a form or two, maybe some dynamic conversions, a carrousel) Static home page for cache performance, html for sales contact cycle, react for the app you sell ... all three can and should be coexisting!

sli 3y ago

In theory it seems like it should scale like a variation on a pretty standard full stack application that does the HTML work on the backend -- as opposed to a SPA -- but instead sends fragments instead of entire pages. I'm also be curious to see how it plays out in practice, since it's been pretty neat for my small projects and I'm intrigued by it, generally.

davedx 3y ago

I doubt it. I think it's like svelte, but a bit earlier in the hype cycle. The "State of JavaScript" survey is illuminating for these kinds of technologies. They often follow a trajectory towards "more liked", while remaining consistently and firmly in the "not used" quadrant. Everyone thinks they look amazing and refreshing, and maybe some people have even actually written some small apps in them, but (almost) nobody is using them at scale. It's not a bad thing really, but the hype can be annoying

caseyf 3y ago
Everyone using modern Rails/Hotwire (including 37 signals) is using basically the same architecture, does that count?
- polycaster 3y ago
  I wouldn't categorize Hotwire as a well-established technology simply because it's included with Rails. Its prominence isn't solidified even with support from notable figures – as all tech trends have their advocates. In my perspective, it's somewhat analogous to htmx: The cool kids are using it for smaller, manageable use cases, but it's far apart, like magnitudes, from the adoption React has.
- davedx 3y ago
  I've used Rails for small-medium sized projects and overall have a good impression of it (I'd even argue it did a lot to drive web development forwards) and I know there are still orgs out there using it regularly, but is Rails honestly still being used to build large scale apps (excepting the ones that have already been around forever like Github)? Every org I've worked at since the last Rails project I worked on around 2014 has built JavaScript heavy thick clients on top of API's. That's not really where Rails shines, and I've not seen it around at all for newer projects since roughly that time. It's anecdotal, but it's my experience that the industry has largely settled on the SPA + API's architecture, and the technologies every org I've worked at use to build those SPA's are either React, Angular, Vue, or very occasionally for niche cases their own JavaScript framework. I understand that some people on Hacker News still dislike the complexity of modern front ends, and I get it, I really do. But I haven't seen any real alternatives that have been seriously used in anger to build an actual commercial application since React, Angular (and Vue) took over.

HackerThemAll 3y ago

Majority of apps are small, yet they load tens of megabytes of javascript and it's becoming the unwanted norm. You can't browse many blogs without enabled javascript for no other reason than personal data harvesting needs.

zdragnar 3y ago
Those are very different issues. React, Angular, Ember and co don't help you with your data harvesting one bit.
- spinningslate 3y ago
  Agree they're different, but it's important not to miss the first point: > Majority of apps are small I'd like to see some data on it, but intuitively that resonates. The lighthouses of UI frameworks - notably React & Angular - emerged from the needs of big apps, with 100s of people, and structures that delineate front-end and back-end teams. The organisations behind the frameworks - Google, Meta - are very influential in setting industry direction. So those frameworks become "the way to do UI". That doctrine spreads through the community, and the context of origin and use is occluded. If htmx or similar drives a re-think then that's healthy to me. My own experience is with lots of comparatively small apps. Plain old server-side rendering hits the 80/20 for most, and something like htmx might move that indicatively to ~90/10. Which is attractive because it means 1 tech stack and comparatively less requirement for hard delineation of skills in dev teams. It's not saying "throw away React/Angular/..., you never need them". There are clearly situations where they're a good fit. Where fit means both organisational and technical. But they're not a good fit in every case.
  - zdragnar 3y ago
    React actually wasn't built for SPAs; Facebook built it for widgets on a server-rendered page. That is why it has no built in SPA features, like routing, data management, data fetching or other batteries a SPA or PWA might want. Conveniently, it provided a very nice set of primitive and composable APIs so that all of those features can be added on in a way that fits naturally, such as react-router and the rest of the ecosystem. That's all driven by the community, not the "lighthouse", so to speak. AngularJS likewise didn't require using the router, and in fact can just as easily run multiple instances on a single page. I haven't used Angular in years, so I don't know the story there. Same goes for Vue, but that's hardly backed by a "lighthouse". I don't disagree that there's no use for HTMX or server rendering of html. Not everything needs to be a SPA. The problem is the argument is a whole lot less convincing when presented with a lot of incorrect facts

naasking 3y ago

> Seems like it could be great for small things, but unmaintainable at scale, and that all the praise is based on the former Why does it seem that way? There are plenty of talks on youtube of commercial projects that switched from React to htmx and found considerable benefits.

beanjuiceII 3y ago
where? I would love to see a big project in htmx, maybe our definition of big is different though.
- naasking 3y ago
  For example: https://www.youtube.com/watch?v=3GObi93tjZI&pp=ygUJaHRteCB0YWxr https://www.youtube.com/watch?v=3GObi93tjZI&pp=ygUJaHRteCB0Y...
  - elvennn 3y ago
    21k LOC ...
    - beanjuiceII 3y ago
      yea 21k lines of code is like a tinymicro project :|
  - DrammBA 3y ago
    Do you have any other project besides 2022 example from the htmx website that everyone shares every time?
- deleted 3y ago
  [deleted]

recursivedoubts 3y ago

https://htmx.org/essays/does-hypermedia-scale/ https://htmx.org/essays/does-hypermedia-scale/

jbergens 3y ago

I don't see any reason why it shouldn't scale. It also allows you to use any backend language. If you write messy code in php and think it is the language 's fault then you can use something else. Rust, Go, Java, C#, Elixir. Everything should work. Just don't write messy code.