hey there, I'm the creator of htmx, and I really appreciate you making this! very cool!
hey there, I'm the creator of htmx, and I really appreciate you making this! very cool!
I was seriously thinking about using HTMX myself, but I'm kinda scared it's developer pool seems too small to hire devs from.
I'm used to proprietary frameworks, in my case I worked with intershop which uses isml. (this is comparible to something like thymeleaf). In recent years we tried to move away from this approach and go to the angular front end Stack because it's easier to hire a dedicated frontend developer than it is to hire a specialized fullstacker. Stuff can get complex when you're using something like htmx and developers don't want to fight spaghetti monsters. You don't want you backend guys to be the bottleneck, e.g. when FE just creates HTML and the backend has to tie it all together.
My question is; has HTMX thought about the pitfalls like this, and how do you counter it?
How to counter it. HTMX takes no more than half a day to pick up, probably quicker than that.
Keep in mind HTMX does not solve all scenarios, there are times when a SPA using a JS framework is required.
I know nothing about HTMX. Where do I look first?
If you want a longer introduction you can read out book (free online): https://hypermedia.systems
ah, thanks! This looks to satisfy a similar use-case to LiveView which I already have access to in my current stack but it's always good to know about other options
The examples at https://htmx.org/examples/ may also be helpful
aha! I already have access to LiveView so this seems redundant but this is good to know about
I'm kinda scared it's developer pool seems too small to hire devs from
It is very straightforward to pick up. Unless you hire code camp devs who only ever learned React, no actual CS topics, anybody should be productive within at most a week.
I would go so far as to say if you can understand React, you can understand HTMX.
If you can understand HTML, you can understand HTMX.
While true this is divorce from organization’s hiring practices. I have to fill out a form to request someone and htmx won’t be on it. You will get someone who only know react and will stomp their feet as to why can’t we use react. A lot of bootcamp programmers are cert jockeys who don’t care or know about development, not that they can’t learn.
For the sake of your organization, get them to add a fill in the blank on that form. Picking a tech stack based on the options on an HR form is a sure way to end up using ancient tech. HR is failing you.
I've not used it in a team environment. I'm used to working with an FE developer or team. The last time I did js, jquery was the new hotness. For me on a personal project, I tried react and svelte. Both we monsters for building a site that needed some js elements and interaction. I was able to get htmx working quickly and I've only had a couple of snags.
One neat benefit is that I am now able to unit test (well, unit integration) my views with a headless browser because my UI is served by my backend and not a separate service that has to run with all the yarn and npm bs.
TL;DR: I'm a backend person who struggled to pick up react over a weekend but picked up htmx in an hour. Your FE devs will have no problems with htmx.
They will have to become familiar with your system's templates syntax and how to work in the backend to organize their partials and components and may even have to decide how that should all be structured.
Stuff can get complex when you're using something like htmx
Interesting to hear that after a mention of Angular. Different ideas of complexity I guess - frameworks like it give you structure but complexity is still there, and probably orders of magnitude higher.
Ultimately you want FE devs that know the web stack well - JS, CSS, HTML, browser APIs. They will be able to pick the best tools & frameworks for the job. Something like HTMx is trivial to pick up.
Well, nothing succeeds like success, and htmx came in at #2 on the 2023 js rising stars:
https://risingstars.js.org/2023/en#section-framework
Just behind react and ahead of vue, svelte & angular. So the future looks promising in that regard (although I do expect it to drop back after the initial excitement dies down).
htmx is pretty simple, most web developers can pick it up in a day or so. It does require a mental shift for both developers as well as PM/architects in how development is done, because it pushes the organization more towards a full-stack paradigm, with developers owning whole features rather than "front end" and "back end". We have a book, free online, you can read, that will help with this:
In addition to the docs (https://htmx.org/docs, which should take about an hour to read) we also have a bunch of essays on both philosophical & practical issues around htmx & hypermedia in general:
htmx tries to be "scaleable" in that there are very few base ideas to the library and you can use only a few of them to implement useful behavior (e.g. lazy loading, to pull a section of a page out of the critical first-paint path, is two attributes: https://htmx.org/examples/lazy-load) but then it provides enough hooks and deeper features (e.g. events, event filters, etc.) that as you get deeper into it you can accomplish what you want.
finally, with respect to spaghetti code, this is a perennial danger in all software development. My admittedly limited experience with SPA libraries has not convinced me that they prevent spaghetti. w/htmx you want to focus your efforts on the back end and take advantage of whatever tools your server-side environment offers to properly factor your application. Because htmx allows you to pick any server side technology (SPAs put pressure on you to adopt JavaScript/TypeScript on the back-end, since you already have a large application written in them for the front-end) you have many more options & paradigms available for organizing the bulk of your application logic.
addendum: I should mention that i try to outline when htmx is a good choice for an application here:
https://htmx.org/essays/when-to-use-hypermedia/
htmx is a tool, a good tool in many cases, but just a tool, and i want to be clear that it isn't a silver bullet for web development
Is Htmx just the long overdue successor to DHTML that was all the hype in, say, 1997?
believe it or not I was around back then and, no, htmx is not the successor to DHTML, which was very JavaScript heavy
htmx is an attempt to generalize the two core hypermedia controls in HTML (anchors & forms). It does this by making any element able to respond to any event by issuing any type of HTTP request and then placing the returned HTML anywhere (and in any manner) in the DOM. This last idea is called transclusion and is probably the most important part, because it lets you build much more dynamic user interfaces within the standard HTML/hypermedia paradigm.
we have a book here if you are interested:
I know this isn't something the authors can fix just like that, but shipping and import duties mean that the hard cover book is about as expensive for me as the smartphone I'm writing this on ($96.32 for a Samsung Galacy M04 as compared to $96.6 for the book).
The book is great though. If you can't afford it I highly recommend reading it on the website. I haven't gotten through the last section just yet due to family obligations unfortunately but I look forward to finishing it soon.
Unfortunately I can't do much about the cost of shipping, etc.
You can head here:
https://hypermedia.systems/hypermedia-systems/
and print the book to PDF, adjusting fonts, etc as you like, and then print it out at a local print shop, if you want the text in high-res print.
If you like the cover, you can purchase a poster of it here:
https://swag.htmx.org/products/hypermedia-systems-cover-post...
We are selling the 18x12 at cost so people can have it w/o spending $50 on the hardback.
This sort of sounds like turbolinks (or whatever it is called now)?
To an extent, htmx is the successor to intercooler.js, which was released in 2013 and which was a turbolinks-adjacent technology (although never really noticed by the 37Signals folks).
htmx is a bit more focused on one core concept, generalizing hypermedia controls, than hotwire.dev is, and is a little less magic. Both are fine choices for a hypermedia driven application.
If you have time, I have a question I haven't been able to answer reading the docs or skimming the linked book. My company's front end apps communicate exclusively with a GraphQL orchestration layer. I tried a while back to learn HTMX by building a demo remake of one of our apps, and I actually couldn't figure out how to make those requests. Am I missing something, or is this just a bad use case for HTMX?
sounds like a bad use case for htmx, if your server isn't returning hypermedia you are making your life pretty difficult
doable, but not fun
htmx is intercoolerjs
htmx is html but: all elements can make http requests, not just <a> and <form>
I don't think so. HTMX is a JavaScript library that abstracts the JavaScript part away from the user
You are currently using the successor of DHTML.
Dynamic HTML was a marketing term used by Netscape and Microsoft to refer to the combination of HTML, CSS, and JavaScript. Also under that umbrella term you have the introduction of the div tag for IE or the layer tag for NS4 (also NS4 included a JS version of CSS)
It was “dynamic” because you could do effects like hover menus using JS snippets or the first iterations of CSS (ohh the memories of my first Geocities pages). But, XHR APIs didn’t existed yet.
Edit: it seems that the marketing term was used mainly by Microsoft for IE.
Nice! I have been using maplibre with django and htmx. I should try and put an example up there to share with others.
I'd like to see this. I don't have anything I can share publicly, but I've been making stuff with Django, htmx, SQLAlchemy and plotly and I've found it to be pretty robust
I'm curious about why you use Django together with SQLAlchemy, instead of using the built-in ORM? Or is it just separate projects?
I'm using SQLAlchemy to access external data sources to build reports on. Essentially, I'm using it as a dumb BI connector (mostly to access a Databricks metastore), while my Django ORM manages any app information.
I'm not sure it's the most elegant solution, but it has been pretty functional
Unless you’re writing raw sql, Django does not make it easy to build reporting type queries with the ORM so I’d suggest you’re probably doing the optimal thing here.
Fun fact (and a bit of a brag, apologies), I was the contributor that added the “new” Expressions API with the intent of building a reporting platform on top of it. That platform never eventuated but I’ve still got lots of use out of those APIs.
Hey same! I made https://ratethispad.com and it was a lot of fun to make. (Nobody uses it though...)
I would love to see your project as well.
Would be cool if either the zoom level I need to see reviews would be smaller (more zoomed out), or if there is a list of the reviews that exist on this page.
Currently, as there are probably not many reviews on that site it is near impossible to see an example of a review.
would love to see this.
Thanks, and you are very welcome to post it here. Also, if you or anyone else wants to adapt more of the official examples, create an issue with the link, and I'll add them to the repo :)
Wonder if there is there anybody who is making an offline app with request-reponse with html(with HTMX) and a virtual server defined in a service worker?
This is a great question.
I love htmx but in situations that have to work offline I can't use it. Would be a great hack to be able to just run your server code in a worker.
I am not sure if I understand the definition of offline here. HTMX has graceful degradation options. What else could you do when the client is offline?
There are many apps that work when the user is entirely offline and HTMX is not a good option if that is a key requirement of your app.
Figma is an example.
Should work if the worker behaves like a traditional backend and return/proxies html pages rather than JSON?
Would be a great hack to be able to just run your server code in a worker.
This is exactly why some people build heavy offline-first SPAs in JS. HTMX tries to avoid this entirely. Conceptually (seen from the perspective of HTMX), it makes zero sense to put the server code in a worker and run a client-server architecture in the client‘s browser.
This would be an over-engineered thing that HTMX explicitly tries to avoid in the first place.
I'm not sure "zero sense" is true. An app designed around REST and hypermedia imposes sensible constraints, like how you handle state, navigation, etc., and this can still yield plenty of benefits.
This would be an over-engineered thing that HTMX explicitly tries to avoid in the first place.
Yes, this is where I think a lot of folks who moan about "bloated JS frameworks", etc. really are just complaining they can't use their favorite (or only) language for web UI development.
I'm working on a server/backend for htmx that's intended to run as a local service beside the browser. In theory you could do this with any server stack that is self host-able. My goal is to produce a single binary with no external service dependancies. I'm using Go, and a lot of the components are readily available, e.g. self updating local service, replicated database, etc. It's easy to cross-compile for different target OS and architectures. As an alternative to building everything into the browser, and assuming you're able to run a separate process, this approach makes a lot of sense to me. It would be great if Go had something similar to Deno's permission management though...
Are there any companies using htmx? Places where we can see examples of complex interaction?
complex interaction
Yeah, htmx looks endearingly simple but I worry we might be painting ourselves into a corner. Not sure what happens when you need more "bespoke" functionality. I didn't really look into it at all, maybe I don't need to worry?
I have been using HTMX with Django for over 3 years on multiple (client) projects.
In 99% of the cases, it works just fine. In the 1% of highly interactive components that aren’t working well with HTMX, you can just put in some Vue or alpineJS. whichever works best for you.
I have migrated all of my own and client apps from a decoupled Vue/django setup to HTMX. It was a ton of work, but it’s awesome having a clean setup with no node modules.
I think you mention a very valid point that is worth reiterating: Even when you enter territory where HTMX gets cumbersome for some reason, you can still use custom JS or some other library to work around it.
I admit that I initially started to use HTMX to avoid JS, but I am now more comfortable than ever before to fall back to some lines of Javascript in the few cases where HTMX does not feel like a great fit to solve the problem at hand.
Another great side effect (that you also mentioned) is how much cleaner the project is structured now. But I also realize that this might not apply to big projects.
I admit that I initially started to use HTMX to avoid JS, but I am now more comfortable than ever before to fall back to some lines of Javascript in the few cases where HTMX does not feel like a great fit to solve the problem at hand.
Many people don't realize that great engineering happens under constraints. When you're faced with an empty project and the full power of JavaScript, you have 5,000,000 ways to do something and the chance to make a series of wrong choices that back you into a corner is high. By contrast, when you're working within a system that constrains the available choices, the possible design paths are considerably fewer and so the system becomes more understandable and maintainable, which makes for a very straightforward, comfortable dev experience.
The same goes for great design, of course figuring out the constraints is the trick with design - when there aren't really the same hard hardline guardrails that programming languages have; I suppose platforms like Figma attempt to create relatively rigid rails to follow.
This is a good talk showing that.
Not sure what is considered complex. I have a login flow and search interface implemented in HTMX and Rust. Polishing the last few rough edges and when it is done I a writing a detailed article about it.
Limited mobile support, Ace Editor (should just be Monaco) and lack of proper error outputs.
Monaco doesn't work on mobile by design, so people use Ace on mobile.
At least the last time I checked GitHub[0].
Monaco works fine on mobile, just used it for https://tsdiagram.com
On my android, I cannot type - the keyboard does not open. So it's read-only on my mobile.
I think that was the problem with Monaco on mobile: the keyboard never worked correctly. That was my experience.
Edit: I don't want to complain, Monaco is superb editor and it would be super if it worked on mobile consistently. But from the github issue, it appears that Microsoft doesn't seem to want to change that.
Super weird, I can type on Android, will try some other phones.
I am able to get the keyboard to pop up if I long press and select something, like copy, from the menu. But I assume they keyboard is supposed to open easier than that. I'm using Galaxy A50, Android 11, Firefox 121 (latest).
What did you use to generate that lovely ERD-style diagram?
Used the amazing https://reactflow.dev <3
As someone who just hit tsdiagram for the first time on my phone, I'll suggest you'd be much better off with an explanatory landing page.
I can see just enough editor UI stuff on my phone to strongly suspect I'm in your target userbase, but because of screen size issue I can not see enough to have any idea what tsdiagram actually does.
Finally a way to use HTMX as a SPA framework ;)
The king is dead. Long live the king
You laugh, but I've been using this technique to fully support offline behavior with htmx. (not a SPA though)
This guy gets it
How sweet it is.
I wonder if it would be a good idea to move the whole HATEOAS thing towards things like desktop and mobile apps. Might be a fun experiment.
Mobile dev here. If you are talking about native mobile then I'v played around with using HATEOAS with native code in the past (around ~2013).
It works fine but is obviously not as flexible as on the web. It also does require that each linkable screen be developed in a strict black box fashion.
It was a fun exercise to try out, but not sure what the value of using it in production would be.
I've found that HATEOAS is actually quite good for CRUD. You "link" to "lists" and items, and the information in the responses is enough to assemble pages, forms, other lists.
This way you only gotta build the "abstraction" in the app itself, the real structure of each page is entirely in the APIs.
Thing is, this saves money at the start, but people obviously want more customisation than is appropriate here. And as more and more pages become bespoke, hypermedia stop making sense :(
I wonder if HATEOAS is a good idea.
I have only ever seen HATEOAS as an abstract concept, but never actually seen a real UI where I think "wow that is actually an improvement in user interaction".
REST was a welcome simplification of the SOAP monstrosities, but it comes with a lot of dogma. REST aligns natural user concepts with data with the service architecture, so I see its purpose fundamentally.
HATEOAS seemed like a product of people wanting even more dogma / pretentious drivel in architecture meetings without really concentrating on if the user experience is improved by the model.
Does anyone have a HATEOAS UI example that highlights why you would use it as some founding principle? I mean fundamentally each page has links to "what to do next", and my impression of HATEOAS is a blinged up way of trying to bring some sort of similar state model to REST service calls.
Does this support ActiveX?
OMG! I had a flashback. Do any of you remember HP Quality Center?. Its early versions had entire UI in activeX and I remember a bunch of progress bars installing DLLs.
OMG, I'm so old I understand this joke. This is sad actually.
Made with svelte?! Where are the purists of the MPA and their pitchforks? ;)
I am an MPA purist, yet I fully realize that there exists a class of applications where SPA is the best choice ;)
This is very cool!
@bitterblotter there is a typo in the description on the main page I think: "It will run a mock server that intersepts outgoing"
Intersepts => intercepts
Dang this is why I keep coming back to HN. Nice one.
Thankyou for the awesome library! I have a question.
Is there a way to use HTMX with minimal server side changes. Specifically if I have an existing page that you fill in a form and submit and response is of course the entire page. I think it would be cool to tell htmx that the whole page is being returned BUT I only want to update #my-form and that way you don’t need any “if htmx request” kinda stuff on the server.
This is for people who care about their site working without JS. But also it allows you to have a single backend endpoint to handle multiple things (for example comments, sign up to email, like button, all in one)
If I understood correctly, you can achive this with `hx-target` and `hx-select` - I'm doing this in an app to replace an editor content based on which link is clicked.
- https://htmx.org/attributes/hx-select/ - https://htmx.org/attributes/hx-target/
Oh that's neat - so you can return more than htmx will use and it can select the element it needs in the response and discard the rest
Yep, I actually don't even do server side checks in my app I am building, I just hx-boost on my html element and then server side I redirect back to the page that should have the updated content, just like you would a traditional server rendered app, and htmx then swaps out the body, but if I use target and that I can tell it to only return say the `<main>` tag and maybe another part of the page, the rest doesn't change.
That could be it! I missed that one. Will try it next time.
I'm not sure about HTMX, but this kind of behaviour is what Unpoly https://unpoly.com/ excels at
I played with it recently and it was pretty easy to enhance a completely non-js CRUD type app and have it fall-back gracefully. Seems a similar concept to HTMX but has a more batteries included / high-level approach.
I'm in the early stages of an Unpoly project and I'm happy with it so far. It's nice to have things built-in like modals and attaching data & logic to incoming elements. Feels like I have less need to integrate with Alpine.
in addition to the other tools mentioned in sibling comments, there is a multi-swap extension:
https://htmx.org/extensions/multi-swap/
hx-boost is the simplest way to do this, but it updates the body content rather than the form. In most cases this will probably be effectively the same.
Likewise man. In the face of avoiding JS, I think we've both taken one for the team here
Wait til you find out I'm using htmx with node.
based
Wait til he finds out what htmx is built with.
Me when I buy a face mask and immediately ask people to spit into my eyes
In which, you still need to include a JS file. I'd still count that as Javascript.
Pretty clear that they mean "avoid writing javascript," not "avoid executing javascript"
Haven’t tried htmx. Have you heard of phoenix liveview? Are they similar concepts?
htmx is lower level than the various liveview implementations
this makes htmx more work, in general, to accomplish things but also less opaque
htmx is laser focused on generalizing hypermedia controls in HTML (anchors & forms)