I am wondering though, if there are any companies using it already, if you think it's going to happen, or if it is only a side-project kind of thing?
they also use hyperscript
working out pretty well i guess, it gets a little crazy sometimes, htmx definitely isn't a silver bullet like some people say, but it works
also, I'm the creator of htmx and hyperscript
First time hearing about hyperscript, was curious why a new DSL instead of just using JS:
https://htmx.org/essays/locality-of-behaviour/
I tend to agree with the author that "Don't Repeat Yourself" and "Separation of Concerns" have their place but make understanding more difficult when taken to extremes. Sometimes clarity is worth a little repetition.
what is the team size at Commspace?
Things like templated logic was considered outdated for a long time, while nothing is perfect, this tool is a nice way to start.
My general take on HTMX is:
1) You need to have your act together on your server. Because HTMX pushes more onto your backend, you need to know what you're doing back there (with whatever tech stack you happen to be using).
I have a friend who teaches at a coding boot camp and they do not teach students about server-rendered HTML at all. Folks coming from this world are going to have a tougher time ramping up on something like HTMX.
2) HTMX is great for the 90%+ of common UI paradigms shared by most apps (form submissions, validation, error messages, partial page reloads, lazy loading, CRUD UIs, etc).
If you have a key, critical experience that demands highly dynamic or novel interactivity, you're going to find yourself reaching to either (a) extend HTMX, or (b) create an island powered by raw JS, React, etc.
--
I love HTMX. It's a fantastic tool for delivering quality product (often with much lower engineering cost).
We don’t have to write very much JavaScript at all to achieve a fairly modern UI experience. I wish the error handling was better in HTMX. We had to write a fair amount of JavaScript just to handle errors and put user friendly error messages on the screen. Maybe this has improved?
I think there’s a great opportunity to attract more developers to this stack:
1. An open source reference app built using HTMX that shows the advantages of using HTMX particularly where it shines, along with best practices for building commercial quality solutions
2. VSCode/other editor plug-ins to improve the developer experience working with this stack (Alpine, HTMX, and Jinja)
I think what’s needed is a sort of, repository of patterns. The main criticism of HTMX is it turns into spaghetti if not well structured. But that is also true of React and needing backend API endpoints well organized, and avoiding React hook-hell. And React has established those robust patterns of usage.
Agreed. I was thinking about a reference application to demonstrate those patterns.
I can highly recommend it for giving older, jQuery-era sites a new lease of life. I dropped in the CDN built into the view files, tweaked some of the controllers to return content outside of their usual template layouts based on a hx-request header, and I was away.
Didn't have to mess with bundlers and compilers. It was refreshing!
https://fermigier.com/slides/2023-htmx-OSXP/#30
I will probably have more stories to tell later this year.
Don't be afraid if it seems good to be true. If it (or anything) helps you ship cleaner, faster, and iterate, it's good to use.
So many things render to html/js/css in different ways and it's good to use what you are effective with.
I absolutely use HTMX at work, but then I do not work at a large corporation with tons of users. Likewise someone working at a large company would never touch HTMX for new projects in anticipation of some kind of roadblock that they may stumble across.
Edit: I do not think there is anything you should wait for to happen as if the community one day settles on HTMX and its concepts being "the right way to go". Just use it for your projects if you feel like it suits the problem and enjoy!
By the book (hypermedia systems I mean) it seems very promising even for mid-sized or large organisations, I can see potentials to develop micro-frontends using the patterns, but I am not a frontend focused engineer at work, and I don't really trust my intuition (see the Elm reference above).
I am not waiting for anything, I am using htmx for my projects and I am indeed enjoying it, but the question in my OP still stands IMO.
As a frontend dev, for me it's primarily just an ecosystem thing. There's nothing wrong with HTMX or any other solution, like Ruby on Rails or Hotwire or even other JS frameworks like Angular or Gatsby, but they are not really what I see in the majority of the web dev ecosystem.
By ecosystem, I mean this:
- Developers are easy to find & hire for, and can work on existing code without much training because there are (relatively) standardized practices
- For any common problem, I can easily reuse (or at least learn from the source for) a package on NPM
- For any uncommon problem, I can find multiple robust discussion about it on various forums, Stack, etc. And ChatGPT probably has a workable overview.
- I can reasonably expect medium-term robust vendor support, not just from the framework developers but various hosts, third-party commercial offerings (routers, state management, UI libs, CMSes, etc.), i.e., it's going to stay a viable ecosystem for 3-5 years at least
- I don't have to reinvent the wheel for every new project / client, and can spin up a working prototype in a few minutes using boilerplates and 1-click deploys
I've been building websites since I was a kid some 30 years ago, first using Perl and cgi-bin and then PHP, and evolved my stack with it over time.
I've never been as productive as I am in the modern React ecosystem, especially with Next or Vite + MUI (https://mui.com/). Primarily this is because it allows me to build on top of other people's work and spend time only on the business logic of my app, at a very high level of abstraction (business components) and with a very high likelihood of being able find drop-in solutions for most common needs. I'm not reinventing the wheel constantly, or dealing with low-level constructs like manually updating the DOM. Or worse, dealing with server issues or updating OS packages.
What used to take days/weeks of setup now takes one click and two minutes, and I can have a useable prototype up in 2-3 hours. Because 95%+ of my codebase isn't mine anymore; I can just reuse what someone else built, and then reframe it for my own needs. And when someone else needs to continue the work, they can just pick up where I left off with minimal onboarding, because they probably already have React knowledge.
I think React, for all its faults, has just reached a point of saturation where it's like the old "nobody ever got fired for buying IBM", i.e., it's a safe, proven bet for most use cases. It may or may not be the BEST bet for any project, but it's probably good enough that it would at least warrant consideration, especially if the other stacks have less community/ecosystem support.
At the end of the day, my job isn't to deliver the leanest frontend as close to the HTML as possible, it's to meet business needs. Robust componentization and a rich ecosystem are better for doing that, quickly and easily, than simpler or less popular solutions, again because it allows me to build off so much other people's work. There's a steep learning curve upfront, but once you learn it, day-to-day work is relatively straightforward and productive.
For simpler projects, I absolutely don't think it's necessary to learn a JS framework or (or even just React). But for apps of medium complexity and up, it's been a super productive system to work in, full-time, with other React devs and open-source contributions. The reusable component model is SUPER important in my day-to-day work and outweighs a lot of other factors (like technical complexity). The complexity you have to learn once (or every year or two), whereas the code re-use/NPM drop-ins is like multiple times a day.
Edit: Really it comes down to this: https://survey.stackoverflow.co/2023/#section-most-popular-t... (under "Professional developers"). It's just a lot easier to use what everyone else is using. HTMX sadly doesn't even make the list, as far as I can tell :(
10 problems with that, you catch no heat. 1 problem with the just-outside-the-norm thing you pushed for? That’s your fault.
What I never understood was new developers have no business context and everyone accepts that will take time. When it comes to languages if someone hasn't worked with specific framework/version all is lost and no one will hire you without x amount of specific experience. Picking up a new framework is easier than picking up your specific industry terms and practices but employers get stuck with these false ideas.
Why take a risk in this case when you’re running a business that’s already printing dollar bills?
I would personally never use any niche technology to build UIs. I stick to what is easiest and cheapest to develop, deploy, and maintain. It’s 2024 and most people who pay have high speed internet. It’s not 2008 anymore. 20kb vs 8kb vs spending millions of dollars on refactor or learning. I mean it’s a business not a hackathon right?
I am all for people trying out new things. But unless those things add significant ROI to the business they’re not worth using. If it happens to align then yeah the business should do it, or pull a Meta with react. Just my opinion.
Usage will likely be skewed to small companies and agencies though. Just like every framework that optimises for less complexity, the disadvantages start to outweigh the advantages when you have so many engineers you can afford to have backend/frontend specialisation and/or you need to support non-browser clients so you need to build services that transport JSON anyway.
Side note/rant: As professionals, we should understand the limitations of different approaches, communicate them to stakeholders and select something that is appropriate for the task.
The problem is, we seem to end up with evangelism where everything thinks their square peg fits in every hole at massive cost to the people they work with/for. Train yourself to recognise this and avoid becoming “that person” that isn’t able to pick the right tool for the task.
See also:
- RDBMS vs NoSQL for everything
- ORMs vs Raw SQL
- Everything is better in rust people
- anti-GC people
- functional programming zealots
- Citizens of the Kingdom of Nouns thumping GoF design patterns at every turn
- LLMs as a solution to everything
- the many flavours of anti JavaScript camp (including, vanilla JS only, HTML over wire, PyScript/ClojureScript)
- writing a SPA for your blog folks
- micro-services vs monolith
- the anti-cloud just give me a VM/cpanel traditionalists
- cloud maximalists provisioning masses of AWS services for a low traffic CRUD site
It's nice to see some appreciation for HTML. And it's especially nice that the front page of the htmx website actually tells you what it is rather than try to convince you how much VC clout it has.
I use it for a monitor that tells students how many people are working out in our campus facilities (based on dwell time), and for a monitor and admin system for scheduling drop in advising. People are impressed by it, it certainly feels like the future, something slick like you'd get in an airport or store, but it's just me and some PHP crud and a bit of htmx icing on top.
The problem causing burnout isn’t the framework but all the tooling around it. Webpack alone has probably caused as much PTSD as a minor war and if you’re not in frontend you don’t know to just install Vite, copy a tailwind config, and get started. With HTMX you just add a script tag and go. The developer experience for adding some simple dynamic features is leagues better, even if the DSL is esoteric.
Coming from a C++ background I will happily write webpack configs for the rest of my life…
In the backend you choose and control one runtime so the framework can integrate tightly with the authoring workflow.
Concretely, Rails, Django, Spring, Elm, all have great tooling and are much easier to work with than frontend stacks.
Now if you know what you're doing it's much better now that everyone has converged on ES6 modules and with the latest generation of build tools like Vite, all you need to do is npm install some packages to provide zero-config support for frameworks like React, Svelte, etc. But it used to be so much worse.
As for HTMX, I've been playing with that on an evening / weekend project and absolutely love it. Getting it working with Django was maybe very slightly harder than with other backend frameworks as Django doesn't have great support for template fragments. Once I'd sorted that though, I had a decent interactive UI on top of my app very quickly, all while being completely new to HTMX. I can imagine being incredibly productive with it with a bit more learning / use.
But if this isn't something you do full time and just occasionally tinker with for a personal blog or something, the ecosystem's signal-to-noise ratio can be very, very low, and it's hard to know the right way to get started, and what's important to worry about or not, or how to resolve obscure errors from some tiny part of the buildchain.
3-4 years ago, it was especially bad, when you had to bundle together a bunch of different things yourself (webpack, eslint, typescript compilers, react, state managers, routers, etc.) all from scratch, and any one of those could cause serious incompatibilities with the other parts. These days it's a lot better with things like Next (for bigger projects) or Vite/Astro for simple sites, since they abstract away all the tooling setup for you (and 1-click deploy on Vercel helps a lot too). But if you're not deep in the frontend world, the differences between all these random projects can be pretty non-obvious. Plus, JS changes so quickly it's impossible to keep up with the bleeding edge... maybe, hopefully, it'll slow down now since all the VCs are shifting to AI instead?
And that's just the frontend side. If you need a backend too (as opposed to simple API routes or a headless CMS or something), then you have to deal with all the differences between Node.js vs browser JS, polyfills, different Node versions, serverside vs clientside rendering... it's a lot of mental overhead vs the traditional "business logic lives on the backend, the frontend just handles presentation" model. HTMX seems like a good tool for a heavy backend and a light frontend, which probably isn't the kind of project that most full-time frontend devs would work on anyway.
At the end of the day, I think it's cool the Web has still managed to maintain its (relative) openness and tool-independence. You can still make a functional site in anything from an expensive IDE + huge framework to Notepad, and everything in between, and there's never really just "one right answer"... totally depends on your project's needs, your team's skills & resources, and various tradeoffs. I'm not the target audience for HTMX either (the React ecosystem is just far too useful, with NPM and MUI especially), but it's cool that it exists.
.NET Framework has it's flaws, but the ease of development of ASP.NET WebForms or MVC sites is awesome.
The JS ecosystem, not only is it confusing, all too often documentation, forum posts, etc. out of date making the barrier to entry that much higher.
I heard they've changed a lot since then, but it's still not super popular (at least in the US). As a web dev, it's a stack I'd be reluctant to invest in because I've never seen a company I'd want to work for who uses it... when even Microsoft themselves jumped ship to JS for so much web work (like VScode or Teams being built in webviews), it's hard to take their other web stack seriously. That said, I'd absolutely consider .NET for a desktop app!
--------------------------
> The JS ecosystem, not only is it confusing, all too often documentation, forum posts, etc. out of date making the barrier to entry that much higher.
Lol, absolutely :( Even within the same codebase, like the one I was working on yesterday, there can be like 3-4 major generations of JS paradigms across different files. It's only a few years old, but feels like it was decades and worlds apart...
I really hate that instability in the JS ecosystem. I guess that's the opposite problem of Microsoft... instead of stable but closed single-vendor support, we have unstable open innovation across 50 different frameworks and ten thousand packages with a million versions. It can be a nightmare to work in for sure.
[EDIT: for the people down voting, I did not mistype, I meant htmz, as opposed to htmx. Htmz was done as a funny PoC.]
https://htmx.org/examples/active-search/
How about infinite scroll?
https://htmx.org/examples/infinite-scroll/
Inline editing of a row in a table?
I've done a couple of small htmx PoCs and it's.... fine? I don't hate what you're doing I just think it's super overhyped and when anything grows in complexity over a year or more it's going to be about the same as any other jQuery spaghetti application we used to build as an industry. Long term maintenance of a htmx app feels like it would be about the same as a KnockoutJS app that leaned heavily into "apps written in attributes" (data-* vs. hx-*, but it's just special syntax you have to memorize either way). KnockoutJS was fine then too, we could build infinite scrollers and inline row edits with it almost 15 years ago.
https://htmx.org/essays/a-real-world-react-to-htmx-port/
Comparisons w/KnockoutJS (and old angular) are pretty superficial: Knockout is a reactive framework whereas htmx is hypermedia-oriented, they scale differently. htmx tends to scale well when UIs are well factored on the server side:
But you can, if you want.
Same with htmx: it's written in JS so that you don't have to write any JS.