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