The Changelog: Software Development, Open Source - The CEO of htmx likes codin' dirty (Interview)

Episode Date: June 18, 2025

Jerod is joined by Carson Gross, the creator of htmx –a small, zero-dependency JavaScript library that he says, "completes HTML as a hypertext". Carson built it because he's big on hypermedia, he even wrote a book called Hypermedia Systems. Carson has a lot of strong opinions weakly held that we dive into in this conversation.

All right, welcome back. I'm Jared and you are listening to the changelog, where each week we interview the hackers, the leaders and the innovators of the software world to pick their brains, to learn from their failures, to get inspired by their accomplishments and to have a lot of fun along the way. On this episode, I'm joined by Carson Gross, who calls himself the CEO of HTMX.

Which you shouldn't take seriously, because Carson doesn't. HTMX is a small, zero-dependency JavaScript library that he says completes HTML as a hypertext. Carson built it because he's big on hypermedia. You might even say he's hyped about hypermedia, if you're a nerd like me. He's so hyped he even wrote a book called Hyper Media Systems. Carson has a lot of strong opinions,

weakly held, that we dive into in this conversation. It's a ride, I think you'll enjoy it. But first, a big thank you to our partners at Fly.io. The public cloud built for developers who love to ship. We love Fly. You might too. Learn more about it at fly.io. Okay. Carson Gross on the changelog.

Let's do it. Well friends, Retool Agents is here. Yes, Retool has launched Retool Agents. We all know LLMs, they're smart. They can chat, they can reason, they can help us code, they can even write the code for us. But here's the thing, LLMs, they can talk, but so far, they can't act.

To actually execute real work in your business, they need tools. And that's exactly what Retool Agents delivers. Instead of building just one more chat bot out there, Retool rethought this. They give LLMs powerful, specific, and customized tools to automate the repetitive tasks that we're all doing. Imagine this, you have to go into Stripe, you have to hunt down a chargeback. You gather the evidence from your Postgres database. You package it all up and you give it to your accountant. Now imagine an agent doing the same work, the same task in real time and finding 50 chargebacks in those same five

minutes. This is not science fiction. This is real. This is now. That's retail agents working with pre-built integrations in your systems and workflows. Whether you need to build an agent to handle daily project management by listening to standups and updating JIRA, or one that researches sales prospects and generates personalized pitch decks,

or even an executive assistant that coordinates calendars across time zones. Retool Agents does all this. Here's what blows my mind. Retool customers have already automated over 100 million hours using AI. That's like having a 5,000 person company working for an entire decade. And they're just getting started. Retool agents are available now.

If you're ready to move beyond chatbots and start automating real work, check out Retool agents today. Learn more at retool.com slash agents. Again, retool.com slash agents. Today I'm joined by the CEO of HTMX himself, Today I'm joined by the CEO of HTMX himself, it's Carson Gross. Welcome to the Change Log. Hey, thanks for having me on. Happy to be here and happy to talk about software and maybe some HTMX and so forth.

I'm happy to have you as well. I feel like our paths have crossed a few times. I think you've been on a show I produced, maybe a show that I would co-hosted, but never got to sit down one-on-one and just talk software. So this is exciting to me. You have lots of opinions about software, don't you? I do have a fair number of opinions.

What are they? What's the, you're supposed to have like something opinion strongly held or something weak opinions strong. Whatever that is. Strong opinions weekly held, I believe. It could be the other way around, who knows. Whichever, I have the opposite

of what you're supposed to have. So, but I do have opinions and not like, but I don't think everyone has to agree with me for sure. What's interesting about you, you've had these opinions kind of embedded in software over the years. Intercooler is where it started, HTMX and became. You spent a long time trying to get people

to pay attention to HTMX, I remember, because we had you on Go Time, we had you on Jay's Party, and you were kind of starting to get some traction. And then you just decided, I'm just guessing, decided like, I guess I need to just become a Twitter troll, and that's how I'll actually get attention. Because eventually, you actually did rise to the point where like, HTMX is out there.

Like, you are a known quantity at this point. Was it, was there an epiphanyiphany, like I just had to become the world's best troll, or how did you do it? Troll is such a, just, you know, it's trolling for lack of a better term is good. Now, what, I had always been, I'd always had fun on social media, like not taking it very seriously.

And I think what really happened, and there's a video you can look up online. The speech that I hear the talk that I gave at the big sky dev con, which is the, the big conference out here in Bozeman, Montana, where I live. And I talked about sort of my experience marketing, HTMX and how, you know, I had had an intercooler, the predecessor to HTMX, technologically very similar, so conceptually very similar. And it didn't have nearly the success that HTMX had. And I don't think that there's anything that I can point to and say like, that's what worked. I think there's a

lot of survival bias problems and just, you know, random things that happened. And so I did when HTMX was sort of going to go to 1.0 and also in our book, Hypermedia Systems, which your listeners can check out at hypermedia.systems online for free and you can buy it in hard copy if you want. We just sort of like a bunch of things came together. And I had been getting so you know, when I when I went to htmx 1.0, I was like, okay, I'm going to double down on being crazy on Twitter. I'm not going to troll people like I'm not going to attack people. That's one thing that a lot of

people try to do is like, you know, you punch up to try and get a bigger account to say something to you. And I definitely like engaged with bigger accounts, but I tried to be funny instead of sort of mean and you know, whatever. And so in that talk, I think it's called a theory of open source marketing or something like that. I talk about sort of like the whole process and sort of what I've what I've found has worked online. So so I wouldn't say set out explicitly to be a troll. I think people are used to very serious technical content. And I do try to have like, you know, I published an ACM peer reviewed paper on hypermedia and we're open to get another one in to the ACM Hypertext Conference this year.

So we're doing intellectual work as well and, you know, more serious work. But at the same time, I think the medium is the message at some level and like on Twitter if you're taking it too seriously or any of these Twitter like situations you're probably not utilizing it the way it was meant to be. It's like it's a hundred and whatever characters like saying something funny and coming up with a good meme is probably going to be much more effective than trying to be trying to be all serious. So I think a lot of things kind of came together once prime, you know, the primogen and Fireship Dev happened to cover HTML X like right when we were releasing the book. And so there was definitely this sort of moment on and then the X algorithm changed

briefly, it's changed back, so I don't get nearly the engagement I used to. But for just for a brief period of time, the way I was posting was just perfect. Yeah, for the algorithm and everyone was like, why is htmx on my homepage every day? Like, I don't know, just got lucky. Yeah, that's kind of the way it is.

Yeah, you gotta play to the crowd, you know, know your audience and know the medium, like you said. For a very long time on Twitter, my entire approach was just memes. And I eventually, and I did pretty well, I had some viral ones and we grew our account from like 2000 up to like 30,000 people.

And I just kind of grew sick of the entire rat race of what it was. This is back in the pre-Musk days. But it was fun for a while to like try to play the game and see if you can get good at it. And of course if you're using that to promote your open source and your thoughts, which really that seems like you're trying to get your way

of creating apps out there through HTML, but also through your essays, which are technical and thoughtful and still interesting reads. They're not like, you know, ACM style essays. Maybe they are, I don't read the ACM. It just seems like it's too dry for me. Yeah, it's pretty technical and academic.

But just, you know, getting your thoughts out and sharing them. Hypermedia, a big thing that you're into, I think taking HTML seriously is something that I've heard you say. Where does this viewpoint of the world come, of web development particularly? Well, I think one thing that I've realized

as I built Intercooler and then HTMLX is I didn't appreciate hypermedia when I really, when I built the things. It took me, you know, there's this idea that like existence precedes essence. That's a philosophical idea where something has to exist. And then you can look at that and say, okay, what's the essence of this thing? Like strip away all the, you know, particularities of this thing. Like what's the essence of it? And that was very much my experience

with HTML Max, where we have to, I had to build it and then understand, okay, wait a minute, this is really generalizing hypermedia controls. Like I didn't, when I had to build it and then understand, okay, wait a minute, this is really generalizing hypermedia controls. Like I didn't, when I created Intercooler and HMX, I didn't think, oh, I know what I'm doing. I'm generalizing hypermedia controls. But when I looked at what I had done and I went back and read some of the historical writings on H, or excuse me, on hypermedia, then I kind of developed

that idea like, oh, okay, this is what's, this is why this is working as well as it is. Cause it always felt like I wasn't writing that much code and I was getting a lot of bang for my buck out of it. I think the reason for that is that it was taking this sort of like higher level idea of hypermedia and then generalizing it is the way that I would say it. So, so, you know, I just think that's,

this is one of those things that, you know, you have to do it before you can really talk about it. And so I did it with IntercoreJS and then HTMX. And that put me in a position to write these more, sort of like deep essays on hypermedia. And the thing that I came to understand about hypermedia as I got into it is it's a, it's one of a few different ways to build distributed systems. And that's, you know, there's, if your listeners are familiar with Roy Fielding, he wrote a

really famous dissertation sort of early on for the web. And it's pretty academic and hard to read. So I don't, you know, you can read, there's a reasonable summary of it in the hypermedia systems book that you can read if you want. But what he talks about in there and what I've come to appreciate about hypermedia is it's just one of these sort of fundamental ways you can build a distributed system.

And it was a really effective way as evidenced by the fact that the World Wide Web sort of took over everything in the late 90s and early 2000s. And so developing an appreciation for like, what's unique about it, what are its strengths, what are its weaknesses? That's just something I've been able to do over the last, say, five or 10 years as I've been working on these things. And then I'm trying to communicate that to the broader development world because the broader development world has sort of left hypermedia behind because of the weaknesses in particular of sort of the base HTML web model

for hypermedia. HTML tries to address those weaknesses. And then it's a matter of convincing these people like, hey, I know the old way was sort of clunky and getting, you know, the big kerchunks and all this like flash of unstyled content and all that stuff, but the web's gotten a lot better. And by the way, HTML X can make it even better and make it more effective. And then the advantages of that old

approach, which were, you know, simplicity, like there's a simplicity to it and so forth, or it can be available to you even if you're building some class, some subset of modern applications. It's not appropriate for everything, of course, and so I try to talk about the trade-offs that are inherent in hypermedia-based applications, but it can be used for a lot of stuff. And it's an interesting, even if you don't use it, I think it's interesting from a technical perspective just to understand the ideas and what the trade-offs are.

If you were to distill down what hypermedia is into a few bullet points or principles, so they're all on the same page, what would you say? I'd say hypermedia, a hypermedia is some sort of media. So text is the most common media we work with, HTML, with what are called hypermedia controls in it. And that's nerdy, but bear with me. What hypermedia control is,

is something like a form or a link where you've embedded in the document what Ted Nelson would call a nonlinear control flow mechanism, where you can jump to some other place or you can submit some information. And that control, so let's use the term control and like, you know, UI controls like buttons and so forth. That control is embedded in the document

in a really kind of unique and interesting way. So you have content and then you've got this control sitting there right in the middle of the content. And so those are hypermedia controls. And what HTMX does is make it possible to sort of generalize that idea. So a lot more things can be hypermedia controls and they can do a lot more

and they can replace only chunks of the screen and so forth. And a lot of these ideas are very old. Like the idea of replacing only a chunk of HTML and a screen has been called transclusion for a very long time. And a lot of hypermedia academics have talked about it but it just never really caught on in the web

because the only way to do it on the web previously was with iframes. And so HTML sort of like breaks out of that and makes it more general and a lot smoother. You don't have to do a lot of frames and the limitations that that has. So, but that's what I would say a hypermedia. That's a media, some sort of media,

we're most familiar with the text. So hypertext that has these weird things in them called hyper media controls that can interact with the network and do crazy things like navigational and update style when you talk about forms, which were added in HTML, these sort of update style operations to interact with a remote system.

So the H in HTML hypertext, right? HT hypertext markup language. HT hypertext markup language. So that would be a form of hypermedia. But HTML exists and I guess a lot of these other styles of building applications exist because like you said of the lack of tooling or the lack of power that's in the HTML spec

or in the elements provided. Was this something like when the fieldings and the Tim Berners-Lee's and I don't know early Microsoft, IE browsers, Netscape people, were they trying to build a hypermedia thing and they came short of it because HTML wasn't powerful enough or how did it were they trying to build a hypermedia thing and they came short of it because HTML wasn't powerful enough or how did it get to where HTML is a hypertext but it doesn't have all the controls that we need to actually build what we want to

build? I think hypermedia is just sort of a weird thing and people aren't used to it. People don't, you know, we developers when we think of remote, when we think about distributed systems, we fall back to this RPC, remote procedure call, like paradigm, just very quickly. And maybe that's because that's what we work in for the most part is RPC. And so that's what I see with a lot of SBA style applications

is it's much more of an RPC style application, which is fine. There's nothing wrong with that. It's just different than hypermedia. And so why, you know, why did they stop with forms and HTML too, which, and that was a really important advance. I mean, it's a, to the credit of the web and what they did with the web, all of web 1.0, which includes like Amazon and Google and all that stuff. Like that was all done of web 1.0, which includes like Amazon and Google and all that

stuff. Like that was all done with web 1.0 tools. That was a massive advance as far as distributed computing goes. So the anchor tag and the form tag are both very powerful. Just those two little controls are very powerful in some ways, but they did have, they just weren't as useful as they could have been if they had kept advancing the web as like the hypermedia aspects of the web. Instead, what they really sort of turned to is more, like they introduced a lot of APIs that were more client-side oriented and scripting.

And so that makes some sense to me. That's just the way we developers tend to think. And I think, you know, it gets big enough and the hypermedia people start getting ground out. Maybe they just weren't thinking too much about the idea of generalizing this notion of hypermedia controls. And so I, you know, I think it was it was so powerful at the time, like it's hard to look back and say, well, you know, guys, this could have been more powerful. It's just, it was doing, it was doing really well. And then JavaScript was there to address any issues that came up when it wasn't powerful enough.

And so we just sort of slid into this world where more and more JavaScript took over more and more. And that didn't, so therefore there wasn't a necessity to keep going with the hypermedia ideas that were sort of inherent in HTML. So I think it's, you know, it's reasonable. And like we've taught, you know, you mentioned before we got on here, like the term rest has sort of been completely like flipped and it's meaning from the start till now because of that. And so there's a historical process there. And, you know, Google Maps, I think,

shares a lot of the blame because Google Maps came out and it was just this amazing app compared to like all the, you know, if you use MapQuest before, and you had to click a button and kerchonk and like go to the next thing, it was horrible. And Google Maps comes out and that's not building in the hyper media way at all. It's all, you know, RPC style stuff and it's amazing.

And everyone freaked out and was like, well, we got to build apps this way now. So, and I don't think that's, you know, that's totally understandable, but it's just a, the historical process. So hopefully we can, you know, hopefully we can bring hyper media back into the consciousness of web developers as a potential and good alternative for some class of web applications. Right, so HTML has the anchor, it has the form, and we do have Ajax for like, you can build in partial page updates, we can build around all this kind of stuff,

but what are some examples of the things that HTMX adds that really gives it what it needs to be a full hypermedia API or whatever you wanna call it. Yeah, I would say, the way I would say it is how does HTMX generalize this idea of hypermedia controls? And so what I've eventually hit on was the HTMX takes, so anchors and forms, what do they have in common with one another?

Some user action, a click or a submit, depending on which one, triggers an HTTP request, like a request to some remote server. And then that server responds with HTML. And then that HTML is placed somewhere in the document. So it just anchor tags and forms that can be controlled with what's called the target attribute. And you can actually target an iframe by name if you want. And that would be, that would be transclusion where you're only updating part of the page.

So what HMX does is it says, okay, let's generalize those things. First of all, any element can be hypermedia control, can participate in this sort of like remote request world as a hyper media control, any event can trigger it. So not just clicks and submits, but also for example, when an element scrolls into view, that's a common time when you wanna maybe make a remote request or something like that.

And then it can issue an HTTP request. HTML also supports things that aren't supported by HTML right now. So in plain HTML right now, all you can issue or get and post requests. That's a, I think a shortcoming of the HTML specification that we're actually, we have our another project called trip tick that Alex Petros who's a core member on the team is, is really driving. And then we're trying to get HTML to adopt some of the ideas of HTML. So we're trying to get those other requests, put, patch, and delete,

are the ones most people are gonna be familiar with, so that you can actually use them from HTML as well. But HTML, you can use all those. And then HTML, the final sort of generalization of it is you can say when the request comes back and that request when it comes back, it isn't gonna be JSON. So you're making a request URL,

you're getting back HTML. And you can say in HTML, I want you to target this element. And the element that you target doesn't have to be an iframe. Can be any element on the screen, you use CSS selectors to pick it out. And then it'll replace that element

or there's a few different options you can say say either replace the whole thing or put it inside the thing or maybe put it at the end of the thing or whatever. And so that's really what HTML does is it takes this the the sort of specialized ideas that you find in anchor tags and forms and then generalizes them. So you know any or any element can act like hyper media control now and can replace any part on the page. And if you were to provide the virtues of that, like here's what hyper media is better or, you know, trade-offs, et cetera, as opposed to the way we're building

web apps nowadays, which is very much more of an RPC style thing, what would you say? I would say the biggest thing is you're reducing the amount of state that you've got in the total system. Because when you have an RPC system, you got server state and you've got client side state store of some sort and then you've got the DOM, which also at some level is a representation of the state.

And all three of those things need to remain in sync via callbacks or whatever and blah, blah, blah. And so that's complicated. That's just another layer. Whereas if you go back to the hypermedia model, there's really just the server and the DOM and that's it. So you get rid, you collapse one layer of state and state management that you have to

worry about. So you're not really talking about like client-side routing or any of that stuff. That all goes away. And it's just interacting with the server in a stateless manner, relatively stateless manner, sort of like the original web. And so virtues of that are really simplicity. It can, in some cases, dramatically cut down

on the amount of code you have to write. The trade-off of that is that the interactivity that's available isn't always as high as it is if you have a much more rich client-side model and all sort of the reactive feedback that you can get with client-side libraries. And so it's sort of gated on this network request model and if your system can't do that well,

then it's not gonna be a good approach. There's some echoes of an old style JQuery building of applications where you have some CSS selectors, maybe you hijack a form submit and then you say, when the submit happens, go grab this HTML, target this thing, put it in there. And we build web applications that way for many years with more or less success.

You can build yourself a sprawling mess like that. Like it can happen. And so one of the things that maybe the greatest virtue of the React movement was this one way data flow, re-render, don't worry about the target spot for this thing and is it gonna intercept with that? And now I gotta update, I got listeners, now I got a pub sub going on

because I have different things I need to update based on what's coming back from the server. Does this have something built into it that helps avoid the jQuery potential spaghetti or is it just a different way of going about similar apps but because it's in the HTML, maybe it's simpler or cleaner that way. What are your thoughts on that?

Yeah, I think there's definitely a line at which if you try to do too much with HTML, you're gonna get into that sort of like, oh man, this is just too much. And it says it's an interactivity line, in my opinion, rather than like an application size line. You can build very big applications with HTML, but if you try and get too fiddly with the UI

and you're putting a network request on every interaction, then that's probably not going to be good. And so you can use scripting with HTML X. That's sort of the style of scripting that you would use. I would call it very DOM oriented. You wouldn't try and have like a model. Whenever you have an additional source of truth in your system and it's

htmx is in there you're gonna start having to deal with synchronization issues that's just the nature of it. I think where htmx is superior to what you were talking about the old jQuery mechanism of building these styles of applications like he, all your listeners might remember jQuery.load which was the method actually that pretty much inspired Intercooler. I looked at that and was like, oh, that's cool. I didn't know you could do that. Use that to solve this problem that I was having in a web app. And then I saw Angular 1 and the way they used attributes.

And I didn't aim in the HTML. And I didn't like the way they were programming, but I liked using attributes. And so where I think HTML is superior and where you don't really get the sort of spaghetti code that you sometimes got with jQuery is because with HTML, you put the attributes that specify what to do on the elements themselves. So it's right there.

So you probably, I mean, older developers who've worked with jQuery a lot have no doubt run into this problem where there's a button, it does something, what does it do? Well, you gotta find the ID and a selector somewhere and maybe someone did something crazy like string concatenation. So it's really hard to figure out

what the heck is going on with that. And HTML eliminates that by basically putting the logic, just like the href or the action on a form tag, it puts it right there on the element. And I think that dramatically simplifies things from a cognitive standpoint. You can obviously still build a snakes nest with it. And again, if you try to get too fiddly with interactions,

I think that can lead to that situation. But for a large class of applications, the interactions aren't that fiddly. You know, they're just, you know, you you just what you want, what you don't want is that really old reset of scroll state and like the flash of unstyled content, which has gone away in modern browsers for the most part, but just that feel of like resetting everything on every action that you got with the old web. And so HTML avoids that.

And I think that's why you can make pretty compelling applications, in many cases, just using that model. Now, they don't have to spiral out of controls, or like the old jQuery app speed. No, I think you're right, I don't know what you call it, but like the co-location of the code that operates on the elements with the elements is a huge improvement over,

I think we went kind of crazy on separation of concerns back when the jQuery day where it's like all your JavaScript was over here in this other file that like randomly attach it, not randomly, but arbitrarily attaches to different elements. And then you're wondering in your HTML, it's super clean, right? But you're like, this HTML has no idea

what's gonna happen with it. And so I think having it there does make a lot more sense. Yeah, I wrote an essay on that idea called Locality of Behavior. You can find it on the htmx.org slash essays page where I talk about exactly what you're saying, which is this idea of co-locating the logic with the element itself

and sort of stepping away from separation of concerns, which I think has not been nearly as beneficial or as many of the advocates for it said it would be, you know, and we've had that experience now with these old jQuery apps. We just know it's better, like, man, I just wish I could see what this thing does. And so as long as what that thing, as long as that logic isn't too complicated and doesn't overwhelm the markup. And in the case of HTML, actually typically does, and it's like two or three attributes at the most, then I think it's fine. I do, you know, tailwinds, CSS

sometimes gets mentioned as well. And tailwinds, I've not taken the tailwinds bill yet because when I see a ton of tailwinds classes on it, on an element, I think to myself, man, that seems like that should be a CSS class to me. But it's just probably a skill issue on my part. So I think there's a balance there. There is a balance. I'm definitely on that fence

where I'm not sure exactly, I kind of agree with you, but there's like a line that you cross at a certain point where it's like, I feel like I'm just writing my CSS in here. Anyways, we can get a little tangent on that. I think there's certainly, again, virtues to having it localized there, but sure it'd be nice to have just like a couple of classes and then have that stuff tucked away.

Right. Well friends, it's all about faster builds. Teams with faster builds ship faster and win over the competition. It's just science. And I'm here with Kyle Galbraith, co-founder and CEO of Depot. Okay, so Kyle, based on the premise that most teams

want faster builds, that's probably a truth. If they're using CI providers with their stock configuration or GitHub actions, are they wrong? Are they not getting the fastest builds possible? I would take it a step further and say, if you're using any CI provider with just the basic things that they give you, which is, if you think about a CI provider, it is in essence

a lowest common denominator generic VM. And then you're left to your own devices to essentially configure that VM and configure your build pipeline, effectively pushing down to you, the developer, the responsibility of optimizing and making those builds fast, making them fast, making them secure, making them cost effective, like all pushed down to you. The problem with modern day CI providers is there's still a set of features and a set of capabilities that a CI provider could give a developer

that makes their builds more performant out of the box, makes their builds more cost effective out of the box and more secure out of the box. I think a lot of folks adopt GitHub actions for its ease of implementation and being close to where their source code already lives inside of GitHub. And they do care about build performance and they do put in the work to optimize those builds but fundamentally CI providers today don't prioritize performance. Performance is not a top level entity inside of generic CI providers today don't prioritize performance. Performance is not a top level entity

inside of generic CI providers. Yes, okay friends, save your time, get faster builds with Depot, Docker builds, faster GitHub action runners, and distributed remote caching for Bazel, Go, Gradle, Turbo repo, and more. Depot is on a mission to give you back your dev time and help you get faster build times

with a one line code change. Learn more at depo.dev. Get started with a seven day free trial. No credit card required. Again, depo.dev. One thing that's interesting, I mean what's normal you have on your website is porting stories like here's a port from React to HTMX,

and there's a few of those. It's abnormal, and I found refreshing and cool, is you actually have a counter port. It's not really a port, it's a lack of a port. It's Gumroad, they were gonna choose HTMX for a new system, and they actually decided not to. And so you host that there on the htmx.org essays written by Gumroad founder Sahil,

I'm not sure how his last name is pronounced, Lavengia, Lavengia? I don't, yeah, we'll just leave it right there. That's cool. How did that come together and then maybe just give a summary of like, what did they find? Why did they decide not to for their particular case?

Yeah, I think that's a good essay, it's worth reading. And I just saw him on Twitter talking about HTMX and being pretty negative about it. And one thing that I've learned about online behavior is that often your first reaction is not the good one. And if you do the opposite, you know George Costanza when he did like opposite, he was just like,

I'm gonna do the opposite of everything I would do. Yeah, totally. Um, so I was like, I've been trying to do that and it has been surprisingly effective in my life. Um, and I was like, you know what? Hey, he didn't, it didn't work out. I don't want people to use HTMX if it's not going to be good for them. That would be like, there was no, no one's winning in that scenario. Just someone is pissed off. They had to use HTML X. And so let's try and capture why HTML X didn't work well for this particular use

case. Um, and so I asked him like, Hey, would you be willing to write an essay on it? And, uh, and he agreed and, uh, sort of went through and like, here's, here's what we found. I would say the way they were using HTMLtmx is was a, it was an SPA developer using it shows like kind of a square peg round hole situation. And so they weren't using htmx the way I would use it. But at the same time, that's going to be the

same experience that a lot of SPA developers have. And so they just, you know, they're trying to make something they're really familiar with the SPA tools, and they make things developers have. And so they just, you know, they're trying to make something, they're really familiar with the SBA tools and they make things work a certain way and they're used to that. And so if they come in and I think the big meta lesson in my mind from that essay is like, if you're going to take the htmx bill, you really have to take it like you have to understand hypermedia and think in terms of hypermedia. And if you're trying to do these really fiddly little interactions, it's going to get ugly and not be, um, and not be super effective. I saw web dev Cody

as well. You never read an essay. I asked him to, but he just was like, he, he tried to do, and I think what he tried to do is he tried to move to go. He was a JavaScript guy and he tried to go to, he tried to do go and HTML at the same time. And I think that was a mistake because now you're fighting with a new, you know, the new infrastructure of go, you don't know where, you know, where's my wrench, where's my hammer, like everything's in a different place. And at the same time, you're also trying to make this pretty, and there is a really big difference between building hypermedia based applications and building SBA style or, you know, RPC style applications. And so I've seen, and I've seen that in not just his case, you know, but in many cases,

if you try and bite off too much, it can, I think, end up in a pretty bad spot. I always recommend that people try htm X out first on, for example, like an internal tool. Maybe you've got like some underserved internal tool that is used just by your, you know, coworkers support support or whatever it is. And it's just like an old school, like curl app or, you know, PHP or whatever. And maybe try sprinkling some HTML X in there and see if you can get some quick wins with it.

And then that'll sort of show you what the strengths are. Rather than, you know, okay, we're doing it. Someone on Twitter said hypermedia is good, so we're gonna rewrite the whole app in hypermedia and we're gonna try and make it all work exactly the same, so. One of the reasons that I found, they did list like five, I think,

reasons why, you know, bullet points. And one of them I found interesting, which is a little bit outside of your control, and it was AI and tooling support. And this is probably outdated at this point because even I've had this similar situation with AI tools with the Elixir, like the earlier versions just didn't really

know Elixir very well, it just wasn't very good at them. And now as I reached, I think Gemini 2.5 and specifically Claude 4 is just better. Like it just knows more. And so like that problem kind of went away to a certain degree. But there is kind of a, that old saying, nobody goes to that restaurant anymore, it's too crowded.

It's like, Next.js sucks all the air out of the room. And so people are just gonna pick it because it's what they know it's what everybody else does It's what where the jobs are where the money is and so at a certain extent some of the reasons why people make choices Aren't actually based on the merit or anything you can control at all. They're just kind of like yeah Well, you know popularity is its own merit Nobody ever got fired for buying IBM is like maybe frustrating to people who are more philosophically inclined, but it's just the reality of life.

You know, like technology is very much a winner take all sort of situation in many cases, although we do see, you know, Microsoft, for example, was like the big dog for a long time and then was down for a little bit. Now it's maybe back and, you know, so these things that seem inevitable, like there are these ebbs and flows. And, you know, one thing I say in that talk that I gave at Big Sky Software is if you're a little guy like me, like it's just me and a couple of other guys his team acts. Really the important thing I think is hanging around and waiting for the winds to shift in a direction that is favorable to your technology.

And the best way to do that, my experience has been is to stay unrelentingly positive and like funny and just have fun. And so that's one reason why is, you know, like I told Prime the other like when I was on a show once like being funny is no no joking matter. Like you have to like keep it fun or you're going to quit because it's frustrating and these people are just picking that because they're picking it because Facebook said so or whatever. And you just have to be okay with it and like, hey, we're going to go over here. We're going to have our fun and we're going to, you know, make some funny jokes. And the technology is serious.

There's a, you know, good ideas behind it. And I'm happy to talk to people about their, those ideas, but I'm not going to let the fact that, you know, so many people pick next JS by default and pick SDA, the SBA approach by default, knock me out of a game, right? Cause I'm not changing that anytime soon. But you know, I think we made a dent and we made a dent because we're just hanging around and having fun and being at,

saying some interesting things. Persistence absolutely pays off. Especially if you can stay positive and interesting for long enough. People will eventually pay attention to you. So Next.js of course, lots of money behind that sucker. HTMX, like do you have a goal in mind? How do you make your money?

Is this just something you do because you're a consultant and you use it yourself? Or how do you make your living and how does it play into that, if at all? I teach at Montana State University, so I'm a professor. That's how I make my salary and healthcare and all that stuff. HTMX does have a fair number of sponsors, many more than I ever expected, which I'm very

appreciative of, but I tried to treat that money as not real because it could evaporate tomorrow. And the, you know, HMX is BSD zero licensed. So there's not money to be made. There's no plan there. There's no. Yeah. Do I look like a guy with a plan? Looks like a guy with a.

I want to say it. You look like a St. Louis fan. Yeah, that's all I got. But you're out there in Montana. So how do you get a St. Louis fan? Sam, that's a funny story. I've actually never been to St.

Louis in my life. So I coach youth baseball. That's like my other like cape that I wear. And I was in California for a long time. That's where I grew up. And in California, it was impossible to be the Giants or the A's or the Dodgers or the Padres or the Mariners. Like you just could never be any of those teams.

Oh, they're all taken by time. Yeah, exactly. They're all like the cool could never be any of those teams. Oh, they're all taking my time. Yeah, exactly. They're all like the cool, the cool coaches get all those. And I got sick of fighting over it. Not, you know, I would, I grew up a Giants fan, but, um, and, uh, but the Cardinals were always available. And I was like, I don't know. I like the hat and like, cool. They're, I always respect their program.

Um, and, uh, so I had, you know, we just had all this Cardinals gear laying around because that's what my little league teams always were. And then the MLB TV came out and they just wouldn't let me watch the Giants because it was in market. Like regional stuff? Yeah, exactly. And so I was like, well, I got the hat. I might as well start watching the cards, I guess. And so I started watching the Cardinals and it just kind of spiraled from there. And now I like the Cardinals one. I like the hat, I might as well start watching the cards, I guess, and so I started watching the Cardinals and it just kind of spiraled from there and now I like the Cardinals more than I like the Giants.

That's hilarious. I had a similar experience in my childhood, for some reason, just based on the markets, is that for some reason I'm here in Nebraska and I don't know why it's this way, but when I was growing up, like in the 90s, on TBS, I think it was, every weekend it was just Atlanta Braves.

Oh, Braves. Yeah, no, no, sorry. Yeah, Braves. Which, why would it be Atlanta? I guess probably because in local Morgan State, yeah, yeah, there you go. Turner's out of there. Yeah, so I don't know why,

but like the Braves was what was on, and I watched the Braves, like, religiously as a kid, and I just loved them, and they actually were a good team back in the 90s. Good pitchers etc. They had some some world series runs and so I became a huge Braves fan. Now I'm not so much anymore but I was just seeing like for me a kid in Omaha. I'm like why do you like the Braves? Like what's the only thing on TV? Yeah exactly that's basically my story too.

So one day actually you know you know, I have to, especially when HGNWX was super hot about like six or eight months ago, a guy in the Cardinals organization, like saw me and saw me wearing a hat, and he was like a technical guy, like a programmer, and reached out and was like, hey, do you ever wanna come down

and get a tour of the stadium? Like, let me know. I'm like, man, I should do that. You should totally do that. Or at least go to a conference or something in St. Louis. So you, although it's kind of cool to be able to say, I've never been there, you know. You would ruin that part of it.

Yeah. Speaking of cool venues, we were at Microsoft Build up there in Seattle recently, and they had their after party in the Seahawks Stadium. I can't remember the name of the place, Lumen Field. Yeah. So like Microsoft bought out Lumen Field for the night and they just had their after party on the field,

like you're on the field, they let you kick field goals and stuff. That was pretty rad, just to be able to be there on the 50th. I'll never forget, what's his name? Beast Mode, Marshawn Lynch, that run that he, oh man. Do you remember that run of his?

Of course I do. Yes. He just throws that guy off. And so I went to Berkeley for undergrad and I was there when Marshawn Lynch was the running back and he was just always such an unbelievable football player. And I'm not a Seahawks fan, but I go and I watch that video every once in a while because I'm like, man, I need to see the greatest run By unbelievable by a Cal Berkeley alumni ever. Yeah, absolutely unbelievable

All right. Well now we're talking sports. Let's get back on to your essays. No, I apologize Vendoring or code and dirt. I want to talk through a few of your essays just because I I think you do a good job Now I know you're a teacher that makes more sense of elucidating your thoughts and kind of your style of programming Let's go to this one. If I think you and I both seem to like which is the code and dirty one I think you wrote this last year. Yeah, and it's a bit of a response to clean code Specifically, but like there's this idea of like how you're supposed to write software of course Bob Martin's clean code book, which is highly regarded in both also and also hated kind of a piece of work. And you wrote quick and dirty, which you know,

is contrary to a certain extent, but I also find myself nodding my head. So talk me through some of the thoughts here on your coding style. Well, you know, Bob Martin and clean code is definitely a dominant idea. There's it's a dominant sort of, you know, ideology, I would call it maybe in coding. And there are aspects of it that I don't hate or that I don't disagree with entirely anyways. But there are aspects of it that I don't agree with and I could, I definitely code very differently and I've had a pretty successful programming career. And so I wanted to communicate particularly to younger developers, like don't be intimidated by these things. It's one thing I just like, and I have, you know, Bob and I has kind of gotten

into it on Twitter a little bit jokingly though. He's been a very good sport and like not, doesn't take it seriously. So I really appreciate that. We don't agree with one another and we can make it, but we can make a joke out of it. So, but I really, you know, I think there is a, what do I want to say? I think younger developers can be intimidated by these terms like clean code is one of these sort of

like how could you be in favor of dirty code? Like, you know, how could you be opposed to this? And then you look at the actual ideas and you're like, wait a second. You know, there's this there's the headline and then there's the actuality of it and the headline, you know, of course, everyone wants their code to be clean, but then the realities of the recommendations, I think, don't necessarily hold up. And so I like now that I've had some success as a programmer, I am trying one of the things I'm trying to do is to go out and say, like, look, as I do things pretty differently than most of these, particularly sort of the consulting oriented, clean code, agile, like that whole

world, the way they say to do things, I do things pretty differently. And I've had a pretty successful career. And so that was the inspiration of this essay. And I think there were three sort of things that I went at. So I don't believe in short methods for the sake of being short. I think long methods are OK. And I don't unit test my code. Like, I don't do TDD. I do test my code.

But I don't unit test my code like I don't do TDD. I do test my code, but I don't necessarily do unit testing and sort of the ideology, what I would call ideological approach of like always writing a test before you write any code. or that I sort of say this is how I do things different is I tend to write code with classes that are much denser and bigger than clean code advocates would recommend. And so I tend to mix concerns. I have classes that do more than one thing, which is something that clean code people would object to. So those are sort of the three things that I picked out in that essay to, to focus on. So, and I'm happy to go into each one individually. Yeah, let's talk about big functions, because I've definitely done it both ways. Early on in my career, like early on,

you don't really have opinions, because you don't know what's good or bad. You're just like, I need to make a thing. And so I'm going to try to make the thing. And so I was very open to advice and I remember early on in the Ruby community I took Sandy Metz's advice on many things. And one of the things she said, of course,

she's very level, level setting in her ideas but she'll say, follow the rules until you know better and then break the rules all you want as long as you know why you're breaking the rules. One of the rules that she had was short functions. And I think she even says like five line functions, like just give yourself five lines. And if it's more, just have another function

and just do that for a while. And eventually you'll know why and you'll know when not to, and you'll break that rule. But there's a rule, I think it was five lines, which in Ruby is very small because like two of them, like we're not using curly braces, so like two of them is the deaf and then the end. And so you're like, what, three lines?

I tried to follow that rule for a while. And I found it incredibly constraining. And eventually I broke out of it, but it always gave me this sense of like, you know, if a thing starts to get too big, I start to at least think about every factor, I may not do it. But I didn't really consider back then

this idea of functions matching kind of the, function size matching kind of the importance of the code. And I definitely realized it with classes. I mean, you have like your user class, for instance, you're like, you can go look at any app and see it's user class or whatever it's functionally. And you're like, yeah, you're like, okay, here's the app, you know, or it was usually like two other classes

that are like, here's where the majority of the app is. I think that's good. I think it's good to have this sort of like matching up, which I think is some of your point. But when you say long functions or big functions, are you talking like 10 lines, 20 lines, 500 lines, 2000 lines, like what are your thresholds? I don't really have a threshold.

I definitely will start feeling antsy when a function has more than say a hundred lines of code in it. But if it's an important function, and if there isn't reusability to be achieved by pulling the code out, I still won't refactor it just because it's too long. I try to make being too long not the reason I do things. If there's code reuse, then I'll do it. And the reason for that is, so you touched on it already,

I think it's important functions should be big. Like important things in general should be large and unimportant things should be small. And so when you go into a code base, if there's 105 line codes, it's kind of hard to get a handle on what is happening there. And obviously it depends on exactly what style of code that is.

Is it like a library, like a list thing, or is it like domain logic, or is it controller logic or whatever? So it really depends on what style of code that is. But I prefer to go into a code base and be like, okay, here's like the five functions that are really important for me to understand. And let's go through them and read them top to bottom

and not have to be navigating down five levels deep and then coming back up and then going back down, doing that sort of tree walk that you have to do if you have too much decomposition in a code base. And I use IntelliJ and all the JetBrains products and I'm good with navigation. So I can move around, but I still just find myself preferring just like, just tell me what you're doing.

You show me like, oh,, only like you do this, then you do this, then you do this and fine. It doesn't all need to be factored out if there's no code reviews to be achieved with it. So I think that's important. I think another important observation, and this is, you know, a bit of wisdom in computer science is that there's two hard problems, right?

Cache invalidate or naming things and cash and validation and off by one errors. So naming things is one of the two hard things in computer science. And whenever you extract a function, you've got to name things. You're like committing to the parameters, the signature. Like if you accidentally make it public, someone else suddenly starts relying on it. There's there's a lot of danger in pulling code out into a separate method that I think is unacknowledged by people that act as if pulling code out to another function is just a free

operation, or in fact, we'll just make things better just because you get it. You have a, you know, that name changes, you're sort of committing yourself to that particular bit of logic now because it's somewhere else, so it's harder to go and change. And there's just a lot of like things like that where you end up constraining yourself because you've committed to this sort of signature now,

a name for this thing. And so, you know, I definitely, it's like I started to get issue when a function's a hundred lines of code, but I'll also, I try to be disciplined and like, okay, if there's no code reuse to be found here, like I'm not gonna pull it out just to pull it out. Maybe for testing, maybe,

but then that gets to the testing thing where I tend to prefer end to end and what are sometimes called integration tests, rather than unit tests of like functions. Like I don't like unit testing as much as I like those other styles of tests. And so that I think sort of dovetails with my opinion on longer functions.

There has been some academic work, some actual empirical work on this, believe it or not. And the empirical work that I've seen indicates that you actually, until I think it was like 200 lines of code, And then there was a modern, someone kind of like tried to fact check me with a more modern paper on it. And again, that paper didn't show strong association with longer run time. And then there was a modern, someone kind of like tried to fact check me with a more modern paper on it. And again, that paper didn't show strong association with longer methods and bugs per function.

So it doesn't seem like there's much empirical evidence that long functions are bad. It's mostly just an assertion based on what, as far as I can tell, are aesthetics. Right. So here's something that I will do sometimes, and I wonder if you would do it or not. Sounds like probably not.

If code reuse is your indicator for extraction, is let's say I have a module that has a, it does one major thing, and it's kind of complicated. Like, let's just call it like a checkout of an e-commerce. Like, you know, at checkout time, there's like five or six things that you have to do. And so like, there's your function, whatever, call it checkout. And then it's gonna have five or six things that you have to do. And so like there's your function, whatever, call it checkout.

And then it's gonna have five or six steps. And each of those steps, like I might even like leave myself a comment, like here's my steps, one, two, three, four, five, and I'll describe them. And then I will either have to decide, do I just code those up right here? Or is each one of those the name of a subroutine?

You know, and I code them up in separate routines. I've done it both ways. I honestly don't have like a strong opinion on it being better or worse, but would you just like code all five steps right there in the function most likely, unless there's code reuse? Or would you would? I'd probably put all five right there,

maybe with comments indicating step one, step two, step three, step four, step five. And in particular, what I would look for is, is there shared state between those things? there maybe with comments indicating step one, step two, step three, step four, step five. And in particular, what I would look for is, is there shared state between those things? Because if there is, if there's like more than one thing that's kind of crossing boundaries for those five steps, now extracting that out like can get dangerous because you have to encapsulate that state and are there callbacks or like some crazy, you don't want some crazy callbacks. So like, but I would, I would be inclined to write it the linear way with just if some loops and,

and then if that proves to be unstable or I need to test them individually or something like that, then maybe I would extract them at that point. But I definitely wouldn't extract them. I would, I would write it for sure the first time, just a straight line code. Straight through. And then if that wasn't good enough for whatever reason,

then I would start, you know? And I would look for opportunities to like pull out utility methods if I see it, you know, kind of the same thing in a couple of places. But I wouldn't feel it necessary to structure something where it is. Like, that's an important thing for someone to see that there's like five things going on here and

Sort of in a linear sub steps and so I wouldn't try and hide that from them too much right Well for instance if step two was calculate shipping Well, there might be some other time you're gonna calculate shipping you probably wait Yeah, you're actually doing it elsewhere. Then you might pull that one out Yep, call it from there and then also call from somewhere else that makes a lot of sense to me Yeah, that's the where I would do it. I do like unit tests, not for any other reason, but they're easier to write and they're faster to run.

And so I feel more productive. Like integration tests are like such a drag because you have to do everything. And I know that's like what the app does, but it makes me not like them. They're slow, they're expensive. A lot of times they include some sort of a runner which may have to fire up chromium or something.

Right. Yeah, so the language here is always difficult because like what is a unit test? And this is one thing that infuriates me whenever I'm dealing with people online. Like test advocates are often like, they'll argue definitions rather than concepts. And it's like, well, that's not a unit.

That's not a really, it's like, okay, right. Like I'm not talking about what you're doing. Not useful, yeah. So to me, a unit test is a test that like has, you have one function that maybe doesn't call any other parts of your system, or you mock those calls out. That's a very common practice in unit testing.

And so you're really just testing the logic in one method at a time. Whereas what I call an integration test is anything sort of higher level than that. And I think even testing the public API of a class, for example, is not unit testing necessarily because the internals of that class might be pretty sophisticated,

may hit a database, maybe like whatever. And so that's the level that I like to work at. So my criticism of unit tests is that they often test implementation details and they're not high level enough. And so yes, setting up a good integration test suite can be some work and can take some time to build out all the utilities that you need and so forth. Like often you have to build data objects or whatever.

But my experience is that those tests tend to survive much longer because they express higher level truths about your code base. Whereas unit tests tend to express more ephemeral like this is true for now, but then if I go into a refactor, then they're all gonna break.

And the real hard thing about that in my opinion, and one reason to maybe be a little bit more careful with your unit tests is that when you get a large unit test suite and you've got thousands of tests, that size has its own quality of like leaning on you. Like you can't do a big refactor because you're going to break all these tests. And which of these tests actually,

like which of these tests that are broken are tests that are broken because we did the refactor because you're going to break all these tests. And which of these tests actually, like what, which of these tests that are broken are tests that are broken because we did the refactor and we want them to break like, and, and which are tests that we actually broke something important. And that can be really hard to tell when you get, you know, like out for the companies were like, you know, 50,000 tests that take 10 minutes to run. And it's like, I'm not going to refactor anything, because if I do clean it up, it's just going to all this stuff is going to break. And I'm going to spend four weeks trying to figure out what is really broken and what just went away or whatever.

And so that again, I think that's one reason to try to get your the assertions that you make about your system up to higher levels, sort of away from the details of like the implementation, which unit testing, and again, you can argue about language and all the rest of it, but I think unit tests tend to test implementation details too much. But I acknowledge 100% what you said,

which is that the higher level the tests get, the harder they can be to run, they take longer to run, But I acknowledge 100% what you said, which is that the higher level the tests get, the harder they can be to run. They take longer to run because you've got to set up maybe some state and so forth. And then when you get to end-to-end tests, like you're talking about browser tests, like it's so far away from the code that like, okay, did this test break because a label changed or an ID of an element changed or did like something actually break down in the mock? And so I love end-to-end tests, but I think you have to be really careful there too, for changed or an ID of an element changed or did like something actually break down in the mug.

And so I love end-to-end tests, but I think you have to be really careful there too, for exactly that reason. You need to keep that end-to-end test suite relatively small. Otherwise people just start ignoring it because it breaks all the time and no one can figure out what's going on with it. And that's why again, I really focus on what I would call integration tests for lack of a better term. Just like not unit tests and not end-to-end tests. So what are those? I don't know, integration tests.

Somewhere in the middle. Those in-betweeners. Hopefully they can run fast enough that they're still not incredibly painful. And then when something breaks, it's more obvious than in the end-to-end case. So things break less frequently than unit tests and more obviously than end-to-end case. So things break less frequently than unit tests and more obviously than end-to-end tests.

So that's why I speak up for what I call integration tests. But I don't know. Yeah, there's certainly a give and take with a test suite where it's like on one hand, it's kind of an asset that you have because it gives you assurances that your software continues to operate the way it was designed.

You know, of course, with your, with the asterisks in there that maybe, you know, you tested it wrong and stuff like that. But, but on the other hand, if you value that asset too highly, now it's actually holding you back for making progress. And so in smaller code bases, especially ones where I'm the primary author,

I have no problem either refactoring the tests right along the code or deleting the tests. Sometimes after I write the unit test, it's already done its job, I know the function works, test can be gone. But in large projects with multiple developers, you didn't write those tests in the first place,

you don't know if that test is passing because you changed this interface in a way that makes sense, or if you actually broke something unbeknownst to you, and so it becomes a, can become a hindrance to progress in that sense. Yeah, and I think that's, this is similar to the case with extracting functions.

Like people act like adding a test is cost free, or like always a net positive, like there's no cost associated with it. And that's just not true. Like extracting a method, there's no costs associated with it. And that's just not true. Like extracting a method, there's a cost associated with that. Adding another test that like isn't gonna, even if it's testing correct behavior today, if it's super low level and testing like a particular implementation, like that can hold you back from changing that implementation.

And people say, oh, well, you know, you just, you just refactor the test too. And that's fine to say, but as you point out, when you get into a big development, or even if you can't remember why you added the test, which I'm old now, so that happens, like, what does this test even do? I don't know. Right.

Then it's not as easy to just delete tests, as people say. So there are costs associated. I think that's one meta point I would make anyone who's listening and is particularly younger developers, is that all these things have costs associated with them. Like closures, another great example. I love closures. I love doing data structure manipulation with functional style maps and all that stuff. But closures can get super out of control and you can turn into a callback out like

you have in JavaScript. So many of these tools that we have, it's just Aristotle again, right? There's underuse and overuse and then there's the golden mean and figuring out what that golden mean is sort of wisdom in development. So I think anytime you get someone who's like X is the way, it's like, well, okay, but there's probably some trade-offs that are associated with that. And I like to talk about those trade-offs and not present any particular tool or approach

or certainly the way I do things is like always unilaterally just the best way to do things. You also prefer few classes. You don't mind God objects and like this, the old fashioned FLS versus polymorphism. So, I'm with you on some of those. I don't have a problem with God Objects. I know that's a majority of people say that.

It usually is a bad thing. But I think like you said, that systems have certain more important parts than other parts. And if the user and the, you know, imagine GitHub like the repo, imagine how much code is in their repo objects, like GitHub.

I'm sure it's more than is in their issue objects, for instance. And that's indicative of like, it's about repos, you know? And yeah, it can get unwieldy. But I think we are too afraid of that too early and hedging against something that may never happen. We're prone to over decomposition is the way that I would say it.

To break left, we just break everything up, it'll be, and it's like, it just doesn't, it's again, it's decomposing a system is not cost free. And so yet, you know, cohesion is the idea that things belong, things should be, things that are related belong together. And so, you know, like you probably don't want your user, for example, being also where you send all your emails from. On the other hand, you're always sending an email

to a user. So to me, like put some methods on user that send emails, and that's all right. Like, it's okay if that functionality is in there. And you know, my experience is the same as yours. The user object is going to do this massive thing. And I just don't think it adds much to break that up a whole bunch. Like, and in fact, again, I would say there's a cost associated with that. If you have everything in one file, you know, if you have everything in one class, then it's easier to communicate across. You don't introduce, you don't introduce additional lines to your UML diagram, right?

Whenever I don't, I'm not a big guy. I'm not a big UML guy, but I do know that like more lines is bad, badder in UML. And so, you know, the, the insight there, I think is to be careful with your decomposition at the class level, not just at the function level. So I think it's just, you know, same thing. Well, one place I'll break from you is that I've, in my career, moved from Ruby over to Elixir about 10 years ago. And the pattern matching properties in Elixir allowing me to match on function invocations

and have multiple functions of the same name with different arguments coming in have really simplified, in my experience, my maintenance of branches, what I call like non-confident code, like defensive code, that's what I used to call it. It's like so much of your code, especially at the top of a function,

is like making sure you didn't end up with a thing that you didn't want to end up with, you know? Right. And of course all the types for people are yelling right now, but I like that more than if else, um, but your thoughts on that, have you worked in languages that have pattern matching at the parameter level? I haven't worked in a language that uses primer uses pattern matching as the primary dispatch mechanism.

It looks a little weird to me. I'm just a Java guy. It did look weird at first. Yeah. And so I'm just a Java guy. I don't have a problem with it though. Like, you know, I think it's probably very effective. And when I say ifs and loops, I think that's more of a spiritual ifs and loops than like

the actual ifs and loops. This idea of just keeping it simple and in the Java world, which is where I spend most of my time, just not falling prey to this temptation of a complicated object model when you can just have an if statement that does the same thing.

Five lines of code with an if statement instead of three classes with an interface and doing dynamic dispatch which again clean code would recommend you know like they say explicitly like you see an if statement could this be think to yourself could this be dynamic dispatch and I would recommend the opposite of that I would say if you see dynamic dispatch think to yourself could this be an if statement because you'll reduce the total cognitive load by getting rid of all these additional crappy small classes that you've got. They just do, you know, they're just there basically to do an if statement. So I don't, you know, I just, I've never worked with Elixir or like Haskell or these languages

that really prioritize pattern matching as a, as a dispatch mechanism. So I don't, I can't have a strong opinion on it. But yeah, I mean, I know a lot of very smart people who love it, so that seems indicative that there's something very good there. Yeah, for me, it's like the only way I've actually felt a lot of my conditionals melt away without huge cost, because everything's still right there,

the function name is the same, and you just have like a list of handlers effectively. And so each one- It is an if statement at some level. It's just a higher level way of doing an if statement. Which I can appreciate. Right, but it's not passing you off to some new class that just has like a, you know,

and you're just instantiating a new object and then calling this thing on it, which is basically what the Java story is. So maybe that's just the, maybe at the function level is like the happy middle ground there. I don't know. Yeah.

Well friends, building multi-agent software is hard. Agent to agent and agent to tool communication is still the wild wild west. So how do you achieve accuracy and consistency in non-deterministic agentic applications? That's where the agency, AGNT CY comes in. The agency is an open source collective building the internet of agents and what is the internet of agents? It's a collaboration layer where AI agents can communicate, discover each other, and

work across frameworks. For developers, this means standardized agent discovery tools, seamless protocols for inter-agent communication, and modular components to compose and scale multi-agent workflows. You can now build with other engineers who care about high quality multi-agent software. Visit agency.org and add your support. That's AGNTCY.org. Let's talk vendoring. The last one here, I'll let you go,

but this is a topic that's near and dear to my heart, just because it's so much of what we do is dealing with other people's code and how to do that well, and then failing to, or when to do it, how to do it, et cetera. Vendoring, of course, is the concept of, pretty simple concept, it was just like actually copying other people's code into your project,

versus statically or dynamically linking to it. And you wrote on this as well, your thoughts on vendoring. Well, I really like vendoring. I really like when libraries go out of their way to have no dependencies. And particularly when you talk about JavaScript libraries like HTMX, HTMX is designed so that it can be added

to a website just with a script tag. Like you don't need to adopt a crazy build tools. You know, as I've heard very good things about VEEP, but still like your average human person is like, I just want to put a script tag in the header. Right. I might be down with it. And, um, you know, we've, I think some of the programming, uh, dependency management is an important, it was an important advancement in computer science.

Like I don't want to downplay it, but I do think we've maybe gone a little overboard and I think some communities have gone more overboard than others and the JavaScript community is one of them. Where, you know, you add a dependency and then a thousand other dependencies get dragged in. And now like you have to have a build a pretty sophisticated build system in order to make that software work and I don't you know my experience

for example for some reason this seems like such an easy problem but like I've used three or four different static site generators in my life and they're just like whenever I go back to these old sites and try to upgrade it's's just, everything's broken always. Like the cross dependencies and like, boy, it's just, I've had so many problems with upgrades like that. And so to me, I think library developers would be, they would do their users a saver if they weren't, libraries in particular apps are sort of their own thing.

Like you've got your dependencies and that is what it is. But if you're building a library, I think it behooves you to try as best you can to have as few or ideally no dependencies beyond, you know, just because. And if you've got to pull in some code and write it yourself or whatever, then just write the test for it. And obviously, that's not always realistic. Like you're not going to do your own SSL library or something like that. But, but a lot of your own crypto, right. But typically that stuff's provided by the, by the system, right? Like most of the stuff you shouldn't write is typically provided like just as a base library by the system. And so I think, you know, what I,

particularly in the JavaScript world, I think a lot of libraries could, and I've seen there's, I forget which library it was, but there was a guy on Twitter talking about how like each release of his software, he had fewer and fewer dependencies. And like in release five, he got to zero. And it's like, that's so awesome because now

your software can be used without all this other complicated stuff. And yeah, the JavaScript community is comfortable with V or whatever, but like there's a lot of people that just want to do web development that don't want to deal with all that. And I actually think so, you know, you talk about vendoring. The idea of vendoring is just copying the code into your code base. It's all right. And I think there's actually a big opportunity right now

for a vendor first dependency management system that keeps this idea of transitive dependencies, right? Like, you know, there are going to be times when a library is going to need to depend on another library and figuring that out is difficult. And that's a big value add that these dependency systems do. But I also think that you could do that. And instead of having like end products like compressed JavaScript It's unreadable or whatever or in my case just Java, you know jars like whatever better

Yeah, you have to go and download the source code from somewhere else instead what you could do is you could have a system like that that downloads the source and say a lib directory and You know uses some naming convention to keep everything but just has the source of the libraries there. And then when you compile your project, you compile your project and you compile that source all at once into the final product. And what's really nice about that is then you can check that source in. That can be part of your project. People don't have to have that dependency management system on their system in order to just check out and build your project and run it. And the other important thing, and I think this will become more important

over time, is now you can see all the code that is in your project due to transitive dependencies. And so it's going to be a lot easier for security analysis and like, you know, trusting that you'll be able to build a, you'll be able to build your app and then ship it to production without this. What to me is pretty crazy. Like when people do builds in production and they're actually doing dependency resolution, like in production and then shipping that out, it's like you're trusting a remote system, like at the very last minute to give you the exact same code that it

gave you previously. And that seems like a really like bad security and my just general stability idea to me. Like to me, I'd love to, I wish Java had this where I could just say, okay, these are the libraries that depend on figure out all the trains that have dependencies and then put all that code in my code base, say in a lib directory. And then if I got questions about how something works, the code's just right there. And I can do an audit of it and like make sure there's no inappropriate file system usage or anything like that very easily. So I think there's a big opportunity right now in what I would call vendor oriented dependency managers, where you have a dependency manager that focuses on delivering source to the project instead of sort of final products like Jars

or compressed JavaScript or whatever. Sorry, that's a little bit of a rant, but I've been thinking about that. No, that's interesting. You know, Ruby on Rails used to do that. I wonder if it still does. It wasn't the happy path, but like you can literally, I think that's where the term vendor came from,

is you can literally type like Rails vendor and then something, and it would, instead of like putting them in your gem file and then having a gem file that lock and you know, downloading them to wherever they are in a system, you could actually unpack all of that source code into your vendor directory. And that was good for deploying it

because it was all right there, but it also kind of has some drawbacks. Like if you're gonna check it into your history and stuff, every time you update your dependencies, you're having these huge splats of files updated, and it can be a little bit gnarly in that sense. So I think there's pros and cons, but I do think it's an interesting way of going about it.

Yeah, well, I think I remember the Rails way of doing it, and I remember it being a little janky. And not working, because there just wasn't the focus of it. And I remember being a little janky and not working. Cause there just wasn't like the focus of it. And then the other thing I'd say is computers are pretty fast. So like big janky check-ins are okay at this point. And I don't know.

I feel like I would rather see like what changed with my dependencies, you know, and add someone who's in charge of managing that. And maybe he's in charge of the that and maybe is in charge of the dependencies and doing that work on their own machine. And, you know, then the situation now where I just like get new random jars and I don't know what's in them

or what's changed or anything like that. So I do think there are a lot of trade-offs. I think there's an opportunity there. You'd have to do it right. And you'd have to, you know, be smart about it for sure. But I think there's an opportunity there. You'd have to do it right, and you'd have to be smart about it for sure, but I think there's an opportunity there. And I would couple that with this general cleat to library developers

to reduce the number of transitive dependencies that they bring into projects as well. I think in the JavaScript community, that's a growing trend over the last five or 10 years, where I've seen especially, you know, people pitch us a lot of libraries for coverage and conversation and stuff. Like dependency free is now a marketing term,

which I appreciate that one. There's some marketing terms which I think are silly, like modern, everybody puts modern on there. It just means like they just got finished writing it, you know? But dependency free has actually like become a term of art that people will put with their pitch. Like, hey man, no dependency.

It's like, and to me, that makes it more exciting. I'm like, cool, I can more easily recommend this tool just because I know I'm not dragging something else along for the ride unbeknownst to me, you know? Yeah, exactly. And I have to point out again, this is one of those situations where it's like, we had bad vendor and we had to manage everything yourself. And then we went to

transit of dependencies and everyone's like, this is great. I can depend on this. And then it's spidered out of control. And now maybe there's this moment when we can sort of go back in between those two and say, can we have some of the good of the dependency management system, but then some of the good of the venturing perch as well. I think that's something that's available to us now. We have the technology for it and the experience to do something like that. So I hope someone builds that. I do not have time to do it but I hope someone does.

You know, write your pitch deck Carson. You know, get that pitch out there. Somebody will fund it. Nope. So real quick, HTMX 2.0. Like was there anything to that? Was it a big thing? I remember emailing you when it happened

and you're like well, you know, it's not like brand new or different. I mean there's some things, but it wasn't a big deal. Is that the story? Yeah. We cleaned some stuff up and we didn't.. We changed basically some defaults in it.

And maybe we didn't do quite enough of that. There's a couple of things I look at and I'm like, man, I wish I had changed that in 2.0, but so 3.0 coming soon. And no, no, we're not doing 3.0. I, you know, there's an essay up on the future of HTMX on the website and I talk about how I think HTMX, there are mistakes that I made in it for sure.

Like there are aspects of it that I would change if I could go back in time, but it's not wrong enough that I'm willing to break backwards compatibility to fix those things. Like they're just small, ugly issues or implementation issues that like, this would be simpler. Like, you know, if I use fetch instead of XHR or something like that, that would be a little bit cleaner. And so I really just, you know, if I use fetch instead of XHR or something like that, that would be a little bit cleaner.

And so I really just, you know, I think HTMX is the conceptual idea of it is strong and the little gronkiness that exists around the edges is not worth breaking everyone who's using HTMX stuff just to clean up for, you know, philosophical reasons. And so we've thrown a lot of config options in there to clean up for philosophical reasons. And so we've thrown a lot of config options in there to turn on and off things. Like that's one way that I try to deal with things. Like I don't like how something behaves, but it's the default.

I'll put in the right way, but then put it behind a config flag. So people have to opt into that behavior. And so that makes HTMLX a little more gronky than it would be if I was more willing to break backwards compatibility. But I think backwards compatibility is a big feature. And so the jump from HTMLX one to HTMLX two is very gentle for most people. There were two or three config options that you could flip and basically have identical behavior with 1.0.

And then that's just,'s the the philosophy and and sort of vibe of htmx like we okay we're generalizing hypermedia controls this is what it does we're not gonna try and reinvent that like there's no htmx server components or anything like that coming it does what it does and that's it and so you know so I think that it's different way of approaching software for sure, but I think there's advantages to it as well. Right on.

Well, if you want more from Carson, Hypermedia.systems, a new book, the revolutionary ideas that empowered the web. Read it for free online by the hardcover to support the authors. Just came out in online by the hardcover to support the authors. Very cool. Just came out in Japanese by the way. Oh nice.

It's just in Japan so you can find it there. There you go. Anything else Carson? For all your Japanese listeners. Excellent. No, I think that's it. You know, HTMLX is the big thing. Hypermedia systems, those are the big things right now.

So check them out. Oh, gregug brain.dev. If you want sort of a humorous take on like my humorous take on software development for me and like a caveman voice, you can check out grug brain.dev. All right. All the links to all those things are in your show notes. So check there, click through and connect with Carson. Good stuff. Appreciate your thoughts.

Appreciate your work and put it out there for free. For all to have, that's always awesome, Carson. Appreciate you coming on the show. Thanks a bunch for having me on, I appreciate it. Are you joining us in Denver for our big Kaizen 20 slash Pipe Lee launch show? You should, if you can. Yes, we are recording live at the Oriental Theater

in Denver on Saturday, July 26th. The tickets are 15 bucks cheap and free for ChangeLog++ members. There's a meetup, there's a hike, there's even a Breakmaster cylinder. Get in on it at changelog.com slash live. Thanks again to our partners at Fly.io and to our sponsors of this episode.

Retool, go to retool.com slash agents. Depot, go to depot.dev and agency.org. That's A-G-N-T-C-Y dot org. Okay, this one's done. But we'll talk to you again on Friday. So I'm out.