HTMX v2 with Carson Gross === [00:00:00] Hi there. And welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try it for free at logrocket. com today. My name is Paul and joined with us is Carson Gross. He is the creator of HTMX. What a guest to have on today. So we're going to be talking about HTMX, specifically HTMX v2. The new content on the block. So Carson, I'm a relative noob to HTMX. I am so excited to have you on. I'm excited to get into not only like the basics of HTMX, but this V2 body of work that has come out. Welcome to the show. ~Thanks. ~Thanks for having me on. Happy to be here. So creator of HTMX, ~like ~like how did you identify that there was. ~I ~need for something like this. ~And ~I'm also curious, ~like ~from somebody who's been working on ~like ~the grassroots of this, new language, ~we could call it like, ~what was the first sort of thing you identified as a shift in the paradigm of? Where [00:01:00] everything was headed with web technology that made you embark on this whole project. Yeah it's mostly dumb luck to be honest. So I think I've told this story before, but just for your listeners who've maybe never heard of HTMX or have only seen it in passing, basically what HTMX is an extension to HTML. And what it does is it makes it so that with attributes in HTML, you can add behavior that's very similar to normal links and forms. But you can effectively add that behavior to any element in HTML. And so you can have different events like click or whatever. Trigger an HTTP request and that HTTP request will get back HTML instead of JSON. This is via AJAX. Most people, when they think of AJAX or Fetch or whatever they think of JSON. But HTML X uses HTML instead. And then it places that somewhere in the document. ~And so that's. ~That's like the big idea. It's very, it's pretty simple idea. And it's not new. There were [00:02:00] implementations previously that sort of did similar things. But the reason I started doing this was because I was at a startup and this was a long time ago, ~boy, ~almost 15 years ago now. And I was trying to sort a table and~ They turned out.~ I was trying to do that on the client side because all the cool kids were using JavaScript and this was back in the jQuery days. But I was trying to sort this table on the client side and it just ended up being too slow. And I, almost outta desperation, I tried this other technique where I sorted the table on the server side and then slammed it into the dom. And that ended up being fast enough to satisfy that particular uh, UI and, so I was like, oh, this is cool. And so I created this little custom jQuery function, and then I saw. How angular one was using attributes to drive behavior. And I thought to myself, Oh, that'd be a better way to do this rather than me putting a bunch of like inline click handlers and so forth in the DOM. And so that kind of grew into a library called intercooler JS back in [00:03:00] 2013. I open sourced it in 2013. I'd been working on it for a couple of years at that point internally, but took the plunge. And then I put it out there and there wasn't a lot of like deep intellectual thinking behind it, it was just a response to a problem that, that I had~ ~~for a particular~~, ~in a particular application I was working on. But after I put it out there some people started. Talking to me about, Oh, this is neat. This is actually restful. Like you're using the web, the way it was designed. You're using it according to the original definition, you're using hypermedia as the engine of application state, all this other stuff. And so I started looking into it and it turned out that, yeah, there was a pretty good, Theoretical backing for it. And so I started, getting more into that. It was an ally. I bolted the theory on afterwards. The practice came first and then the theory came afterwards. But that was really good for me just to learn all that stuff. Cause I'd seen it when I was younger, but didn't really understand it. ~And then that. ~In around, I think 2018 or so right when COVID hit I [00:04:00] intercooler had flatlined as far as adoption went. ~And I just was ~in order to avoid being bored and going insane. I was like I wonder if I can pull the jQuery dependency out of intercooler. ~And ~~I could~~,~ and I decided to rename it to HTMX. ~And that made it a. ~It's a little bit larger than intercooler because it doesn't have jQuery to lean on, but ~it's~ it's now htmx is now dependency free. So it's just like a standalone library. It doesn't depend on anything else. And then release that. And I think in the last like year or so, just got very lucky. That there's been , technologies, things move like tides, and so I just got lucky that about six months ago, maybe eight months ago now the tide sort of turned more towards server side. Looking at how the server side can be more involved in building web applications. And react server components are a part of that sort of that move back to the server and HTMX. We were just in a lucky position that we were there with a, with another potential story for people that wanted to [00:05:00] move things to the server side. ~So~~ that's ~that's the history of how we got here not planned at all. ~I'm ~I'm very surprised how popular it's become in the last year. Just cause, intercooler again, flatline. So I wasn't expecting this, but it just goes to show you never know what's going to happen. Huh? ~I, ~I think the perspective that you're sharing right now is really unique, ~if anything, ~of somebody who creates something that a lot of other people use, it's like, Oh this is a fantastic thing. It's the way things should be. But like Carson, you're talking here about this was just my thing. I was just working on it. I identified a need and look at that. People are using it now. So it makes me feel like I have the privilege to ask the question. Do you feel like HTMX is 100 percent ~like what's the word? Like~ properly garnering of the attention that it's getting? Is it being used in the right places that you hope it's being used? Or maybe is the tide causing it to overextend its reach? I'm really curious on your perspective as the creator ~Y ~Yeah, that's a good question. ~I, ~there's definitely a hype cycle around it, and there's the standard Gartner hype cycle, [00:06:00] right? Like the initial promise. Everyone's sick of the old stuff, and so they, oh, this new thing. And it's really simple for simple stuff. But then ~in the reality, the, ~in the long run, the reality sets in, and I do say this quite a bit. HTMX isn't a magic bullet. ~I think that, so ~two things I'd say, first of all, I think some of the ideas behind HTMX are probably more important than HTMX as ~like ~a particular library, ~just ~this idea of hypermedia and how to use the hypermedia model in the web, that's a very important. Technology and it's in sharp contrast with the way S. P. A. S. work ~like ~there is. ~I don't want to pretend that there's not ~a big difference between those two models, and ~I think ~it's good for web developers to understand those two models and understand the trade offs between them when one might be a good approach and one another, one another might be a good approach. And I expect there to be Other implementations like htmx, coming down the road, ~like it's ~htmx is ~a ~a library with enough history at this point that there's things that I would change if I could about it, ~like we, ~we made the initial version IE compatible. And so that came along with a lot of. [00:07:00] baggage ~that's just ~I'm a backwards compatibility guy. So I'm not going to change that. I think it's a good implementation. There's a really good test suite. And I think the API is pretty reasonable. ~Like ~I ~would ~hope that eventually these ideas get folded into HTML itself. But ~I, so I don't think that there's ~I don't think that there's ~a there's a, ~any. Aspects of htmx that I would point to and be like, okay, this is just clearly wrong, but there are lots of aspects that I would point to and say you could have gone one way or the other on this. ~And ~some people would like this choice. Some people would like another choice. As far as being overextended and used too much, I don't even know how much it's being used. That's one of the problems with the hype cycle. Like HTMX is in is everyone's excited about it, but how many people are actually using it? And I think when people use it, there will be at some point inevitable disappointment that, it doesn't make coding easy. Coding is still hard. It can be easier in some ways. And I think, you can simplify there's, examples of people that have really dramatically reduced their code base by moving to HTMX for something like react. But at the end of the [00:08:00] day, code is code and. ~There, ~there isn't a silver bullet and I'm not going to ~prevent the ~HTMX is, so my hope is, and I've been saying this lately is that once the hype wave is over to an extent, there'll be people relax a little bit, both pro and anti HTMX people. Cause there's a lot of both of them. And just look at this as this is a tool. And there are times when it's appropriate and there are times when it isn't. And we'll use it when it is, or maybe not, we'll use some alternative to it when hypermedia is appropriate and then we'll use something else when it's not. Kind of my last question on like the bird's eye view of HTMX and your journey with it thus far. Do you see this project having, defined? Scope limit as to what its responsibility is because there's other frameworks out there or libraries, whatever you want to call them that, ~they'll ~creep into domains that people didn't expect, or even now people don't want, and it provides this murky water as to what is this good at? So do you have a scope limitation [00:09:00] line? Do you think the community does? Why or why not? Yeah, we definitely do. And maybe to the detriment of HTMX adoption. ~So I, ~the way I talk about HTMX now that I understand what it's, ~what I'm ~doing conceptually is that it generalizes hypermedia controls. ~And so what that means is it takes so hyper, ~what's a hypermedia control, something like a link or a form, something that embeds control information in a document. ~And so ~what's unique about those things is that ~they, Okay. ~They embed behavior in documents like a link lets you go somewhere else ~in ~a form, lets you update something or ~whatever, ~do a search ~or whatever. And so ~HTMX ~really~ focuses ~pretty tightly ~on generalizing those things. ~So ~making ~it so that ~any element ~can ~behave in a manner similar to ~the ~links and forms. As we get into what htmx2 is to the point that htmx2 is not going to be that interesting. Certainly nowhere near as interesting as ~like ~the next release of React or Svelte or any of these things. It's going to clean some stuff up and change some defaults that we think are wrong. We're going to drop~ ~~We're going to ~IE support, ~so that'll ~let us clean up the internals. But the API is staying pretty much the same. ~And that, ~for better or for [00:10:00] worse, my take is that this is what HTMX does. It's not going to do anything more. It's not going to do anything less. And that's good. I think ~in the, ~it can provide a steady, like a stable base to build on top of conceptually for your web apps. But it's also bad in that there's going to be stuff that isn't available in HTMX, you're going to have to reach out for other libraries to accomplish some things. And that's just the trade off that you have to make. ~So I can, I want ~HTMX at this point is I think it's at 14 K in the 2. 0 branch, which is pretty big. I'm a little disappointed how large it got. But history support and some of the things that it has baked into, it ~would be, it's, ~I've looked at it and it would be difficult to take much out without changing it pretty dramatically. ~I just, I think ~I think HTMX is going to be a very stable tool and so hopefully~ it I don't want ~I don't want to say like jQuery because jQuery comes with its own baggage, but jQuery has been pretty stable. And my hope is that HTMX is pretty stable ~in that, in~ in that same manner. Yeah, I think it's great that you ~also ~mentioned, in htmx 2. 0, You're not [00:11:00] reinventing the wheel or anything here. It's great segue into, the crux of this episode. What's going on with htmx 2. 0, right before we do that, I just want to remind our listeners, this podcast is brought to you by log rocket. So if you're building a web app, this can be reacts felt, maybe you're using htmx doesn't ~really ~matter. And you want to spend more time building ~right ~and less time debugging in the console. So you can use log rocket to do things like Get a heat map of where your users are clicking, find and surface issues you might not have noticed just from your sentry or console logs. So head over to logrocket. com today and check it out for free and try to supercharge your building. So yeah, Carson, I want to dig into HTMX 2. 0 because that's ~like ~a major version change. And you're telling us yourself, like we're reworking, we're refining. We're defining stuff ~like ~more rigid. I have a list of notes of things that we could talk about, like ~compat about ~compatibility with the shadow DOM head tag merging. I bet there's a bunch of technicals that we could pull out. I wonder if there's ~like ~something from your perspective, though, if you want [00:12:00] to avoid running down a list of something that you think is profound and it doesn't have to be a new feature ~at it doesn't have to be shiny. ~It's just something that you think pushes the library forward on its timeline to maturity. Yeah I think ~the biggest thing that I, ~the biggest feature of htmx 2. 0 is its lack of features is the fact that it doesn't do much compared to 1. 0. It's basically a line in the sand. To me, 2. 0 in htmx is a line in the sand where we say, okay, We're really going to drop IE support and we can in the internals of the implementation, we can start using features that we couldn't use previously because we were committed to this IE support. We're going to keep the one X line around forever and support it forever for people who have IE and who need IE. And I don't expect these two things to diverge too much, but the features that we have are mostly additive, shadow DOM support was added we're going to add a. A new swapping mechanism to swap text. So a little, some people worry about security issues. So that'll be a little bit [00:13:00] more of a secure swap mechanism. But~ but yeah ~you mentioned head support and to take a step back there's. A library that ~I work, ~I created called Idiomorph. And Idiomorph is a library that does something called DOM morphing. And so if you're listeners, Morphdom was the original morphing library and what it does is it takes ~a new. Set a new HTML, ~a new bit of HTML and an original DOM document, and it merges the changes in, so it preserves the DOM nodes as best it can~ and that, ~that allows you to do things like, for example, keep the focus of an input or something like that in a way that ~just like ~straight replacement doesn't really work and ~Morphdom, ~there's a plugin for HTMX to use Morphdom as a merge, so you can get this nicer preserving DOM, preserving behavior. And I created a library called Idiomorph that was inspired by Morphdom and uses a slightly different algorithm to try and match things up a little bit better. ~And ~that's actually being adopted by 37signals for~ for the, ~for Rails, for Turbo [00:14:00] 8, for their ~sort of ~front end. Framework they're using idiomorph. And so when we went into HTMX 2. 0, I was like, Oh, of course, we're going to have a morph swap for HTMX 2. 0. That's an obvious feature. And we went back and forth on it and I eventually just made the call. I'm like, guys, this is too big. And to unfocus like HTMX, the job of HTMX is to generalize hypermedia controls. ~And ~with this morph swap, we've gotten too far beyond that. And so we ~actually ~abandoned a branch in which we had integrated morphdom into the library itself in order to. Really try and focus on simplicity of implementation. ~And yeah, ~And yeah, you can still use more idiomorph as an extension. We're keeping as much as we can and extensions. And that's bad in some ways, because if you want that behavior, you have to go out and get this other thing. And that can be challenging, especially for people that are new. They might not know about these extensions and so forth. It's nice to have everything just there. But we've really on the core team at HTMX~ in HTMX development, ~which is, [00:15:00] you know, me and a couple other people, we've really talked ourselves into like, let's just really stay focused on the basics and ~have, yeah. ~Make it extensible so we can add in these other behaviors and where we need to add extension points to support that. Fine. But let's really try and keep the core pretty simple and Not change it too much. And so that makes the upgrade story from HTMX one to HTMX two much easier. ~And just, ~you get a lot of advantages from that. The disadvantage again, is that ~like we, from ~when someone's like, why should I upgrade to 2. 0? It's like, well, I don't know. ~It's a, ~it's got a few features like, Oh, I'm not using shadow DOM. Okay I'm not going to hunt you down and make you not use 1. X. That's okay. So we're just picking ~a different, it's just ~a different strategy. It's very idiosyncratic when compared with most JavaScript front end frameworks which tend to do sort of big bang reworkings. JQuery does not to their credit in my opinion. But most of the other big front end libraries tend to ask for these big bang releases where there's some brand new idea and, you [00:16:00] have to re implement. Stuff. Although, it seems like I don't want to say that universally, but that's certainly the reputation that front end libraries have at this point. I think a lot of people would agree with you, Carson. And that's why something like, in my circles, people talking about HTMX, that's one of the things they'll tout is it's not super spicy. It speaks to some things that folks have wanted. in their HTML, but it's not super spicy. And that almost feels like a breath of fresh air sometimes. On this list of things that did change with HTMX 2. 0, ~one of ~one of the ones that caught my attention, because we're talking about like standards and wanting to push forward ~like ~the correct use of these protocols, was the changing of delete requests. Instead of form encoded bodies, we have parameters. And this one was interesting because we have a battle. If we're talking about the other frameworks, they have opinions about this. Like we go to the remix versus the Sveltes. Some are all JSON. Some are like, listen, form data is the way to do things. So here [00:17:00] there's an opinion being made. And I'm curious, like, why was it technical? Was it like a standardization thing? Yeah. So the that change was an interesting one. Basically ~delete~ delete. Requests by htmx are going to encode any ~like ~variables and so forth included in the request as request parameters, rather than as a, like ~a ~form data body. And, ~the that's ~that is believe it or not spec compliant ~and ~I saw someone on mastodon, man What is it with mastodon folks? Like sometimes they're very nasty ~Like~ It's the special forum, Carson's. You got to act special there. Yeah, some guy was like What did he say? He was like tell me you know, nothing about rest Without telling me, nothing about rest, because I mentioned that, Hey, we're changing it seems a little crazy, but we're changing from form encoded bodies to parameters for deletes. And I think, you probably can go into the spec and if you want to delete a resource, like that's just you're saying delete the [00:18:00] resource, you're not providing context for what to delete in the same way a post provides this. Body of context, and then it's up to the server to determine what it means. It reminded me a lot of why I was initially alienated by the rest discussions, because we've had these people arguing about rest forever, ~and then the~ and often like arguing very, to me, pedantic points that, I don't know, I don't mind. I don't mind reading a spec and I don't mind understanding the details. I feel like I have a pretty good handle on Roy Fielding's dissertation, which defined the term rest at this point, but practically like the reality is like when you issue a delete, like delete means something to normal humans, it means remove something, some resource. And it seems to me like you might want to do that against both specific. Elements. So if like we were talking about contacts, you might want to say delete contact slash 32 to delete the contact with ID 32, for [00:19:00] example. But then also ~you might want to say delete, ~you might want to issue a delete to contacts and include on a list of IDs to say, like here that, ~just~ I'm thinking of a checkbox UI where you've got all your contacts and you check three or four of them and then say, okay, delete all these. And it makes sense to me to be able to issue a delete request in that instance and include, form data about it. Now you can put that stuff up in query parameters, but there's a limit to the number of query to the length. Of the query parameters that you can include in a request. And so there's this kind of like practical consideration as well. ~The the, just ~the query parameters only support so much data whereas ~form ~form encoding stuff in the body can be very large. You know, It was a little surprising to me to learn this, but I don't have strong opinions on it. We're going to try and follow the spec in 2. 0, but you can revert that in 1. 0. We,~ We use bot, ~use the body, we form and code stuff in the body. But in 2. 0 by default, we'll use parameters, but we also allow you to revert that behavior. And unfortunately this [00:20:00] is one of those sort of obscure areas where different server side frameworks behave differently. And so,~ ~~this is~~,~ that's one of the areas I'm a little worried we're going to break some people's code because it could just start , failing silently in a way that's hard to detect. So we are going to have to do a good job of messaging like, Hey, we're following the spec now, but your server side framework might not be following the spec because it just, the obscurity and vagaries ~of the~~ ~of the tech industry. Thinking about spec makes me also think about cross site requests. Those have a lot of different flavors as well. ~And ~I'm personally, ~I'm ~not super familiar with how the different RFCs or specs ~like ~tell you. The best way to do a cross site request. So how did you guys handle in 1. 0? Is it different in 2. 0? ~yeah. ~Cross site requests are easy enough. ~Like ~you just put in a different domain and then ~there's a bunch. ~There's a huge amount of security stuff as far as like getting cores right and all that. ~That's just, ~it's a nightmare. ~We are ~in 2. 0. We are by default disallowing cross site requests. In 1. 0, we didn't say [00:21:00] anything. And so you could make a cross site request with htmx without an issue. ~You can, ~there's a security policy that you can put in place to disallow that stuff, but htmx didn't form any opinions on its own. ~Around that~ in 2. 0, we're going to disallow cross site requests by default, and you're going to have to explicitly turn that on. Now, htmx is a JavaScript library, and if you're compromised due to bad escaping, like there's not much htmx or any other JavaScript library can do about it. And so it's really just like another layer of security, but really, ~if ~you should be securing your website with a proper course policy that allows and disallows the particular stuff that it makes sense for your particular web application. So we're trying to help you know, there was kind of a brief flurry of like, Oh, HTMX is a huge security issue because of X, Y, and Z. And a lot of that was just people that didn't understand how. Web applications were built, 10 or 15 years ago, where, you have to [00:22:00] sanitize HTML or you have to sanitize content coming from users in order to avoid security issues. And this was a security issue that was recognized very early on in web development. And, ~it~~,~ for old timers, it can make you chuckle because this is like every templating language ever ~since, 2000. ~Since the year 2000 has handled this in some manner. But you know,~ ~~we~~, ~I think just we've tried to tighten up the security story by default with the caveat that at the end of the day, HTMX is JavaScript and that's not where your security layer is. Your security layer is really like a level down ~your~~ ~when you're defining security policy for your web app. So speaking of defining security policies, sanitizing your input, putting in that due diligence, do you folks feel like or the general ~like ~open source team feel like there's pushback about HTMX being pushed to the back end in terms of responsibility work that needs to be done? And if yes or no, depending what that is, how are you guys responding to that? [00:23:00] And is there A change in plan Yeah, ~no, there's~~,~ so it's been interesting again I'm trying to deescalate stuff, but like someone posted on LinkedIn the other day is HTMX going to come for all the front end jobs. And I just do not see that. I think that HTMX I've, and I've said this before, but I think people who understand front end really well, particularly CSS and HTML really well. And who also have the programming chops now front end, front end 20 years ago or 25 years ago, say was, it was all CSS and like, bit pushing, like you're using GIF images to make things line up and so forth. And so front end at that point was much more oriented towards design. And less oriented towards coding. And that's obviously dramatically changed like in the last 10 years where front end coding is very serious software engineering. And so my, my, my take on this is that means that a lot of front end engineers who understand CSS really well, who understand HTML [00:24:00] really well, and also have the ability to understand pretty complicated code, like, GraphQL is a complicated concept. I think those people could very effectively switch to generating HTML on the back end and then use something like SQL, which in some ways is similar to GraphQL in many ways is much more powerful than GraphQL in order to generate their HTML and become incredibly effective HTML engineers. ~The~~,~ I do think that there are backend engineers who are picking up HTMX and. Building more and more interesting user experiences with it. And that's good, but there's still those people for the most part are going to be back end engineers. They're not going to have the design skills and the ability to build the UX patterns that are ~as, as ~as good ~as many~ as many front end engineers have the ability to do. And so I think, I look at it both ways, like the backend engineers may become a little bit more. Useful and generating sort of front end patterns. And then the front end engineers start dipping their hand into the back end, which is [00:25:00] already happening with react server components, and again, I think we got lucky ~that react, ~that the react team is making people look this direction. Anyways, we're riding on some of the wake from that move on their part where we can say, okay, that's cool, but here's this other story that can get front end people involved in the back end. So you guys really see this as like a cross pollination of, domains of expertise, and it's not like htmx is being super opinionated. You think about pushing complexity one way or the other. Yeah, ~I, ~it's ~an unopinionated language or excuse me, ~an unopinionated library, I should say. And~ that, ~that doesn't mean that they're unopinionated people who use it though. So some people are going to use HTMX and be like, I'm never writing a line of JavaScript again, and that's fine. ~Those people are~~,~ there's sort of a limit, an upper limit to what you can achieve if you take that idea. But then there are other people that are like, Oh, HTMX is cool, we really need. JavaScript, something more serious for these parts of our application. And so they'll use, a more elaborate JavaScript library, like viewer Svelte or whatever for that [00:26:00] part of their library, and then use HTMX for all the dumb stuff for all, the cruddy stuff that doesn't need to have all that infrastructure in place, try and save some complexity budget. That's a concept I like to talk about, you've got so much complexity you can heap into your application before things go sideways. And so use HTMX to save some of it and then heap the complexity into whatever part you're really adding value with, maybe that's on the front end, maybe it's on the back end, whatever, but HTMX can take care of the dumb stuff for you. Last question about big ticket items for htmx The shadow DOM compatibility, is that squared away? Or is there more work that you guys see coming out in 2024? ~I~ I have to admit, I'm not ~super, I don't know I, and I looked at the change, but I can't say I'm ~an expert on the change and the shadow Dom has, I've always felt that web components suffer a little bit from being a little too isolated from the rest of the Dom. There's this big focus on isolation, which has made it difficult for them to integrate with other elements, ~with~~,~ it's just hard to integrate them in my [00:27:00] experience. ~But ~I haven't used them practically ~and ~in a few years. So I don't know if that still holds, ~but so I, my, ~my guess is that with the renewed focus on ~sort of ~web standards that we're seeing, we're seeing a lot of this, right? Like the objections to Apple. Pulling web apps, ~like ~like the zeitgeist right now is web standards, let's get these web standards worked out, and a big part of that's Microsoft is really on board, not necessarily for good reasons, but ~they're, ~they're on board. ~And so I think I think that, my, or ~my hope ~I would say ~is that web components. Become ~more and ~more useful and they start listening to the criticisms of web components. And as those changes come in I would imagine HTMX will have, changes that are necessary. We have a team member, someone who's working~ on the~ on the HTMX team who knows web components really well, actually has their own library for building web components. And we've got the expertise to react ~to. ~To changes that come down the pipe, ~but~ I ~think ~the definitely 2. 0 is at least a good first step. Awesome. I'd like to close out our conversation today because we are running up on time getting close to that [00:28:00] mark , with some projects, Carson, that maybe you've seen made with HTMX that have caught your attention. And if you happen to like know a particular feature or design pattern. When you looked at that website and said, Hey, like they used HTMX and they probably use this neat thing that people can do with it. Curious about that too, but at a basic level. Just wondering if there's any projects you would like to share with listeners. Yeah one that's near and dear to my heart ~is one ~is the Berkeley Nobel prize website. Just cause my undergrad was at Berkeley. ~And ~and so ~the Berkeley undergrad or ~the Berkeley Nobel prize site uses a pretty simple pattern in HTMX, which is the filtering, the app, we call it active search. If you go to htmx. org slash examples, slash. Active dash search. ~I think ~you can see it in action and it's basically where you type in and then it updates some other content. ~And ~that's one of those things that can be a really quick win with htmx. You've got just a plain old website. You want to add this kind of flashy ability to ~do~~ ~type a little bit and see some search results [00:29:00] immediately. Behavior to it. Htmx makes that pretty easy. So the Berkeley Nobel Prize website has that. Yeah. And then Nike vision, just because it's Nike uses it as well on their website. And it's the same thing. As far as active search implementation using HTMX. The probably the most elaborate site that I'm aware of that uses it is Zorro management. That's a kind of a project management system that was created by a guy who's on the core team now on HTMX. And that's a pretty elaborate mix of HTMX and JavaScript. He has written a lot of vanilla JavaScript and he does a really good job. Integrating scripting and then HTMX using events and using HTMX to synchronize with the server. So using JavaScript for what I would argue it was intended for, which is client side enhancement really extensively supporting really nice, date selection ranges. He did all that stuff by hand himself. And he just integrates it with HTMX. So I think that's a good [00:30:00] example. That's probably in my mind, an example of how far you can push HTMX ~if you're willing to integrate that scripting, ~if you're willing to integrate your scripting with it in a hypermedia friendly manner~ there were, boy, I forgotten the name, but there was an AI and ~there's a bunch of demos on YouTube. People that are integrating HTMX with an AI, chat system and~ and it's basically, ~it's almost the same thing as the active search thing where you like type a question and hit enter and then it streams down a response. A lot of them use server side events, the server side events extension ~to, ~to HTMX. And~ those I think ~those can show how HTMX is simple as the model is when you're using it. It can be. Relevant even for pretty sophisticated pieces of software. And that's an example where I talk about this, like if your system adds a lot of value on the server side. So AI, obviously, like we're adding our value on the server side. Then HTMX can be this really simple. Front end that ~sits on front ~sits in front of that, but still provides a pretty good user experience. User experience is pretty sophisticated, even by today's modern web term. And that [00:31:00] allows you to, once again, ~like to ~minimize that budget, the complexity budget that you put into your front end so ~that ~you can focus your efforts on your backend. So I think ~those are, ~those are some examples of applications out there that are being built with it. If you go ~to the ~To the essays page on htmx org slash essays, there's two things, a real world react to htmx port, and then another real world react to htmx port. And those have details on two people who took their software and moved from react to htmx and saw some pretty. Good improvements as far as ~they're like ~developer velocity, total code base size and so forth. Now, that being said, ~again, ~I want to stress that HTMX isn't always the right choice. ~And it's ~~those were two examples, ~~those type, ~those two applications were particularly amenable to an HTMX based implementation. ~There's, ~there are a lot of applications that ~would, ~could be done with HTMX. And many of them couldn't have similar benefits from adopting it. ~Yeah,~ Thank you for those examples. I especially know the work management one people be interested in because you want to see what can it do? What are the limitations and where can you push [00:32:00] it? Appreciate you calling out that's where they push the envelope there. And last but not least, if htmech. org slash docs htmx. org slash docs is, or that's the introduction examples. If you're more of an examples person, go to slash examples, and those do a pretty good job of showing you what htmx can do, at least basic htmx. And you can walk through those. And then also we do have a book that we wrote called hypermedia systems which is, you can go to hypermedia dot systems. You can buy a hardcover version or you can buy it in Kindle or it's available online for free. And so you can read that. That kind of walks through the history of web applications, how we got to where we are and walks you through how HTMX can help improve web applications. Yeah, we build out a contact application in it. So you can see different patterns ~to ~that you can use with HTMX. There's also a section on a mobile hypermedia called [00:33:00] hyper view. That's a really interesting thing as well. So we, again, I'm trying to focus as much on the idea of hypermedia as I am on the specifics of HTMX. hypermedia dot systems, right? Yep. Awesome. Carson, it's been a pleasure. I've learned a lot about htmx today, and hopefully folks, if they haven't known about it, now they know about it. And if they're didn't know about 2. 0, 2. 0 is out. So go to htmx. org and get building. So thank you for your time, Carson. It's been a pleasure. Thanks, Paul.