The CEO of htmx likes codin' dirty (Interview)

29:47If they're using CI providers, 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.

30:26The problem with modern day CI providers is there's still a set of features, 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.

31:07Yes. OK, 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 depot.dev. Get started with a seven day free trial. No credit card required. Again, depot.dev.

31:37One 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 going to 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. Lavingia? Lavingia? I don't know. Yeah. We'll just leave it right there. That's cool.

32:15How did that come together? And then maybe just give a summary of like, what do they find? Why do 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, you know, 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, like, you know, George Costanza, when he did like opposite, like he was just like, I'm going to do the opposite of everything I would do. Yeah, totally. So I was like, I've been trying to do that and it has been surprisingly effective in my life.

32:53And I was like, you know what? Hey, 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, no one's winning in that scenario. Just someone who's pissed off they had to use HTMX. And so let's try and capture why HTMX didn't work well for this particular use case. and so I asked him like hey would you be willing to write an essay on it and uh and he agreed and sort of went through and like here's here's what we found I would say the way they were using HTMX is it was a uh it was an SPA developer using it was like kind of a square peg round hole situation and so they weren't using HTMX the way I would use it um but at the same time that's going to be the same experience that a lot of SPA developers have and uh so they just you know They're really familiar with the SBA tools, and they make things work a certain way, and they're used to that.

33:49And 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 super effective. I saw WebDevCody as well. He never wrote an essay. I asked him to, but he just was like, 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 do Go and HTMX 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.

34:33You 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 uh so i've seen and i've seen that and not just his case or you know but in many cases if you try and bite off too much uh it can i think end up in a pretty bad spot i always recommend that people try htmax 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.

35:14And it's just like an old school, like curl app or, you know, PHP or whatever. And maybe try sprinkling some HTMX in there and see if you can get some quick wins with it. And then, and then that'll sort of show you what the strengths are rather than, you know, okay, we're doing someone on Twitter said hypermedia is good. So we're going to rewrite the whole app and hypermedia and we're going to try and make it all work exactly the same. 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.

35:50And 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 wasn't very good at them. And now as I reached, I think, Gemini 2.4, five and specifically clawed four is just better. Like it just knows more. And so like that problem kind of went away to a certain degree. Um, but there is kind of a, that old saying, you know, nobody goes to that restaurant anymore. It's too crowded. It's like, it's like next JS sucks all the air out of the room. And so people are just going to pick it cause it's what they know.

36:26It'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 right there technology is very much a winner-take-all sort of uh 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.

37:07Now 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 working on HGMX, 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, uh, the best way to do that, uh, 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, uh, being funny is no, no joking matter.

37:49Like you have to like, keep it fun or you're going to quit because it's frustrating. And these people are just picking that cause Facebook said so or whatever. You just have to be okay with it. Like, hey, we're going to go over here. We're going to have our fun. We're going to make some funny jokes. The technology is serious. There's good ideas behind it. I'm happy to talk to people about those ideas. But I'm not going to let the fact that so many people pick Next.js by default and pick the SBA approach by default knock me out of the game. Because 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, you know, saying some interesting things.

38:32Persistence absolutely pays off. Yeah. Especially if you can stay positive and interesting for long enough. Yeah. People eventually pay attention to you. So Next.js, of course, lots of money behind that sucker. You know, HTMX, like, do you have a goal in mind? I mean, how do you make your money? Is this just like something you do because you're a consultant and you use it yourself? or like what's the, 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, I'm a professor. That's how I make my, you know, salary and healthcare and all that stuff.

39:05Um, HGMX does have a fair number of sponsors, uh, much, many more than I ever expected, um, which I'm very appreciative of, but I try to treat that money as not real because it could evaporate tomorrow. Um, and, um, I, uh, the, you know hgmx 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 to you i look like a guy with a i wasn't gonna say it you look like ast louis fan yeah that's all i got but you're out there in montana so how do you get ast louis fan saying that's a funny story um i've actually never been tost louis in my life um so uh i 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 taking my time yeah 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 i'm cool they're i always i 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 uh the mlb tv came out and they just they 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 I might as well start watching the cards, I guess.

40:42And so I started watching the Cardinals and it just kind of spiraled from there. And now I like the Cardinals one. 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 nineties on TBS, I think it was every weekend, it was just Atlanta Braves. oh yeah no sorry why would it be atlanta i guess probably because in local market state yeah yeah there you go turner's out of there yeah so i don't know why but like the braves was on and i watched the braves like religiously as a kid i just loved them and they actually were a good team back in the 90s good pictures 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 you know exactly that's that's basically my story too so one day actually you know i have to the uh when especially when hgm was super hot about like six or eight months ago um a guy in the cardinals organization like saw me and saw me wearing a hat who are like a technical guy like a programmer and reached out and was like hey do everyone want to 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 inst louis so you yeah although it's kind of cool to be able to say i've never been there you know you'd ruin that part of it yeah uh 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 like you're on the field you can kick they let you kick field goals and stuff that was pretty rad just to be there on the 50.

42:35I'll never forget what, oh, what's his name? Uh, 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 him. 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 like unbelievable football player. And, and, uh, I, I, I'm not a Seahawks fan, but I go and I watched 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 uh no i apologize um vendering 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 uh let's go to this one which 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 not 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 and both also and also hated kind of a piece of work and you wrote quick and dirty which you know is contrarian to a certain extent but i also found myself nodding my head.

44:00So 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 an, 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 code, 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 dislay and I haven't, you know, Bob and I have kind of gotten into it on Twitter a little bit jokingly though.

44:42He'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, 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.

45:17And 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 now that I've had some success as a programmer, one of the things I'm trying to do is to go out and say, look, guys, 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.

45:54So 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 necessarily do unit testing and sort of the ideological, what I would call ideological approach of like always writing a test before you write any code. And then the last thing that I take issue with is, 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.

46:40So those are sort of the three things that I picked out in that essay 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 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 def and then the end and so you're like what three lines i tried to follow that rule for a while yeah 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 if a thing starts to get too big I start to at least think about every factor.

48:05I may not do it. But I didn't really consider back then this idea of functions matching kind of the, or 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 that. And you're like, yeah, you're like, okay, here's the app, you know? Or there's 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 is some of your point but when you say long functions or big functions are you talking like 10 lines 20 lines 500 lines 2 000 lines like what what are your thresholds um i don't really have a threshold um i uh i definitely will start feeling antsy when a function has more than say 100 lines of code in it um 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.

49:10I 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 a hundred five line codes, it's kind of hard to get a handle on what is happening there, you know? 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?

49:48So it really depends on the, you know, 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.

50:23You know, you show me like, 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 reuse to be achieved with it. So I think that's important. I think another important observation, and this is a bit of wisdom in computer science, is that there's two hard problems, right? Cache invalidate or naming things and cache invalidation and off by one errors. And 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.

51:00Like if you accidentally make it public, someone else suddenly starts relying on it. 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, 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, you, you end up constraining yourself because you've committed to this sort of signature now a name for this thing.

51:40And so, you know, I, I, I definitely, it's like, I started to get itchy 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 going to pull it out just to pull it out maybe for testing maybe but and then that gets to the testing thing where i tend to prefer and 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 um 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 um and the empirical work uh uh that that I've seen indicates that you actually, until I think it was like 200 lines of code, you actually end up with fewer bugs per line of code if you're willing to allow functions to get larger.

52:36And 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 does one major thing, and it's kind of complicated.

53:16Like, let's just call it like a checkout of an e-commerce. It's 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 going to 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.

53:46I honestly don't have like a strong opinion on it being better or worse, but will 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? 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 know you don't want some crazy callbacks so like uh but i would i would be inclined to write it the linear way with just ifs and 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 i'm kind of the same thing in a couple places but i wouldn't feel it necessary to structure something where it is like you're right 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 set of steps and so i wouldn't try and hide that from them too much right but for instance if step two was calculate shipping well there might be some other time you're going to calculate shipping you'd probably wait until you're actually doing it elsewhere then you might pull that one out yep call it from there and then also call it from somewhere else that makes a lot of sense to me yeah that's the way i would do it i do like unit tests be 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 it's like well that's not a unit that's not a really it's like Like, okay, sure.

56:06Like, 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, may do like whatever.

56:43And 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 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 going to break.

57:20And 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 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 I've worked at companies with like, you know, 50 ,000 tests that take 10 minutes to run.

58:03And it's like, I'm not going to refactor anything because if I do, if I can't 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 this again you know you can argue about language and all the rest of it but um i can you know i think unit tests tend to test implementation details too much so um 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 um 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 mug?

59:05And 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, And 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. Right. Somewhere in the middle. Those in-betweeners. Hopefully they can run fast enough that they're still not like incredibly painful.

59:38And 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 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 the asterisks in there that maybe, you know, you tested it wrong and stuff like that. But on the other hand, if you value that asset too highly now, it's actually holding you back from making progress.

1:00:19And so in smaller code bases, especially ones where I'm the primary author, I have no problem either refactoring the test 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. The 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 can become a hindrance to progress in that sense. Yeah, and I think this is similar to the case with extracting functions.

1:00:56Like 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 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 tests even doing?

1:01:34I don't know. Then it's not as easy to just delete tests as people say. So their costs, 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 sort of functional style maps and all that stuff. But closures can get super out of control and you can turn into a callback help like you have in JavaScript. And so, so many of these tools that we have, you have, it's just Aristotle again, right? Like there's like underuse and overuse, and then there's the golden mean and figuring out what that golden mean is sort of wisdom in development.

1:02:17So I think anytime you get someone who's like X is the way, it's like, well, okay. But like, 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 f-else versus polymorphism so uh i'm with you on some of those i don't have a problem with god objects i know that's a, that's a pejorative. Like people say that it usually is a bad thing.

1:02:57Right. Um, but I think, like you said, the, that systems have certain more important parts than other parts. Yeah. And if the user and the, you know, imagine GitHub, like the repo, imagine how much code is in their repo objects, you know, 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 um 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 we're to break left we just break everything up it'll be and it's like it just doesn't it's again it's a 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.

1:03:54On 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 obviously comes to do this massive thing. And I just don't think it adds much to break that up a whole bunch. Like, in fact, again, I would say there's a cost associated with that. If you have everything in one file, you know, know, if you have everything in one class, then it's easier to communicate across. You don't introduce additional lines to your UML diagram, right?

1:04:27Like 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 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 you know arguments coming in have really simplified in my experience my maintenance of branches what i call like non-conconfident code like a 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 typescript people are yelling right now but i like that more than if else um but what 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 primary uses pattern matching as the primary dispatch mechanism it looks a little weird to me i'm just a java guy i grew up it didn't 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 um 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 you know this idea of just like keeping it simple and you know in in the java world which is where i spend most of my time um just you know not falling prey to this temptation of a complicated object model when you can just have an if statement that does the same thing like you know five lines of code with an if statement instead of like 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?

1:06:35And 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, you know, they're just there basically to do an if statement. so um i don't you know i i just i've never worked with elixir or like haskell or these languages that really prioritize uh pattern matching as a as a dispatch mechanism so i don't i can't have a strong opinion on it so but 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 right you just have like a list of handlers effectively right it is an if statement at some level it's just it is it's a higher level way of doing an if statement right let's not pass 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.

1:08:10That's where the agency, A-G-N-T-C-Y, 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 interagent 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 A-G-N-T-C-Y dot org.

1:08:58Let'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, a pretty simple concept of 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.

1:09:36And 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. You don't need to adopt a crazy build tool. I've heard very good things about Veep, but still, your average person is like, I just want to put a script tag in the header and be done with it. And, you know, we've I think some of the programming 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.

1:10:14And 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 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 just everything's broken always. Like the cross dependencies and like, well, it's just I've had so many problems.

1:10:52with upgrades like that. And so to me, I think library developers would be, they would do their users a favor if they weren't libraries in particular apps are sort of their own thing. Like you've got your dependencies and it 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, And, you know, just 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.

1:11:29But do not write 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, 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.

1:12:04And 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. 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.

1:12:36And 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 that are, you know, 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 into, 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.

1:13:13And 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 trusting. You'll be able to build your app and then ship it to production. Without this, what to me is pretty crazy, when people do builds in production and they're actually doing dependency resolution in production and then shipping that out, it's like you're trusting a remote system at the very last minute to give you the exact same code that it gave you previously.

1:14:07And that seems like a really 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 you depend on, figure out all the transit of 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.

1:14:49Sorry, 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.lock and you know downloading them to wherever they are on a system it would actually unpack all that source code into your vendor directory and that was good for deploying it because it was all right there but it also can have some drawbacks like if you're going to check it into your history and stuff every time you update your dependencies you're having these huge splats of like 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.

1:15:37Yeah. Well, I would, I think I remember the rails way of doing it. And I remember being a little janky and not working like, 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, you know, I don't know, like, I feel like I would rather see like what changed with my dependencies, you know, and have someone who's in charge of managing 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.

1:16:17So 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. And, you know, I would couple that with this general plea 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. And like dependency-free is now a marketing term, which I appreciate that one.

1:16:56There's some marketing terms, which I think are silly, like modern. Everybody puts modern on there. It just means like they just got finished riding it, you know? But, but dependency free is actually like become a term of art that people would put with their pitch. Like, Hey man, no dependencies. 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.

1:17:27and then we went like transitive dependencies and everyone's like this is great I can depend on this and then like 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 like can we have some of the good of the dependency management system but then some of the good of the venturing approach 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 is you know get write your pitch deck carson you know get that pitch out there somebody else somebody will fund it nope so real quick uh htmx 2.0 like was there anything to that was it a big thing i remember emailing you when it happened 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 yeah we we cleaned some stuff up and we didn't, we changed basically some defaults in it.

1:18:26And 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. 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, oh, this would be simpler.

1:19:00Like, 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 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 if 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.

1:19:40and so that makes HTMX 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 HTMX1 to HTMX2 is very gentle for most people you know there were two or three config options that you could flip and basically have identical behavior with 1.0 and then that's just that's the philosophy and sort of vibe of HTMX. Like, okay, we're generalizing hypermedia controls. This is what it does. We're not going to try and reinvent that. Like there's no HTMX server components or anything like that coming.

1:20:20It does what it does and that's it. And so, you know, so I think that it's a 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 the new book the revolutionary ideas that empowered the web read it for free online buy the hardcover to support the authors just came out in japanese by the way oh nice there you go anything for all your japanese for all your japanese listeners excellent no i think that's it um you know hgmx uh is the big thing uh hypermedia systems those are the big things right now.

1:21:03So check them out. Oh, grugbrain.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 grugbrain.dev. So, 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 putting 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.

1:22:00Live. 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.

1:22:35Thank you.

1:23:05Game on!