Ask HN: Anybody Using Htmx on the Job?
63 comments
yeah, i'm using it on a consulting job at
https://www.commspace.co.za/
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
https://www.commspace.co.za/
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
Thanks for your work!
First time hearing about hyperscript, was curious why a new DSL instead of just using JS:
https://hyperscript.org/docs/#history
First time hearing about hyperscript, was curious why a new DSL instead of just using JS:
https://hyperscript.org/docs/#history
It looks like Locality of Behavior was a driving principle, one which I am completely on board with.
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.
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.
Locality drives me insane, but I'm old-school and keep my HTML, CSS and JS separate. That said, I really like HTMX because you aren't required to do that React bullshit where CSS and HTML are all mixed up with JS. HTMX looks like HTML, so it's less of a cognitive leap (my opinion, anyway, and I haven't dug deep into it, yet).
Thanks for saying hi and your work - I have been playing with things like alpine.js and hotwire, and HTMX is a nice way to ship regularly.
Things like templated logic was considered outdated for a long time, while nothing is perfect, this tool is a nice way to start.
Things like templated logic was considered outdated for a long time, while nothing is perfect, this tool is a nice way to start.
first of all thanks for the awesome book and library!
what is the team size at Commspace?
what is the team size at Commspace?
3-5 devs on the project
the hell is that last line, lol. thank you for your work sir!
Very modest to assert that others call your project a silver bullet and that you wouldn’t go quite that far.
ikr, silver-alloy bullet at most c'mon people be reasonable
HTMX powers the UI for my AI transcription product TurboScribe (https://turboscribe.ai). Dynamic UIs that change without a page refresh, lazy loading, multi-step forms/flows, etc. It's working GREAT.
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).
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’re using HTMX along with Alpine JS and a Python/Jinja2 backend in a commercial startup. So far, it’s working great. The UI is simple to code and we don’t have such a mental leap when moving from backend Python code to working on the UI. This is advantageous for us as we can prioritize hiring backend Python engineers, and don’t need to build out a team of frontend engineers just yet.
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)
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)
Part of the challenge of a reference implementation is that HTMX works with every backend. The Hypermedia Systems book [1] has a reference implementation in Flask (Python), but that’s less helpful if you’re in a very different ecosystem.
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.
[1] https://hypermedia.systems/
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.
[1] https://hypermedia.systems/
> I think what’s needed is a sort of, repository of patterns.
Agreed. I was thinking about a reference application to demonstrate those patterns.
Agreed. I was thinking about a reference application to demonstrate those patterns.
Thanks for the link! I’ll check it out.
I brought it into an aging ~12-year-old system to add a bit of SPA-like functionality to some pages. It works wonderfully with those classic MVC-style web sites.
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!
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!
I did a presentation last year with a couple slides on experience reports:
https://fermigier.com/slides/2023-htmx-OSXP/#30
I will probably have more stories to tell later this year.
https://fermigier.com/slides/2023-htmx-OSXP/#30
I will probably have more stories to tell later this year.
thank you for sharing! the data is really interesting.
Htmx is modern, but also rooted in some timeless stuff.
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.
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.
Forgive me if my comment comes across as snarky, but why would HTMX not be suitable for projects at work? And what characteristic makes a tool only suitable for side-projects?
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!
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!
I am not in the position to judge myself, at least not yet, and I got bit last time when I tried Elm :D
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.
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.
(My opinion only, please treat it as just one person's thought process, not some eternal truth)
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.
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.
I think you’re somewhere off base here. Yes, you understand React very well, but many don’t. And HTMX gives you a lot of leverage without needing to (1) deal with learning React, (2) deal with all the extra baggage that comes with it (oodles of extra complexity and code)
I don't disagree with any of that...? My argument was that as a frontender, the added complexity is worth it because the ecosystem is so huge that it enables a lot of code re-use. I don't see the same "easy to build on top"-ness in other frameworks, whether it's HTMX or even other JS frameworks.
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 :(
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 :(
For corporate projects, the most important attribute isn’t whether the framework can do the job, but whether it has résumé forward compatibility: “Can we hire people later to develop and maintain this project?”
It’s also the case that you take basically no risk picking a shitty tool as long as it’s popular (in enterprise).
10 problems with that, you catch no heat. 1 problem with the just-outside-the-norm thing you pushed for? That’s your fault.
10 problems with that, you catch no heat. 1 problem with the just-outside-the-norm thing you pushed for? That’s your fault.
If you hired an average developer they can pick up most frameworks in a short amount of time.
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.
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.
My take is that we are in this situation because most hiring is done by managers and/or recruiters who have very little knowledge, or are completely clueless about programming. This leads to checkmark based recruiting where the client wants tech x, candidate has tech x on his CV,
Honestly because at bigger corporations customers usually pay to solve specific problems. They literally don’t care if you use x y z technology. Can you solve their problem? The technology, even for a tech company, is usually never the primary concern for the end user unless your end user is technical.
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.
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.
Yup. And it's good. My aspiration, though, it to migrate to https://leanrada.com/htmz/
Almost every library that exists will have commercial usage.
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
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
I'm using unpoly (which is similar to htmx) on my job at a public sector org. I mainly use it to enhance the pure request/response views of our Django apps since we won't enter the js framework bandwagon. It works very good till now
I'm using it for an exams booking company https://www.mtsglobal.uk.com/
It powers the calendars used both on the public side and the admin side, as well as a few forms and admin context switching. (solo dev)
As a primarily backend dev, it was easy to get around, and allowed me to get things up and running much quicker.
Didn't solve everything, some selectboxes that updated each other wasn't a great candidate, so JSON was used here (Choices.js) as reinitializig the select box was a bad idea.
I had never heard of HTMX.
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.
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 and I like it. It's approachable enough to make me look good, but simple enough to learn without having to dive very deep into javascript.
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.
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.
Using this architecture with htmx is the future
https://cirw.in/blog/time-to-move-on
https://cirw.in/blog/time-to-move-on
I'm currently trying to sus out if i can use it for more data intensive / dashboard-ing tools. Not unlike Plotly Dash.
Lots of discussion here: https://news.ycombinator.com/item?id=33987578
I don't really understand how people get so burnt out from frontend frameworks. I started out using jquery and bootstrap, but I don't miss that at all, and love the convenience of the modern frameworks.
As someone who professionally does mostly frontend since jquery I agree but when working on full stack personal projects in Django and other backend frameworks that aren’t Node, I start to empathize. Doubling the yack shaving quotient on a project is not fun.
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.
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.
I’d be curious to know what has better tooling than the web? From what other platform are people coming from that they find web tooling to be a downgrade?
Coming from a C++ background I will happily write webpack configs for the rest of my life…
Coming from a C++ background I will happily write webpack configs for the rest of my life…
Every modern backend web programming framework? Frontend requires a lot of flexibility and compromise because the runtime environment is so disparate.
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.
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.
VB6 had amazing tooling. Unified dev environment, easy UI designer, step-debugger, press one button and your App works on all (Windows) devices from Win95 and newer!
Oh man, VB6 was the pinnacle of writing desktop software. The language itself wasn't great, but the overall experience was stellar.
Web tooling on the browser side is amazing, but until relatively recently the build tooling was so bad I'd easily put it on par with C/C++. Not as bad mind you, since package management is better, but otherwise I'd rank both as from the same layer of hell and in the same ballpark in terms of suffering. The only thing that rose to the level of debugging webpack configs for me recently is debugging the build for a QT app that linked against non-system KDE libs.
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.
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.
I'm professionally mostly in Django and my front end skills have been left to rot for a decade - your comments about Webpack, Vite etc. ring very true. I recently looked into replacing Webpack on a project with something less painfully slow, failed to get Vite working so tried Parcel which is supposed to be idiot proof. I guess I'm more even more idiotic than that.
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.
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.
I think at a certain level of complexity, the frameworks do add a lot of value. Especially if you're primarily a web dev and understand the value of componentization, good tooling, etc., and are OK with Javascript's many idiosyncracies.
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.
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.
> traditional "business logic lives on the backend, the frontend just handles presentation" model
.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.
.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.
If Microsoft had played their cards differently 10-15 years ago and been more open and less prone to embrace-extend-extinguish back then, maybe they would've dominated the Web like they hoped to. But they lost a lot of trust back then that's hard to regain :(
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.
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.
It's probably for people like me who only need to build a web frontend 1-2 times per year.
Anyone using htmz unironically?
[EDIT: for the people down voting, I did not mistype, I meant htmz, as opposed to htmx. Htmz was done as a funny PoC.]
[EDIT: for the people down voting, I did not mistype, I meant htmz, as opposed to htmx. Htmz was done as a funny PoC.]
I doubt it has any practical advantage over just using HTML as-is. If you have a decent performing server, and lightweight pages the browser can render a in such a quick time you won't notice the load. For example try tabbing around the links in HN.
Isn't htmx a JS bundle? How does that make it "JS free"? I don't get it
It's like how bash and .bat scripts are C-free: they're written in C so you don't have to write any C.
Same with htmx: it's written in JS so that you don't have to write any JS.
Same with htmx: it's written in JS so that you don't have to write any JS.
You don't have to write any JS.
Instead you write hyperscript to accomplish anything nontrivial. Potato, potato.
Is an active search UI non-trivial?
https://htmx.org/examples/active-search/
How about infinite scroll?
https://htmx.org/examples/infinite-scroll/
Inline editing of a row in a table?
https://htmx.org/examples/edit-row/
https://htmx.org/examples/active-search/
How about infinite scroll?
https://htmx.org/examples/infinite-scroll/
Inline editing of a row in a table?
https://htmx.org/examples/edit-row/
Yes, those are incredibly trivial. Front end development jobs do those tasks every day non-stop, and I'd confidently hand any of those to a junior developer to accomplish in pretty much any front end framework/library/toolset or however you want to accomplish the most basic data driven DOM manipulation. IMO you don't have a non-trivial example on your website at all and even these that you've linked are showing that it's going to get verbose, messy and magically coupled through unchecked identifiers and labels quite quickly.
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.
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.
OK, well in that case I agree w/ you, htmx handles trivial stuff pretty well:
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:
https://htmx.org/essays/when-to-use-hypermedia/
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:
https://htmx.org/essays/when-to-use-hypermedia/
“You don't have to write any JS.”
But you can, if you want.
But you can, if you want.
[deleted]
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?