htmx: a new old way to build the web

Hello, everybody! Another week. First – actually, this is my first recording of 2024, and I could not think of a better first interview for me of this year than the topic we’re going to do today, and with the guests that we’re going to do it with. So we’re here today to talk about HTMX. You may have heard about this thing a lot lately. It’s having its moment; it’s having its 15 minutes. And we’re here to talk about HTMX with none other than the creator of HTMX. Carson Gross. Hello, Carson. Welcome.

Hey. Thank you for having me on the show. I’m really excited to talk about HTMX, and then just the web more generally.

Absolutely. Because we’re gonna not just talk about HTMX, we’re here to talk about rendering patterns, and we’re going to talk about the history of all the different ways we’ve been doing this dance, since the beginning of JavaScript and HTML… And here to join us for that discussion of the web dance is a person who I’m calling WP3000. Can you take a guess for – okay, it’s Alex Russell, okay? It’s Alex Russell. Welcome, Alex. But Alex, can you guess what WP stands for in this WP3000?

I hope it’s a web platform, not WordPress, but you know… No shade to WordPress. I’d love me some WordPress. But yeah.

It’s definitely a web platform, because I feel you are web Mr. Web Platform 3000. That is who you are. And I think –

I thought I was just here to represent the sedimentary history of web development, from the ancient person’s perspective… I’m here with your dad jokes and you’re –

Yelling at the cloud.

Yes. Absolutely.

Don’t forget the yelling. But yeah, so welcome, Alex. We’re so excited to have you back on the show.

So, Carson, in just kind of doing a little bit of prep for this show, I noticed that not only have you been on JS Party before, which by the way, I completely slept on that episode, I guess; this was a few years ago. So you’ve been on JS Party, talking about this topic… But you also were on Go Time about a year ago, talking about HTMX with those folks. And that was a brilliant discussion; I highly recommend folks to check it out. We’ll link it in the notes.

We’re excited to have you back again today, and kind of fast-forward a year, I would say - maybe not the average developer, but I would say the average tech Twitter developer has heard of HTMX. And so I think some of the things that you were mentioning in that interview with the Go folks was that React is king, and for better or worse, and no one knows about HTMX, and that’s the unfortunate part. Even though this is a good idea, it hasn’t really gained popularity or wide-scale adoption, and yadda, yadda, yadda. So I’m excited to see that we’ve moved the needle on that a little bit. However, just because developers are talking about it doesn’t mean it’s actually being used at companies at scale as well, right? So hopefully, we’ll dig into all of that.

So before we get into kind of the crux of what is HTMX, can you just tell us a little bit about yourself, Carson? You’ve got a really interesting background, you’ve been working on the web a long time… So I’m very eager to hear a bit about your backstory.

Sure. So yeah, I’ve been developing for the web for a very long time now. I started working with the web back in ’98-‘99. I was doing Java applets. Actually, it’s kind of ironic that I’m now sort of an ambassador for hypermedia, because early on I didn’t HTML; I preferred more thick client style applications Java applets, and there was this thing called Java Webstart, that was around for a long time, and I tried to use that, rather than embrace the web. But eventually, the web kind of got me, and it just became compelling enough, so I started doing – and in my primary web development, when I did structured web development, beyond just sort of CGI scripts, which was the very early way you would do dynamic web pages, was it was mainly in the Rails environment. So I did a couple of startups – I did some early work in Java, kind of worked for a company that built its own web platform, that I worked on a little bit… And then after that, I kind of went over to Rails, mid to late 2000s.

From there, I worked at a startup – or, me and a couple other guys did a start-up based on Rails. Developed sort of more traditional web 1.0 style application functionality, and one of the things that came up when I was doing that was this idea - I was actually working on a problem where I was trying to sort a table… And I was trying to do this in probably around 2007. And I was trying to do it in JavaScript, on the client side, because that was faster, I had been told… And it was way slower. Maybe it was a skill issue or whatever, but I just couldn’t make it work… And I just almost out of desperation tried this trick of sorting it on the server side, and then slamming it into the DOM, using the inner HTML of the table, and it was really, really fast. And so I was kind of shocked, but I took that approach and I started using it, and first I had a little custom jQuery-based function. I was using that, but then it eventually grew into something called Intercooler.js; I released that as an open source tool back in 2013, I think.

[06:20] And where does one release open source in 2013? I can’t remember when GitHub became a thing. Probably around that time… Did you put this up on GitHub?

Yeah, it was up on GitHub. GitHub I think was 2010-ish. It all blurs at this point, but… But yeah, so I open sourced it. It was my first real foray into open source software. And it went okay. It didn’t take over the world, obviously, because at the same time Angular – Angular was the thing right when I was releasing Intercooler.js, and then React came in and kind of shoved everything else out of the way at that point. So I feel Intercooler.js was just sort of this interesting thing, but it was based on jQuery, which is sort of old and weird, and it just wasn’t right for the zeitgeist at the time.

And then I ended up moving – I was in California for a long time. I’m a California native, and I ended up moving to Montana after the last startup I worked at kind of blew up, and I just wanted to change the scenery… And so I moved out to Montana, and I started teaching at Montana State… But during COVID, I took a look at Intercooler, which wasn’t really going anywhere, and I was “Man, it’s probably time to – JavaScript has come a long way, and so maybe we should try and rewrite this in vanilla JavaScript. Let’s take Intercooler.JS and see if we can rewrite it in vanilla JavaScript.” so I did that, and ended up releasing it as HTMX… And that’s kind of been the history of how I got here, anyways. So it’s sort of a cleanroom implementation of Intercooler.js. Although I don’t know how cleanroom you might call it, because when I wrote it, I was “I’m gonna be Internet Explorer-compatible.” [laughs] So I sort of cut myself off from a lot of modern JavaScript when I did that… So I think you could do an even cleaner room implementation of HTMX if you came at it from a pure JavaScript perspective.

That’s such a great background. Thank you so much for that summary. And I’m curious, at one point you said Web 1.0. So can you kind of maybe just break down for folks what’s the delimiter between 1.0 and 2.0?

Sure, yeah. Web 1.0 would be forms and links, and that’s it. Not using forms with inputs, and sort of the old ugly kachunk… You know, you click – although, I have to say, these days browsers are much better at what would be called Web 1.0 applications… But where you’re interacting using full web pages; you click and go to a full new page, or you submit a form and then it does the – I guess some of your listeners might not be familiar with this pattern, but there used to be this thing where you would submit a form, and if the form succeeded, you would redirect to another page in order to avoid resubmitting the form. There were a lot of these sort of tricks around the early web and web 1.0 applications. But it’s the older, grunkier… I don’t know, if you ever use MapQuest… I don’t know if MapQuest is still a thing, but it’s sort of where you had to click on something and wait for a whole new page to refresh… That was sort of the web 1.0 style of application. And that’s in contrast with the single-page application.

Right. We were sending up full HTML pages, and using the web felt more taxing. And so that’s why, from a user experience perspective, this single-page app, it just felt “Ah…” Such a delight for users, right? Because here we’re just using AJAX to send bits of pieces back and forth, and you’re not having to do a full whole page reload. And yeah, with the 2.0 came that rich interactivity, because we could now all of a sudden – we weren’t doing these full round trips, right? But there’s a lot to kind of unpack there, which we’ll get into in just a second… So let me toss the ball over to Alex. So Alex, I feel like Mr. WP3000 needs no introduction, but please, can you tell us a little bit about yourself as well, Alex?

[10:24] I’m apparently a product manager on the Edge team at Microsoft. But I still work on making web pages faster. And that work started when I was on the Chrome team at Google for a long time… Because we started to see that folks who were trying to build these kinds of richer experiences that we were just talking about were getting beached pretty frequently. Folks would start with high ambitions for the end user, and then because of the tools and techniques and cultural assumptions that they had brought with them from what was in circa 2015-2016 the dominant ideology about how you built nice things on the web, we ended up with teams who had built themselves into a corner with extremely tall piles of JavaScript, in a moment when the market was changing dramatically.

So since 2015 or 2016, we’ve seen just the continued explosion of what happened in 2007 with the iPhone moment. But from – I want to say 2013, 2014, it was pretty clear that diffusion was going to take hold worldwide, not just in wealthy Western markets, and that meant that we were going to see this extreme profusion of cheap devices, where every year, to the extent that Moore’s Law continued to play out, it meant that you could get more transistors per year, per dollar. But that didn’t translate into faster phones for most people; that translated into their first smartphone. And that meant that every year, the same capability got cheaper. And that just grew the market.

And so it’s only now, 2023-2024, that we’re starting to see full saturation, or let’s say replacement of what used to be the market for dumb phones being replaced by smartphones. Feature phone handsets were as late as 2019 half of the entire market in India, and that has finally rounded the bend. And so now we’re in a place where folks are starting to get maybe their second phones based on replacement rates and income worldwide. That’s not what it is maybe where we live, but the global reality is continuing to change… But that change, for most of the last decade, has meant that computers didn’t get any faster. They stopped getting faster. And so our patterns and practices as a culture for people who are building on the web had been set; they sort of cemented in 2013 on this idea of “CPUs get faster, networks always get faster, and that means we can afford more JavaScript every year.” And that has created one gigantic branch mispredict. And that great branch mispredict in the sky has caused us, sort of at a cultural level, to make choices that are not compatible with actually delivering good experiences for most people, including people who are wealthy, but just don’t happen to be at the right time in place right now… And so it’s been fascinating to see this turn to access, and then hopefully away… But I’m excited about HTMX and some of the patterns around it in that context.

Yeah, great points. I mean, it’s this interesting irony where all of a sudden more people are accessing the web on mobile devices, that have much tougher constraints, especially in emerging markets, like you’re saying… And we’re also just kind of, at the same time, exponentiating the amount of JavaScript, because we’re like “Oh, we want these rich experiences”, and this and that, but we’re not really designing for… Like, we talk about mobile-first design, responsive design, all this stuff… But we’re not really designing for those experiences in the way that these apps perform in the wild. Right? And so yeah, I’m very excited to kind of unpack the how we got here question with both of you today.

[13:57] So Carson, let’s talk a little bit about how we got here. So you’ve created this popular library based on this kind of core primitive of the web that I think most people don’t know about. And when I say most people, I really mean probably most of our listeners, most people writing JavaScript… This notion of kind of hypermedia, and how you can leverage hypermedia to really just be talking in HTML, right? JSON has kind of been this language that we’ve been using as this kind of like intermediary between servers and clients. And it’s “Oh, this universal language, that we can send over the wire, and it doesn’t really matter what the consumer is. It can be Swift, it can be Flutter, it can be JavaScript…” All these different – like, every single programming language knows how to deal with JSON, and so it’s this universal connector. But at the same time, I think HTMX and this pattern of sending HTML back and forth over the wire - it kind of highlights that “Hey, maybe there isn’t always a need for JSON”, right? So yeah, can we talk a little bit about how we got here, and then we can kind of dig into some of the merits of HTMX?

For sure. So I think one of my core ideas is that the web – the web is hypermedia. The thing that made the web interesting - at the start, in any event - was it was a distributed hypermedia system. And there was a lot of thinking that went into that, there were a lot of new ideas, and it was something that was developed in reaction to the older sort of 1980s-style thick clients. This idea – there’s this thing that, you know, if you’re familiar with Roy Fielding, who… I don’t know how nerdy your listeners are, but he wrote a really famous dissertation sort of about the web back in I think the late ‘90s. And the design of the web, and the way hypermedia works is it’s designed such that there’s a really strong decoupling between the client and the server. And the client here is defined as the web browser. And so one thing I try to stress to people is when they think about a web browser, even – just take JavaScript out of the whole equation here, and think about the fact that you have a piece of software on your device, that can talk to a pet shop, it can talk to a car lot, you can reserve a hotel with it, you can get your news from it… And this one client that is sort of a universal client that’s able to speak hypermedia, and is able to do all these things. And if you told someone in the 1980s that they would be using the same piece of software to pay their taxes, work with their bank, pay their utility bills, and do everything else - order the food or the dinner for the evening - they would have looked at you cross-eyed, because that’s just crazy. How could you have a client that – it just wouldn’t have computed for those people.

So I think that hypermedia - it was really exciting. I remember – I was sort of like late in the game. I was very young when the web sort of hit… But looking back on it, you can see the excitement around this sort of different way of building software that was based on this notion of hypermedia.

And just to give your listeners a definition of what hypermedia is - it’s something that has hypermedia controls in it. And hypermedia controls are things like links and forms. That’s if you’re just talking about HTML. So links and forms. And what’s special about links and forms, or what’s interesting about them, is that they encode an interaction with a remote system within themselves. So when you get a web page from some new website that you’ve gone to, the links and forms that are in that web page have the URLs and the interactions with that remote system baked into the HTML itself, baked into themselves. They’re sort of self-contained; they contain the remote logic necessary to do the things that website wants to do. And that gets at something called the uniform interface from Roy Fielding’s dissertation. But it’s really that idea of hypermedia controls that’s what defines the hypermedia in my estimation. And HTMX, what it does is it generalizes that idea. It takes the two hypermedia controls most people are familiar with if they do web development, that is links and forms, and then generalizes it so that any element can effectively act as a hypermedia control.

[18:27] Yeah, I think it’s interesting. It’s like hyperlink, which is the kind of more – the actual name for anchor tags and all these other things… I’ve never made that connection until hearing you explain this so well, Carson. But yeah, but that is kind of – that is the web, right? This series of links and things that redirect you to other primitives, and it doesn’t really matter what’s coming back on the other end; it’s going to be one of these three primitives: CSS, HTML or JavaScript. And so Alex, can we maybe dig into kind of this hypermedia protocol? Because it is a web primitive, it is a web protocol… And so why are we not talking about this more often? And how have browsers failed to maybe perhaps expand on this protocol to enable richer experiences?

Yeah, I think we don’t talk about it as often in the web development community because we find that it’s not something that we can personally influence… Aside from building or rebuilding large piles of it in JavaScript in userland, it’s very challenging to imagine extending the vocabulary of the web in kind of a way that simpatico with the built-ins. Because for many, many, many years, it was fused shut. This was the instinct for us to develop Web Components in the first place, it’s why you see – there has been some intensity around form participation for custom elements, that sort of thing. And I can report that it’s finally here, now that Safari is mildly off the fence, which is great… We’re in a position now where some of these expansions of the vocabulary are sort of easier to imagine doing inside of the system. But for the longest time, you just had to rebuild everything.

Between the constraints of legacy and the need to have control, for instance of things styling, the built-ins have not been the most simpatico way to try to get yourself a better version, a slightly upgraded version of that protocol whenever you wanted. And so one way to think about this is we kind of migrated culturally into JavaScript out of partial necessity, and then I think beyond that, to some degree, we’ve stayed there out of storytelling and tribal identity. The narratives are strong, and it’s hard to unseat them, especially when you think you can afford what you’re doing, and that everything is going fine. And if everything had been going fine, I wouldn’t be spending any effort trying to unseat those narratives… Because you know, I’ve spent most of my career trying to make life better for JavaScript programmers, too.

But if your listeners are interested or curious about this, I’m fascinated by the progress that’s being driven out of the Open UI community group. They have had a big impact on the thinking of kind of finishing some of the things that we intended when we started the Web Components journey, around making pieces of markup, existing form elements, existing types more extensible, certainly from a styling and layout perspective. And there’s more to do there about the data types that we encoded underneath. That data type system is still a little bit fused shut in ways that I think are a little bit frustrating, unless you go and build a form participating in a custom element today. But the good news is that the deltas that we need to apply on top of what the platform gives you in the 2024 moment are so much smaller than the deltas that we needed to apply previously… So I think it really will be a mind-shift change, and I love what HTMX is doing as a result.

Okay. So let’s break that up a bit… Because there’s a lot there. So the Open Web UI group that you referenced is this kind of standards working group that’s trying to kind of create better higher-order components that are more what you would think of when you think of a React component, or an Angular component, or something, right? Something richer, and easier to work with…

Well, you might sort of work back through the justification process and say “Why am I pulling in Angular, or React, or something?” And the answer might be as simple as “Well, I can’t style my select box. I would it to be reactive.” Because the built-in elements, they all have a kind of reactive belief about their own internal lifecycles. That just hasn’t been opened up to us. And so there’s a fusing shut of the hood. So you can’t go replace just the bits that you want to get the change that you need. You have to build a whole new vehicle. And there’s also the fact that the existing ones aren’t very customizable, nevermind serviceable. So they are pushing on both of those doors, and I think that’s very helpful.

Anyone who’s tried to style a native form knows the pain of - yeah, you can’t get it to look the way you want it to look. And there’s a lot of really great work that’s been happening over the years. Interop work with browsers, and kind of improvements to form elements that people have been working on, which is great… But yeah, we’re still far away from I think what web developers need for that more turnkey experience that they’re used to. So that’s really exciting work…

And so we talked about, okay, if the web had these components, and we had richer kind of elements that could help us tell this hypermedia story, why do we even need something like JSON? That’s what I want to try to understand. So if I can just have a conversation with my server in HTML, and I don’t have to go through this serialization process, and blah, blah, blah… What’s the need here for something like JSON at all?

Why are we using JSON? It’s a good question, especially because HTML – I mean, HTTP has the name right in it, you know? Why aren’t we transferring HTML with this protocol? So one of my assertions here is that one of the problems we ran into was that HTML sort of froze as a hypermedia as far as the functionality. It wasn’t taken forward as a hypermedia. And so you only had links and forms. Now, links and forms are very powerful. All of web 1.0 was built with just links and forms, which is pretty amazing to think about just two hypermedia controls let us do all of that. A tremendous amount of wealth was generated, a tremendous amount of information was distributed, and so forth. But the fact is that HTML, really the form element, which was part of HTML 2, was the last hypermedia control, and really the last part of HTML – it was the last time that HTML was moved forward as a hypermedia. There’s tons of other stuff that’s happened HTML, but almost all of it – or not almost all, but the vast majority of it is in terms of either client-side improvements, or you get things like the validation API… These things that didn’t touch on the core idea of hypermedia controls. And so I think what happened there was that that HTML stayed frozen, and that necessitated a certain level of usability, of user experience that was achievable with those hypermedia controls. And so because of that, almost out of necessity, everyone switched to JavaScript, or went JavaScript-heavy. And then when they went JavaScript-heavy, the obvious thing to use was JSON. I mean, again, it’s in there in the name, JavaScript Object Notation.

So I think that’s why we ended up with JSON, is because – yeah, I don’t think it was a mistake. I just think there was this unfortunate freeze in thinking about HTML. And what’s really unfortunate about it is that there was thinking earlier on about – like very early on, in the ’70s and ‘80s about this concept of transclusion, which is the idea of including one document in another document, that I think is really sort of the crux of what HTM - or HTMX, I should say - does… Because HTMX, by allowing you to have a hypermedia exchange where a piece of HTML comes back, and then you place it inside an existing document, it really gives you a big boost in usability over plain links and forms, because you don’t lose scroll state, you get a huge amount of functionality… It’s just a much smoother feeling that comes with building an application, just with that one feature of HTMX.

[29:57] The concept was around for a long time. I actually wasn’t familiar with it when I started making Intercooler, but I’ve come to go back and read up a lot more on the early hypermedia discussions. And so it was there, but just for reasons that I don’t have the background to answer, HTML just kind of stopped. And so that ended up pushing people who wanted more usability into JavaScript, and then the natural communication medium was then – we adopted this thick client sense, like we’re building thick applications, and so you’re not going to use something like hypermedia for that, you’re gonna use the data format. And JSON beat XML out… So JSON was the way.

Yeah, yeah. Well, anything that’s also a little bit closer to JavaScript - there’s gonna be less friction to kind of adopt that, as well within codebases and whatnot… So I can see that as well. And so I think this concept of transclusion - for me, when I think about the web, and especially the early, early web… Like, we’re sharing documents, and there’s just a bunch of links that lead to other documents… And so just from a mental model, that makes sense to me; HTML begets more HTML. That makes sense. So Alex, you were kind of smiling along when Carson said the word transclusion… And it seems like you probably have some history with this. Do you want to let us in on that?

Yeah. One of the contributors to one of the earliest JavaScript toolkits that I worked, something called [unintelligible 00:31:27.17] a guy named Brad Neuberg, who is I think spending most of his time on ML topics these days… But I was lucky enough to work with him for a while at Google. He got involved in a project with Doug Engelbart, trying to rebuild a piece of the system that they had imagined for hypertext early on… This is probably 2011-2012, but working on ideas that had been husbanded by Doug Engelbart and his group from the ‘60s. And that transclusion idea sort of made it into pieces of this work… And they are one of these things which is possible at the limit of our shared vocabulary, and our shared performance; to the extent that we can afford to represent the same concepts in a document that’s hosted on someone else’s computer, then we get to do transclusions, and to the extent that we can’t, we don’t. I think it’s fascinating, going back to – rolling back all the way to the JSON idea. One way to think about this is in the footer of every document that’s been “SSR-ed”, why don’t we have a copy of those same exact semantics living as a JSON structure, which then gets rehydrated? I think that’s probably what we mean by JSON… Because this is actually the dumbest version of taking a local data model; the one and done local snapshot of a data model is the dumbest version of that data model… And from the perspective of just going back and forth across several pages, if you just go look at the structure of - I don’t know, just pick on anyone; a New York Times web page. Just view source on a New York Times article, and if it doesn’t make you laugh, you aren’t looking hard enough… Because you get some HTML at the top, and that HTML pulls in some JavaScript, and then if you scroll halfway down, you’ll get to the bottom, and it will have the same HTML as a JSON structure. Everything, literally everything, as a JSON structure.

And what does that tell us? Well, it tells us that the way that we want to make those things interactive has to bootstrap onto some representation that is not the HTML. And so we don’t actually share those HTML representations anymore. We’ve tried to abstract yourselves up off of HTML and into some other thing. And then we want to operate on that thing when we want to make changes, and then splat it back out in some other way. And this is kind of - you know, I think back to Carson’s point about having some necessity driving this… Without the ability to upgrade the semantics of HTML, maybe because browsers get good at doing this again - although we don’t have a great track record there… Or because we have failed to bring along a system for doing it naturally ourselves, we wind up in this logic of building a parallel world, and then having to reconcile it with the displayed reality of the thing that actually pumps our rendering system, the thing that actually takes the diffs and turns them into DOM diffs, and turns them into CSS diffs against that, and layout trees, and then render trees, and then raster.

[34:10] That whole flow requires that we pump it with something, and how far away we are from that core semantic model that it’s designed to be pumped by is this tension that we feel. And that I think gets us into this question of “Well, why did we pile into the clown car of web 2.0?” And it’s interesting to me that all of the examples that we bring up about where that stuff was truly revolutionary are systems that had many clicks, or taps, or drags. They had many detailed, drilled-in interactions per session… And it’s in those places that that local data model thing shines. And it’s in the other places, which is - I’m just gonna handwave and say the vast majority of interactions on the web, where you have shallow sessions, whatever the designers intent, where you aren’t doing many clicks or taps against something that would be better if it was a local data model, that this stuff just feels like it’s… It feels like cruft, but we’re not sure why, even though we have some innate belief that it’s good for us. Because we’re not looking at the diversity of session depth.

Yeah I’m surprised we’ve managed to get this far into the podcast without bringing up the word React… I don’t think we have - I’m the first to bring it up - and I cannot wait to deconstruct React and some of the paradigms with both of you… Because really, there’s just so much that doesn’t feel natural, or that doesn’t feel – it feels like we’re using the web all wrong. We’re working against it, in the fact that the React core team at one point was creating a scheduling API, which is still part of core, I think… It’s just mind-boggling to think that we are trying to manage scheduling threads in JavaScript, instead of just actually just working with the browser, and working with these primitives in a way that makes not only sense, but it just greatly simplifies our code, and the complexity that we’re managing as engineers… Let alone the benefit that it gives to users as well. That’s what we’re all trying to do.

So I don’t know, Alex, this is kind of why I wanted to talk about the “how did we get here”, because using Angular, and Backbone over a decade ago - I’m thinking talking about Angular 1x - single-page apps were just so sexy to everyone. It was just like “Ooh…!”, you know? And I don’t know where we lost sight of the complexity meter, and where we lost sight of “Does this make sense?”

And the other thing is clearly there’s some standards gaps that also pushed us to this. Like, let’s take ownership here on the platform side. This is not just on web developers. They were just trying to get stuff done, to ship things to their users… And so where did the platform fail us, too? Because we can’t just put all this blame on web developers. Which are, by the way, world’s smartest people; I will argue that with anyone. But I think sometimes too smart for their own good, you know? So I don’t know, what are your thoughts, Carson?

Well, I think developers, they tend to underestimate the complexity of state synchronization in general. And one of the tremendous simplifying things about the web, the web 1.0 model, was that state was on the server, and you rendered a representation of the state, and that was it. And I remember when I first saw that, I had sort of a reaction against it too, because I was – I had built some thick clients, and supported things like Undo, which if there’s one great simplification of web applications, it’s that our users don’t expect Undo to work. Because holy smokes, getting Undo to work in a real thick client is not trivial.

So I think developers tend to underestimate that tremendous simplification of distributed systems that the hypermedia model gave them. And they saw this clunky user interface, and were like “Man, we can do better than that”, and they could… And so they got attracted to that.

[38:05] I think another dynamic – I know DHH… You know, say what you will about the guy, he says interesting stuff. He said that – and he’s kind of going out on his own sort of riff on this, where he’s saying… Obviously, he’s been saying this for a while, but he doesn’t think single-page application frameworks are as necessary as a lot of people do, and he’s got his own thing called Hotwire, which is in some ways very similar to HTMX… And he said that a lot of this was sales. People were selling stuff; there was a slick aspect to it… And I think there’s something to that.

I think that the broader dynamic though in technology is a fear of looking dumb. And I think it’s really hard for people, when someone comes in with a really complicated system, and is like “Look at this cool stuff that we can do”, for someone and be like “Man, that is crazy. Maybe we don’t need to do all that. Maybe – can we do something dumb, that’s an 80/20 solution to that?” And that, I think, is the broader problem in the tech world that enabled us to go as far as we went.

Again, I’m sympathetic, because we work in an industry where your intellect is very highly valued, and appearing dumb can be very bad for your career prospects… And the reality is there are people who have been left behind in technology. Perl developers in 1998 didn’t see the Java meteor coming at them. And if they stuck with Perl, and didn’t get on the Java bandwagon, or go over to PHP or whatever, they ended up really limiting their careers. So it’s just a dynamic that I think you have to acknowledge about the technology world.

Yeah, that’s so well said. And by the way, are you just trying to score points or something, Carson? Because listeners on the show know how I beat that simplicity drum a lot… And I beat the 80/20 trade-off a lot, in the sense that - everything you just said, all these incentives that we have as engineers, to be smart, work on hard problems, be the hero, crush it, be the bus factor… Because I really do think some people strive to be the bus factor… Bus factor being - to explain this - being an invaluable person to your company or team, where you’re the only one who knows this esoteric code, and you’re the only one who can touch it, and they have to call you at 3am to make an edit, or approve a PR, or whatever… I do feel like there’s a little bit of fetishization of that person, that persona. And we are not incentivized towards simplicity. And for me, this is like a leadership problem, in terms of our engineering leadership. Our engineering leadership should be incentivizing simplicity, because that’s just better for everyone, on all fronts. But here we are in this complexity race, and it’s like a race to the bottom, which is where we are now. I feel like things are so complicated in JavaScript. It’s so hard for new people to come in and write modern web applications. When I say modern web applications, it’s quote/unquote; modern web applications that are using popular tools and technologies, right? A little Hello World, you have to learn how to use a bundler. You have to learn how to potentially use TypeScript, because the examples are all in TypeScript. Whatever it is, there’s all of these barriers to entry, because we’ve just – I don’t know what it is. Maybe we’re just trying to prove to everyone that JavaScript is a serious programming language, or… I don’t know what it is, but this Napoleon syndrome needs to go, because it’s hurting the web; literally hurting the web, you know? And Alex, I see you laughing… So please, chime in.

[41:52] Well, I would just cut the question of “Why are we doing all of this complexity, and how did we get here?” by trying to always challenge it by saying “Who are we tackling all this complexity for?” There’s a version in which I think, Carson, your point about people’s hiring prospects gets to, which is to say that there is always, and will always be some aspect of this, which is about looking over your own back, for yourself. And there’s some aspect of this, which I think is a little bit more inspirational, and I hope more aspirational, which is to say “We’re gonna go make this get better for everyone.” And getting better for everyone is not about making it better for just me, or people who are just like me, or who are in the same situated physical geography, or in the same situated socio-economic bracket. Those are questions about who do we want to have served, looking back from our future selves… And I think, if I was just going to characterize today’s technology landscape, I would say that it is – and this is not an indictment of any individual, but it is an extremely selfish enterprise. It has bought into kind of a libertarian trickle down developer experience idea, and it’s just as falsifiable today, in the evidence that we’re getting from Imp and all the rest, as it ever was in the data, in the ’80s, from some various tax experiments.

These things - these are ideas that don’t work as well today as they didn’t work in the past, and we don’t have to keep trying them; we don’t have to keep believing in triple down DX. We can just say that the way that you make something better for the user is to focus on the user, and that the problems that are worth solving are the problems that we can identify being as problems that users face, rather than problems that we face. And yes, we can also say, in a very cross-pressured way, that it is important to solve problems for ourselves, so that we can get problems for users. This kind of developer experience bait and switch operates on the kernel of truth that there is something there that is so valuable, that if we solve it, we will have also solved problems for users along the way… But I would just say that we have got so much evidence now of not marking those ideas to market along the way, and that when we don’t do that, it turns out that it’s just a bezel. It’s just a failure that we don’t account for yet.

And we can call them out as such in the future. We don’t have to keep pretending that the next thing that the React team ships is going to solve anything, because it actually isn’t phrased in terms of solving something for the end user. So if it’s not phrased in terms of solving something for the end user, to a first approximation, it doesn’t matter, and at a second-order effect, we definitely need some evidence to show that it’s actually going to move the needle for us. And if we don’t have that evidence, then a la Hitchen’s razor, we just get to throw it out. We just get to ignore it, the way we should have ignored it all along.

Yeah. And standing ovation… I’m just gonna fake – it’s not a fake clap, it’s a real clap person. Okay? Seriously. Yes. Also, how much of this do you think is a leadership problem? Because as an engineering leader now, myself, I am like “Holy Moly!” I’m like, I need to start blogging and I need to start helping these other engineering leaders learn how to set some darn standards. You know what I mean? Set some standards for your team.

Absolutely. 100%.

So can we talk about that?

Yeah. And I want to put responsibility where it belongs. I don’t want me to say that, you know, the enthusiasms of engineers are things that we should pin industry-wide failure on. That’s not true. There’s a lot of technology that I love, that hasn’t taken off, and probably never will, and I just have to be sad about that. That’s okay. But I wish it was different in some ways. But also, managers have responsibilities in these environments. And if anyone is supposed to be asking the question of “Who are we doing this for? Who does it benefit?”, setting benchmarks that help you do it, setting up environments where we can make that legible and visible…

[45:48] You know, the overlap between teams that I consult with - and I do a lot of consulting with teams here at Microsoft to dig us out of the ditches that we have reliably put ourselves in with regards to performance on the web - the number of teams that actually need the kind of help that we can provide from the browser side, and the overlap in those teams between folks who have done bake-offs, to find out what actually works for the user… It’s a Venn diagram in the style of two circles that don’t touch. Folks who do bake-offs, managers who are wise enough to put the user into the calculus up front, and then make sure that they stay there, or that they’ve got the kind of metrics that they need to do it, they generally don’t have these problems. Now, that’s not true – you can get yourself into a place where you’ve got such a large organization that it’s hard to contain any of these effects. But the difficulty in containing those effects is a core argument for stack simplicity in the first place. Because - I’ve written a bit in the last couple of years about what I’ve called the performance management maturity kind of cliff that you have to scale as a team… And if you’ve got simpler technology, your problems are generally simpler on the other side, of trying to solve a problem a particular way. Now, you might resent things about that stack, but it didn’t leave you with the most complex problems as a residual kind of side effect of doing the work. Whereas if you buy into complex stacks, or stacks that leave you with complexity upfront, or try to hide complexity from you, you own all of it on the other side anyway, and now your problems are more complex, and your solutions actually take much longer to execute.

So teams that get beached or stranded are teams that have bought into stacks that they don’t actually manage, and the outputs of those stacks manage them. And that’s the worst place to be. And so this is a management maturity problem.

And that’s where a lot of people are now, right? They’re just on this bandwagon where I’m like looking at some of the new things that are coming out of React, and I’m like “Whoa, man… I wouldn’t want to be stuck on that roadmap, having to upgrade and start using some of those patterns.” But anywho. Alright, so we’re gonna come back to some of this stuff, as we kind of do some compare and contrasts, because there’s a lot more to unpack here… But since we’ve been focused on rendering patterns and the “How did we get here?” problem, let’s just shift into HTMX, Carson.

So this is going to be the quickest part of this discussion, because I think it’s such a simple framework, it’s going to be super-easy to explain it. It’s going to be three minutes, and then we’re done. We can all go home.

Sure.

But why don’t you just – lay the groundwork for us. So qu’est-ce que ça? What is HTMX?

Okay, so the way to think about HTMX is it’s a few attributes - there’s probably 10 to 12 core attributes, and really, there’s only five or six that can get you started. And those attributes are HTML attributes. So you put them on HTML elements. And what they do is they generalize the idea of hypermedia controls, which is a nerdy way of saying they make elements do things over the network.

So just as an example, if you have a button, and you want that button to issue a put to /liked. Then you put an attribute on that button that’s called hxput. And you say hxput equals, and then /liked. And that’s similar in many ways to what you would put on an anchor tag; you have an href, and that would tell the browser “When someone clicks on this, load that whole page.”

So when you put that hxput on a button, what that’s going to – HTMX, which is JavaScript, which looks for that attribute, and then hooks up an event listener, what HTMX is going to do is it’s going to issue a request to that endpoint, and then that endpoint is going to return HTML. And that’s really the crux, that’s the really major difference between thinking about things in a JavaScript-centric world, and the HTMX approach. These are what I call hypermedia exchanges, where we’re making a request to the server, and we’re getting back hypermedia.

So then the question becomes “Okay, I’ve issued this request, I’ve gotten back hypermedia. Where do I put it?” We’ve already talked about transclusion, and so HTMX has a few attributes; one is called hxswap, and one’s called hxtarget. The hxtarget attribute uses a CSS selector, which hopefully web developers are familiar with, to pick an element in the DOM to put this content into.

[50:12] And then the hxswap attribute lets you tell HTMX how to put that into the DOM. So maybe you want to put it inside the element, maybe you want to replace the element… So that’s like the outer HTML. Maybe you want to put it after the element, and so forth. There’s a few different options there. And so that’s really the crux, is those attributes.

The one other attribute, the one other generalization of HTMX is that there’s an attribute called hxtrigger, which lets you pick which event causes an HTTP request to occur. And so all those attributes come together to generalize the idea of hypermedia controls, and they let you implement more rich applications within the hypermedia model. So a good practical example - and I would encourage your listeners to go to htmx.org/examples, because that probably doesn’t sound like very much, and it’s not. That’s kind of the idea. But despite that fact, you can actually do quite a bit with a htmx, some user patterns that people – UX patterns, I should say, that most people wouldn’t expect; those very simple – they’re not trivial, but still… It’s not a big step beyond plain HTML that the hypermedia controls are already used to.

So to give you a simple example - this is one of my favorite examples, because it’s two attributes, but if you had a web page that had a chunk of it that was taking a while to render, so you had some components, say graph, for example, that took a little bit to render, and you wanted to render it on a web page, with HTMX what you could do is you could take a div, and you could put hxtrigger equals load on that, so trigger the request when this div loads. And then you could point the URL, you could say hxget from /graph. And then what you could do is you could move that complicated graph computation out to another endpoint, and remove it from the first paint of that initial web page.

So maybe that graph isn’t super-important, maybe there’s other actions you want the user to be able to do. But these two attributes, hxtrigger equals load, and then hxget equals /graph, allow you to take this piece of HTML and move it out to another endpoint, and have the initial page - because it’s able to use transclusion - do a first paint without that content.

And so that’s an example, this lazy-loading, it’s a great perf win; it can get users to a user interface they can interact with a lot more quickly. And if I first talk to you – when most people first start looking at HTMX, it wouldn’t occur to them that they could do a pattern like that with this concept. So for whatever reason I just love that example, because I’ve used it very effectively, in a lot of web applications, just to make a particular page faster.

Yeah. Oh, my God. That’s super-cool, and - wow. And that kind of partial loading… I feel like JavaScript developers have kind of recreated that with the islands architecture a little bit, if you’re familiar, Carson, where we are able to kind of do this graceful lazy loading by kind of drawing boxes around different parts of our app. But here, we can do that very simply and cleanly using HTMX’s ability to use transclusion. Like, duh… It’s so duh, it’s like “Huh?”

Okay, so let’s talk about this – Ajax with attributes. So first of all, I want to say, congrats on being probably one of the best marketers, I think, of a library framework. I don’t even know who does your marketing, if it’s you, or people from the community, but y’all have some awesome marketing. Your Twitter pictures…

It’s literally just me.

It’s you? Okay. Well, you’re awesome. And if I ever have a library that I want to go viral, I know who I’m coming to.

I have no idea what I’m doing.

[54:06] That’s so funny… Okay, so can we talk about Ajax with attributes? Many folks are probably familiar with data attributes as a thing on HTML elements, right? But now you have all this other stuff, and because HTML has this very graceful extensibility, where you can have all these custom attributes, you’re able to leverage that similar to, somebody might say, a prop. But these props are a bit more specific. So can we talk a little bit about this, how big is this API that you have for these built-in attributes? And can you give us some examples of some?

Yeah, it’s not very big, because there’s really – so when I think about hypermedia controls, I think about four areas where they can be generalized. So if you think about a link or a form, really what makes them – their essence from a hypermedia standpoint is that an event occurs, in the case of the link it’s a click, or in the case of a form it’s a submit, and then a request is issued. And then that response is used as a document to replace the whole page. And so the generalizations there are “Okay, let’s let other elements issue those requests. Let’s let any event trigger that request. Let’s let any type of request be made.”

One of the sort of tragedies of HTML is that in the standard hypermedia controls you can only issue gets and posts, but HTTP has put, and patch, and delete, which - these all have meanings, and it’s a shame that you can’t access them directly from HTML. And then finally, that last one, which is instead of replacing the whole document, let’s make it possible to do transclusion, a flexible transclusion mechanism.

And those attributes boil down to hxget through delete. So hxget, post, patch, put, and delete. Hxtrigger, which is the event, and then hxtarget and swap, which is sort of how to transclude the content that came back into the DOM. And for better or for worse, I tend to use just hxget. You can use data-hxget if you want to be a better web citizen. I don’t know how Alex feels about that, but I’ve always just kind of used – I sort of like how sloppy the web is.

That’s never mattered, and it will never matter.

Okay, perfect. An adult has said it doesn’t matter. I love it.

So I will just say that whether or not you use the data- prefix in terms of attribute names has never practically mattered. I can see the case for why it might. We’ve had cases in the JavaScript standard where people have sort of camped out on global names, and that’s been challenging to introduce things in… But we have not, as far as I know, run into a case of that happening with data attributes, or non data prefix attributes.

Yeah, that’s awesome. That’s great context. I’m just amazed at how you have just such a simple API, simple interface, but it’s so powerful. Because it’s really it’s the stuff that – you know, what are we doing on the web? We’re sending back a bunch of actions: put, delete, get, post… And we’re updating information on a screen based on the results of those actions. And here, now we have this framework, or this library that allows you to do that gracefully and elegantly with HTML. And for me, the beauty of HTML is it can handle structural complexity very well. And then with that structural complexity, if you do it well, you also get nice semantics and nice ways of organizing your code. And for me, the best part about kind of moving more towards an HTML-first world is that we now get to say hello to a bunch of other classes… We’ve lost a class of developers over the past 10-15 years.

[57:56] We had CSS and HTML experts that we’ve kind of shoved to the corner in this JavaScript-first world. And I miss those folks; those folks are amazing. Those folks know HTML better than we do as JavaScript developers. Those folks know CSS better than we do as JavaScript developers. Those folks know how to write accessible experiences, that are performant, and clean, and organized… And I feel we’ve kind of – I don’t know, we’ve just shoved them aside, and I hope that this is our new reality, of focusing more on HTML… Because I’m excited to welcome back that class of developer, that’s not super-into JavaScript, but is into the other two big primitives of the web. I see you nodding heavily, Alex.

Oh, yeah. I think there’s a [unintelligible 00:58:40.27] right now. If you were going to try to determine whether or not someone who was sort of, I would say, you know, given the median level of familiarity with CSS, versus the median level of familiarity with JavaScript, who’s going to turn out the better experience for most users, I would give it to the CSS expert or journeyman every time, every single time, just because most experiences are not composed of the kinds of extremely deep sessions that require us to pile into the JavaScript clown car. We don’t need that local data model to operate against with low latency, with speculative application of data model diffs, if we aren’t going to keep the page around forever. So in most cases, you want to hire people to solve problems with HTML and CSS with as little JavaScript as possible, not to pay them to make new problems with JavaScript.

Let’s actually get into that a little bit, because I want to talk about this session, and types of web apps… Because we’ve kind of danced around this a little bit. And this kind of data model that’s kind of conscious of session time, and architecture that’s conscious of how long are people spending on this site… For example, Netflix’s login page, I remember - this was a fun story. They rewrote their login and signup page, just an HTML and CSS, and they’ve removed React, because it was just too slow. So why did they do that? Well, they were optimizing for performance, and “Hey, we don’t want to make people feel it’s taking too long to sign up or log in.” That’s smart. Let’s optimize for that. So let’s have more of a static architecture, so that we can meet our users as quickly as possible, so we don’t lose them to another tab, or another – like a TikTok video, or whatever. So that’s one. But can we talk a little bit about these different types of architectures, and session depth? And I’m also curious to hear from you, Carson, when is HTMX not a good idea for the thing that you’re trying to do?

Sure. Alex, if you want to go first here…?

Go for it.

Okay. Well, the idea of session depth - I learned about it a couple days ago, and I feel like I’m not in a great spot to talk about that particular way of looking at things… But the way I look at things - it’s sort of what Alex was getting at earlier, where if you have a bunch of events that need to drive interactivity, then hypermedia is a bad idea. Roy Fielding said this; he said it’s designed for what he called coarse grain hypermedia interactions. And so if you’re trying to respond –

And who is Roy Fielding?

Roy Fielding being the guy who wrote – his dissertation sort of formed the basis…

The dissertation guy, okay.

Yeah, he’s the dissertation guy: he gave us the term REST, and HATEOS, if you’ve heard of that term, so hypermedia as the engine of application state.

I’ve always called it HATEOS. Is it HATEOS?

I don’t. HATEOS… It’s a bad acronym. He actually prefers the term “the hypermedia constraint.” So that would probably be better for everyone involved.

Yeah, I speak too many languages. Nobody should trust my pronunciation on anything, because I’m multilingual, and so… Whatever.

Yeah… But I think Alex’s point that if you have a lot of interactions, you can’t put a hypermedia exchange in between those interactions. And you mentioned earlier the idea of this island architecture. To me, one of the missing links in the discussions around a lot of these things is the notion of events. Having an island of interactivity, be it a web component, or whatever, something that does or gives a richer experience, but then that integrates with the broader hypermedia system using what are hopefully not super-frequent events. Someone gets a rich text editor; that’s an amazing piece of software, an amazing extension to the web. Maybe they put markdown in it, or whatever it is, and then they click a Save button, and okay, now an event occurs that triggers a bigger hypermedia exchange, where that markdown is sent to the server and rendered into HTML and placed somewhere else in the document, or whatever it is.

And so just to give your listeners an idea of what HTML wouldn’t be a good idea for, it would not be a good idea for Google Maps. I don’t think it would be very difficult to make Google Maps work well with HTMX. It would be difficult to make Google Sheets work well with HTMX, because you have a lot of very crazy dependencies; you can’t afford to just sort of replace parts of the DOM.

But one thing I often say is that on the other hand those two applications probably have Settings pages that could use HTMX, where you’re much closer to the standard form, where you’ve got some checkboxes, and this and that. That’s sort of a wheelhouse for the web. And I don’t think it’s an either or necessarily, but there’s definitely – the more fine-grained your event handling needs to be, the less ideal the hypermedia infrastructure is going to be.

Yeah, that’s a great summary. And you’re just reinforcing this notion for me that it’s okay to have different parts of your app be architected differently, right? Optimize for each experience using the best tool for the job; it doesn’t have to be one size fits all.

[01:05:56.05] It doesn’t have to be one size fits all, that’s right. I have taken, in some of these cases, working with teams, to break down their apps into different experiences. I think the one that we may be most familiar with is maybe a blogging piece of software. WordPress is probably a good example. So WordPress has a viewing mode. And that is a query against the database, or a bunch of different queries against the database, nested with some templating, and it spits some stuff out. And the set of interactions that each of the viewers who go to each of the responses from those queries has about that content is extremely shallow. Those are shallow sessions. And they’re mostly scroll. And scroll is handled by the browser, so they don’t count in your total denominator number of interactions.

So if you think about the number of interactions that we’re counting here, the interaction where you clicked on a link, or typed in a URL, or tapped on something to get to it, that’s the first one. So you get to one to start. And every subsequent interaction in the session is another added to the denominator, but scrolls don’t count. So if we take that as our model, viewing a piece of content, and maybe scrolling down it is one interaction. Whereas the editor for a blog post inside of WordPress or something else - that’s going to be hundreds, thousands of interactions. You’re typing. You’re doing this stuff. And one way of maybe testing this theory is “Could you benefit from having a local copy of the data model, and having it sync up with the server?” So to the extent that that makes good sense from a sort of user latency perspective, and from a user experience perspective of the total end to end experience, should I have a CRDT, or should I have Replicache in my architecture is kind of this. But you can disaggregate a lot of these applications and say “It’s got a viewing mode”, in which case the denominator is one, or maybe less than five, on average. And then you’ve got an editing mode. And that editing mode is a much more sophisticated application, which may benefit from, I don’t know, having a local offline copy of your stuff, so that you can modify and edit your stuff, and sync it later. And a multiplayer version, be able to do that stuff, too.

So kind of disaggregating some of these applications is a pro move, but also just thinking about it from a top-level perspective of “Who are my users? Who is my median session? Who’s my P95 session? How deep are their sessions?” And if their sessions are pretty shallow - you know, every e-commerce yearns for deep sessions… But they’re generally pretty shallow. If they’re generally pretty shallow, then the denominator that you can divide the costs per interaction on is low. And so if you think about this in terms of the ideal architecture serving you up only the Delta in what you need, when you need it, per interaction style, to get to the lowest total cost per interaction over the amortized session depth, then you’re getting into a place where you can start to make these kinds of trade-offs. We don’t do that today with these things; we sort of kind of eyeball it and go “I don’t know, smells like an app.” But you know, most things aren’t. Most things just aren’t apps; they aren’t apps in that style of having deep sessions, which again, kind of reinforces our intuition that things stuff that needs lots of scrolling and panning in any session to be moderately useful, like Maps, probably need more infrastructure on the client, versus things that we could offload more to the runtime for us to do.

Right, like the VS Code in the browser, Google Maps, Gmail… These things where you have deep sessions, and you have a ton of interactions, and it’s too expensive to kind of do those round trips. So for that case, it’s like have a local data model, have an architecture for kind of syncing as often or as infrequent as makes sense for that application. And for things like your shopping websites, and for things where – yeah, everyone has this fantasy of people spending hours and hours on their application, right? But really –

Yeah. And you can investigate your logs; you can find out whether or not people spend hours and hours in your application.

Yeah. Use data to make that decision, to figure out how long are people actually on your site, or on that page.

[01:09:56.05] It won’t surprise you to find out that a lot of these things, again, they’ve got more little humps. They’re multimodal distributions. You know, working with the Word team. The Word team in their data know that some large fraction of sessions are basically viewer sessions. They look like reading a blog post. But it’s also an editing interface. Which means that they can, for people who are going to do long editing sessions, afford to load up a bunch of stuff. But most people aren’t, so they can’t. So the overriding concern – because you don’t know who’s who about most documents when you load them up.

But wouldn’t this be a – and by the way, when you say Word team, Alex is talking about the Microsoft Word team. And so, for example, with Microsoft Word, wouldn’t that be an opportunity to kind of break up that experience into two paths, where you have a read path and an edit oath, and by default you assume that everyone’s just doing a read, and then when they decide to do an edit, you flip over? Or you use that time, you use some background process to kind of buy you some time while people are in read mode, to get ready for edit mode… Or whatever it is; I’m just saying, wouldn’t something like that makes sense?

Absolutely, it does. And there’s a range of tools you can employ to make that mode switch more gradual. But it’s really, I think, informative to be thinking about what the costs are for most users foremost, first and foremost, rather than to fetishize your most engaged user… Because your most engaged user is going to be super-valuable to you, but if you’re not taking care of most of the people who are using your service most of the time, then you’re failing by default, right?

Coming back to this question of “What is the engineering manager’s job in this?”, it’s to ask “Who are we doing this for?” And then “What does it mean to succeed?” And then to phrase that as a series of metrics that get pushed back to the engineering organization to say “These are the things that we’re going to drive up.” And if you’re not phrased in terms of user success, again, your organization is just going to be a stopped clock. It’s right twice a day, but not more frequently than that.

Right. Twice a day, but not more frequently than that. That’s so funny. Yes, yes, and yes. And I would say for me there’s an education gap. It’s a knowledge and skills gap here. And on multiple fronts. For example, on the engineering side we don’t have enough kind of discourse, dialogue, examples of multi-architecture applications. So how do I support these different paradigms under one codebase, in one monolith, or whatever it is? So that’s one. The other thing is on the engineering leadership and product management side there’s just gaps, and I think in the way that we work, which don’t really make space for this kind of data-driven decisioning, right? And “Here’s some targets that we want to set”, and this kind of obsession with the user. I mean, honestly, Alex, I feel like you and I should work together, to either write a bunch of blog posts, or do a bunch of talks on this topic… Really, because I think this is something that needs to be taught, and it needs to be part of the wider discourse, and it’s just not. Can you give me an example of who’s doing this well? Outside of Microsoft and Google, places that you’ve worked.

I mean, doing which well?

Oh, this kind of setting benchmarks, and targets, and using analytics to kind of help drive architecture decisions, and so forth.

So most of the teams that I see who have actually got to a place where their systems are – and I just want to talk about this not in terms of which technologies you pick, but in terms of whether or not you are managing the technology, versus the technology is managing you. A lot of teams this never comes up in, because they pick simple enough technologies that they maybe have to fix some image loading or encoding issues somewhere along the lines, or maybe something went sideways with the fonts… At least in terms of performance. Or your problems will be just as simple with accessibility, because you - to Carson’s point - piled into HTML, rather than rebuilding the entire universe on top of a very small footprint of the JavaScript runtime, compared to [unintelligible 01:14:02.21] of the rest of the platform by default for you. So lots of teams end up with very small problems, and they fix them quietly, and we don’t tend to talk about them.

[01:14:12.29] The teams that I end up spending most of my time with are teams that have gotten themselves into the ditch. And they get themselves there on good intentions. No one’s trying to do a bad job, no one’s trying to do the wrong thing for the user. It’s just that the user was not put front and center through the entire requirement process. And pulling back from that requires management support. If you’d just do it as an engineer, if you’d just try to roll the boulder up the hill, you will feel like Sisyphus at the end, because without management support, it’s just going to be rough.

So the places that have fixed this are – I’ve seen great results out of Wix. They had a many-year remediation challenge where they had bought into the usual React nonsense, and that tanked their metrics… And then they got management support to go fix it, and then that turned into many years of not shipping features, but instead fixing the stuff that they had meticulously broken with way too much JavaScript. And then at the end of it, you end up with the infrastructure that you would have needed to keep any piece of technology in line, right?

Teams that have climbed the management maturity mountain can manage anything. Teams that have not climbed it will be done in by anything but the simplest technology. So from a management capacity perspective, the real magic is to marry the simplicity of the solution, to the capacity of the organization and its willingness to spend on keeping the complexity in check. So that means that the pro move for every manager who’s looking at a new project is to do a bake-off, because it’s going to cost you a lot less to spend the time to actually try stuff, to set up some pro user and pro marginal user metrics that you can judge against, and then to pick the simplest thing from your set of potential available options. The most option value that you get is the option value of not having to be dead in the water for six months, while you try to remediate something that’s on fire, like I’ve seen dozens of teams do.

People talk about “Oh, well if we do this, then we can do all of that.” Do you remember the – I don’t know if you ever saw Arrested Development…

Of course…

I think it was like the one Netflix only season…

Oh, I haven’t finished the Netflix only season.

Yeah, they’re buying a house, and the conversation with a circa 2007 mortgage broker goes “Well, if you have the extra bedroom, then you’ve got it.” And they look to each other and go “Oh, yeah, then we’ve got it.” And that’s kind of how I think - Carson, to your point earlier about how we’ve got this aspirational complexity budget in our heads, which is much larger than our execution stomachs are… You know, those eyes are outmatched by what we can actually handle. And that turns into a bad time, predictably. So it’s the role of managers to keep that in check.

Yeah. Hear, hear. And we’re gonna link – there’s gonna be a lot of links in the show notes, everyone. A lot. Actually, Alex, while we’re in this discussion, this is how I’m like – I want to know if Alex is human or not, because I know typically a human being is not capable of doing two things at once… He’s literally talking and sending us links at the same time. I’m just like “What’s going on?” We have a ton of links, from Alex.

But the visual that I really want you all to see is this lovely diagram that he put together around interaction depth, and the local data models, and… Anyways, it’s pretty cool, so check that out. And I think for me the cherry on the cake here is that we are starting to wake up to this, slowly but surely. I think people are starting to see that the world that we’re in is like “This is not sustainable.” And you can have an appetite for a Ferrari, but you can’t be driving a Ferrari when you have a Corolla budget, you know what I mean? And that is most teams. Most teams don’t have that Ferrari budget.

[01:17:59.29] And I think your blog posts, Alex, “Market for lemons”, which we talked about last time we had you on the show, which was “Web development’s lost decade”, I think that’s what the show was called… You know, we talked about how one of your frustrations has been that hey, for example tools like React are upfront about how much infra and maintenance and time you need to spend on pruning and maintaining and blah, blah, blah, blah, blah. It doesn’t just come for free. So your whole point was like “Hey, be honest about this stuff, so people can make informed decisions.” But the problem is we have this hype cycle, hype train, whatever, and no one wants to go up against that. I actually feel so sorry for the engineering managers that have to even talk about tools that are not React with their directors, or their engineers, or their ICs… Because it’s like “Why would we use something that’s not React? React is going to be easy to hire for, there’s all these existing open source things” etc. So that’s the argument that I think a lot of people are coming up against.

These are all nonsense arguments, by the way. And I don’t mean that in the sense of they are not marginally true, that there’s not a kernel of truth in them. It is possible to find lots of resumes that say React on them. But the idea that someone has made it to the end of the journey of putting all of the just totally useless stuff that you have to learn to sort of make a React app go, that that person can’t also learn HTML, JavaScript and CSS, or get their hands around the platform, or pick up HTMX… That idea is – it’s insulting to the people that you would hire.

That’s true.

And it’s so dumb that it really makes you think less of the person saying it. Because they obviously haven’t thought hard about this claim, either. So it’s a dead idea. And we can call it dead, and we can call it unacceptable in conversation, because it doesn’t ever come with evidence, other than there are a lot of resumes that say this. But I can tell you right now, we just put out a rec for some Web Components developers, and a lot of people say “Oh, well we couldn’t possibly hire for those skills.” And my intuition has been “Well, that means you’re not looking.” But now that – you know, we’ve just put out some Web Components recs for a team that I work with on the design systems side at Microsoft… I can tell you, people are coming out of the woodworks for this stuff. You can hire for whatever skill you’re willing to pay for.

So if you’re willing to pay for platform fundamentals, and then a little sprinkling of JavaScript with HTMX, or platform fundamentals and then a little sprinkling of Web Components, or whatever your flavor of the month is for a little sprinkling of JavaScript, I promise you, those people are available. I promise you, they’re awesome. And they’re not going to reach for things that are going to create a larger problem than they solve, most of the time. You’ll actually get better culturally-aligned values out of that population than you would by sort of the usual thing that people claim that they must have.

One thing – you mentioned earlier that class, they’re web developers, but they were CSS, and HTML specialists to an extent. It overlapped with design, and they got kind of pushed aside by the JavaScript world. And I do have to say, because I don’t live in React, I don’t have the same negative vibes that you and Alex have towards it. And obviously, HTMX has a different approach to things, but one thing I do want to say, to especially listeners of JS Party, is I would like to see HTMX deescalate the language here. Like, there’s not a silver bullet that’s coming from the React team. HTMX is not a silver bullet. The web platform is good for some things, and it’s bad for other things. And it would be amazing if we could get to a point where we could discuss those in a mature way, without saying “Okay, this will never work.” Well, it can be made to work. I’ve seen bad design decisions be made to work.

And if people could - you know, especially listeners of JS Party - could look at this as like “This is another tool. I can use it to save complexity here.” And the irony of HTMX for many JavaScript developers is that it actually makes the value per line of JavaScript that you write much higher, because you’re writing a lot less JavaScript. You’re saving JavaScript for those high-value spots where it’s important to get it right for the user. And you leverage the platform for the other stuff.

[01:22:18.15] It’s kind of a waste of the power of JavaScript to use it to get a form into a database. That’s not what it was designed to do. It was designed to – again, Roy Fielding, the guy who wrote that dissertation, said that the scripting is there in order to provide functionality that the platform doesn’t already have. And so okay, make drag and drop work for elements on an HTML page. That’s something that is not baked into the browser, and that’s a great use, an amazing use of JavaScript, that makes the user experience significantly better. Use it for something like that. And again, the value that you derive per line of JavaScript written goes up significantly.

Sometimes you see this - and it’s true, there are people who really hate JavaScript and love HTMX, because they don’t have to write any JavaScript. But the truth is, to use JavaScript as effectively as possible, you have to understand the platform, and JavaScript is part of that platform. And so there’s an opportunity – you know, one thing I’ve said is that I think that the most effective HTMX users five years from now will be people who really understand the web platform in its entirety - CSS, HTML, and JavaScript - and who also have a strong sense of what they can accomplish on the backend. I often say in SQL, but SQL is just a stand-in for whatever backend technology. But I think there’s an opportunity, and that would allow some of the people who have been pushed aside because their knowledge is mainly CSS and HTML.

HTMX also boosts the relative value of HTML and CSS, because it takes out this layer of junk you need to deal with to make those effective for modern user experiences. So it’s just something that, especially being on JS Party, I want to mention. I don’t want HTMX to be viewed as the anti-JavaScript framework. It will, to some extent, because of the way it’s set up, but I really do think that, again, it drives up the value per line of JavaScript that good JavaScript developers, who know the platform well, can achieve.

Yeah, so well said, Carson, and thanks for that excellent point. I mean, you have to understand, Alex and I have been ranting… We have a text thread – we have threads on different platforms, I should say, but we’ve been ranting about this stuff for years. So I think it’s like, you get two salty people together that have been ranting about this, and it makes it sounds like the opposite of what you said… But yes to what you said. And I think we’re both definitely aligned with that. And I would say that I want to make sure that Alex – I think his point about React specifically, it’s not that it can’t work, it’s just that it you need all these other things to make it work in the way that you think it should work, or could work. Right?

Yeah. And if you’re happy to pay that cost, then your team is paying full freight. The place that I spend a lot of my time, and therefore have a departure and experience with maybe some other folks, is that I spent a lot of time with teams who are having a terrible time. And because of the kind of toxic positivity bubble in the JavaScript community for the last decade around a lot of this complexity we haven’t talked honestly about those costs, and that means that teams get ambushed by those costs. And that’s bad for the teams, and it’s bad for the products, and it’s bad for the end users… And I care about all of those constituencies, so it’s not a “This can’t work.” Like you said, Carson, you can push a lot of bad ideas along the way with enough effort. It’s just that I want us to get to a place where we’re having an engineering conversation around that delta, in both cost and capability, rather than sort of reiterating a bunch of old wives’ tales about how it could possibly go when we have more data available to us.

Yeah, totes. And I think one discussion that we are not going to have time to really dig into here, but I would advise everyone to go listen to the interview that Carson did with the Go Time team - we’ll link that; I think it’s episode 266, around kind of the full stack developer. I want to have that conversation with you, Carson. I don’t care what you’ve discussed with the Go team, but you and I need to talk about that on air one day in the future… Because honestly, I have so many thoughts on this, and I think there’s a crisis identity around that, what is frontend, what is backend…

[01:26:26.01] And as these things are interdependent, merging, talking to each other with the translation layer like JSON, or now kind of being able to make that simpler with just HTML… I mean, there’s so much to discuss there, we can’t get into it today. But I do want to touch upon Web Components and how HTMX plays with JavaScript specifically.

So I haven’t used HTMX in any production context, just outside of looking at the docs. I’m very eager to try it… And so, for me, my mental model of kind of looking at this as it feels like it kind of draws the outer boxes. It helps you manage that transclusion. But what’s inside the HTML that’s being transcluded? This swap, this element, or tree that’s getting swapped in - that can be anything, right? Custom elements, web components… So I just want to talk about this - Lit elements are my favorite thing in the world. I love the Lit API. It just makes it so easy to work with web components. And Lit is having a huge surge in kind of adoption. Eager to have Justin Fagnani back on the show again. For those of you who missed it, I highly recommend checking out that episode. We had him on the show a few months ago. And so how do Web Components and HTMX - how well do they play together, how well do they work together?

They play pretty well together. In HTMX 2 we have an engineer who has been working on making HTMX attributes within Web Components work. There’s always that getting across the fence to the other side, it’s always a trick. My theory on Web Components - they work… It’s just HTML. That’s one of the nice things about HTMX, is it’s leveraging the platform. And so as long as we don’t do anything to screwy, they just kind of work.

But I think the integration story between Web Components and HTMX is, again, events. That to me is what the DOM is; it’s this hierarchy, this tree of elements. And looking back historically, the way that you’ve done loosely-coupled user interfaces that sort of interact with one another without a hard interface between them - because there’s not; there’s no type-safe interface on the DOM - is via events.

Now, events are tricky, and I’m old, so I programmed in something called HyperTalk, which was this thing called HyperCard back in the day… And so I’ve just always had a soft spot in my heart for events. Event-oriented programming does take a little bit to get used to, particularly if you’re not just saying “I just want to handle clicks on this button.” If you start saying things like “I want to listen for an update event from this point in the DOM.”

So there’s a different mindset to adopt, but again, my theory here is that any sort of client-side enhancement, even if you were to say “We’ve got this little bit. We’re going to do it in React, because React has this feature that’s super-important to us for this part. But we want to integrate it with HTMX”, I would say use an event. Have that thing when it’s done doing its mutation, when it’s built up the state locally that is ready to be synchronized to the server… At that point, have it emit an event to HTMX, and then HTMX can take over and do the state synchronization, which is what it’s good at.

[01:29:45.27] So I think the same thing with Web Components. That’s what I would look to in the web component world. And I say the same thing with JavaScript libraries. People ask me “How can I make my JavaScript library work better with HTMX?” and I say “Emit a bunch of events.” Because the more events you can emit in your lifecycle, the better an HTMX user can respond to those events in the ways that it’s appropriate for their use cases.

That makes so much sense.

This matches with my belief about why we built Web Components, was to return the idea of the component model to being something about creating things that platonically feel just like HTML elements. And that means that they coordinate with their tree peers and siblings and parents through events, and that they respond to attributes, and JavaScript property changes like everything else. And so HTMX as a thing that just lives in and with and around HTML should – if your Web Components are built well, should just work. This is the magic of things being composable on the DOM interface, and the idea of the platform being a platform for you, rather than being an inconvenience that you target by side effect later.

Yeah, yeah. Hear, hear. And I guess another point to add here was - and you put this in the chat, Alex, so this is actually your point, which is not a React event, but a real event, right? Because React uses synthetic events. So if you’re trying to pub, or wait for events, and all of that, just use the real DOM events. And I have to say, the on load events on elements - that’s probably been the API that I’ve used most consistently throughout my entire career. I mean, the DOM is really rich in events; it’ll tell you when things are done loading, it’ll tell you all kinds of things. You’ve just got to listen.

So thank you for that amazing PSA, Carson… And so we’re just going to end this conversation just talking a little bit about the delta that you see. I want to hear from you, Carson, on what is the platform missing? What’s missing in browsers to kind of really elevate us to the next – that’ll take us through the next era of the web? So what are we missing?

Yeah, well, I hope at this point people are starting to take an interest in HTMX. As far as just the concepts, one thing I say is that I think the ideas of HTMX are probably more important than the implementation, which is written by a flawed person… But that idea of generalizing hypermedia controls - I’d like to see discussions around that at the platform level. And the tricky part there - and this is another long conversation - is getting accessibility right for a lot of this stuff is hard. And improving that, so that things are more accessible by default. I think it’s unrealistic – one thing I say is “We should try and make accessibility accessible.” And one of the glories of the web is that anyone can create a webpage. And I think it’s a shame to gatekeep that. I loved the early web, when you could right-click and view the source of a page, and see what was going on. So taking just this idea of generalizing hypermedia controls…

Another big thing - and boy, this is pretty nerdy… But the ability to reparent an element in the DOM without losing the state associated with that element… So right now, if you take a video element and move it in the DOM, the video stops playing, and kind of restarts. And similarly, if something has focus, and you move it from one spot to another, it loses focus, and so forth. And if you were able to move things around, and not have them lose that sort of in-flight state, you could do a lot of very interesting transclusion work, where elements could be preserved between navigations. And even at the top level - imagine a world where you could just have an anchor tag, and you could mark a video as like “Keep this thing around.” And all someone has to write is an anchor tag, and they can click, and go to another - maybe a detail page for the video. The video keeps playing, but they’ve just authored HTML; they haven’t had to do anything beyond that. That ability to do – I call it stable reparenting, where elements don’t lose state; that would be a huge feature in browsers. I think a lot of people who are building on top of JavaScript would love that feature. I don’t hear a lot about it, but I think if you showed it to them, it would be pretty mind-blowing.

[01:34:18.01] Yeah. I mean, that’s that sounds amazing. I’m like “Take me there. I want that future.” That sounds really excellent. And I just really – Carson, you’re just so humble, and I’m just so thankful for your contributions to these important… Not only discussions, but I would say paradigm shifts that I think we’re slowly but surely, hopefully going to have. And it’s just so great to hear that you’re not antagonistic to JavaScript either. That you understand that it takes three to tango on the web, right? JavaScript, CSS and HTML. You need all three to tango well. You can do a pretty bad tango with just one or two of those, but to get the right mix, you need three.

So I think for me as kind of someone that’s really passionate about technical education, it’s definitely a drum that I hope to be able to kind of continue beating throughout my tenure here on this podcast, and hope to have more discussions with folks like you, hope to have you back on the show, Carson… There’s so many takes that I want to hear from you, including your take on the Imp, which we’ve kind of briefly – so I think Alex mentioned it an hour ago, or something like that, but we didn’t even get to click into that, is interaction to next paint… Which is a new Core Web Vital that’s landed, that we’re all really excited about. We’ll probably do a show on that at some point soon. So just, again, many thank you, Carson, and many thanks to you, Alex. Alex, any kind of closing thoughts from you before we kind of wrap?

I would just say that – we touched a little bit on how the browser kind of stopped delivering. We kind of got ourselves into a rut after the initial burst of energy around… The initial, to borrow your phraseology, Carson, the hypermedia controls… And those built-in controls are extremely powerful, and they have not been configurable enough, and that has meant that people have lost faith in them, and sort of moved to other places to get what they need done. So I would say if you care about those things improving, the Open UI community group is still looking at those and they could use your input. And we are starting to be able to deliver some of those things into the platform a little bit more credibly now, because browser competition is actually potentially going to become a real thing again. And I know this is a much, much, much, much, much, much longer conversation, and I’m looking forward to hearing your –

Yeah. I forgot that we – we wanted to talk about this, and we completely missed it, Alex. Browser choice… Yes.

Well, I’m looking forward to hearing your conversation with the Open Web Advocacy folks, because they’ve been doing the most important work, I think, on the web, in the last couple of years. I mean this in an absolute sense; of any group, they are probably the most leveraged set of people, who have created a larger, better potential future for us. Because in a lot of ways, what we can ask of the platform is gated by the total channel capacity of the teams that implement browsers. And so if those teams are underfunded, or they’re stalled, then we can’t ask for very much, and therefore we don’t get very much. And so they have been doing the most to unblock that pipe, and keep it open… So again, I can’t wait to hear what they’ve got to say on your episode with them… But I would just say if folks aren’t aware of what they’re doing, they are looking for volunteers at open-web-advocacy.org. They’ve got a Discord, they’ve got a whole kind of rigamarole going, and you can be part of the solution, too.

Yeah, yeah. And just thanks for ruining the surprise, Alex… Folks don’t know that I was going to have them on the show. I guess they do know now. But yes, we’re gonna do a show with the folks that started the Open Web Advocacy Group. It’s a group that’s really been kind of fighting really hard… And literally, consulting with nation states. They’re meeting with Korea, and France, and the EU. And it’s crazy. But they are talking to all these large, important entities about the importance of the web, and the importance of free and open web with browser choice.

[01:38:13.03] And that’s just one thing, I think – I know there’s other aspects that they’re also advocating on… And they’re just regular developers us. And when I say regular, of course, it’s regular in quotes. But these aren’t policy PhD’s, or engineers that we know. Including our very own Feross. Our own Feross is part of that group. So I’m excited to have them come on the show and talk about that important topic. Obviously, Safari’s slowly gotten off the bench with kind of their support for PWA’s, but it’s far from where it needs to be, and there’s just bugs in the implementation, and blah, blah, blah, blah… Really interesting to see DHH kind of yell about this on the internet as well this past week, as he’s having trouble getting his app on the Apple’s App Store approved, the Hey calendar; it keeps getting rejected… According to him, it’s because they’re not willing to do kind of in-app purchases, and give Apple that 30%… But who knows? Either way though, no company should stop you from putting out a product onto the internet. And this is why we need to fight for the open web.

And so we’ll put links into the show notes for you all to see funny tweets from DHH, including a really funny – did you all see the one where he… Alex, I know you’re not on Twitter, but I sent you this link. Oh, and by the way, everyone… You remember last week I talked about a friend who judged me, one of the friends who judges me every time I send him a Twitter link? It’s Alex. Alex Russell judges me pretty hard. Yeah, he’s put his hand up. Yeah.

Don’t be on Twitter, y’all. There’s other places. You don’t have to go to the Nazi bar. It’s fine.

Oh, good, Lord… Anyways. Nazi bar… Oh, my gosh. Anyways, so there’s this tweet where he – “What did the DHH do?” This one was hilarious. Yeah, he basically sent his mob of reply guys to Apple, because Apple basically said “What do you want the App Store to do?” or something. I don’t even know. Or what are your favorite apps, I think, of the year; productivity apps. And then all his reply guys started hounding Apple’s marketing team around “Here’s an app that I wish was on the store.” So anyways, pretty hilarious. Sorry for the tangent, but…
So to wrap up our show, this was an epic, long discussion. It’s gonna require, I think, a couple of listens for me, as I unpack all the information that was shared… Carson, any kind of closing thoughts from you before we wrap?

Yeah… Again, I just want to stress that deescalation. Hypermedia is a tool, and I think it’s an interesting tool, even if your listeners don’t end up using it… We did release a book, it’s available for free online at hypermedia.systems, and that’s particularly for developers who just have never really worked with a web 1.0 style application. That’ll kind of walk them through the history of hypermedia, and then it builds a simple web 1.0 style web application, and then enhances that with HTMX. So that might be a good sort of more long-form introduction to HTMX.

There’s a lot of stuff on the Essays page, htmx.org/essays. Some of those are pretty serious, some of them are less serious… And definitely, the least serious of the bunch is my – I’m sorry, Alex, but my Twitter account, which is twitter.com/htmx_org. Every time I think about going to a Mastodon server, there’s always a [unintelligible 01:41:30.18] stipulation, and I’m like “Oh, man, I don’t know how to do it without [unintelligible 01:41:38.08]

[laughs] Alright. Well, and are you available for hire for other library authors or maintainers that need some marketing help, Carson? I’m just curious…

No… I’m literally the dog flying the airplane, that has no idea what it’s doing… I’m just like “I don’t know, man…” At some point this all ends in tears.

Oh my gosh, you’re too humble. Well, again, many, many thanks to both of you. So Carson, where can folks find you on the internet? Same question for you, Alex… If they want to connect, what’s the best way for them to connect with you all?

BigSky.software is my software company. It’s just me… I don’t know, go to Montana State… I’ll teach you some computer science if you go to Montana State.

Are you guys available online? Is there like an online course that people could join, where you are their professor?

No, we don’t have anything online.

Good. So they have to literally fly to Montana.

Yeah. Unfortunately, at this point you have to go to Montana State. I don’t know…

Okay. That’s not bad. Montana is a beautiful state. I would love to go.

Yeah, Montana is – it’s very cold, but it is very pretty.

For sure. How about you, Alex?

You can find many links at infrequently.org, and a lot of very long blog posts that cover some of the background about my education, and links to other ways to get a hold of me.

Yeah. One of the best blogs on the internet, by the way. So everyone should RSS feed that; hands-down incredible writing. And thank you for all the advocacy and the work that you do as well, Alex. I super-appreciate you. And so with that said, we are gonna wrap, kids. It’s been a long one. Many thanks. I hope you learned a few things, and I hope you all get to play around with HTMX. And also Lit. Play around with Lit, too. Alright, take care, everyone. Bye!