Ask HN: Anybody Using Htmx on the Job?

https://news.ycombinator.com/item?id=39875374

by Dansvidania • 2 years ago

94 62 2 years ago

news.ycombinator.com

I just started reading the Hypermedia.systems book and tried it out for some toy project, and I love it.

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?

pc86• 2 years ago

Lots of discussion here: https://news.ycombinator.com/item?id=33987578

willsmith72• 2 years ago

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.

throwup2382• 2 years ago

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.

Zetobal• 2 years ago

It's probably for people like me who only need to build a web frontend 1-2 times per year.

solardev4• 2 years ago

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.

recursivedoubts5• 2 years ago

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

hombre_fatal• 2 years ago

Very modest to assert that others call your project a silver bullet and that you wouldn’t go quite that far.

recursivedoubts5• 2 years ago

ikr, silver-alloy bullet at most c'mon people be reasonable

rkwz• 2 years ago

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

SoftTalker• 2 years ago

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.

Dansvidania3• 2 years ago

first of all thanks for the awesome book and library!

what is the team size at Commspace?

recursivedoubts5• 2 years ago

3-5 devs on the project

j452• 2 years ago

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.

joshxyz• 2 years ago

the hell is that last line, lol. thank you for your work sir!

karmarepellent• 2 years ago

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!

Dansvidania3• 2 years ago

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.

solardev4• 2 years ago

(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.

pavlov• 2 years ago

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?”

vundercind• 2 years ago

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.

ipaddr• 2 years ago

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.

moomoo11• 2 years ago

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.

fermigier• 2 years ago

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.

Dansvidania3• 2 years ago

thank you for sharing! the data is really interesting.

liam_ja• 2 years ago

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!

djbusby2• 2 years ago

I'm in this boat. Using HTMX to modernize legacy apps. Works a treat and saves loads of money vs rewrite in $NewHotness.

zerr• 2 years ago

Outside HN bubble, jQuery is quite an active project.

PreInternet01• 2 years ago

Yup. And it's good. My aspiration, though, it to migrate to https://leanrada.com/htmz/

j452• 2 years ago

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.

havaloc• 2 years ago

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.

shuntress• 2 years ago

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.

runoisenze3• 2 years ago

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)

halfcat2• 2 years ago

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/

runoisenze3• 2 years ago

Thanks for the link! I’ll check it out.

runoisenze3• 2 years ago

I think what’s needed is a sort of, repository of patterns.

Agreed. I was thinking about a reference application to demonstrate those patterns.

spapas82• 2 years ago

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

udev4096• 2 years ago

Isn't htmx a JS bundle? How does that make it "JS free"? I don't get it

Cruncharoo• 2 years ago

You don't have to write any JS.

evilduck2• 2 years ago

Instead you write hyperscript to accomplish anything nontrivial. Potato, potato.

lelanthran2• 2 years ago

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.

lelanthran2• 2 years ago

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.]

worddepress• 2 years ago

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.

jasongi• 2 years ago

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.

Ask HN: Anybody Using Htmx on the Job?

Related Stories