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.
Something tells me that the backlash will be enormous.
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
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.
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.
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.
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.
For the record, I hope that it succeeds.
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...
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
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.
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!
> 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.
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
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.