Anybody Using Htmx on the Job?

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

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

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)

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

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.

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!

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

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.

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.

Using this architecture with htmx is the future

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

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

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