HTMX Web Apps with Carson Gross

Welcome to Syntex.

On this Friday's supper club, we have Carson Gross here. We're gonna be talking all about HTMX.

We're gonna be able to pick the brain of the hypermedia man himself and talk all about everything, that you all have been asking about since our 1st from Denver. With me, as always, is Wes Bos. What's up, Wes? Hey.

Not too much excited to have Carson on today to ask him all the questions that we have about HTMX and, understand what's going on here and and hopefully clarify. Because, like, we had tons and tons of feedback from that show, and some of the stuff was valid, and some of the stuff was just like, oh, you act I don't think that you totally understand how it works. So, hopefully, we're gonna clarify all of that. Yeah. Totally.

And, also, if you're asking questions of your Node, like, hey. Why did this bug happen? Maybe you want to have a tool like Sentry on your side to reveal all of those bugs and why they happen so that way you can go solve them. So if you want to use a tool like that, head on over to century.i0forward/ syntax. Sign up, and you'll get 2 months for free.

Carson, how's it going, my man?

It's going pretty well. A little crazy. Things have been crazy since, last July in HTMX land.

For sure, got a a lot more attention than I was certainly used to, when the Primogen picked it up and FireShip dev, did a short on it. And so there's been a sort of a huge amount of attention.

Little overwhelming, but, you know, it's all good. It's fun.

Yeah. Was that the sort of catalyst for the It was.

I was I was sitting on a on a bucket at a at the Scott youth baseball championship.

I'm a baseball coach here, and, I just checked Twitter and was like, that can't be right.

And it's kinda it's it's been that can't be writing for since about July. It was really good. I got very lucky because I released a book, like, you know, at the end in at the end of middle and end of July last year, and so it really helped. Just a lot of things kinda came together at one time, so very lucky in that in that sense.

Cool. Well, do you wanna give a a brief introduction to who you are and what you do, to our audience?

Yeah. I, so my name JS Carson Gross. I I run Big Sky Software, which is a Big Sky Dot Software.

And that's just a consulting company that I run that supports my open source work for the most part. And then I teach my primary job is I teach at Montana State, which is where the primogen actually went for under his belt. Nice.

So, funny connection there. Did you teach him?

I didn't I you know, I did not. I know people who taught him, though. There are people that are still there that he that he knows.

So So all of these HDMX ideas are, like, institutionalized at a a very high level?

Yeah. We're trying. I mean, I'm sure yeah. It's I'm trying to write actual academic papers on it, and we'll see.

The academy is kind of its own thing. So,

Oh, so you're out in Bozeman? Yeah. Bozeman, Montana. Yeah. Yeah. I've been there a few times. Yeah. It's cool town.

The joke is that, the the nice thing about Bozeman is, like, it's right next to Montana.

Like, you can see you can see Montana from Bozeman. So,

there there's some, just I don't know. The the vibe out there is really great. Obviously, the the skiing and mountain stuff is is wonderful too, but, yeah, big fan.

Yeah. Yeah. It's a cool town. Don't move here, but it's a cool town.

Yeah. I get it.

And, like, what led you to developing what HTMX is? Actually, maybe let's step back 1 step further because people are probably tuning in to the 1st couple of minutes and being like, should I listen to the rest of this one? Right. What is HTML for anyone who hasn't heard of it?

HTMLX so, basically, you can think of it as HTML plus plus. It's it takes the ideas of HTML, in particular, anchor tags and forms.

And then when I say, those are to use some fancy terminology, those are what warp called hypermedia controls.

One of the interesting things about HTML is that you embed these controls, the things the things that do stuff inside the document itself.

And, Scott what HDMX does is it takes those 2 ideas, forms and lengths, and then tries to generalize that idea.

So, it it lets you put attributes on it in HTML that let you trigger, an HTTP request based on whatever event you'd like. And then that HTTP request is going to be, returning HTML rather than JSON, which is what's normally, used for, for AJAX Wes these days. And then that HTML is placed in the dom somehow.

And so h t HTMLX basically just provides you there's, like, 7 or 8 core attributes that let you generalize that idea.

And, this is surprisingly powerful 7 or 8 attributes. You can do quite a bit with it. So if listeners wanna go to h t m x x.org/examples, we have, like, infinite scroll can be implemented in those terms.

Active search where, like, you type something and then the results kind of immediately come back. That can be implemented using 3 or 4 HTML attributes. And it's all done in terms of HTML rather than sort of reaching for a a thicker client side model.

So that's that's the big idea there. It's, again, I think it's probably it sounds pretty simple, and it isn't super complicated to implement either. But, it's a surprisingly powerful idea.

I think that hypermedia is underestimated by most people today because HTML has unfortunately just sort of stopped making progress in that area. And so, you know, people, when they think about hypermedia, they think about clunky, you know, full page refreshes and so forth. All the browsers have gotten better at that stuff. So

Yeah. One thing that I've really noticed is that when when you bring up HTMX, people are so quick to say, well, you can't do x, y, and z with it. And I do think that one of the smartest things that you've you've done on the site is have this examples page. Because if people were to just take a quick glance at this examples page, you could see that they're really you know, that kind of invalidates many of those those conversations because people just straight up they underestimate it, like you said, and they underestimate what it's capable of, especially with in the fact that many of the times when we're doing a lot of this stuff, you know, deleting a row or or, like you said, searching, you're having to hit the database anyways. Right? You're having to make a server trip. So what Yarn we doing just ESLint JSON and then, you know, using JavaScript to distribute that? And and so I I think that's really powerful. I wanted to know, like, what was the the catalyst that made you want to create something like

Yeah. So the original HTMX was Intercooler. Js, which was released back in 2013.

And, that was based on some work that I had done internally at a Scott up for a friend, where and, it's kind of funny, but I was trying to sort a table, and I was trying to do it client side because in 2013, all the cool kids were doing stuff client side and JavaScript.

I was using jQuery because in 2013, everyone was using jQuery, and, I just couldn't make it fast. I was trying to sort a table. There were a couple 1,000 rows in it and, browsers at the time. I'm sure now browsers can handle it without breaking a sweat.

But at the time, the browser run times were not as good, and so it was very slow.

And, I ended up, out of desperation, just trying this technique out where, jQuery had a few methods for for issuing a request and then slamming the results into the DOM. And, I did that, and it was it was very fast.

This was a Rails app at the time, and, I was a little bit shocked by that. And so I started writing. I I I I I recognize that technique.

There's also something called Pjax, which is sort of an old Mhmm. Older take on this idea.

So there were some ideas floating around, and I, I I then saw Angular one and the way they use attributes. And and I thought to myself, well, I'll just use this this attribute idea, this custom attribute idea to to basically drive this little custom function that I've been using to do the same pattern, and that eventually grew into Intercooler JS. So it came out of a performance, but at the end of the day, it was a performance issue. I wasn't super passionate about hypermedia at the time. Mhmm. It was only after I released it that people pointed out to me, hey. You know, this is restful. This is, like, real rest. I don't know if we wanna get into that or not, but this is a you you know, the language I would use today is, like, this is a hypermedia oriented approach to web development that you're doing. So, you Node, and, eventually, I I learned a bunch more about that and kinda wrote a bunch of essays and, understood what I was doing a lot better, you know, over time. And, the HTMLX is basically a rewrite of Intercooler Wes where I pulled out the jQuery dependency just because, JavaScript has made so much progress in the last 10 years. It was it was possible to do that in a way that worked across most of the major browsers.

Yeah. I remember Pjaxx first hitting the scene, and it blowing my mind. Being like Yeah. Wait a second. We're doing a a a route here without a full page load.

Wow. This is this is crazy. Yeah. I could have an, I was building, like, an audio player on a site. And the fact that I could change routes and have that audio Scott restart like, totally scrap out everything

we've done and and done it from, like, totally scrap out everything we've done and and done it from from the beginning. Like, do you think that we would have some declarative ways to do what we're doing, to to run fetch and and get parts back? Do you think that, like, HTML might look like or sorry. HTML might look like HTML if we were to scrap it and start fresh?

I don't think you even need to scrap it and start fresh. I think that the ideas of h t I say this a lot. Like, HTMX is cool and, you know, it's it's not like it's a big library.

It it it'll be useful for people that adopt it. But I think the idea is, like, the essays, h t m x.org/essays page, and then our book at hypermedia.systems, which you can read online for free. It just talks a lot about hypermedia in terms that normal developers can Unfortunately, the hypermedia world can often be pretty academic. There's a lot of negativity in it as well, I've noticed. I don't know what it's, you know, but it it's whatever.

But the ideas there are good, and they're interesting. And so I think you could take the ideas of and integrate them into HTML in maybe a more standardized form. Like, okay. Maybe you don't want everything to be a hypermedia control because of accessibility issues, but, like, let's just look at buttons and make it so the buttons have the ability to be stand alone hypermedia controls. And, I think you could start making progress again.

Progress again as a hypermedia.

There's also some, like, frame sets. There's some ideas that, HDMAX kind of led to your gives you a lot of flexibility around that were there in nascent form early on, like framesets and I like, you can target an iframe with a link. It's just that iframes kinda stink. They can't participate in the DOM. There were frames and there were frame sets, and and those have been deprecated to an extent. And so there there I think the ideas are kinda laying around, and, my hope is that HTMLX helps sort of spark those, you know, spark the thinking around what what could HTML be? Because I don't think HTML can you know, Figma, for example. Like, h you're not building Figma in HTML, or at least you're not building it in, you know, HTML based logic. Like, there's just too much going on there.

But on the other hand, there's a lot of apps that probably could be built in pure HTML, and very effectively if they were to start, you know, picking off some of the bigger ideas from HTMLX.

Yeah. And, you know, it it is something that I've been really paying attention to when I use various apps that I use day to day. Like, I I tweeted about this. It was, you know, like, how many of these things really need anything more than HTMX to do what they're doing? And I don't know if it's that people don't realize that you can do things like, you know, streams or Vercel and events or stuff like that. But there it JS really way more capable.

But the Node comment I I I tend to get on repeat whenever I bring this up to people is why would we go backwards, Wes we went forwards to this, you know, client side and now SSR and hydration world or even resumability world.

And that it's a step backwards into, you know, old school Ajax.

Do you have, like, a a a comment on on that,

kind of response that people typically have? Yeah. I think, you know, I look at it like a more of a Hegelian dialect. Like, you know, it's a dialectic.

Like, we we were all Vercel side.

It's not thin client, but hypermedia oriented, where hypermedia was really running the show.

And then we moved to, to the the reactive thick client model. And, you know, in some ways, I have to say, even reactivity isn't new. Like, in the eighties, we were building apps in this way. You know? Like, we had if you only look at, like, Java ESLint, for example, it has reactive aspects to it. There's a lot of infrastructure there.

And, you know, I built I built apps like that. Initially, this is kind of ironic, but initially, I sort of rejected the web, and I built web, Java based remote app you know, using what I would consider a real remote protocol rather than JSON.

And so I've you know, I'm pretty familiar with that stuff, or at least I was. It's been a long time.

So, you know, I think there's there's been more in back more back and forth, particularly if you step back than, probably appears to particularly younger web developers.

And so, you know, I think there's a there's, again, there's a dialectic here.

The original web HTML, it was amazing what we accomplished with HTML. You know? Like, the web apps that we were able to able to build, it just showed the power of, you know, the the network and because it was clunkier. And and a lot of people complained about, you know, web apps versus the thick apps they were used to. But web apps still kinda won, and the web still kinda won.

But then, eventually, we realized, okay, this use the the user experience that we can produce with hypermedia isn't good enough, So we need to start moving towards JavaScript based applications, and that's fine. But then there was also you know, in my mind, HTML just kind of Wes always, hamstrung by not continuing to add features, hypermedia features in any event, as it made progress. And so I view HTMX as sort of like a an Scott not necessarily a return to, you know, an older model so much as it's a, it's it's building, taking some of the good ideas from today, you know, and then building on some of these older ideas as well. And so I think there's a dialectic in play there. And so h t m x. H t m x isn't right for everything. There's a lot of apps that it doesn't it just won't work for. Yeah. And we have an essay up on that Wes to use when to use hypermedia.

So, you know, I think I just you Node? Oh, it's an endless cycle. I don't know. Mean, we're making progress. HDMX is better than p jacks in many ways, so we're making progress.

Yeah. What are some examples of apps that are, like, you you shouldn't build with with HD Max? Like, when should you personally, do you think that you should reach for React or some sort of SPA framework?

Yeah. Well, I don't know about React because I just to be honest, I don't have a ton of experience with it, so I don't know what it's good at.

But obviously, Figma is something you're not building in HDMX.

And similarly, I you know, another example that's given in that essay is something like Google Sheets would be difficult to implement in, h t m x because in Google Sheets, you've got very fiddly interactions.

You update 1 cell in Node part of the screen, and then you've Scott update some other cell in another part of the screen, and that's all highly dependent on the formulas, and it's very difficult. Like, all you know, with Wes tabular data, then HD max can be very effective. Like, if most of your value is being added on the server side rather than on these client side interactions, which is the case in a lot, like, ERP apps and, you know, any sort of app where you're coordinating human or Node any coordinating activities. Like, very often, the the value of the app is is on the back end. It's not in the front end. And in those types of applications, HTMX is maybe a better option because not because you can do better u UI with it, but just because you can do good enough UI.

And you're adding your value on the back end, and then you save a tremendous amount of complexity, hopefully. And then that, you know, that complexity that you save on your front end can be dumped into functionality on your back end instead where where there's more value to be found.

And do you think that puts more of a more of a a load onto the server, to do more? I think that's a a comment I get a lot. You know, I've been talking a lot of HEMX ESLint the the Svelte Discords and stuff like that. And people say, well, that's putting a lot of that, resources now that you need onto the server rather than dumping it into the client.

Yeah. I you know, I mean, there's some truth to that. Like, the an HTML app is going to be less burdensome on the client because we're just first of all, we're just parsing HTML, which is done in, you know, c like, we're not we don't have a lot of heavy JavaScript logic.

That's actually typically a good thing because it means your client can often perform more quickly.

But, you know, the one thing I've tried to point out to people is that the difference so okay.

The difference between rendering a JSON representation and rendering an HTML representation, particularly if you have compression enabled, which you should, is actually very low. Like, there's there's not a massive difference between the 2. And, so, like, you know, if you have tabular data, HTML JS actually more efficient in some ways than JSON because JSON repeats field names, right, unless you do, you know, something crazy, in your formatting.

And so, I don't think there's as much of a CPU and memory and network, transfer time difference between JSON and HTML as many people suspect.

And so, you know, that's the first thing that I'd say. But on the other hand, what HTMX does imply is a network request, for some interactions.

Not all interactions, but for some interactions. And so there's a network latency there that is present in HTMX that might not be present in, you know, a a well tuned SPA application, because a well tuned SPA application might do an optimistic update or whatever, you know, or might be able to do something entirely client side. Now that being said, there are tools available in HTML like the details element, for example Mhmm. That are there to support client side interactivity. And HTMX is not against client side interactivity, per se. Like, we encourage scripting. We just say you should script in an an an a hypermedia friendly manner. Like, you shouldn't be doing you basically shouldn't synchronize state with the, server, in a non hyper medium way. Now that's you know, I'm pragmatic about it. Like, there's gonna be times when you're just gonna do that, and it's fine. I'm not gonna hunt you down about it. It's fine. It's all good. We gotta get work done. Mhmm. But, so I think that there, you know, there is some truth to that, that there there are gonna be user experiences that are difficult to achieve in HTMX, that are easier to achieve in SPAs. On the other hand, what I would say is is your experience with SPAs universally good? Mhmm. Like, this this promise of performance we've gotten, I I would say, has not been achieved as broadly as many of the advocates for SPAs would suggest. It's it's hard to do. There's a lot of layers often between, like, the front end and the back end. It's you know, it can be difficult to figure out exactly what's happening. And, so that can lead to, you know, the the sort of famous, GIF of, like, you know, an Yarn argument in favor of SPAs, and then it's just a spinning GIF. Right? So Oh, yeah. You know, SPAs can be done very well. I don't wanna say they can't. But on the other hand, I think you can build very good HTML Bos applications that don't overburden your server.

HTML JS focused on updating partial bits of HTML, and partial bits of HTML can be very efficient to generate. They can actually be more efficient to generate than, like, a bunch of JSON API calls to to build a particular part of your UI. Mhmm. And what what about

your thoughts on, like, a lot of these frameworks right Node? Obviously, React Vercel components.

They are now saying, alright. Well, let's render everything on the on the Vercel, because in a lot of cases, that makes sense. Why send the JSON and the library to build the table and all this other stuff that you need just to render it out in the browser? Just do it on the server where it could be a lot faster and then just ship the the actual endpoint. Right? Like, clearly, that's going to be in in some cases, in a lot of cases, that's going to be a much smaller payload that needs to be shipped to the end. But you can sort of, like, dip into front front end stuff as as well if you need it.

Do you have any thoughts or opinions on sort of that trend as well?

Well, I agree to you know? I agree.

You know, I I I I think that those approaches from what I've seen, and I'm not an expert on that stuff. You know, I get people that come in on Twitter and are like, oh, you know, have an opinion on server components. I'm like, I can't even have an opinion on React, really.

So, you know, I but I I think JS as well as I understand it, my my criticism of that would of React components in particular, and I even this might be wrong because there's someone I think who's doing work to make this not true, is that it tends to tightly couple your front end and your back end. Like, now you have to be running React type code or JavaScript on your back end. Whereas if you if you just take the hypermedia model and say, okay. We're gonna exchange hypermedia. One of the good things about HTMX is you can pick whatever back end language you want, and that's something that I'm pretty passionate about. I you know, there's been a a a meme going around, like, this lava flow kinda, right, coming coming at people, and there's this sort of fruitless person using a a backhoe trying to, you know, save a street that's obviously gonna be destroyed. And the the title says this is back end developers trying to prevent JavaScript from taking over the world.

I think if the situation is not that dire, and I I've seen a lot of people in the Go world, obviously, the the Django world, the Python world, pick up HMX. And I think HMX does give life to some of these, back end frameworks that, you know, have been for the last 5 years in particular kinda shunted aside in favor of the, you know, what a lot of people seems like the obvious pick of JavaScript on the server. That's not to say I'm not in favor of JavaScript on the server. There's some very good run times Node, but, and, you know, I think there's reasons to pick it, but I I I don't like the idea that, like, you have to you have to pick it on the server side. And so that's that would be and even that even that's not a particularly informed criticism because, again, I've seen someone claiming they're they've been implementing, React Vercel components in other programming languages.

It makes sense that you you can do that. And, like like, my so I build full stack JavaScript applications, and my back end is 90% not it's not React. Like, my logic is not yeah. I'm not writing database queries in in JSX. I'm writing it in JavaScript, and then I pass that data to my templating layer. And and that that's at the point where you you sort of pick up React, but I do think that it's important because a lot of times people just assume, like, that's the only way to build these types of things, and they realize, like, no. There are large companies out there that do not have a tightly coupled front end and back end, and they they need something like this. So I thought that is is pretty neat that you can do that JS well as, like, some people prefer to build their logic in PHP or Ruby or Python or all these different languages.

Yeah. And one of the things I say is, like, I'm never gonna be a ESLint person. You know? I may use Go at some point in my life, but I'm never gonna be a Lisp person.

But I think it would be a shame if the Lisp community was not able to participate in web development because we had just decided, okay, we're gonna do everything in JavaScript.

I think it's good for a list of people to exist and a and the ESLint programming language to put pressure on other programming languages and so forth. So I like that diversity of back end, choices for for web development, which I think HTMLX helps with.

Yeah. I I I think there is some poignant things in there. Like, the fact that I did hear this criticism, from React folks a lot when talking about HTMLX was that it it does tightly couple your your server to the UI because you're sending HTML.

But, unironically, they're not even recognizing the fact that if you are using React Vercel components, that's a much more tightly coupled system.

Given that you're saying that, you know, you like that it can expand to all sorts of different back end languages.

Personally, like you, if you're writing an app, what is your favorite stack to work in?

Well, I worked in Ruby for a long time, and there's an awful lot of, tools in in Rails in particular that are just there that are really nice.

I don't do I may start this summer doing some web development again, but I don't do a lot of day to day web development, unfortunately, right now because just so I'm so busy with teaching.

But I I would probably, at this point, I would take a hard look at Django. I didn't pick Django for the book, because it's kinda like Rails and that it's sort of a a a one stop shop that has everything that you need, but that also adds a bunch of complexity. So in the book, I used, Flask as the web server because it's just a little bit easier, I think, for nonexperts to pick up. And this gets at something that I I've been talking about on Twitter a little bit lately, which is there's so many of these things are context dependent. Like, you shouldn't be you shouldn't be a false dichotomist or whatever. Like, you know, sometimes one thing's the right choice and sometimes another thing's the right choice, and it just depends a lot on the context.

So I would probably lean that direction. A lot of it would be driven by exactly what I was trying to achieve. Like, if I was doing, you know, an AI thing, I would probably I would definitely look at Python. If I was doing something that was, you know, maybe, let's see. What's another good example? Like, Java's got a ton of really good libraries. I know Java pretty well. If there was a good library in Java that did the thing that I wanted to do, I wouldn't be so I think it just depends. Just depends.

Cool. Yeah. I've been personally grabbing, all kinds of different stuff to work in HMX lately, whether it JS, like, gave me an opportunity to get my hands dirty with BUN, the JavaScript runtime a little bit, just because, it was easy to pick that up and shoot some HTML. It comes with a folder based routing setup and stuff out of the box. So yeah. There I I do love that that flexibility and and freedom. I did quite a bit of Rails and Django myself earlier on in my my career.

And it it is funny how the types of things that you lost by moving into this JavaScript framework world that we never really quite reclaimed in the JavaScript world. Like what?

Like what? Like,

okay. So what what come you could think of the closest analogy, and this is not even in JavaScript, but in PHP, like a Laravel system. Right? You you get, like so you have a templating syntax. You get scaffolding. You get, migrations. You get ORM. You get, routing.

So you get more, especially more in the data piece, that you you get in JavaScript. And that's a the an area that I think the JavaScript frameworks are afraid to touch. You know? Oh, yeah. You know, one thing I really like from Rails

is the model stuff, like, an active record and then all the callbacks, like, life cycle callbacks they have. Active record, I know our ORMs have a little bit of a bad name now, but I really like active record. It does a pretty good job of giving you the 80, 20 solution for an ORM, and then you can kick out the SQL when you want.

But it has a lot of life life cycle hooks, and it does, I think, a really good job of, allowing you to encapsulate your encapsulate your business logic or your domain logic in model object in model classes. I like object train. I I've got a bunch of my popular opinions. I like object train in programming.

But, you know, one thing you mentioned, Scott, a little earlier was, people saying, oh, we're we're we're coupling with the HMX, you're coupling your front end to your to your back end, and that's true. They're not wrong.

There's an essay up on the HTMX website called 2 approaches to decoupling.

And, HTMX does couple your front end to your back end, in a a a a pretty dramatic way compared with, like, a generic JSON API. Wes actually argue that's a good thing, because your web app tends to be very churny and, like, you need lots of little features to or or whatever, and this can put a lot of if you have a generic JSON API that's serving that, then that API ends up getting very complicated because of that. So you either have to introduce something like GraphQL or you have to create a bunch of specialized endpoints for your app or whatever.

And so separating those 2 actually helps your your general purpose data API be more generic and, you know, satisfy the people that need that. It gets the the chaos of your web app sort of out of the JSON API.

And then, you know, there's also this this idea, you know, as as we pointed out, HDMX does let you pick whatever kind of back end you want, and that's because you've decoupled sort of at the network architecture layer. So you've d you've d you basically decoupled, like, a level down.

Mhmm. Rather than at the application level, you've decoupled at the network architecture level.

And so that is a different style of decoupling, but it does give you this sort of, freedom to pick whatever back end you want in a way that you can't if you're, you know, more committed to, a a tight integration between client side JavaScript and server side JavaScript.

I even saw somebody embedding a their entire API in a worker. It was like a Go compiled the WASM through their entire API and a worker using a SQL lite, and everything's local on device, shipping HTMX. And I was thinking, this is a this is a wild wild

world that we're entering here. Yeah. I've seen some pretty crazy, mashups with HTMX. I can't say I support all of them because I don't understand all of them. Yeah. But Yeah. But, you know, it's cool. Have fun.

Yeah. How do you feel about web components?

I haven't used them very much myself.

H t m x 2 is gonna have better support for them. They, they kinda suffer from what frames iframe suffer from. They're kinda ice they there's almost too much isolation.

I don't think they did a good job of thinking through how to integrate them. Like, there's so much focus in the components world on isolation, but they're often you know, they're just times when you when you need to integrate. And so form participation JS always has always been kinda, you know, difficult and, so forth. I I understand they're improving, but I just I'm not an expert on them, so I don't have a super strong opinion. I've just never I've never needed them. I've always achieved sort of similar ideas by using, server side template reuse, like inclusion and so forth on the server side.

So Mhmm. And I think I think that that that the the firewall that kinda got in the heads of the designers, like, we have to have this, like, hard firewall between the component and the rest of the DOM, has has hurt their adoption. That's but, again, I'm not an expert. That's just my my outsider opinion on it.

Yeah.

And what are the big, like, templating engines that, people are using? Are you are you and or or what are you reaching for?

I like any template system that supports something that we call template fragments, which is the ability to, you know, within a a bigger template, to call out a piece of that template and say, this is a separate piece of content that I wanna be able to render by itself.

And that that's kind of an obscure feature of template languages. More more templating languages are picking that up as they see HDMX being adopted, and they they hopefully, they read that essay, on it. But what that lets you do is it lets you have 1 page with your content in it. And then if you need to dynamically rerender a part of page rather than extracting that out and having another file to deal with that's somewhere else and you can't see, you can just tag some of the content in that template and say, okay. I wanna be able to render this separately.

And that that works really, really well with h t m x because then you can say, okay. You Node? Something like, if you're doing a poll, for example, you can say, okay. Just rerender just that bit of the screen, but I still can see everything in one place.

That's one thing that, I I like about it is, like, in still sort of see everything in one place.

I'm so glad you said that because, like, I in the past, like, 2 months, I've brought up the fact that Svelte can't do multiple components in a single file. Everyone's like, ah, just bring them ESLint another file. And and React Vercel components, if if it's a client component, you gotta put in another file. And I I've gone so far to try to, like, change my editor so that I can edit them in line, like, put a mini editor inside the Versus Node because, like, I I just wanna look at the whole thing and type where I want it to go like it was HTML, but a lot of these templating languages make it really tricky to do that type of thing. So and I was thinking the other day. I was like, am I wrong? Am am I wrong? And I'm glad, finally,

somebody else is is on board with me. Yeah. There's there's another I'm sorry to keep referring to the essay's page, but there's another essay up there called locality of behavior, where we talk about kind of exactly what you're the the the big idea of what you're talking about, which is you don't yeah. And this is a criticism I have of the idea that you should separate scripting and styling and HTML all apart JS that in order to understand what's going on on a given page, Node you have to look in, like, 10 different places. Mhmm. It gets very difficult to Yeah. You Node? You have to keep a lot in your head to understand everything that's going on. And so, we the terminology we try to use around that is locality behavior. You wanna put the stuff, like, where it's being used as much as possible.

And so I think template fragments are sort of a an example of an implementation where you get more Sanity. So you can just see, okay, on this page, this is what's going on. Cool. Alright. Move on with my life. I don't have to navigate

navigate around so much. I saw an interesting thing today.

Object oriented HTML.

It was an interesting repo. Have you have you is it have you come across that? I just saw it for the first time today. Yeah. I saw it on Hacker News. I didn't dive into it too deeply,

but, I don't know. What do you what was your take on it? Did it look interesting?

Yeah. It looked interesting because I think, specifically, it does kind of what we're talking about here, where in line with your HTML, you're able to define, like, okay. Even just in line, this is a template here. This is a fragment here Mhmm. In one specific file. And even as far as you could reference another HTML file, it it seems like kind of the way that I almost wish HTML was invented to be where you could have your own fragments and templates both in line or imported.

Yeah. I've got it in my it's in a It's in a tab somewhere. I need to read it.

I was just reading before this conversation, which is why it's on my brain. I have no idea if this is a valid approach or not or anything, but I thought it was kind of interesting.

Yeah. Is there any kind of local first story in HTMX given that there's so much server required? This is something that I've it's been on my brain just a little bit. I don't I don't Node. You know, I haven't been doing too much local first myself.

But is there anything there that h t m x can can do?

Not a HTMLX is it's like, you Node, in my mind, again, if you're talking about HTMLX, you're talking about HTML plus plus. And so HTML doesn't have much to say about local first. It's they're hypermedia controls. You can set up a a web worker, I believe, to handle Wes, and so you can you can just kinda intercept the network, abstraction a little bit from that sense. And I've seen people do that, but it's not something I would do unless I was really pressed into service to to make local first happen. So I would say, you Node we say this in the essay on when to use hypermedia. If if local first is a must for you, then h t max is problem or hypermedia is probably not a good thing, and h t m max is probably not a good thing. So

Yeah. You you've mentioned h t m x 2, in this conversation.

I guess that goes into one of my questions, which was, like, what JS the the future of HTMLX look like given, its rise in popularity now?

Yeah. I think the future of HTMX looks very much like the present of HTMX, which I hope looks very much like the past of HTMX. I think the core at like, you know, again, there's 7 core, attributes.

The core abstractions of the library are are correct in as much as they implement what my idea of generalizing hypermedia controls is.

And, there you know, there's flaws. Like, there if I could take things back, I would, but we're not planning on breaking backwards compatibility in HTMX 2, very much at all. There's gonna be a couple of sort of corner cases we clean up a little bit, but not not any major API changes. So most h t m x Node users should be able to upgrade to h t m x two without any any, changes at all.

And my hope is that that, you know, we're gonna drop IE support for Intu, so that'll let us clean up the implementation a little bit, use some more modern JavaScript features internally.

But the API should not change.

So I and I don't anticipate it changing much going forward.

That's my Node, anyways.

Let's talk about the Twitter stuff.

A a lot we went as far to to title our episode, is HTMX a Node? Because like like, props to you, but you're like a a number Node troll online, and just run the most hilarious Twitter account. And so much as to be whenever somebody talks about HD Max, they have to say, I know the Twitter account is a little bit much, but it's actually a pretty smart way to to build applications. So, how did you learn to be such a good,

troll online? Good troll online. How did I learn to I think shoot post is the word you're looking for there. Yeah.

Yes.

I I you know, I grew up in, like, on the forums in the in the late nineties and early 2000, and there was a lot of rough and tumble. And I got pretty good at, like, you know, making memes and and stuff like that. And I didn't do it for a while because I I was I had a startup gone. And Intercooler JS kinda I don't wanna say it died, but it it definitely flat lined. Like, you know, it had nowhere near the attention that HDMX is getting now.

And, when I came back and did HDMX, I had this Twitter account that still had a fair number. You know, for me, it was a lot. It was, like, you know, a couple 1,000 followers, which seemed like a big deal at the time.

And, I was like, you know what? I'm just gonna have fun again because I can't I tried to be professional a little bit. I mean, you can go look at some of the you can look at intercoolerjs.org website. There's some silly stuff there. But I I did try to be a little bit more serious about things.

And, with h t m x, I was kinda like, you know what? This is just this idea is dead anyways, so I'm just gonna have fun and run the Twitter account the way I want to. And, and I did that, and it, you know, it just worked out. People you know, there's not a lot of strategy here. This is just me being creative. Like, the just having fun. And And there have been a couple of times when, like, I you know, I got lucky. Like, that whole Microsoft you know, the the whole setup for, you know, me pretending like Microsoft Wes gonna buy out h t m x. I just got really lucky, like, you know, there. And so I got this stupid email from Bed Bath and Beyond from Microsoft.

So, you know, there have been a couple of times whenever, you know, Node to set things up like that. But for the most part it's just me being be me being me.

So Can you tell the story about the the whole Microsoft thing? Because I I had caught parts of it, but I I could not piece every all the hilariousness together. And I was like, I'm not gonna you you know Wes you, like, see, like, a subtweet on Twitter, you're like, I don't got time to research what this is about. What's the background here? Yeah. I think someone had,

somewhat there was a job posted at Microsoft that mentioned the HTMX. That's what started it. And so there was a this job and it didn't even say, like, oh, you have to be an HDMAX expert. It was like you it was, you know, as a comma, like, after React and Vue and all this other stuff. Like, at the very end, they were like, oh, and HDMAX.

And, so someone retweeted that, and I was like, oh, okay. Let's we'll we'll have some fun with this. And, so I, like, I just I quote tweeted that and said, oh, this, inter I think I just said interesting. I tried to be, like, really mysterious about it. And then I started, like, finding people that were mentioning Microsoft positively and, like, quote tweeting them and saying interesting and so forth. So that's for, like, a week. I did that I did that for about a week. And then, literally, like, this is just shows it's way better to be lucky than than good. I got an email from, like, the Microsoft credit card division offering me a credit card with 10% off on Bed Bath and Beyond, And and and I wanted to change the license of HTMX from Bos d 2 to b s d 0 because b s d two requires that you distribute the license and copyright with it, which doesn't make a lot of sense in a JavaScript library.

And so I I I started, I I think, on Friday or I I forget what it Wes. But I was like I I first of all, I made my account super professional looking. Like, I took out all the, you know, junk. I made my icon, like, normal and so on and so forth and just started being, like, really serious, freaked people out. And then I posted, I think, on Saturday or Sunday night, I I was like, okay. I have an inter I have a very interesting, I have a very interesting offer from Microsoft. And I was just talking about that stupid credit card offer that I got.

And, I'm gonna announce a license change tomorrow to guarantee the financial stability of HTMX going forward. You Node? I'm just trying to get people freaking out, you know, about, another open source rug pull coming incoming.

And, and then the next day, I I just said, okay. It's Bos d Deno, and the the offer was the stupid credit card offer.

So that was probably the biggest setup I've done.

You know, beyond that, it's all just been, like, Bos.

Like, you know? Well, at some point, I think you I hope Elon Musk actually takes the bait on one of my tweets, and that that'll be I'll probably delete my account after that.

Oh, that's great. That's good.

Okay. So we're about 50 minutes here.

Is there anything that you want to get across about HTMX that we haven't haven't covered yet?

Yeah. I think one thing I've been saying this on most of the podcasts I've been going on lately is, I do, I do like the idea of of of de escalating the language, around HTMLX and just the web development in general.

HTMLX is a tool. I think it's a useful tool. I think people who are React developers could, you know, learn about it and find something useful in it and maybe find it useful for, like, an internal project or whatever. If they've just gotta get a button up that does a thing, maybe they don't need all that stuff.

And, you know, the the ideas of hypermedia are interesting, just from a technical standpoint. So I think, you know, you don't have to and I I you know, I can't tell I can't tell people who hate HDMX how to behave, but if Node, you know, if you if you like HDMX, I would ask that you be, you know, reasonably balanced in your promises around it. It's it's not a silver bullet, and software development's always hard regardless of, you know, whatever tool you pick. So, I've been trying to deescalate. So it's tough because, you know, I I do joke a lot. And so I'm like, yeah. You know, everyone be nice. And then I post some, like, just outrageous meme, and it's like, wow.

You know? But,

but I, you know, I did like, in general, I think it's, I think it's an interesting tool which you can learn pretty quickly, and there's some interesting ideas behind it. Don't feel like it's, like, life or death situation.

Yeah. Wes, I've noticed that, you know I mean, it's not anything new.

But, you know, peep people are so tribal about their tools.

And their their tool that they find to be effective is apparently the only tool that can be effective.

And I think that's such a wrong place to be in in life, which is one of the great things about us getting to do this show is that, you know, Wes and I, we get to try a bunch of different tools. We we don't have to necessarily deeply ingrain them into our personalities. We can talk to people like yourself and and really get a a good handle on, you know, what these things are good for and maybe where they're not appropriate. But, yeah, I think it's a good advice for anybody out there and not just fans of HDMX is that you don't gotta be tribal about your tools. You know? I think these tools all exist for reasons. Right? They all exist for a reason, and just keep an open mind about them. Okay. So now is the part of the show where we can get into sick picks and shameless plugs. Did you come to the show with a sick pick or a shameless plug?

Let's see. I'm gonna, I'm gonna recommend your listeners look at 2 pieces of technology.

I will recommend they look at Alpine JS. I don't know how much you guys have talked about Alpine JS.

Yeah. We had Caleb on the on the show.

Okay.

And, so that's really interesting.

You Node? That that that library has a lot of locality, you know, associated with it. And then another one that's a a smaller library that and it's kinda has a a mix of h t max and Alpine together is something called DataStar. And I believe the URL is datadashstar.dev, which is it was made by someone who came on the Dave Delaney, who came on the, he came on the HTMX Discord and had a bunch of ideas around how to improve HTMX, and we basically were like, Node. Too complicated. Mhmm. Mhmm. So he did the right thing. He went off and did it himself. And so that's another approach to Scott of this hypermedia oriented, model. It's it's it's more sophisticated in some ways. But I think that's like if HTMLX doesn't grab you because it's too simple or stupid or whatever, maybe go check out datastar.dev.

Cool. Yeah. I've never heard of this. I think it's pretty new.

They also have an essays page. All these academics getting into web development.

Yep.

And shameless plugs, is there anything you would like to plug?

I guess, you know, my my book, Hypermedia Scott Systems, you can read it online for free. If you want to, you can pay for the Kindle version or, we sell a a hardcover version of it as well. The hardcover version I've heard has had some printing issues, So it's unfortunately, Amazon on Demand JS appear is apparently somewhat erratic in what it produces, but the cover is really cool, which is why you're buying the hardcover anyways.

So Yeah. The website's really cool too.

Yeah. It it is. And then there's also swag.htmx.org if you wanna go buy HTMX stuff, including there's a poster of the cover. So if you don't wanna pay $50 for the hardcover, you just want the you just want the cover for a poster.

We sold the the smallest version of that poster at cost because, Berkeley Graphics, which is now, I think US Graphics, he changed his name. They they did an unbelievable job on the cover, and so we wanted to make that available to people if they want. Wow. There's a lot of silly stuff on swag too.

It's really cool.

What's up with the pickle?

What's up with the pickle? Someone generated that pickle, and I took it and hacked it up a little bit in Photoshop or I use, photo p, I think is what it's called, the ESLint, version.

And, and then I used it. I don't know, man.

I don't know what's going on.

It's just really, really funny and, like, awkward in a in a sort of very h t m x.

Yeah. It it it just it just works. I don't know what to say about it. There's a lot of good vibe stuff on here like the, the platypickle.

It's like a platypus pickle, the buffalo with the laser eyes and

Yep. The influencer. Wes try to have fun. Chill of the month. You know? You might as well have fun. You might not be successful. You might as well have fun.

Yeah. Well, it's been awesome, Carson. It's been really great getting to talk to you. And, I I hope the audience has a little bit better of an idea about the intricacies of HTMX after this one. And, yeah, it it's something that I personally been really enjoying working with. So, I'm gonna continue to dive deep into this world, and,

I I'll see you online. Great. Well, hey. Thank you very much for having me on. I appreciate it. Thank you.

You Node? Just, just, again, thanks for taking a look at it. And admittedly idiosyncratic way to do web development.

Love it. Cool. Well, thanks so much, Carson.