In this episode, SE Radio host Sriram Panyam explores HTMX with its creator, Carson Gross, who is also creator of Hyperscript, the mind behind the Grug Brained Developer, a professor of software engineering at Montana State University, and co-author of Hypermedia Systems. HTMX is a modern JavaScript library that allows developers to access AJAX, WebSockets, CSS Transitions, and Server-Sent Events directly in HTML using attributes. It represents a return to hypermedia-driven application architecture while supporting modern user experiences.
The episode starts with a look at the current complexity in web development and how HTMX offers an alternative approach. Carson explains the core philosophy of “HTML as the interface” and how hypermedia principles influenced HTMX’s design. From there, they dive into HTMX’s technical concepts, including its attribute system, server-side integration, event handling, and state management approach. Carson shares some real-world implementation strategies, including migration paths from JavaScript frameworks, architectural patterns, and performance considerations — as well as a few scenarios in which HTMX might not be the best fit. Finally, they look at the growing HTMX ecosystem, community contributions, and future development roadmap. Throughout the episode, Carson provides concrete examples and case studies of HTMX in production environments.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes
Transcript
Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
Sri Panyam 00:00:18 Hello, this is Sri Panyam for Software Engineering Radio. Today I have with me Carson Gross, the creator of HTMX, a library that’s challenging how we are thinking about modern web development by returning to the hypermedia-driven principles of the early web and all the while liking modern user experiences. Welcome to the show, Carson.
Carson Gross 00:00:40 Thank you. Very excited to be here. It’s really nice to be able to talk on a show that’s a little bit more geared towards software engineering and sort of principles instead of just, here’s another, here’s how HTMX works. So I’m excited to talk about sort of the philosophy and software engineering around it.
Sri Panyam 00:00:57 Sounds great. Before we dive into the details of HTMX, I want to get your perspective on the current state of web development these days. Web development seems to involve a lot of complexity; complex tooling, complex frameworks. Could you share your perspective on where we’re at?
Carson Gross 00:01:14 Yeah. I agree with that. I think obviously I wouldn’t have created HTMX, which we will get into the details of exactly how it works later, but it is a simpler way of creating at least a certain class or a certain percentage of web applications. And I think, as you point out, in the last say 10, 15 years, web development has gotten pretty complicated. Part of that was driven by needs. Obviously if you need a more sophisticated user interface, things get more complicated. But I think, part of it too is just driven by developers. We have a hard time saying no to things and the shiny new thing and being impressed by sophisticated approaches rather than maybe accepting a little bit less sizzle, but with a simpler approach. And so I think it’s been a mix of those things. I don’t think I’m alone in suggesting and modern web development, which is really, I think the main area, HTMX is interesting. It’s pretty complicated now. There are a lot of people that are very good at it and experts at it. So, and I don’t want to denigrate what they can do and what they can achieve with the tools they have. But at the same time, I do think there’s a large class of web applications in particular that could be simplified using some of these older ideas.
Sri Panyam 00:02:29 Nice. And in terms of these challenges, where and how does hypermedia driven approach come in? I mean, first of all, what is it?
Carson Gross 00:02:37 Yeah, let’s talk about what the hypermedia approach is. So HTMX is what I call a hypermedia driven library. And what that means is that it uses the ideas of hypermedia, which are very old. I mean, the term was coined back in the 1960s and obviously the web was invented in the 1990s. So you’re talking about some pretty old ideas at this point. But with HTMX, the idea is let’s take those ideas and sort of extend them. And really the big idea, I would say in hypermedia is this notion of what’s called a hypermedia control. What makes hypermedia interesting from a technical standpoint is that you mix control information and display information in a single document. And I don’t know if, Ted Nelson might not, wouldn’t probably talk about it in that way, but I’m taking my terminology from Roy Fielding’s dissertation.
Carson Gross 00:03:27 He had a famous dissertation about REST, was describing the web. And I’ve written a paper and a CM paper that you can read called Generalizing Hypermedia Controls that sort of riffs on this idea. But again, to get back to your original question, a hypermedia is a media, so some format that sort of display content weíre used to when we talk about media. But then it has these special things called hypermedia controls mixed in. And so the canonical hypermedia control is the anchor tag. And so you put an anchor tag in an HTML document and then someone clicks on it, and they go somewhere else. And that doesn’t seem much probably to you or me because we’re so used to the web, but from a historical perspective, what you’re doing is you’re putting control information in the document, you’re putting navigation in the document itself, and that’s really what makes it a hypermedia, something that’s beyond normal media.
Carson Gross 00:04:18 So when the term hypermedia was coined, Nelson was contrasting it with books and magazines and things this where he just kind of plotted through it directly. And I think the informal definition that he gave was basically any sort of media that needs to be consumed on a computer because computers allow you to have these interactive experiences. So again from my perspective as a computer scientist, I really focus in on this notion of hypermedia controls. We talked about links, the other major hypermedia control that’s available in HTML, which is a hypermedia format is our forms. And so if your listeners have ever created a form in HTML to submit a contact or something that or just filled out everyone has experience with a credit card form at this point and click submit and then you purchase something that’s different, that actually forms were added in HTML 2.0.
Carson Gross 00:05:12 And it was really a pretty massive and a step forward in the ideas of hypermedia, which hasn’t been discussed a whole bunch because hypermedia before that wasn’t always, but it didn’t have this explicit notion of reading and writing. So hypermedia before the form tag, again, there was a bunch of different hypermedia systems, so I don’t want to say universally, but it was very tightly associated with the notion of navigation like clicking hyperlinks. But when forms came along and HTML 2.0 that really transformed the web as a hypermedia system, as a system built on top of hypermedia from a read only system, which is what it was initially designed as a way to share research documents at CERN into a potential web application or a potential application mechanism. And so we sort of stumbled around for the next 10 to 15 years figuring out, okay, how are we going to build web apps and model view controller, how does that apply to the web? And so on and so forth. So I think if someone’s okay, what is a hypermedia, what I’m going to tell them, the one sentence answer is it’s a media, something that displays media in some way that also allows you to encode actions in or control actions via hypermedia controls in it.
Sri Panyam 00:06:23 Interesting. Interesting.
Carson Gross 00:06:23 So, and that’s sort of what the web was. I’m so sorry, I got off on a tangent there, but that was the history of the web and then what HTMX does is it takes those ideas and sort of extends them.
Sri Panyam 00:06:33 So that’s pretty good context. How does that either relate or conflict with the RESTful approaches that Roy’s dissertation brought us 20 years ago?
Carson Gross 00:06:43 Yeah, so I think what you’re referring to is Roy Fielding’s famous dissertation at the University of Irvine, which gave us the term in chapter five of that dissertation gave us the term REST, which stands for Representational State Transfer. And that document, it takes a network perspective, a network architecture perspective and defines the RESTful network architecture in terms of a series of constraints. I have to say, I don’t think there was as much focus in there. I mean it was his dissertation, he was concerned about network architecture, just not his real thing. But I focus much more on hypermedia controls as the interesting part of it. And so basically in that dissertation he gave, there’s a series of five constraints, I think in a sixth optional one that define whether or not a system is RESTful. The most important of those constraints on a network architecture I think is what’s called the Uniform Interface constraint.
Carson Gross 00:07:39 And it’s the last one before the optional scripting constraint. Basically what he noted about hypermedia, one thing that’s interesting about it is because you encode the control actions directly in the media that are returned from the server, it has this very unique characteristic as just a way to build distributed systems in that client. And here client means browsers don’t need to know in advance how a website works. Instead they enter the website through URL and then as you interact with that website, all of the actions that you take are discovered through the HTML or the hypermedia is what I would say that is returned from that system. And so that’s called a Uniform Interface because the client, the browser in this case can interact with any website regardless of its domain. So if the website is a car sales website or if it’s a hospital or bank or if it’s a coffee shop or whatever, the browser doesn’t know any of those concepts.
Carson Gross 00:08:38 It doesn’t know what a coffee shop is or anything like that. And the network communications with that system are all done in terms of hypermedia. So this browser has this kind of crazy characteristic to it where it’s a universal client because there’s this hypermedia that provides a Uniform Interface to access that system. And another aspect of this that I think is sometimes overlooked with this Uniform Interface of hypermedia is that you can dramatically change a website. And if I go to it, I don’t need to update my app to use it, I don’t have to update to the current version of the API instead your website or web application, however you want to think about it just returns here are the current things you can do. And then I select the actions from those responses. And so the RESTful approach that Fielding was pointing out has this really nice characteristic where if you’re doing it properly, then you don’t have to worry about versioning your network API as much because just this nice characteristic of the Uniform Interface of hypermedia.
Carson Gross 00:09:39 It’s kind of ironic, I don’t know if you’ve read, I have an essay on the HTMX website called How Did REST Come to Me in the Opposite of REST? Because today if people use the term REST, they’re typically talking about Json format APIs and those are actually, they’re very unRESTful for the most part. And I don’t mean that in a moral sense. I’m not saying they’re bad for not being RESTful, but they’re just from a descriptive standpoint, they’re not, if you take the original definition of that seriously, mainly because they don’t communicate in terms of a hypermedia, which has this Uniform Interface aspect to it. So it’s interesting, if your listeners are interested, they can go read that essay on the HTMX.org/essays website. It’s called How Did REST Come to Me in the Opposite of REST..
Sri Panyam 00:10:23 In a way, I mean what I’m hearing is with hypermedia, it’s kind of user-centric in that the user or the client will come in there and do things on that site or on that application without necessarily knowing or needing to care about the modeling of those things behind it. Which sounds what REST might be more focused on.
Carson Gross 00:10:43 Yeah, that’s exactly right. Unfortunately I find it’s often difficult to communicate that properly to people because particularly when you’re, today we’ve specialized in many ways into sort of front end and backend. And so the front-end people think in terms of libraries like React and so forth, and the back-end people think in terms of what they consider an API and what they consider an API is typically what I would call a data API RPC style data, API maybe not RPC. There are RESTful aspects to it, but at the end of the day, they’re not returning hypermedia. And when you suggest, hey, here’s this other approach, they often are flabbergasted and say, that’s a horrible API because it’s my UI, I’m coupling my API to my UI. And they’re right, I mean they’re not wrong. At the end of the day when you’re returning hypermedia at some level, you’re returning the UI.
Carson Gross 00:11:36 So what I would say about that is it’s coupled at the application level. Now, on the other hand, I think one thing that’s interesting to think about is this fact that the browser doesn’t need to be updated when you change your website if you use hypermedia. And so whereas if you’re using a Json API and you have an SPA or something like that, then you do have to, or maybe to make it even more explicit a mobile client, a thick application that’s talking to a Json API, if you change your Json API, you have to change your client too. And so at some level, those two things are actually more tightly coupled. They’re more tightly coupled than the pure web application is. I think I don’t want to put words into his mouth, but the way I interpret Fieldings, the way Fielding talks about this stuff, and certainly the way I think about it is that what is happening there is that REST decouples client and server at the network architecture level, not at the application level.
Carson Gross 00:12:34 And so you couple yourself more tightly at the application level, but by doing that you actually decouple lower down. And so you get this nice characteristic where if you change what your endpoints return, then to a first order approximation anyways, you don’t have to update the client, the client being the browser in any major way. I think that’s an interesting sort of, for the listeners of this podcast that are interested in software engineering, I think that’s an interesting thing to think about because it appears that there are different meanings of coupling and the fact that when you change a Json API, you have to change the client, even though the Json API feels more generic at some level implies there’s some coupling going on there, right? That’s sort of the definition thereof. And so I think it’s something that software engineers should think about because it’s just an interesting characteristic of REST.
Sri Panyam 00:13:22 Richt, no that helps with the context of HTMX. I mean, so it’s, how does HTMX take this and extend it and what was the origin story of this?
Carson Gross 00:13:32 Right. Origin story is actually very practical. I was trying to sort a table and I was doing it in 2010, so a long time ago. And I was doing it in JavaScript on the client side because that’s what all the cool kids were doing at that point, I was using jQuery and I was just having a bear of a time making it go fast enough. And I just couldn’t on the browsers of the time, which didn’t have the highly optimized JavaScript run times that we have today, it wouldn’t sort quickly enough. And so out desperation, I tried this trick that jQuery had a method, I think called Load, I think on jQuery. So if you’re an old jQuery person, you can look that up. And what that does is it takes a URL and then puts the result into an element in the DOM just issues an HTP get request and then puts it into the DOM.
Carson Gross 00:14:19 So I tried that again, just sort of out of desperation, and lo and behold, it was instant. I could sort it quickly. And I think that was an artifact of the JavaScript runtimes of the time. Everything was kind of bad this, way back in the day, but I found out you could do that and was oh, this is cool. And so I started building up some tools around that method. And then I saw, I don’t know how familiar your listeners are with web development, but Angular 1.0, when Angular 1.0 came out, they used attributes and HTML to drive behavior. And I didnít the way that they were doing it, but I like that idea of, let’s use attributes. That’s because oh, okay, I have an H wrap and an anchor tag and now I’ve got my own little thing that does something different.
Carson Gross 00:15:00 And so I started mixing sort of these ideas together into a helper library that I was using. And then I eventually released that helper library is a library called Intercooler JS. And that was in 2013 is when I finally released it. And when I did that, I started getting people emailing me and saying, hey, this is cool, this is RESTful. And at the time, I didn’t understand REST, nowhere near as well as I understand now, I hope anyways, as I understand it now. But I went back and I’d read Fielding’s thesis, but not that much. And I didn’t understand a lot of it. I didn’t understand what the Uniform Interface was, but I over slowly over time recognized, oh, okay, this library is actually, it’s RESTful. I would go further and say it’s hypermedia oriented. that’s what makes this library distinct from other options.
Carson Gross 00:15:47 Like say, React or Angular was the big thing at the time or whatever. And so what I came to understand, and if you go to the HTMX org website, you can see sort of in the introduction, what I came to understand is that an HTMX, I’m sorry, I should just mention HTMX is a rewrite of jQuery, or excuse me, of Intercooler inter JS. Because Intercooler JS depended on jQuery. So HTMX is a standalone library. It doesn’t depend on jQuery because the JavaScript runtime, they come so far. But if you go to HTMX.org and you look at the introduction, there’s sort of a motivation part of it. And the idea is, so if you think about hypermedia in terms of hypermedia controls, we really only have two that we can build things with, right? So links and forms, I think it’s a testament to how powerful hypermedia is that we could build so much of the web with just those two things.
Carson Gross 00:16:39 The first 15 years of the web, that was pretty much it. There was some JavaScript coming along and we built quite a bit of useful functionality with just those two hypermedia controls. And so what HTMX says is, okay, why should only anchor tags and forms be able to issue HTTP requests? There are two elements, but what makes them special? There are other elements that you might want to issue a request based on. For example, a button is an obvious one. why can’t buttons issue requests? Also, right now, the way the HTML specification works, you can only issue what are called GET and post style methods. And so HTTP itself, the protocol actually supports additional HTTP methods. So thereís a delete request and there’s a put and a patch. There’s, you have these other options. And so HTMX says, okay, not only can anything make a request, but also, they can make any of these types of requests.
Carson Gross 00:17:35 And then finally, the sort of last big piece of the puzzle is why should, when you submit a request, why should you have to replace the entire viewport? So why not make it so that rather than replacing the entire viewport, we can just replace some chunk of the current document. That’s actually not a new idea that’s called trans exclusion. It’s been around for a long time. So there’s a lot of academic work in the hypermedia world around that notion. And it actually exists in HTML, believe it or not. So there is an attribute on links and forms called Target, and you can use that attribute to target an iframe and only an iframe, which is interesting. But it really, it makes it a limiting, a pretty limiting thing in the overall scheme of things because iframes, for better or for worse of just kind of, they have this historical baggage associated with them.
Carson Gross 00:18:27 And so what HTMX says is, okay, anything can issue an HTTP request. It can be any kind of HTTP request. And then in addition, the hypermedia that comes back, and this is a big distinction between HTMX and say React, is HTMX expects HTML to come back from the server, that HTML can be placed anywhere in the DOM. And so there’s a couple of ways you can specify exactly how that happens. Oh and excuse me, I missed one other concept earlier. There’s also the notion of the event that triggers the request. So when you’re talking about anchor tags or links click triggers that interaction and when you’re talking about forms, a submit action triggers that, well, there’s a bunch of other actions or events that occur in an application that you might want to have some interaction with the server.
Carson Gross 00:19:16 And so, HTMX also makes it possible for any action to trigger a request. And so that ends up being the sort of four generalizations of HTML that I talk about. So any element can issue any type of request in response to any event, and it can place the response content anywhere in the DOM. And so kind of, this might come across as arrogant, but I to say it completes HTML as a hypermedia and that it sort of fully generalizes this notion that I think is super important of hypermedia controls in HTML. So that’s the sort of philosophical basis of HTMX.
Sri Panyam 00:19:50 Right. Again our listeners are quite familiar with frameworks React and View and, so-called modern Sure frameworks. Right now, obviously there’s a server-side focus to HTMX and there’s a large client-side focus to these frameworks. But beyond that, at a deeper level where do you see the diversions? Where do you see the compatibility? Where do you see the, you know.
Carson Gross 00:20:12 I think the big thing is really hypermedia, I’ll keep saying it. And that’s one, again, my reason I’ve really focused on it. My essays page, I have a lot, and I’ve said this on other podcasts, I think the essays page is probably more important than HTMX as a library in the long run because, just because it’s got a lot of ideas around hypermedia and it really is a different way of building web applications as Fielding noted in his dissertation. It’s a different way of building applications. The hypermedia systems work differently than non-hypermedia systems. And I would say a lot of the web applications that are being built today use thick JavaScript style. Talking to a Json API, it’s funny that some level, those actually are more the 1980s thick apps that we did, right? JSON is the new CORBA or whatever is the new data exchange standard that we have.
Carson Gross 00:21:02 And it, yeah, it’s very loose and whatever, but the way those applications work with the backend is much more a thick application from the 1980s than it is a web application from say the 1990s or early 2000s, the sort of traditional web application. Again, I don’t want to criticize people for going down that when it first happened, it was because the hypermedia approach with only links and forms had a lot of usability issues. I don’t know if you remember old online email clients where every time you clicked a button, it was a full-page refresh and it was, you had to wait, and a little dinosaur came out and did a cartwheel around a star or something that. And it was charming in its own way but does not have the sophisticated feel of a modern application to it.
Carson Gross 00:21:47 So people very reasonably said, okay, well JavaScript is here, and then Json and Ajax, the technologies that sort of form the basis of a lot of applications today came along and they said, okay, now we can achieve better usability. We don’t have to have this big chunk or whatever every time I want to do an action. So that was reasonable. But when that happened, we also, and I think at some level inadvertently sort of left behind the advantages of the hypermedia approach. Because it just, we were going back to a more fixed style apps. And so HTMX, what it does is for a certain class of web applications, it allows you to achieve a better user experience while still staying in that original hypermedia model. And so it’s not a good answer for all applications because hypermedia isn’t a good answer for all applications, but I think it does significantly increase the number of web applications that could be built using the hypermedia approach. And I also, just, as an aside, I think the hypermedia approach is interesting technically. So even if you’re not sold on HTMX, just understanding the engineering aspects, particularly the Uniform Interface and this idea of decoupling at different levels, I think is worthwhile for web developers.
Sri Panyam 00:23:04 Right. Before I dive into the internals, I mean, something I wanted to ask later, I can ask that now. When would HTMX not be suitable or not be the most ideal choice for you?
Carson Gross 00:23:15 Yeah, I’ve got an essay up called ìWhen to Use Hypermediaî I believe, where I go over some when is it a good idea, when is it a bad idea? But basically if you have interactions that drive a lot of requests, like really fiddly interactions. So an example application is Google Maps, where dragging a mouse implies a bunch of UI updates. That’s something that you don’t want network latency to be hitting every time someone moves a mouse. That’s just not a good user experience. And so that’s probably something that wouldn’t be a good application to address with HTMX. I do think you could maybe do the settings page for a MAP application in HTMX where it’s just a more traditional, here’s a bunch of toggles and inputs or whatever and then the user fills them out and click save. That could be done very effectively.
Carson Gross 00:24:03 And that’s sort of in my mind the ideal application for HTMX is that sort of form driven applications because there’s a lot of think time and the user interacts with things for a while, interacts with local controls for a little bit and then click save and they’re okay because they’ve done a bunch of work. So they almost feel better if it’s not instant. I don’t know about you and your listeners, but I’m not a big fan of setting pages where there’s no save button where itís you just set it and then did it save, did it change? Am I good? Do I leave? What’s going on? That’s an example where it’s not even necessarily application versus application, it could be as simple as just what’s the feature I’m currently working on where you might choose hypermedia over a more sophisticated client approach.
Sri Panyam 00:24:46 Sounds good. Sounds good. I was thinking more about the HTMX attribute set, right? To help control a lot of the client-side behavior and interactions, but there’s also a big focus or big advantage of using HTMX from the server- side perspective. From the backend perspective. Can you talk about how HTMX integrates with the server side of the application development pipeline?
Carson Gross 00:25:08 Yeah, so one thing that’s different about HTMX is that it puts a tremendous amount of focus on the backend because the backend is producing the UIs for your web application. Now the backend becomes a much more sophisticated, a much more integral component to your application. You shrink down the amount of code that’s in the front end and that code tends to be an HTML, which you don’t write. And again, I’m sorry to jump around a little bit here, but HTMX, you don’t write JavaScript for the most part on the front end. When you’re just using the straight HTMX functionality, you’re typically just putting attributes on HTML to say, okay, this button issues a request to this URL and then takes the result and puts it in this place in the DOM, simple things like that. And so what that does is it puts a lot more logic on the backend in particular, if you’re familiar with older web development, you go back to templating or some sort of HTML building tool technology on that, your front-end gets built on the backend.
Carson Gross 00:26:07 And because of that, what that means is that a lot more of your code is going to be written in whatever backend language you’re using for that system. So if you are a Go programmer, then rather than having a large JavaScript application that talks to a maybe medium sized Go application, what you’re going to have instead is a large Go application that uses maybe Go templates or something that to produce HTML. And then everything kind of lives on the backend or it feels much more backend focus. And I think that’s a good thing for the following reason in particular, first of all, let’s say a couple reasons. First of all, if you’re a Go programmer, switching back and forth between Go and JavaScript probably isn’t something you want to do a ton of, you’re going to have to do a little bit of it, but HTMX will help minimize that.
Carson Gross 00:26:53 So you can really focus in on the backend in a much more focused manner. And the other thing about it is that because you don’t have a large JavaScript application on the front end, something that you’ve seen in the last 10 years is tremendous pressure to adopt JavaScript on the back end because then you’re using one language. Why would we have, if we’ve got a big JavaScript system on the front end, why would we have Go or, whatever on the back end. So if you use HTMX, it takes that pressure off because you don’t have a big JavaScript on the front end. What that does is it opens up the potential backends, I think in a way that if you adopt a large JavaScript framework for your front end, you’re going to feel this pressure, why aren’t we using JavaScript or at least type script on the backend?
Carson Gross 00:27:38 And with HTMX you don’t have that pressure. And I that because I teach the compilers class at Montana State and UI programming languages and lots of different programming languages and the cultures that grew up around them. I felt it would be a shame if the JavaScript juggernaut kind of steamrolled all these other languages just by being, having the advantage of being there on the browser side. And so I think HTMX helps address that and can help people if they want to use a particular programming language, they can use it on the server side. It does push a lot of problems that you have on the front end to the back end. So how do we compose UIs for example? A lot of people who are used to React are used to React components. So the way you can address that is via UI reuse on the backend, which if in a traditional templating system that might be in template inclusion, but their backend component systems that are growing up as well. So it just, it shifts your problems to the backend, which I think is a good thing. Everything else being equal, it’s better to have your problems in one place rather than two places. But that’s maybe a subjective claim.
Sri Panyam 00:28:41 Fair enough. I mean I certainly have felt this problem where this is pressure to kind of use the one language that’s decided by what’s in your front end, right? And it can get a bit uncomfortable.
Carson Gross 00:28:51 Right.
Sri Panyam 00:28:52 One thing here in this pattern, how this differs from the BFF patent, the backend for frontend patent.
Carson Gross 00:28:58 Could you give me a quick over, so I’ve heard BFF before and people have come at me with the term before. Could you give a quick overview of it so I can, I just want to make sure I don’t, I feel I understand what it is, but I don’t want to speak incorrectly if I have a bad understanding of it.
Sri Panyam 00:29:13 My understanding, my limited understanding is that just you’d have your data layer and your application UI layer, you might have a layer or an API that determines what the UI model should look like. If a forms page needs an object list, three, four entities, it’ll be the collecting layer for the front-end.
Carson Gross 00:29:32 Right. Okay. Yeah. My understanding of it, again, I’ll just lay out if I’m addressing the wrong thing, I apologize, but this is what I’m going to try to address my understanding of backend for front end is the idea that there’s backend code that is tied to your front-end needs in the form of objects that maybe model it. And then also you see this idea that you should split your application API and your pure data API up. Right? They should be two different endpoints. So general purpose people who want to consume a general-purpose data API have one set of endpoints and then your application has another set of endpoints. And I think HTMX speaks to that in the following way. First of all, I agree that you should have your web application API and your Json, your data API split up into two separate components.
Carson Gross 00:30:19 And I will say further if it makes sense that your application API should maybe be in terms of hypermedia using something HTMX because hypermedia makes a bad general purpose data API, you don’t want to be pulling down HTML from some website and trying to figure what the HTML is. That’s just not what it’s designed for. So I think the reason you see people advocate for the split though in the Json world, even if you have Json APIs, there’s this pressure for this split between what my application’s doing and what the general-purpose data API is. I assert that that is there because there’s a fundamental tension between your application needs and the needs of general-purpose data API. So general purpose data, API needs to be stable number one, right? Because people use it and so that’s why they’re typically versioned and so forth.
Carson Gross 00:31:07 So it needs to be stable, it needs to be general, it needs to provide general data access to whatever possible reasonable needs might occur. It also needs to have things rate limiting. You don’t want to let someone just hammer on your data API and so forth. On the other hand, the application API tends to be much more churny because your front end changes so dramatically and so quickly. And furthermore you have specific needs for a particular UI and implementing the fetches against a general-purpose data API that might be necessary to get that data could be really expensive when instead what you could do is on the backend, sort of collect everything that you need for the UI and just send it back in one chunk. But you don’t want to do that in your general-purpose API. because now it’s not general purpose, it’s for a particular UI.
Carson Gross 00:31:56 So I think what you’re seeing there is this tension between the need for a general-purpose API and the need to respond quickly and have very efficient queries for your UI needs. And I assert that in many of those cases, if you can get the interactivity that you need out of it anyways, using hypermedia for your application, API rather than Json will give you even more advantages because then with hypermedia you sort of have the ideal interaction with the server in that you issue one request and you get back the entire UI and that’s it. So you don’t have these chatty interactions where you’re hitting a bunch of different endpoints to wire together all the data that’s necessary. You also send the ideal amount of data on the response because you’re sending the UI, you don’t send any extraneous data.
Carson Gross 00:32:43 And so if you’re using a general-purpose data API, very often you’re getting back data that you don’t care about. You just need maybe a couple fields to build out a UI. And so, I think from what I understand of it, the backend for front-end idea is sound. I just would add, and by the way, the front end might be hypermedia and if you do that to me as an old school guy, I will think of it more as model view controller. That’s just, maybe I just grew up on it. I would just think you want to have two different controllers and then they talk to a model that represents your domain model and your data API, which won’t change very much because you’ve taken the application churns out of it can just work against a very generic model.
Carson Gross 00:33:26 Return table, just return things as JSON serialization is pretty simple. And then your application controllers can be tuned, and they can change a whole bunch as you change your UI because it’s a hypermedia API. So you’re not trying to satisfy two sets of people with it, you’re just, this is for your web app. And so I think it’s a good fit philosophically for that problem. I don’t know, again, the details of backend for front end I’m not super familiar with, but to me it feels a good fit for certain types of applications facing that.
Sri Panyam 00:33:55 No, you touched upon it pretty well. You talked about churny applications and that obviously brings us to managing state, right? Obviously in client-side heavy applications states kind of somewhat simpler to manage in one place. So this shift in burden, how does that change? How does that make it easier or harder? And what are the performance characteristics of this?
Carson Gross 00:34:14 I would take issue with the idea that it’s simpler, it’s a local cache, right? It depends on the application of course. But for most web applications, what you have, if you’re in an SPA and you or a Single Page Application, a JavaScript heavy application, you have a local cache of what the data on the server looks like. And your listeners are probably familiar with the adage that there’s only two hard problems in computer science, right? Like naming and cache invalidation and off by one error. And so cache invalidation isn’t trivial, it’s not trivial. And one of the dramatic simplifications from a distributed application standpoint of hypermedia is that the hypermedia, there’s a term for it, hypermedia is the engine of application state. And so you have a representation of what was on the server when you made the request, but that’s it.
Carson Gross 00:35:01 And so all the state is actually encoded in the hypermedia. So I think, again, I don’t have a ton of experience building super complicated single page applications or JavaScript heavy applications. But I understand that that’s, it can be tricky to what do you do when the server gets out of sync with the clients and how do you reconcile those things? Those are hard problems that to an extent or diminished when you go to a pure hypermedia model and you just say, look, the server is the source of truth and you’re going to make a request, we’re going to respond with the new state of the system and that’s it. So there’s a big simplification from state management when you adopt hypermedia, there are disadvantages as well. So you have to make a server round trip to indicate, okay, I’ve updated the state, what do things look?
Carson Gross 00:35:46 And that’s in contrast with a JavaScript based application where you might update the UI immediately and then make a request and wait and then that request will update the server later. But I would point out in that case that’s called an optimistic update. I would point out that when things go wrong, that’s good in on the happy path, but it’s bad on that sad path where maybe that update couldn’t occur for some reason. So an example I often give is, and because people complain, oh, hypermedia-based applications, I can’t buy a ticket on the subway because the signal goes away or whatever. I say, okay sure, but at the same time do you really want to be told that you got a ticket and then find out later on that you didnít get a ticket? Because it seems the source of truth for whether or not you got a ticket on that thing or to that concert or whatever, is really on the server.
Carson Gross 00:36:35 And even if you just cash that request and wait till later, what if your phone dies and you think you’ve got a ticket or whatever. It’s all trade-offs. There are certainly trade-offs associated with hypermedia. I think it does lean on the server more heavily and on view operations in particular, if every single interaction causes a get request and those get requests are slow, then the application is going to feel slower. On the other hand, a hypermedia-based application doesn’t require that every click actually interacts with a server. So a good example of that, if you’re familiar with the details element in HTML is a details element is it’s just a standard tag in HTML. If you click on it, it’ll expand a detail section. And that’s an example where an interaction, a click is not, even though it’s still hypermedia based, it’s not interacting with a server there. And so this idea that every single interaction has to have some sort of server request is not true. What is true is if you update state, if you update the state of the system, then that should be done via hypermedia request with the server. It’s kind of a subtle distinction and it’s one thing that’s a little frustrating when I talk with people is that I really try to, there are a bunch of tradeoffs here.
Sri Panyam 00:37:48 It’s interesting because one of the clear tradeoffs is how much interactivity you want and how much consistency you want tradeoff for that. Right? The example of the fully SPA application where you optimistically update the state, you could be wrong only to be finding out about it much later on in some other way. Right. And again, going back to how this affects performance for example where is the performance shifting? Who are you robbing to pay for who?
Carson Gross 00:38:12 Yeah, a hundred percent. And again, this is an area where I do sometimes get a little frustrated because my experience with single page applications has not particularly in the presence of unstable network connection has not been uniformly amazing. Yeah. I’ve seen plenty of spinners in single page applications in my life. So okay, you can put a spinner on a page as well. HTMX has support for what are called request indicators. You can put a spinner on a request just as easily in the hypermedia approach as you can in the single page application approach. And so I feel their tricks, yes, if you need to be off, if your application absolutely has to work offline, then the hypermedia approach probably isn’t a great one for it. But people have remarked and actually a part of our essays section has some examples of people that have moved from React to HTMX and had much faster applications with much lower memory usage and so forth. And so I think the simplicity, what makes something fast being simple, right? More complicated, you make it the slower, it’s just inherently going to become. And so the simplicity of the hypermedia model I think helps in that regard.
Sri Panyam 00:39:22 Okay. What about browser support and compatibility? I think you mentioned earlier HTMX is trying to evolve HTPO of sorts, right? Right. So how should we think about this?
Carson Gross 00:39:33 So HTMX is interesting because HTMX, it’s currently in 2.0 and in the 1.0 line we still support Internet Explorer 11. And so there was for a long time in the project and almost sort of stubborn weíre going to support the old stuff because no one else is doing it. But in 2.0 we said, okay, look, Microsoft declared Internet Explorer dead, we’ll stop doing that and we’ll simplify some of the stuff, simplify some of the implementation hacks that we had to put in that work around Internet Explorer shortcomings. So at this point I would say HTMX is, it’s very compatible. The 2.0 version is very compatible with the vast majority of browsers that are out there. On the other hand, when new features come down from the browsers, HTMX tends to introduce them but not necessarily make them the default. And so there’s a conservatism to HTMX when it comes to adopting new technologies because, and the reason for that is, I think the core idea of generalizing hypermedia controls is that’s what HTMX does.
Carson Gross 00:40:37 People have tried to push HTMX in different directions. Oh it needs to handle this and needs to handle that. And I’ve really tried as much as I can and I haven’t always been successful, but I’ve tried to keep it really focused in on just generalizing hypermedia controls. So I think that makes it a more conservative with respect to the newer browser features, it makes it more conservative in that regard. And that probably lends itself towards backwards compatibility. So someone can pick HTMX and be pretty confident that almost any browser they’re going to encounter in the wild is going to work with it.
Sri Panyam 00:41:08 Can you give an example of one of those things that’s in high demand but you’re being cautious about it and why?
Carson Gross 00:41:14 Well, I would say, well it’s a good example view, if you’ve heard of the View Transitions API, which came out about, I think about a year ago in the browsers?
Carson Gross 00:41:23 Yeah. So View Transitions are a new API for basically taking one UI and then transitioning it as the name suggests, into another UI. And HTMX supports that you can use them, you can turn it on in HTMX, but it’s not available in Firefox. And so we don’t use it by default. So you have to select to use it. Instead HTMX uses CSS transitions, which have been around forever and are supported in all the browsers and there’s a bunch of code which is kind of junky, you have to admit making that work, to make CSS Transitions work because they don’t work easily unless you do some additional work. So that’s a tradeoff that HTMX would make is, okay, let’s support, we have this kind of, okay, it’s a little crazy internally the way it works, but for the end user it makes CSS transitions work properly without them having to think about it. Versus tearing that out and saying, okay, use view transitions and start yelling at the Firefox people to support it.
Sri Panyam 00:42:22 Interesting. Looking at couple of advanced features, to understand out of bound updates a bit more and what security implications are and what should be developers think about and how.
Carson Gross 00:42:34 Yeah, so out-of-band swaps are an interesting idea. I just sort of came up with them and they’ve taken on a life of their own. There’s a lot of features in HTMX that people either love or hate and out-of-band swaps, I feel a lot of people love or hate HTMX. It’s an interesting psychological aspect of HTMX is that there are a lot of people that love it and there are a lot of people that hate it. So not too many people that are indifferent towards it. But even within HTMX there are features that a lot of people love and a lot of people hate. So I don’t know what the situation is, but out of band swaps, what those are the normal sort of functioning of HTMX, here’s how a user would use it. They’d have a button, they put an attribute HX get for example slash ToDo slash one to get the first ToDo.
Carson Gross 00:43:22 And then they’re going to have another attribute on that button that says, okay, HX target equals say hash output. And what that’s saying is, I want you to take the result of the HTTP get request to that URL and I want you to put it into the element with the ID output. That’s what hash, that’s a CSS selector if you’re listeners are familiar. So that’s what it’s going to do. What out of band swaps let you do is when you make that request and you go and you get some content and you put it into that output element on the page, they let you also include another thing or not many things, as many things as you want. Basically additional elements that will be swapped into based on their ID or, and you can use a CSS selector again for this and the stuff that will be updated is elsewhere in the document.
Carson Gross 00:44:09 So you sort of break this direct relationship between the button, the request and the target and you allow people to start sending content to random places on the UI. And what I about that is that it obviously increases what you can do with a single request because you can piggyback on these other updates with the request. What I dis about it is that it makes it harder to understand what the hell is happening because you’ve got the main content coming down and then this other content that’s being squirreled away in different parts of the DOM. But it is a very powerful mechanism, and it lets people continue to use the hypermedia approach in situations when if they didn’t have out-of-band swaps, they would probably feel pressure to adopt a reactive approach in order to update more than one place at the same time. So to give you a sort of a canonical example of when you would use out-of-band swaps, if you want to update, we just said, you want to get a to do and put it in some element somewhere on your UI, and at the same time you want to flash a message to the user.
Carson Gross 00:45:10 So you might send a flash element in the response as an out-of-band swap and that’ll pop up and maybe show for 10 seconds or something that. That’s sort of a canonical usage of out-of-band swaps. So it just allows you to update more than one place at the same time with a single HTDP request.
Sri Panyam 00:45:27 Almost like firing off a Go routine to do something.
Carson Gross 00:45:30 Yeah. I don’t know. I have to admit, I don’t know Go routines, I don’t know Go that well.
Sri Panyam 00:45:34 No, no.
Carson Gross 00:45:34 No. I’m ashamed to admit I’m a Java program.
Sri Panyam 00:45:36 No, no, sorry, sorry. So, youíre firing off a new Java thread and not worrying about what it’s doing?
Carson Gross 00:45:42 Yeah, itís whatís a good metaphor for it? Boy, it’s hard. It’s if you were sending a present to your aunt and you included a bill for your uncle or something, I don’t know, I’m struggling with a good metaphor here, but it’s very useful and I’m always, I said, I’m a little uncomfortable with it because it breaks the traditional model of a hypermedia control makes a request and updates one thing, but it’s proven useful.
Sri Panyam 00:46:06 So can these outbound updates trigger further updates? Like kind of a graph of updates?
Carson Gross 00:46:12 Yeah, they can. And that gets it the fact that HTMX is event driven. So you can listen to events and, if something updates, you can issue another request. The content that comes back can also inside of it have additional HTMX code. So a really basic use case for HTMX is you have a DIV and that DIV has an HX get to some URL on it and then the trigger is load. And what that means is put this DIV into the UI and then immediately trigger another HTTP request to get the inner content for it. And that implements a pattern called lazy loading, which can be really useful for making a response fast, the initial response fast and then the thing that takes longer you can have a spinner and show the user, but the user can interact with the content sort of right away.
Carson Gross 00:47:03 That’s a technique that is very commonly used in HTMX applications. So that’s an example of something you could do an out of band swap with something that then has lazy loading inside of it or infinite scrolls and other things you can implement with HTMX, interesting, whatever. So yes, those events can then trigger further requests very easily. There’s also, a way to actually trigger using HTTP headers to actually trigger events on the DOM and that you can listen for those and trigger requests as well. It’s really is a Swiss Army knife of hypermedia. There’s a lot of ways to skin a cat. It is very unopinionated, which some people donít because you have to kind of figure things out sometimes. How do I want to do it?
Sri Panyam 00:47:42 Is there a risk of this triggering infinite updates or infinite triggers? And is there anything you can do to kind of put correctness checking in this somehow?
Carson Gross 00:47:51 Yeah, yeah, there is for sure. One thing that you’ll often see when people first start out with HTMX is they’ll have a button and then they’ll click the button and then they’ll get back an entire webpage and now the entire webpage is inside the button and the button looks ridiculous. Yep. So there are dangers. It’s not a strongly typed, hypermedia is not strongly typed. And I think it some level you just have to accept that there are systems that are in place to do static verification of not only HTMX but just hypermedia links and forms, which have to an extent the same problem. I mean, you’ve probably been in an Infinite Reader Act loop at some point in your life but if fundamentally I think you have to accept a little bit of this is just, you got to do it right. So
Sri Panyam 00:48:36 Yeah. Itís just software engineers being software engineers.
Carson Gross 00:48:39 Yeah. Just got to do it. Right.
Sri Panyam 00:48:41 I want to jump into some real-world implementations success stories that you heard of what challenges they might have faced, what the impetus was. Are there stories you want to share?
Carson Gross 00:48:52 Yeah, thereís the story, the whole reason HTMX started getting popular was because of a talk that was given in I think 2022 at Django Con Europe. So Django for listeners that don’t know is a web framework, very popular in the Python world, and an engineer at a company, a French company, gave a talk about HTMX called from React HTMX on a real-world SaaS product. We did it and it’s awesome. And as the name suggests, they had a really good experience with this. So they’re a news site its context is the name of the company in France. And they had a react based application that they were building to show news items with some pretty sophisticated filtering and so forth associated with it. And they were in a bad spot. They had a team of five or four, but they had one front end developer and then sort of a lead developer and then two backend developers, if I’m understanding correctly, how their team was laid out and they were really struggling.
Carson Gross 00:49:52 They were not making progress. The application was pretty slow, and the lead engineer decided, hey, I’m going to try HTMX. So he tried to use HTMX for it and I have to say in advance for listeners, I don’t want to oversell HTMX because their application was ideal for HTMX. They’re a mostly text and images sort of orient. I mean that’s media. This is Hypermedia wheelhouse. And so them using HTMX really, was well suited for their particular use case. But they did a rewrite of the React app and it took them two months. They had the same user experience that they had with their React application and they reduced their code base size by 67%. So two thirds of their code went away. That went from 21,000 lines of code down to 7,000 lines of code. So just a massive reduction in complexity in the overall.
Carson Gross 00:50:44 So there’s no way you can lose that many lines of code and not just have a huge weightlifting off your chest. They reduce their JS dependencies. So HTMX has no other dependencies. You can use it without even using node package manager or anything that if you want. So they reduce their JS dependencies from 255 dependencies to nine. They reduced their build time for their web app from 40 seconds to five seconds. Their first time to interactive went from two to six seconds down to one to two seconds. And the way their application works is people often click a link and go directly to a particular deep. What sometimes people call deep links to a particular page or URL in their site. And so that first time to interactive is really important for them. That was a very big deal to them.
Carson Gross 00:51:29 They also were able to handle much larger data sets because they were relying on the browser to show a table or a list or whatever, instead of React, which, is trying to synchronize a shadow Dom with the normal Dom and just has a lot more stuff going on. And so by just relying on the browser, they were able to show a lot more data to their users, which led to a better user experience. And then finally, the last sort of bullet point that we’ve got up on the website is they reduced the memory usage of their website by 40%, which is a big deal as well from a performance standpoint. So it’s a very dramatic success with HTMX and it is moving from React to HTMX. But I want to temper that by saying their application was very amenable to the hypermedia model. And so what I think that indicates is that there are a lot of people think when you do a web app, you have to use React, and that’s not true. There’s a large class of web applications that can be addressed very effectively and often in a much simpler way using the hypermedia approach. So that’s an example of a pretty big success.
Sri Panyam 00:52:30 Great. I mean, for teams looking to adopt HTMX and obviously replicate the success of this company, what would be some of the migration strategies that can help them be successful and avoid pitfalls?
Carson Gross 00:52:42 Yeah, well the first thing I’d say is don’t switch to HTMX just because you heard me talk about it. If React is working for you, stick with what you got. So let’s talk about non-technical things to consider. First of all, if you have an app that’s working, don’t change it. If you have an app that’s not working, okay, maybe now it’s time to start thinking about whether or not this other approach will help. The reality today again from a non-technical standpoint is that the standard front-end technology is react. And if you’re concerned about hiring and you want to make sure that you’ve got a good pipeline, a lot of people that know the technology then react is no one ever got fired for using React at this point and HTMX is very simple to learn.
Carson Gross 00:53:25 Most mid to senior developers, even very junior developers, I think can pick it up pretty quickly. But it’s much less opinionated. And so depending on what your backend is, you may have to figure out the patterns that make sense for your particular application. And so there’s a little bit more freedom and with freedom comes danger there and then unfamiliarity. And I hope that’s being addressed because HTMX is getting more popular. HTMX won the JavaScript Rising Stars for web frameworks last year. So we actually finished ahead of React and the number of stars on GitHub for as much as that’s worth. But it’s a big deal to me. So I think it’s starting to get mind share. We have a book called Hypermedia Systems that’s at Hypermedia Systems that’s available online for free to help people learn that stuff. But I don’t want to say, there’s danger there.
Carson Gross 00:54:11 It’s not the standard. And so anytime you’re not using the standard, you’re taking a little bit of a risk. One advantage I think to teams is if the team wants mainly to be full stack developers instead of having this front-end backend split, then HTMX can be a really good choice because HTMX moves the front-end generation to the backend. And so your developers become much fuller stack. I often say I think the most powerful HTMX developers in the next few years are going to be people that understand the web. So front end type people but who also know how to use SQL because thatís the most powerful technology on the back end. And if you can tie those two things together, which you kind of see them trying to do with GraphQL, but they can’t quite do it because you just can’t give SQL to the front end.
Carson Gross 00:54:58 You just can’t do it. But if you’re generating your front end on the back end, you can use SQL to do that. And so you can have access to both these very powerful tools. So I think that’s another thing that they note when they transitioned at Context Day from React to HTMX, is that everyone on the team became full stack. And there’s a big advantage to that sort of, and again, not technical necessarily more sociological, which is that people, they tend to own features rather than parts of features. So rather than a front-end person fighting with a backend person about an API change, they just do what they want. They’re writing SQL, they just change the sequel, you don’t have this, well okay, we’re going to get to that change in two sprints and then two sprints later oh, it’s got to slide another sprint.
Carson Gross 00:55:41 And at that point the front-end person has forgotten about the feature or whatever, you’re much more as an engineer in charge of a feature from full stack from the front end to the back end. And that can be a much more efficient way to work. So advantages there are advantages and disadvantages. I do want to stress that at this point, and I tell this to engineers too. Oh, should I learn HTMX? And I say, well if you want a job, you should learn React. Because React is the standard. But if you have a job or if you have a project and it’s not going well in React or you want to give another approach a try, then I think HTMX makes a lot more sense.
Sri Panyam 00:56:17 Fair enough. You mentioned HTMX, not being opinionated means that there’s a lot of opinions. So what are some of the good backend patterns or architectural patterns you’re seeing emerging that are showing promise?
Carson Gross 00:56:32 Yeah, I think the old patterns are good. The good old patterns that we used to have. So I programmed in Rails for a long time, Ruby on Rails, and there’s a real strong notion of models and views and controllers. And I think model view controller is a really powerful way to organize your software. So the ideas of hypermedia and the Uniform Interface I think are interesting. You kind of get them by default. That’s one of the nice things about if you use hypermedia, if you use HTML to be more concrete. I don’t know if you’re familiar in the 2010, for a while it was super popular to argue about whether or not an API was RESTful.
Sri Panyam 00:57:10 Yes, yes.
Carson Gross 00:57:11 I remember, I donít know if you remember this. So everyone, it’s not RESTful, it’s Level one, Level two, the Richard Maturity whatever. And to me that was all super alienating and it felt kind of puritanical. Oh, you didn’t do, oh, but then the nice thing if you just use HTML, if you just return HTML from the server, your API is RESTful just by default almost itís very hard to make it not RESTful. So I think that’s one of the interesting aspects about hypermedia is that it takes a lot of these things. They just evaporate. How are we going to synchronize backend and front-end state? Well we don’t. It just goes away. That’s a whole layer of code that you just toss, now there’s obviously that whole layer of code is doing something, so you lose something there and that something that you lose is that local cache of remote data and maybe the optimistic updates and so forth.
Carson Gross 00:57:59 And so there are trade-offs and I think you have to make some trade-offs when you’re building things with hypermedia. There are times when in many applications you might want to do it one way and you have to do it maybe not as sexy, not as cool away with hypermedia and accept maybe an additional request. Or maybe it’s a little bit you click a button to save instead of things updating automatically. Or whatever. But I think if you’re willing to do that, if you’re willing to make those trade-offs, then you can get a bunch of simplicity. You can get back; you can drop a lot of complexity. And any software project is, everyone listening to this podcast knows involves thereís a complexity budget and at some point, you’re going to go bankrupt with complexity and so, you need to be kind of frugal with what we’re going to spend our complexity on.
Carson Gross 00:58:46 And so being able to give up and just say, not give up maybe the wrong term, but to accept, okay, this isn’t going to be as cool as it might’ve been in React, but it’s good enough, it does the job. And because I’m willing to make that statement, I get back a tremendous amount of complexity that I can then put into say the backend code somewhere where it’s more effectively spent. Maybe it doesn’t matter if I can drag and drop contacts in this UI, although there are, you can do drag and drop in HTMX. There’s an example for that. But again, I think being willing to trade off a little bit of front-end sizzle for saving a complexity can be a very good trade off in many cases.
Sri Panyam 00:59:23 Would this be a software engineering general problem or eact versus HTMX kind of physician making thing, right? Where can something help you in advance know way? This complexity might be when picking between HTMX and React.
Carson Gross 00:59:35 Yeah, it’s hard I think, and maybe it’s an existential choice, right? Maybe you have to pick, maybe you have to pick to see the choice and I’ve seen people say this and I can’t say they’re wrong where they say, why would I pick HTMX when I might need react? And then if I do get into a position, I need react now I’ve got to rewrite it. And I would respond to those people in two ways. I would, number one, I would say, there’s the engineering principle, youíre not going to need it, right? And so in general, we’ve said before in computer programming, you shouldn’t worry about the future too much. Obviously, you have to make good architectural decisions in the REST of it. Again, I do have an assay where I try to lay out, here’s the shape of an app that’s probably going to be pretty good for HTMX.
Carson Gross 01:00:22 The second thing that I’d say to those people is that, to get back to what I was just saying, sometimes you can just say no, we’re not going to do that. I think front end people sometimes, and I don’t blame them, they’re focused on the front end. They really want to achieve a particular user experience. But there are times I think when you have to ask yourself, is that user experience so much better than just say a stupid form of the save button that it’s worth all the additional complexity to achieve it? And sometimes that answer is yes, and sometimes that answer is no. And if you’re willing to say no, then that again expands the class of applications that can be addressed effectively with HTMX and can save your complexity budget for other stuff. Third one is that you can use HTMX in combination with another technology, right?
Carson Gross 01:01:07 So HTMX is relatively lightweight and not hard to figure out. And I know people have used React or View, for example, I think Context Day actually uses a view for a rich text editor where they’re coordinated where itís an interactive text editor with two people editing the document at the same time. And so they said, this is too crazy to do with HTMX and I agree a hundred percent with that. So we’re going to use a View component to make that happen. And I think that’s absolutely the right thing. That’s absolutely the right thing. So these aren’t mutually exclusive approaches either. Now the counterargument to that is, okay, well now I’ve got two technologies that I have to understand. And I agree with that. At some point if you find yourself using React all over the place and just, you’re going to have to make a decision, okay, maybe we’ll just drop HTMX then. So it’s all trade-offs and I unfortunately, I don’t have a crystal ball, so I can’t even know a project pretty well, I can’t necessarily say that HTMX is going to be a hundred percent the right choice at all times. I do think it’s the right choice in more situations than most people suspect because I think most people underestimate what you can achieve with hypermedia and with HTMX at this point.
Sri Panyam 01:02:16 Going off from migrations and corruption. Right. How do you see the developer experience side of HTMX? I mean given simplicity where do you see the developer experience pain points are? Advantages are recommendations are,
Carson Gross 01:02:29 Yeah, there’s only 12 attributes, 12 million attributes to HTMX. So how much developer experience can you possibly have, right? But the major IDs are supporting it. There are language servers now for it and it has some syntax in some of those attributes. So, but I think the developer experience as it improves isn’t going to be an HTMX proper. HTMX proper is not going to change very much for the next a hundred years, I hope. But instead what it is going to be is it’s going to be improvements in server-side code for managing hypermedia. And so just as an example of tools that I think help, there’s a concept, again, I’m sorry to keep referring people to the essays page, but there’s a concept called template fragments. So a common way to build hypermedia systems in the past, right, was to have templates.
Carson Gross 01:03:19 And so you’d have some Java or whatever, Go has templates in it, if you’re familiar with Go, or Python whatever you’re using. And then you would have an HTML template, which was sort of an HTML file with some special syntax in it for doing loops or whatever. And one technology that we’ve sort of advocated people put in is a notion of template fragments, which is the idea that you’ve got a template, and you want to be able to mark a section of that template as this is a piece of template that I want to be able to render independent of the enclosing template. That’s really helpful, I should say for HTMX style applications. Because what it lets you do is have one template with all the stuff in it, and then you can sort of see everything in one place, right? You don’t have to get into this world where every single little snippet that you want to update dynamically has to get pulled out some other template.
Carson Gross 01:04:10 Now you’ve got to navigate back and forth and try and get into your head what’s going on. Instead, you can have one template or fewer templates anyways in the overall system and then use those snippets within that bigger template to respond to HTMX requests for a particular update or whatever. And so that’s an example I think of a tool that will improve the developer experience for HTMX. And I’m happy to say a lot of people have added this functionality to their systems because of that essay. So it’ll improve the developer experience in server-side frameworks, but it’s not really HTMX itself that’s changing. It’s instead thinking more, okay, how do we want to do things on the server side to produce hypermedia effectively? So that’s where I see developer experience going. And also for any listeners out there, I wrote a book on HTMX called Hypermedia Systems and it’s pretty philosophical, but it’s sort of in Python and it intentional uses a very simple web framework called Flask.
Carson Gross 01:05:07 But I think because HTMX is unopinionated, there’s an opportunity for a bunch of books that are more opinionated and are, here’s how to use HTMX with X. There’s a book out on how to use HTMX with Spring and Timely. But basically if you’re interested in writing a book and you’re passionate about a particular backend system, I think there’s an opportunity for pretty much every for every application or, application server or web server language pair to write a book on Here’s How to Use HTMX Effectively with this particular backend tool. And that’s a weakness to an extent of HTMX. It’s unopinionated, it’s a strength and a weakness. So it means anyone can use it, but it also means that you’re going to have to figure it out. How does your system work, you know?
Sri Panyam 01:05:53 Be the pioneer.
Carson Gross 01:05:54 Be the pioneer, be the change you want to see in the world. There’s a lot of good ideas. So I would highly recommend people even if they donít Ruby, to get familiar with Ruby on Rails. because there’s a ton of really good ideas in it. That’s a system that I would say has been really honed to a fine edge when it comes to producing hypermedia. And so I think there’s a lot of great ideas in there, Django as well. But again, there’s an opportunity there. But it’s also, it’s something that I think I just, I mean you have to admit, it limits the HTMX ability to sort of takeover in any particular area. So HTMX has done really well with Django developers. It has also done very well with GO developers. And I think that’s because the Django people already had everything, they needed except for a front-end system.
Carson Gross 01:06:36 Django had everything except for that. And then the Go people are so used to just writing everything from scratch because that’s just the Go culture that they were, oh cool, I can just write everything from scratch. I always do and do it my way. And so I think HTMX sort of resonates with those communities strongly because of that. I’ve had this interaction before online where a JavaScript developer who’s used to server-side JavaScript and all the generators and all the tools and you just type NPM, Run, make my app and it generates although they look at HTMX and they’re, where is everything? Well that’s not the idea.
Sri Panyam 01:07:11 Where are the batteries?
Carson Gross 01:07:12 Yeah, that’s not the HTMX thing.
Sri Panyam 01:07:15 I mean, I can resonate that coming from a Go Ecosystem. Looking at the community in the future and obviously the growth, that’s been phenomenal. How has this ecosystem grown since you first released it and what are the trends you, you’re seeing in terms of the adoption and community engagement?
Carson Gross 01:07:30 Well, so it’s grown really, really rapidly, particularly since July of 2023 now. So in July of 2023, two online influencers, the PrimaGen and also Fireship dev PrimaGen has a daily show. He does development and so forth. And then Fireship dev, he does these sorts of 30 or I think it’s 90 seconds, I forget, it’s some three minutes as a very quick and very well produced introduction to some technical concept. And they both happened to cover HTMX. PrimaGen I would say more got into HTMX. Fireship dev covered it right at the same time. And that happened to be right when we released our book, which was dumb luck because that book had actually, we had been in contract with a publisher to publish it and they had canceled right at the end they canceled it.
Carson Gross 01:08:21 And we were, oh man. So we had gone back and rewritten it. So the whole timing was just extremely dumb luck. But it worked out so that there was a huge boost in interest. And you can see that if you go look again the way I, for better or for worse, I use GitHub stars to think about the popularity of something. And there’s definite Elbow in July of 2023 where it just started shooting up. This is a serious podcast and I have to admit my online behavior can, there were a lot of antics and I enjoy that, but I also, I can’t necessarily recommend it for everyone, but that has turned out to be very effective on social media for the last year and a half. And before that, maybe let’s say the last two years in getting attention and so forth.
Carson Gross 01:09:07 And I actually, I gave a talk at Big Sky Software called a Theory of Open-Source Marketing, where I sort of talk about my experience of going through that and just what happened, how did this happen and some ideas. So listeners can go and check that out if they’re interested in, in more on that. But I would say the HTMX, the vibe is very lighthearted and lightweight, which is a good thing. And that’s in general my approach to life. I don’t take things super seriously, but at the same time, I do have a paper that was a CM published paper on hypermedia controls. And so there’s a mix of serious content and joking content that I think has been very effective for HTMX.
Sri Panyam 01:09:47 Talking about joking content, one of the criticisms of HTMX is that HTMX is really a big ploy by big HTML to take over, JavaScript frameworks. How would you respond to that?
Carson Gross 01:10:00 Right? They’re not wrong. Now that’s JavaScript is part of the web, I donít know, people have a problem with proportion, right? Everyone wants an either/or and they don’t talking in ends and there’s an essay again, I’m sorry to keep referring to it, but there’s an essay called Hypermedia Friendly Scripting. So scripting is okay, scripting is okay in a hypermedia driven application. So JavaScript is okay, what’s not okay, or what makes something less of a hypermedia driven application is when you start having side state that lives outside the DOM and is updated in some other way and whatever. So I don’t think HTMX is anti-JavaScript. I gave a talk at JS Nation this past November called HTMX’s Pro JavaScript, kind of saying how I feel HTMX can be interpreted as being pro JavaScript.
Carson Gross 01:10:51 And the core message there is that HTMX makes the amount of JavaScript you have to write much smaller, that makes each line of code of JavaScript more valuable, and therefore JavaScript is more valuable, but you are writing less of it in general if you’re using HTMX. But again, I love these discussions. I love the back and forth on Twitter is where I usually spend most of my time. But I have definitely heard criticisms that the antics on social media might hurt HTMX in the long run. Yeah and they’re probably right, but at this point the graph is going up until the right. So I don’t know what to tell people. And I tried to mix in the serious content with the jokes. I think you have to have both.
Sri Panyam 01:11:33 No, you got to have both.
Carson Gross 01:11:35 I couldn’t be a buffoon on Twitter only, and I couldn’t be an academic only, but I try and mix the two together. Seems, you know itís time.
Sri Panyam 01:11:41 You have a funny academic.
Carson Gross 01:11:43 Right well, humor, I mean, we all know it. Humor works itís very effective, right? This has been known for very long. I said this on the PrimaGen at one point, joking is no, what is it? Humor is not a joke, being funny is not a joke. You have to work at it because it’s a really useful skill. But anyway, I don’t want to.
Sri Panyam 01:12:04 As we get to the end, how can developers get involved? I mean, beyond just using it, how can they actually help it grow? How can they help contribute to it?
Carson Gross 01:12:11 The code base itself is pretty stable, so I don’t think direct contributions to HTMX are going to be, it’s going to be hard to do a direct contribution, particularly a big one at this point. We’re kind of in the sanding phase of the library and so we’re just trying to maybe sand down the rough edges. But I have seen people come in and do testing, more add tests that have been really effective. And I appreciate that. It’s one of the most valuable things you can probably do for software is add tests on the other hand, because HTMX is so unopinionated, again, there’s an opportunity for writing books, but HTMX and a preferred backend, a preferred technique that you’ve come across, but also building up libraries in languages that are designed to work with HTMX is something that someone could do.
Carson Gross 01:12:56 There are a bunch of those that are but I think there’s still a lot of opportunity around that. So I think those are the major ways if you want to contribute to it. But there’s also just reading the book, if you have a philosophical bent, understanding hypermedia, there’s always new ideas that can come out of, I really like this idea of going back and looking at old systems. There’s so much cool stuff from the seventies and eighties that people have forgotten about. And I think going back and looking at those old ideas, you can find a lot of really good inspiration. I’ve been on a kick, I’ve been reading a bunch of Nicholas Wirth stuff from the eighties and nineties. I don’t want to say I don’t agree with him. He’s operating at a level far beyond me. But it’s just really good to see someone really smart thinking about things at the level that he’s so.
Sri Panyam 01:13:44 Fair enough. Sounds good. Thank you. Do you have any closing remarks?
Carson Gross 01:13:47 Nope. HTMX.org is the website. It’s for frontend, hyper media driven frontends. There’s an essays page slash essays if you’re interested in more philosophical stuff. There’s a lore page, so slash essay slash lore if you want to catch up on the social media aspect of the whole thing. And Hypermedia Systems is the book. There’s a hard copy, a soft copy of a few different digital editions. And then it’s, you can read all the content online for free on the website. And also, we’ve uploaded the EPUB to LibGen, so you can find it on LibGen for free if you don’t want to buy it. So those are the main places I would point people. I guess one other website I should mention, just because some listeners might find it funny is Greg Brainin Dev. So that’s a web page really that I put up with sort of some observations about software development that people might find funny or infuriating or whatever. So
Sri Panyam 01:14:41 Thank you. Thank you, Carson for being on Software Engineering Radio. For our listeners, you can find the links to everything we discussed today, including HTMX aids documentation, community resources, as well as examples in the show [email protected]. Thank you very much for listening.
[End of Audio]
