No Seriously: htmx is Pro-JavaScript!

All right, well, I'm going to give a talk called No Seriously, HTMX is Pro JavaScript. For some reason, I feel like people don't take me seriously. I don't know what the situation is.

So about me, my name is Carson Gross. I work on a bunch of different open source projects. HTMX is probably the one you've heard of. I also work on something called HyperScript, which is a scripting language for the web. Idiomorph, which is a morphing algorithm, actually 37signals is using it in Rails now. I wrote a silly essay on software development called Grugbrain that you can read at grugbrain.dev. And I've got a book that you can buy if you like or read online for free at hypermedia.systems.

And today what I'm going to talk about is HTMX, obviously, that's what you're here for. And I'm going to give some HTMX demos. And we're going to talk a little bit about the relationship between HTMX and JavaScript because it's a little bit more awkward than the relationship between, say, React and JavaScript.

So HTMX, what is it? Well, it's something that I call a hypermedia-oriented front end library. And what that means is that it enhances HTML as a hypermedia in hypermedia terms. And that's different stylistically than most of the frameworks or libraries that people here would be used to where those frameworks tend to lean into JavaScript. So it just takes a different look at things from, you know, approaches web development from a different perspective. And it builds on this idea of what are called hypermedia controls in HTML.

And this is a concept that I don't want to say has fallen on hard times but isn't as sort of interesting, hasn't been as on the top of web developers' minds for a while since the standard approach has become sort of single-page applications. But you all probably know what hypermedia control is, even if you've never thought about the term before because the canonical hypermedia control is a hyperlink. In HTML this is implemented as an anchor tag. So here we have an anchor tag on the screen in front of us, a very simple one. And this allows for what's called non-linear linking. So when hypermedia was created, it was contrasted with old media. So paper and PDFs and things like that. And what was unique about hypermedia is you could jump around, you could pick what you wanted to do. And this, you know, hyperlink obviously is the fundamental navigational mechanic of the World Wide Web. There's another hypermedia control called the form. And forms are more complicated. You may have used them in your applications.

And these allow people to express more sophisticated interactions with a remote server. So updates and searches and so forth. But more control is given to the author with forms. So if you want to understand HTMX, I think the best thing to do is to look at a, to look closely at a hyperlink or an anchor tag. And if you look at this anchor tag, again, a very simple, very simple hypermedia control, very simple link. What it's telling the browser or the hypermedia client is render some text. And then when a user clicks on that text, I want you to issue a get to a remote server and then replace the content of the entire viewport with whatever HTML document comes back. What HTMX does is it actually, it just, it generalizes that idea. So there's four components to that idea. And those four components are the trigger, the element that's issuing the request of the thing that's actually a hypermedia control, the verb or action that's being used to make that request, and then where and how the content is being placed into the DOM. And so HTMX, the goal of HTMX is to generalize all of those things based on this core concept of hypermedia controls already present in HTML.

So this is how we do it. Here's an example of an HTMX powered like button. It's not a great button, but it's my like button. So the way this like button works is you can see we've put some attributes on it. And those attributes all start with HX. That's the prefix that HTMX uses. So what this is saying, the first attribute is HX put, and then there's a relative URL after it. And what that's saying is when this element is interacted with, I want you to make a request to a remote server, and this is the type of request that I want you to make. And so that, and there's a set of attributes that all correspond to the various HTTP verbs. So we have post, patch, delete, and so forth. And that makes it possible for any element in an HTML document to become a hypermedia control, and you can also issue any type of request, which is in contrast with the basic anchors and forms in HTML where you can only really issue gets and posts, unfortunately. The next attribute on it is HX trigger, and this generalizes that notion of what event drives the request. So rather than only clicks or in the case of form submits, why not have any event able to trigger requests. And then finally there's an HX target attribute, and you can see that takes a CSS selector. It's targeting this output element. Believe it or not, output is a legal HTML tag that has the ID output. And so this HX target allows us to target any element in the DOM rather than just replacing the entire viewport. So the technical term for this, I sometimes go to academic conferences, is called transclusion. So this generalizes transclusion with HTMX.

And so with these attributes, HTMX really takes this concept of hypermedia controls, generalizes it, makes it available anywhere in your document responding to any event. There's some other practical attributes in HTML as well. So HX swap which lets you change exactly how the content is swapped in. HX indicator which is used to show an indicator when a request is in flight so that the user knows something is going on. And all in all we've got a total of, I'd say, maybe a dozen attributes. I think in total there's a little over 20. Really most people who are working with HTMX typically use like 5 or 6 attributes and maybe a total of 12 you could call the core. You can go to htmx.org slash reference to sort of see what the core API is.

But at the end of the day we're practical developers, we want to get stuff done. So what can we achieve with this generalization? Well, I think the best way to sort of show people what you can achieve with this is demos. And my favorite demo is one called active search. So we've all gone to Google and started typing in a search term and had the results kind of pop up as we're typing. And that, I forget exactly what Google calls it. But I call it active search. So as you're typing things pop up. And I want to switch over really quickly to another tab. And you can see all the examples that I have for HTMX at htmx.org slash examples. But I'm going to show you active search. And so what we have here is we have an input, so just a standard search input.

And we're going to make a post to search. And the trigger is probably the most interesting aspect of this demo. So we're going to trigger it on the search event. Don't worry about that. That's basically what happens when someone – search inputs often show a little X that you can click on to clear the search term. But more importantly on the input event, and that's going to trigger every time someone changes the input. And we're going to – after the input indicator for the event, we're going to give it two modifiers. The first one is changed, which means this input's value must have changed for us to actually issue a request. And then finally, delay colon 500 milliseconds, and this is the important one.

The first one is changed, which means this input's value must have changed for us to actually issue a request. And then finally, delay colon 500 milliseconds, and this is the important one. So what this does is this actually de-balances the request, because you don't want to hammer the server as you're typing, you know. Every single time someone types, you don't want to issue a request. And so what this says is, okay, wait 500 milliseconds, and if another event, another change event hasn't come in, then issue the request.

And you'll see that when you go to Google as you type, there's a slight delay. And so that's called de-balancing. So htmx has this to sort of provide that sort of functionality. And then finally, we're going to target the search results, which is just the body of this result table down here. And so what I want to do is I want to come down here, and there's actually a demo. And I'm going to hit A, and you can see there's a little sort of debugger – total hack, it's horrible, don't look at the code, but it shows the requests that are being made.

And so I typed A into this input, and we got back some HTML. And htmx, since it's hypermedia-oriented, gets back the HTML. You can sort of see the content that it got back from that request there. And then it just inserts it into the DOM where we told it to. And that's it. That's really all that it does. But at the same time, you can see, as I'm typing here, it's filtering down. It's making these requests. And you can see there I was able to type E and then S, and there was a delay because it didn't – after I typed the E, an event was triggered, but it waited 500 milliseconds. I typed S before that, and so it waited. Then I typed S, paused for a second, get the results back. So one thing you'll notice is, for example, the scroll state doesn't reset and all that. All the bad things about the old web applications have gone away to an extent here. So we're able to work with this and we're able to work with HTML in what I think are arguably HTML terms and hypermedia terms anyways, but achieve a better user experience.

So that is our active search example. I think it's a good example because it really gets at how dynamic behavior can be, even with the hypermedia model, even using hypermedia as our mechanism for our standard programming. So by generalizing hypermedia, we're able to do more with HTML. What you'll notice if you look at this example is you as a JavaScript developer might say, where's the JavaScript? And the answer is there is none, or at least there's none that the user is writing.

What you'll notice if you look at this example is you as a JavaScript developer might say, where's the JavaScript? And the answer is there is none, or at least there's none that the user is writing. So HTMX is written in JavaScript, but the user themselves, they don't write a ton of JavaScript to achieve this UI. They use a few attributes instead. Okay? Now we can build some web applications, not all, and I have an essay up about what I think hypermedia is good for on the HTMX website. We can certainly build a lot of applications without a ton of JavaScript. I think unfortunately, and it's just the way the world is, because of that, HTMX is often viewed as being anti-JavaScript. And I think that that's true to an extent in that HTMX definitely appeals to people who don't like JavaScript because now they can participate in modern web development, they can at least achieve something like an active search, or we'll see some other examples later on, or you can see some other examples on the examples page on HTMX. They can achieve those user interfaces without themselves needing to write a lot of JavaScript. And I see this online a lot. Now I have to admit the way that I act on Twitter, I'm lucky anyone likes me at all, but certainly there's an attitude and a subset of HTMX developers that is anti-JavaScript. Now I don't think that's totally fair. I do understand where it comes from. But of course HTMX itself is written in JavaScript. In fact, it's just one giant ball of JavaScript if you've ever seen the... If you've ever gone to the GitHub repository, you can see it's a single gigantic JS file because that's the way I wanted to code it. So I think at some level it's impossible for HTMX to be anti-JavaScript because it is JavaScript. But I think at a deeper level you could argue that HTMX is actually very pro-JavaScript. This is... Bear with... Hang with me here. But the argument I'm going to make is that HTMX focuses on improving HTML that expands the class of problems that HTML can address in hypermedia terms. And yes, that does shrink the amount of things that need to be addressed using something like JavaScript. But I think that's actually good in that it allows JavaScript to be used for what it was originally designed for, a lightweight scripting language for the web. And so the way that HTMX and JavaScript interact can be very mutually beneficial to one another. It can actually narrow down the responsibilities of JavaScript in your web application and allow that to be a higher value component of your website. So in relative terms, at least per line of code, JavaScript can increase dramatically in value. So let's look at another demo to show this. This is an example using SortableJS. And so what the SortableJS, if you've never seen it before, allows for really nice drag and drop behavior in HTML. It's a JavaScript library.

You add it, you know, you add it and you hook it up into your DOM and you can make things support drag and drop. And so this is the JavaScript that is necessary to do that.

So HTMX has an onload function that will be executed anytime new content is put into the DOM. It will pass in the content in the callback. And so what this is doing is it's just looking up anything with a sortable class on it and then initializing this sortable instance on it.

And so if we look down here, we've got a form that has that sortable class on it. So we're adding this JavaScript enabled behavior to the form and it has a bunch of divs inside of it with some hidden inputs. And what this is going to enable is for users to drag and drop, reorder these elements using the SortableJS functionality. One of the things that SortableJS does is when a drop is complete, it actually triggers an end, triggers an end event. And so that's great because now HTMX can integrate with SortableJS listening for that event. When an end event occurs, it's triggered by SortableJS, it's going to issue a post to slash item. So it's going to tell the server, hey, this has been updated.

And so if we come down here, I'm going to grab item one and drag it down here. And you can see that's the functionality that SortableJS is providing, a really nice drag and drop experience. And when I drop it, you can see that a request was made. And we set the hidden inputs up with that form, from that form request to the server. And the server can reorder those elements and then re-render the whole list.

So that's an example where HTMX has worked in concert with JavaScript. So HTMX could not achieve this user experience by itself, at least not well. And I think it shows how these two technologies, JavaScript and HTMX, are complementary to one another. And complementary as technologies.

And so this is obviously a much nicer experience. And I think it shows how these two technologies, JavaScript and HTMX, are complementary to one another. And complementary as technologies. This is, again, something that HTMX couldn't achieve on its own. And so we have a JavaScript library that's extending and improving the user experience, which is actually exactly in line with the original goal of scripting in the web architecture.

So Roy Fielding is an engineer who worked on a lot of the early technologies of the web. And he wrote a pretty famous dissertation in which he defined the term REST. And so that dissertation sort of became how a lot of us, especially us older web developers, thought about and talked about the web. And he explicitly mentioned scripting in that document. Okay. We're going to have, to be REST, it's an optional constraint, without getting too much into the academic language, but it's called code on demand, or what we would probably call scripting today. And this is what he had to say about scripting. So REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts. This simplifies clients by reducing the number of features required to be preimplemented.

And here when he says clients, he means browsers. There's going to be stuff that browsers can't do that scripting is going to allow them to do. That's what he's talking about there. Allowing features to be downloaded after deployment improves system extensibility. And so the system he's talking about there is the web. So the web is a RESTful system and it has scripting, and that allows us to do interesting things with the web that the web itself wasn't designed to do, because we have this ability to script.

And really the key, I think, in integrating between the scripting world and the hypermedia world is this notion of events. So events allow us to cleanly bridge between these two worlds, because we can have a JavaScript library like sortable JS. It does some crazy stuff with the DOM, makes everything look super cool, drag and drop behavior, that's awesome, slides things around, does all the animations. But at the end of the day when things are settled and we want to persist that to the web, we say, okay, you fire an event, you tell me, and then I'm going to interact with the web in the traditional hypermedia oriented way, and that's how HTMX can integrate so well with sortable JS. So with these events, these two technologies can work in concert, and furthermore, if you do that, then HTMX can relieve JavaScript from having to do everything for your web application. So HTMX can take care of persisting state. You can have only one sort of source of record, or system of truth for where the state is on the server. And when you do that, that can tremendously simplify your web applications. So it's not perfect for every web application. There's certainly very highly dynamic web applications that the hypermedia model isn't good for, but by pairing the hypermedia model with scripting in its traditional sense in the web environment, you're actually able to achieve quite a lot, and often at a much lower level of complexity than will be necessary if you made JavaScript take over everything in your web app.

And so in that sense, I think it's arguable not only that HTMX is, like, written in JavaScript, but it's also very pro JavaScript. It can allow that JavaScript to be very high value. It can allow it to focus its value on exactly what JavaScript and only JavaScript can do, which is being the native scripting language for the web.

Thank you. The first question I have here is what kind of applications is HTMX the best for? And I guess you could probably flip it, like, what's a type of application maybe that you wouldn't build HTMX with? Sure. I think HTMX works best the closer to a cruddy app you are. So the closer... the better it would be as a traditional web app, the better it would be with a little bit of HTMX sprinkled on top of it. So a lot of, you know, business, line of business apps and things like that. I think you could do a pretty good Gmail. It would be online. So offline functionality, that's one of the big problems. If you need offline behavior, then HTMX isn't a good choice. Something like Google Maps is typically an example I give because with Google Maps, you have a lot of interactions that are very fast, and obviously making a server trip on every interaction isn't a good idea. On the other hand, Dragable.js shows that you can integrate sort of a more highly interactive experience with HTMX. You just have to do it with events.

And on that note, like, are there other libraries you think that pair well with HTMX to kind of give you that interactivity that if you're missing it? Yeah, for sure. Alpine.js is the biggest one, I would say, that I've seen a lot of people use successfully. But also, I know there's a pretty famous demo that a developer gave at Djangocon in Europe where he uses HTMX, basically rewrites an app in HTMX and has a good experience. But I know that he ended up using a view component within an HTMX app for sort of a highly interactive editing experience. And so you can use them together, but again, it allows that view app to be a small component rather than the entire application.

I got another one here that is, well, kind of related. I mean, you kind of touched on it. What are the limitations of HTMX, if you could add any? Yeah, I think just getting your head around the hypermedia model and, okay, there is going to be an interaction with a server, so that doesn't mean that every interaction has to be with the server. So for example, that sortable JS demo that we did, it could be rewritten so that rather than reordering and making a request on every drop, you click a button and go into reorder mode and then allow them to reorder and then click a save button and then make another request. Now, that's obviously not as sophisticated an experience, and so these are the sorts of tradeoffs you have to make when you're building a hypermedia-based application.

What are the limitations of HTMX, if you could add any? Yeah, I think just getting your head around the hypermedia model and, okay, there is going to be an interaction with a server, so that doesn't mean that every interaction has to be with the server. So for example, that sortable JS demo that we did, it could be rewritten so that rather than reordering and making a request on every drop, you click a button and go into reorder mode and then allow them to reorder and then click a save button and then make another request. Now, that's obviously not as sophisticated an experience, and so these are the sorts of tradeoffs you have to make when you're building a hypermedia-based application.

And we have a couple of questions here about testing. So there's one that says, can you integrate with Cypress? Yeah, and there's another one that's like, how do you test it? Is end-to-end testing the only way? Yeah, end-to-end testing is definitely the way that it works, but there's pretty good end-to-end testing infrastructure at this point. And so I would say it's the normal way you test an application now. What they're probably contrasting that is with testing your JSON API. And I get that, but with HTMX, you collapse. Since you're building your front-end on the back-end, you're building your HTML on the back-end, you move a lot of your logic back there, and so you can test it there. And so your testing strategy just becomes different. Oh, yeah, that's a great way to think about it, because at that point, yeah, it's just testing your back-end end points, not necessarily like how HTMX interacts with it. Right. I don't know if this is a joke or not, but there's a question here. Does it scale? Does it scale? I guess also, maybe if you could talk about, are there any examples out there of larger applications that have been built with HTMX? Yeah. HTMX doesn't scale. Okay. No, it depends on what you mean. It depends on what you mean by scale. So there's a few different definitions of it. From a performance standpoint, I think hypermedia scales very well. The web is an example of a giant hypermedia system, and it's scaled tremendously. It might not scale if your company is used to the front-end, back-end split, because HTMX eliminates that. And so if your scaling strategy is built around that split, then it might be difficult. But what it does do is it makes everyone full stack. When you do development in HTMX, you become more of a full stack developer. So the advantage of that is now an individual developer has ownership over a feature rather than one half of a feature, either the back-end or the front-end of it. And so I think it can scale in the sense that people can get trained up on it. It's a simpler model in many ways than the more sophisticated SPA approaches, and so you can scale your employees more easily, I think, in most cases with it. But there are trade-offs.

But there are trade-offs. I don't want to pretend that there aren't. For sure. This one is most upvoted right now. So a lot of web development these days is using React, Next.js, etc. How do you see HTMX fitting into the JSX ecosystem? I know a lot of people are using JSX on the server side, because it's a really good templating language, and so I think that's probably the easiest, if you're familiar with JSX, probably the easiest way. And this is a mistake that I've seen people make, actually, with HTMX. A lot of people get excited about HTMX because they can use a different back-end programming language. So, oh, I'm going to try Go or I'm going to try Rust or something like that, and so they do both HTMX and a new server-side environment, and I think that's a mistake because it's just too much. I think you should do one at a time, and if you're familiar with JSX and you know JSX, then what you should probably do is just use JSX on the server side and start using HTMX. It's not super hard to figure out how to do it. And so I think that's probably the best first step for a JavaScript engineer is to pick something and say, okay, we're going to do this in SSR, but I'm going to use JSX on the server side and start working with it and figuring out what the patterns are because it is just a different mindset. I think also another good and effective way for JavaScript developers to think about HTMX is let's use HTMX for the dumb stuff and let's use JavaScript for the cool stuff. And I often recommend try it out with an internal tool that maybe doesn't have a great user experience right now and doesn't have a lot of attention. Try it out there and ease yourself into it because it is a very different mindset. I think my book, Hypermedia Systems, which you can get at hypermedia.systems, is good, but it's a mindset shift, so you have to give it time, and if you throw another variable in there, like a new server side language, that can often just make it a bad experience. That makes sense. I will mention I have experience with, I think it's called typed HTMX, and you can actually get auto-complete on your attributes inside of your JSX. Yeah, the tooling is coming along for sure. Yeah, they definitely play well together. And there was a question here, like what backend stacks play well with HTMX? I think everything plays well with HTMX, and that's one thing I'm really passionate about is that the web has always been this sort of open system with a bunch of different programming languages, Perl, I hope Perl makes a comeback, but PHP, Java, JavaScript, OCaml, like all these languages, Haskell Lisp, all these languages, I want all of them to be able to do web development and do, you know, nice web development. And so, HTMX, by putting that focus back on the hypermedia side of things, I think allows these languages to be great for web development. And so, I think if you have HTMX, your decision on the backend becomes more, what language do I want to use? What tools are like, if you're in AI, maybe Python is the way to go, because there are so many libraries for it. And so, you can make that decision based on your backend needs, rather than like, well, we're going to have a gigantic JavaScript codebase anyway, so we might as well use JavaScript on the backend. Definitely. And this next question is, it seems JavaScript friendly, but what about TypeScript? TypeScript? Next question. No, I'm kidding. I'm kidding. I've got no beef with TypeScript. I don't know it very well. Obviously HTMX is not written in TypeScript, but, you know, I think it's a, I like, I mean, what am I going to talk smack about TypeScript. I like Java. So, I feel like it's a good programming language, and you can use it on the server side to create HTML, so, great. You know, you can use HTMX with it effectively, I would bet. Awesome. All right. That's all the questions we have time for now, but if you have more questions, you can follow Carson over to the Glassroom, and you can actually ask your questions in person, but thank you so much, and please give it up for Carson one more time. Thank you.