Is Htmx Gaining in Popularity? | Hacker News Reader

Is Htmx Gaining in Popularity?

trends.builtwith.com

156 pointsandrewfromx82 comments

I’ve also noticed a rise in programming content creators discussing it.

I’ve also explored it briefly a couple days ago (with a Go server) and it’s actually really really convenient to work with.

My next project will definitely be in Go + htmx + tailwind and MySQL/PostgreSQL

I’m excited about working with plain html again and not having to deal with over bloated js projects.

Dependency issues will be a thing of the past

If you’re aiming for simplicity, how did tailwind make it to the list? Why not use plain CSS?

Not OP, but for me but for me it eliminates one more decision - naming. I don't want to think about class names or follow a convention like BEM (and probably set up linter rules so I don't do it wrong). I like sscs / BEM in some projects, but it's just one more thing to think about. With utility classes you don't think about it, you style the page as you go inline in the class attribute. The biggest hurdle is learning the utility class names, but there are good cheatsheets for that and my editor already autocompletes all the tailwind classes for me, plus whatever other classes I may have defined.

I think HTMX and tailwind fit well together because I also see HTMX as a kind of "utility framework". It augments the standard html elements with additional capabilities using attributes and HATEOAS.

If you are not writing S/CSS or styling anything beyond what Tailwind/Boostrap (or other frameworks) already has, then it is as simple as it gets. The last time I was involved (actually writing) in a Tailwind project was in 2018. However, today, I can just look at the documentation and do a design all the way without writing any S/CSS at all.

^This. After using it for the first time in my last next js app; played around with the basics of tailwind when I built typefaster.app and it’s my favourite css library.

Also, their discord is very active and very very helpful

Having used it only for my small typefaster.app project and a couple other small unpublished projects I can’t speak to great detail on advantages or disadvantages; I am not a CSS expert. From my limited experience, I found it’s far more convenient and intuitive than any CSS library I’ve used.

It’s concise; writing css directly in my html and not feeling like I’m cluttering the file makes readability great.

Debugging styling in SPAs is significantly easier since I can just glance at the DOM in the browser dev tools and be able to quickly find the CSS causing the styling issue (just looking through the HTML tree, not having to look through styling tool saves time)

DaisyUI is a library built on top of it; a lot of great snippets of styles elements there.

The config file; all custom configs are concise in one file.

It makes things like conditional styling or just if you have any state determining styling, it is very easy to do and readable

But in summary, honestly for me it’s just the direct in-html styling and conciseness. I’m a simple man

My personal suggestion based on Tailwind as well:

- Ripple UI

- Preline UI

- Hyper UI

- Flowbite, and

- Daisy UI

https://github.com/versoly/versoly-ui would also work especially well with this stack as it comes with classes like Daisy (btn btn-primary) and JS like Flowbite (tabs).

Think of Tailwind as another language; A variant of CSS which is technically a superset. The way that Typescript is to Javascript.

For many, Typescript / Tailwind simplifies the code, even though it has to be compiled.

Live reload means I can inline edit classes as styling to quickly create components and not have to context switch to a css file/section. It feels easier to create structure and style as I go.

I think it's the classic simple vs easy. For a non expert, you cannot deny Tailwind is a good mix of ease of use. For me CSS is simple but not easy.

I used it on a project and I liked it but then I got into situations where I needed to pass a bunch of data back to the rendering page and it got really messy. The author says on the HTMX page that if you have this type of situation then HTMX is probably not the greatest fit.

Also as the project got larger there was a lot of issues with like "Wait, why isn't this loading? Oh man someone changed the name of a div I was using".

It's just not as clear when things stop working compared to most JS frameworks (which I hate, hence my interesting in HTMX).

I think for smaller projects it can be decent though.

I think it would be a good idea in these situations (many cooks in the kitchen) to use a data attribute for each HTML element that uses HTMX, such as `data-htmx-id` to reference your elements instead of just using the `id` attribute (which already carries a lot of contextual baggage).

This would solve a couple potential issues:

- Identifying that the element is used for HTMX swaps

- Warning anyone that changing this attribute will break said HTMX swap

Sure, there are ways to work around it but it's just fairly brittle in that way, those measures help but on a large project people are going to be breaking things relatively frequently.

It sounds like in a bigger project a simple linter which checks that front end htmx and backend htmx tags have a match would solve that issue.

That would help, and certainly there are ways around it, but in the state of things right now it's gets ugly.

> I got into situations where I needed to pass a bunch of data back to the rendering page and it got really messy.

Could you not fetch that data separately from the patterns htmx provides and do some light parsing/rendering logic client-side?

That data needs to go to the page itself. Like you need to pull data that is on the main page and send that data down to the modal form submission. That is tricky. Is it doable? Yeah, it can be done but it's really ugly at that point.

What you’re explaining didn’t make much sense. Would like to see an example where it’s messy because I haven’t seen one yet.

The ids changing is annoying tho!

The data was on the server at some point to begin with. How could it be tricky to put it somewhere just because $component is a modal?

How could it be tricky to have html loaded on multiple different parts of the page? Do you think it happens automatically? You have to track all of it. It's a pain. You need to embed hidden inputs then need to capture them, send them off, The modal stays on the screen but the underlying page needs to change behind it.

If you think that's easy then you'll love HTMX

You mean something like this? This does get a bit messier... https://htmx.org/docs/#oob_swaps

I've found Alpine + HTMX a good combination for similar use cases, though I haven't tried to use them both with the same page elements and large collections of data. In my case Alpine localizes date times client side [1] and I intend to use Alpine to pass a bunch of data back to the rendering page. When you say HTMX got real messy, did you find something like Alpine conflicting with HTMX on the same elements?

[1]: https://pentacent.com/blog/date-time-inputs-with-alpine-js/

Go + htmx + tailwind + SQLite is my current stack and it's the most enjoyable web dev experience I've had in a decade.

SQLite adds an extra level of simplicity and convenience that I can't endorse enough

I wonder how much of this is familiarity.

I grew up in the LAMP world, throw in laravel, and I can basically copypaste and whip stuff up.

I know Apache isnt cool anymore, but I can do all sorts of crazy stuff with it after using it for 15 years. I'm not opposed to change from mariadb/mysql since the syntax is the same.

I dread switching from laravel though. Maybe I should since I hate debugging php... and Laravel major versions are so destructive that basic outdated tutorials will have you frustrated.

I’ve only been professionally developing for 3 years now and I’m starting to realize it’s all about familiarity; I think of it as “wear whatever shoes fit you best for the marathon”

I mentioned Go + htmx in my original comment because I use Go at work and we do a lot of templating with the .gohtml and I absolautly love it. The ecosystem of go is what I love about it most

Although I do get tempted by shiny things often; I try to remind myself to stick to a couple tools/languages

On interesting I like SQLite; i never thought to use it for web projects though.

Any tips or advice on trying to use SQLite for web dev? What platforms do you use for deploying web apps with SQLite ?

Correct me if I’m wrong but sqlite has no support for concurrent users right? You would have to have a mutex or queue system in production to make sure only one thing at a time tries to run sql?

Assuming you're talking about users of your web app, rather than database users.

Using the WAL mode [1] you can have truly concurrent reads alongside writes. You can't do truly concurrent writes, however, but the database driver you use (may) automatically retry writes that fail due to locks automatically. The Python driver [2] does with the `timeout` configuration parameter for 5 seconds by default. As your writes should be very quick, so long as you don't hold transactions open or attempt to do lots of work in a transaction, you may find that it's perfectly performant for your use case / usage loads.

1 - https://www.sqlite.org/wal.html

2 - https://docs.python.org/3.11/library/sqlite3.html#sqlite3.co...

You have plenty of options actually, including a safe default: https://www.sqlite.org/threadsafe.html

No dependencies, except for htmx and whatever else you need to make it work.

We didn't say 'no dependencies', we said 'dependency issues'. Htmx is a single <script> tag in your page, your custom JS is another one. That's it, unless you have specialized needs that can only be solved by more client-side JS.

No one said no dependencies. htmx itself has no dependencies which would make me a lot more comfortable adding it to a project.

Sorry for confusion; when I said “dependency issues will be a thing of the past” I was referring to large js projects where your dependency list is 50+; updating one dependency to a new version can be a very cumbersome task

Using htmx will be breath of fresh air if you’ve ever had to deal with complex dependency issues

Fireship published a short video about it couple of days ago. Hopefully it'll gain even more popularity.

I'm sure that will give it a boost on github. He's influence is quite big for people who are just starting out.

I've gleaned value from many of those 100 second explainers video

preach. one can't give the seven databases in seven weeks treatment to every tech in the world.

Video in question: https://youtu.be/r-GSGH2RxJs

We're using it in production and really like it. We're very intent on removing as much React/JavaScript as possible (given the user experience we want to build).

On another note, +1 to Phoenix LiveView if that stack can work for you.

I’d love to but selling elixir is such a nonstarter for most companies. I really wish there was a way to make elixir have a python moment where suddenly everyone is fine with internal teams using it.

Same here (albeit Vue, not React). It’s excellent.

I checked one website in that list, it uses CraftCMS, which apparently has htmx bundled. (https://github.com/craftcms/cms/tree/main/src/web/assets/htm...)

Would be interesting to know which other CMS'es make use of htmx (and to what degree).

I started a WordPress integration. https://github.com/svandragt/htmxpress Early days but there is some interest.

Svelte is already so lean and provides so many QOL improvements to the whole JS/HTML/CSS experience itself that I haven’t found time to try out HTMX, but I’m keen to learn it. I imagine it would be great to stash in the armory for a rainy day. Unfortunately, my use cases almost always require way more firepower than your average website… so I’m not sure when that rainy day might come, but I dig the spirit and simplicity around HTMX.

I prefer vue over svelte but at this point anything is better than react.

N=1 - but been building on htmx for our startup since Sep 21. We got acquired a month ago with successful exit.

One of the best technical decisions we took.

Love to hear more about the reasons why? Long admired it from afar but never been game enough to jump ship.

Best thing is the dev productivity and speed of shipping. Basically, 1 person does what 3 people would do at half the time.

There is a bit of challenge with separation of concern as the team gets bigger, but definitely worth it.

Is the app you built with it heavily dynamic? I'd love to consider HTMX for my team given the sheer volume of React code that we're having to write.

Yea - super dynamic actually with web sockets and server sent events all over the place. All what your would expect from a modern SPA SaaS.

I’m trying to push it for enterprise internal apps that do a lot of crud operations along with SQLite. It’s really only a hunch at this point, but I’m guessing it will let my mostly back-end oriented dev team more comfortably deliver web app functionality.

It may be sacrilege to say this, but I have adopted Retool in my organization for the purposes of quick-and-dirty internal apps that are essentially thin GUIs around internal data stores. It has worked out well for us and even stodgy backend engineers like myself can be productive with it.

htmx is often touted as an alternative to React/Vue/Svelte/etc., but is it more realistic to say htmx+backend is the alternative? In the same vein as hn.svelte.dev [1], can someone provide a htmx equivalent or some similar non-trivial demo?

[1] https://hn.svelte.dev/

For a developer already satisfied with a mature backend framework such as Django or Rails but hesitant to embrace the ever-changing JS ecosystem on the backend, it makes sense to view HTMX as an alternative to React/Vue/Svelte/etc.

Given this, it makes sense to me that HTMX is popular amongst Django developers especially.

Remix Run is not listed? https://trends.builtwith.com/javascript

EDIT: under frameworks https://trends.builtwith.com/framework/Remix

Does it work well when users have poor internet connections?

No, but neither do most SPAs.

I'm using it for a personal project and I'm loving it. I was wondering if anyone had "issues" due to the fact that some components (in my case a date and time picker), use some javascript to show the calendar. I don't see anyway to load it outside of when I load the actual componenet, and if I click the same button twice, it gets loaded as much generating js error because component was loaded the first time. I can of course put some global variables to check and avoid reloading, but it seems to be so patchy. There must be a better way.

Never used it - can anyone tell me how you use htmx with localStorage and webrtc?

normal javascript functions that htmx would just call:

    // Save the value to localStorage
    localStorage.setItem('myData', inputValue);
  }

</script>

Ok cool thanks!

Could someone explain the graph to me? My interpretation of the Y axis (without a legend) is that it’s the number of sites using Htmx among the top 10k/100k/1M sites, but if that’s the case, that doesn’t jive with the numbers detailed in the site totals section.

E.g., this lists Htmx as being used in 143 of the top 100k sites, but in the graph it’s currently at or just below 100 on the Y axis.

I'm curious if an eventual goal of the project is for native htmx support in the browser? And cut out JS entirely?

If you want the bells and whistles for the UI, fine, React/Vue/Svelte will help.

If you just want something that achieves the goal, without bringing new skills or dependencies, HTMX is the way.

I've used HTMX with Alpine for a backend application, and they help on making the application more dynamic, along with Tailwindcss a lot of the frontend effort is complete.

Already have experience building nested dropdowns and reactive search bars with Express, Liquid Templates, and Tailwind.

This is a completely different sense of enjoyment, try to build a reactive modal element that displays a form in it where there is reactive value from the server.

I'm thinking of using it with either n8n or Directus in the backend storing data in SQLite.

I'm glad to see more options to render content on the backend using stable backend languages (not Next.js). I've seen too many slow React websites that could have been rendered with simple PHP or else.

If someone think htmx is too much or htmx syntax is meh check my libraries uajax and ajax-button on github

wondering if that up and to the right is going to continue? Is it winning?

According to that site htmx is used on 7,188 "currently live" websites, which is 0.008% of jQuery's installed base, and around half the number who've starred it on GitHub. So yes, htmx is winning.

I never worked with HTMX, but I think that frameworks like next.js or Astro, that can render server side and client side with the same code, are superior.

HTMX may work well for many websites though, especially if they are using mostly static content with limited interactivity.

I wanted to go down this route but Astro can’t render table rows without being wrapped in a table tag. Which killed this as an option for me

Why would this be the deal breaker of all things? If necessary, you can tack on both the semantics and the layout properties to any container really.

Astro renders JSX to html, what happened when you tried to render a table row without a wrapper table rag? And more importantly, what is a table row doing outside of a table?

Astro removes the html tags and just renders text, so I can’t return a new table row for simple crud setup. Only when it’s a valid table does it not strip out the html.

Oh that's interesting, never seen that happen before but I must have just never run into that use case

Would he great if it gained popularity and finally have react and clones fade out of mainstream development. It’s gotten to a point where react is just bad practice.

still prefer Svelte '__')

Instead of this ridiculous package, you can use packages with more stable specifications such as alpine.

I've seen this misconception a lot, but HTMX and Alpine do two different things.

Alpine enables client-side reactivity and does not require a round-trip to the server. Say, clicking a button and incrementing a counter on the page.

HTMX enables something more akin to server-side reactivity. You could use it to modify, say, a single element in a list of elements. The crucial difference is that HTMX makes a call to a server. This means you would use it when you need to read/write data to/from the server.

Alpine provides client-side reactivity. HTMX provides server-side reactivity.

Yup. It's pretty common to see Alpine + HTMX used together since they are both HTML first. I've heard web components work well with HTMX too.

Reply on news.ycombinator.com