#321: HTMX - Clean, Dynamic HTML Pages Transcript

00:00 Have you wanted to add more interactivity and lightness to your web application, if you built it using flask, Django or some other Python web framework, that thought probably didn't fill you with joy. And that's because it might mean you need to change a bunch of your code and rewrite a significant bit of your application using a full on front end web framework like Vue JS or react js. In this episode, we meet Carson from Big Sky software. He's the creator of HTMX, this front end JavaScript library lets you leverage the server side aspects of your Python web app and add amazing interactivity. But keep the logic on the server near the database and implemented in Python. You're going to love it. This is talk Python to me, Episode 321, recorded may 25 2021.

00:56 Welcome to talk Python, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities. This is your host, Michael Kennedy, follow me on Twitter, where I'm @mkennedy, and keep up with the show and listen to past episodes at talk python.fm. And follow the show on Twitter via at talk Python. This episode is brought to you by Sentry and yourbase and the transcripts are brought to you by assembly AI, please check out what they're offering during their segments. It really helps support the show. Carson welcome to talk Python to me, thank you, I'm really happy to be here, I'm very thankful that you're willing to go a little bit outside of the lines of normal Python development to talk about something like HTMX. You know, I'm extremely happy to see HTMX getting picked up particularly by the Django community in Python. And so I was very excited to come on here. Yeah, I'm really excited to have you here. It is such a cool technology. And I think so often the JavaScript story is, oh, you're doing this other technology that you like, let us tell you how you should drop that and go to JavaScript, right. And what I feel HTMX brings is whatever technology you're using; Django flask, even some other thing like rails, or ASP.net, whatever it is that you already got working really well, here's a really cool way to extend that we're going to dive into that. So I think, you know, I've had people reach out and say, Oh, I'm a JavaScript developer. And let me come onto your podcast and tell people about how cool Node is. I'm like, Well, I'm not really sure that's the best topic for a Python focus podcast. So I'm going to decline your invitation. But I was really happy to get a chance to have you on the show. Because I think there are many people out there who are nervous about JavaScript, they're not yet learning JavaScript they want they know they need some interactivity. And they feel that means they have to abandon what they've already learned or what they actually love. And I don't think that's the case. And we're going to dive into that. So I think HTMX plus Python web frameworks is a beautiful thing. But before we get into that, let's just start with your story. How did you get into programming? And yeah, started that. Sure. Well, I've been programming for a very long time now. And I started programming in college back in 94. Actually, before that, I was programming on a Mac and hyper card, which is a very old technology, which I love the web before the web, like local web, I keep talking about that. If we talk about hyper script at the end, maybe that'll come up again. Yeah, but I started programming in college. And then very early on, started programming for the web back when it was CGI scripts and Perl and stuff like that. And then I moved into Java during kind of the original com boom, and did a lot of the was in the Java world for a long time, and eventually moved into rails. And so I've been programming and rails. Now, for the most part I do. I program, a lot of different stuff, though, mainly Java and rails. And I have to admit to your audience, please don't judge me too hard. But I haven't used Python very much in anger. I've used it for local sort of sysadmin scripts, but not for a bunch of web development. So but you know, rails and Django share a lot of things in common with one another. And they're both great server side pieces of infrastructure. And it's, I always felt like it was a shame that they were kind of being left that they were being ignored to a large extent by the by the bigger JavaScript frameworks. one term that I try and coin, there's a lot of different stacks out there, right, like the LAMP stack, and so on and so forth. And one joke stack that I've made up is the house stack, which is highbrow Ah, oh, who, who? Okay, so HTML on whatever you'd like.

04:33 So use HTML on the front end.

04:37 HTML is really empowering for this, right? I mean, that's kind of the philosophy and some degree, I mean, a joke stack, but like, literally, that's Yeah. It's a joke. I mean, it's kind of true.

04:48 Sam, yeah, absolutely. And how about now what do you do day to day, so day to day I teach part time at a university. My passion is actually programming languages. So I teach that as well as some other programs.

05:00 classes at a university part time. And then I also I work for a startup as well that I've been working on for a long time and which uses intercooler js, which is the predecessor to HTMX the story with HTMX was that well, we can go into in a little bit if you'd like to, but but that's what I'm doing now. So kind of a mess, I find myself doing a lot of different stuff. Yeah, that sounds like a really nice mix. I love universities, I love university campuses. Maybe it's a slightly different story today with COVID. Right? I think we'll kind of get back to it. But some of my fondest memories are just, you know, spending time dreaming about ideas walking around various campuses, yeah, it's a good energy. The kids aren't quite as beaten down some of the, when you're in that corporate sector. I mean, you see a lot of these posts on Hacker News, and so forth, just old guys, older guys and gals that are just sick of a sick of the grind. And so it's nice to be around younger kids that are maybe not quite as jaded. And there's just an energy and you know, it's a beautiful environment. So yeah, keeps you young being around that crowd. I do think that's awesome. So I want to start our conversation by taking a little bit of a step back. And I think we've circled around this a little bit. But when people are working in some technology, let's focus on Python. But it could be rails, like you said before, and they've got something working really great. You come to some part of the site. And it's like, well, this should be really interactive. Like I want to click on this thing. And depending on what I select here, I want that drop down to select that other thing. Or, as I search here, I want it to actually just fill out as I type, I don't want to have to type in the search text, hit enter, see what comes back from the server, oftentimes, that is sold as a, well, your site is going to be more responsive if it's running on the front end. And sometimes that's sort of true, but I feel like a well designed website can be really responsive. Like I don't really feel like the speed thing is the story. But this interactive like navigation thing where it resets where it is like that is a real challenge. And so often people get pulled down this path, right? Well, you want to have that experience. So is it Vue js, or react, which you're going to do and then 10,000 lines later front end code, you've winnowed down your back end to just a couple of simple HTTP API methods, then also something that serves up I guess, HTML static page. And then the question becomes, well, why are we doing Python? Or why are we doing rails at all? Why don't we just do Node on the back end, and we just have that as our entire stack, I feel a lot of times people either end up going down that path and throwing, you know, the baby out with the bathwater type of thing, right? Like you have this really cool server side ORM and a bunch of stuff happening that you really love, from your server side, say Django or whatever. But you kind of already gone like, you're just so close to just like, well, let's just we're already right, mostly writing JavaScript, let's just write JavaScript. So I think that's one side of the story. And I think there's real pressure on the other web frameworks, Python and other spaces for that. The other side is people who are not doing that, but they feel bad. They're like, I know, I'm doing it wrong. I know, I'm not using react. I'm just using Django. But this is all I know, and I just not ready or we're just not a big enough team. How does that sit with you? Or do you think about this? Yeah, I didn't like that. That's exactly the pressure, I don't like it either.

08:23 About 80 of x, that's exactly the pressure that I felt on rails, I liked rails, you know, Ruby as a programming language, I'm so so on. It's fine. It's got its issues, but I liked rails quite a bit. And I just disliked that pressure to adopt something else on the back end, that came with using these more complex JavaScript front ends. And, you know, like I said earlier, it was just a shame. And you know, the other aspect of that is when you go to that model, when you go to the Vue JS or the React model, your back end becomes pretty dumb. It's just producing JSON, you know, there's validation code. And you know, yeah, your validation code can now live on both sides. Which is important, because the front end is not a trusted computing environment. So you can't trust validations that are done on the front end, you always have to read them all. You just redo them again. Anyway, that's Yeah. So there's just all these kind of, I don't think they're complete arguments. But just, it's just with the grain to start pushing JavaScript onto the back end, especially once node really came out and gave JavaScript a good runtime on the back end. Yeah. And and it's not a good thing. And the reality is, is I hope we can demonstrate with HTML today that a lot of very good UI or slash UX patterns from the web can be achieved using just HTML using the original HTML model. They are the original restful model for the web. I know that's a kind of a fancy term, but just using the original model web, just kind of generalizing what we're already familiar with in our day to day development links and forms. That's where HTMX is coming from, is this idea Wait a second, let's take a step back.

10:00 We don't need a super complicated front end. We just need to improve HTML, right? We don't have to push it all down to the front end, right? We only need to push a little bit of that interactivity down, right? That's right. And that interactivity can be defined in terms that are very familiar to us from normal HTML. So let's just let's just take HTML and try and push it as a hypermedia. hypermedia. And I guess I should say people get mad because hypermedia is plural. But I say

10:30 so you know, that's what that's where HTMX is coming from. It's very similar, you know, this frustration with the industry. Particularly I don't think this is strong now, because Python has had I mean, you're going to look at the trends and Python is just crushing right now. Yeah, it's it's such a not a resurgence, but such an acceleration from where it was right now. 10 years ago. And I think if you compare that with five years ago, JavaScript was really the thing that was accelerating the most, I don't think that's true today, I think JavaScript is maybe plateauing a little bit, there's still plenty of JavaScript out there, obviously. But I feel like pythons really taking off because of, you know, big data and and some of the AI tools that are available in Python. And so some of the great older tools like Django, and flasks that have been around for a long time, and they do a good job. So again, just very similar situation with you where I'm looking at this guy, man, this thinks that you have to, you have to become either like a killer JavaScript front end engineer, and then have two languages that are pretty complicated. or abandon whatever back end you you prefer in favor of JavaScript. Yeah, I'm 100%. with you. Let me pull up a couple of things. One, here's that that graph that you're talking about, that's exactly going pretty, pretty wild. Like, you talked about JavaScript plateau. And so this is the Stack Overflow, Stack Overflow trends for the major programming languages. So yeah, this is really surprising to me. And I find it quite interesting here. Yeah. Also a couple things from the live stream, Nick Harvey. Hey, Nick says, For me, it's a constant battle between all the benefits of server side Plus, I don't want the page to keep refreshing. Yep. I sympathize, Nick. And that's exactly what HTML is designed to help with the real bad part about the original web and browsers, we have to say, I think you made this point earlier, Michael, browsers have gotten better at making the page transition not quite as clunky visually. So you can do sort of web 1.0 style apps and get away with it for a lot of stuff. Yeah, you talked about doing programming and 94. And I remember the first mosaic that I saw, that was the graphical web. And I was just my jaw was just dropped. And I, This changes everything. I've been using telnet and go for crazy stuff.

12:47 And I'm just like, this is a new world. I literally think I had to skip the next class I was supposed to go to because I'm like, I can't I have to explore this. This is unbelievable what I've just found. I remember going to Hong Kong, you could just see it building the page as it comes. And that was Yeah, yeah. It's luckily it's not like that. It's the big problem with it is you know, it's much better now. But it's still a problem. And it's a big problem for many UX patterns, you just you don't want it and that's exactly what HTMX is designed to to help with. So you can stay within that original model of the web can use whatever backend you want to produce your HTML, but we can get better user experience out of it. Yeah.

13:24 So also RJ out there in the live stream says I just discovered HTML a few days ago. Great timing.

13:32 This portion of talk Python to me brought to you by Sentry. How would you like to remove a little stress from your life? Do you worry that users might be having difficulties or are encountering errors in your app right now? Do you even know it until they send that support email? How much better would it be to have the error and performance details immediately sent to you, including the call stack and values of local variables and the active user recorded in that report? With Sentry This is not only possible, it's simple. In fact, we use Sentry on all the talk Python and web properties, we've actually fixed a bug triggered by a user and had the upgrade ready to roll out as we got their support email. That was a great email to write back. We saw your error and have already rolled out the fix. Imagine their surprise, surprise and delight your users today, create your Sentry account at talk python.fm slash Sentry. And if you sign up with a code talk python 2021. It's good for two months of Sentry's team plan, which will give you up to 20 times as many monthly events as well as other features. So just use that code talk Python 2021 as your promo code when you sign up.

14:39 Yeah, so speaking of which, let's go ahead and let's let's get into it, right, so we've set this up as a, it doesn't have to be either or it doesn't have to be either Django or flask or react or view right. Like it doesn't necessarily have to be that way. And there's some really cool stuff going on here. Like let me just read this little introduction you got over here htmx.org he says

15:00 MX allows you to access Ajax CSS transactions WebSockets server sent events directly in HTML, just using attributes. So you can build modern interfaces, simply, which is really nice. And one of the things that frustrates me about these frameworks like I do some stuff in Vue, and like, I'm not against it, I just want to put out there, I realize there are apps that are absolutely making sense to build with Vue or with react, right? Are you trying to build a mobile app that is really sort of a progressive web app, like, it should absolutely be in that, are you trying to build Gmail, it's very likely be in something like Vue. But most of us just want a sprinkling like a little salt, you know, a little bit niceness here in there to our app. And in order to get that these days, JavaScript has moved so far, that it's no longer this simple little language that you just include a tag and then to the file and you're good to go. It's like, you've got Webpack. And you've got CI tools, and you've just got all this stuff to go. Right. So what's the Getting Started Experience for HTMX? Yeah, HTMX looks pretty straightforward here. Yeah, it's a small it's so it's no, it's a no build libraries here. There's no build step associated with it, you just drop it in. And you can use a CDN, if you want. The starting experience for it can be as simple as just adding a single attribute, or maybe two attributes would be the minimum thing. And so it's not, it doesn't require a total rework of your front end. And that's one, you know, one concept I like to talk about with my students is this idea of a complexity budget, your application has a complexity budget, you need to spend it effectively. And so with HTMX, you can pick the parts of your app that need it, and add interactivity to them. And the remainder of your app can remain just a standard, you know, web app that works the normal way. And because of that, you can sort of spend your complexity budget where you want to on your app, rather than saying, okay, we're going to, we're going to react and now we need to react router. And now we need graph qL, we need all this stuff to make our next sprint is going to be the rewrite sprint, right? I hope it's, you know, people would agree that it's a lightweight library in that sense. And that you don't, you don't need to do a lot to make things work. Within one particular, there's some attributes like Ajax boost, for example, that you can just kind of toss on your, you know, on the body tag, and it'll turn all the links into Ajax requests, and all the forms and Ajax submissions. And so it's kinda like turbo links, if you're familiar with that technology. And so we, you know, there's, that isn't a big focus of the library, but it's there as well. So, hopefully, relatively lightweight, and the user experience I was gonna say, so you basically include a script tag to link to HTMX x 10 kilobytes, and it has no dependencies. Yep.

17:51 Yeah, RJ l out there in the live streams, as I strongly believe that these JS library, speaking of view and react and whatnot are overkill for the majority of CRUD apps that exist on the web, probably 90% of the Chrome apps are built within private corporations. And I've been doing that since 94. And then also, does NPM and web pack are both a blessing and a curse. Yeah. Especially if you're a back end sort of person. Yeah, I never liked big complicated build tools in any, you know, in any, even on the back end. I just, I'm not a big fan of them. I like dependency managers. But beyond that, I don't want a bunch of stuff going on. Yeah, I'm with you on that as well. Alright, so let's talk about the motivation that you got here before we get into some code, because I think it really sets the stage. I mean, obviously, we've we've been setting the motivation here. But you know, you throw out some questions. Some hypothetical is like, hey,

18:42 why should only anchor tags and forms people to make HTTP requests? Like, if I click on an image, shouldn't it be able to make an HTTP HTTP request? Why should click and submit be the only events that trigger them? Right, like mouseover key down or something like that, right, pry key down for a smart autocomplete search? Why should only get and post be available? And why should you watch the only replace the entire screen? Yeah. And that last one's really the crux for what Nick is talking about earlier, right? Is web requests have to do this big chunky replace the whole screen. If you have an action that only updates a small amount on a screen, why not just return the HTML for that small amount of the screen, and then in that element that's issuing that request, specify Oh, put the return content into that thing. And that's exactly that. So HTMX has an attribute called Ajax swap that lets you or excuse me, Ajax target, that lets you say exactly where you want to place the returned content. And then Ajax swap is another attribute, which lets you tell a CMS exactly how to do that swap if you want to replace the whole thing or just the inner content or appended or whatever. So let me lay out an example here of a type of app that feels like it would need view or something

20:00 I'm just going to pick on view is like the catch all for all the major, you know, front end frameworks going forward. So imagine I've got like a photo gallery of like, five images up on the screen, and I want to be able to click on that image, and then have like details of it like maybe the EXIF tags or like where it was taken or other stuff stored about it on the server. And maybe it's like a Wikipedia thing. And like, you click on the picture, and it gives you some details about the picture below. And you just want to keep that there. And as you click on them, maybe even use an arrow keys, or click around between them, and have that happen. Yeah, that's the kind of thing you're talking about, right? Like I could set it up. So I can have an event where I interact with the image, and it does a swap. And explain to me what I have to write in order to get that bottom part to like reload, yeah, all you would do is on that image, you would say Ajax get and you would give it the URL to get that information from. And now that information will come back in HTML form. And then you would say, Ajax target, and there would likely be a div down below, that would be your details div. And let's say it as the ID details. So your Ajax target attribute in that case would be hash details. And that tells HTML, when this request comes back, take that content and jam it into the details div or whatever that has, right, exactly ELLs on it. Yeah, to that bottom section. And then if you want to, you know, depending on how you want to do that swap, the AJAX swap attribute, lets you say enter its default is enter HTML. So it'll swap that into the inner HTML, but maybe you want to replace the whole thing for whatever reason, you could say Ajax swap outer HTML. And then there's a bunch of attributes that are and there's some syntax and there lets you control stroke, scroll state, whether or not something gets pushed into history, depending on how you want to do that, and so forth. And so there's, there's little, there's a lot of stuff like that, that lets you determine exactly how that swap is gonna happen. Yeah. Oh, fantastic. So right on the home screen, you've got

22:00 got an example that is commented, without the comments. It's four lines of HTML, right? And that's the entire application, I guess you probably would want to wrap that in like an HTML and a body tag, but right beyond that, right? So what you do is you include the script, and then you have a button and on the button, you have an attribute says h x dash post equals slash clicked. Then you have your h x equal dash swap equals outer HTML, presumably of the button, right? So you could say click the button and the button would replace with like, a map of where you are or rate of results or whatever the heck, the returned HTML from slash clicked is right. Yeah, that's right. And it's a it's a checks post, right? Is that what you said? Yeah. ajax post, I probably said it wrong. But yes, exactly. That's, that's what I mean. Oh, no, it's okay. I just want to make sure. Yep. Yeah, keep me honest. No, it's all good. It's hard to do code visually, my screen is flickering again. So I want to make sure I'm on the same page here. Yeah, yeah, this is just the Quickstart at the home page. This is so neat. Because when people think about all this stuff they have to do, in order to adopt this type of dynamic page that you're talking about, what you have to do is you have to have a method on the server view method on the server that returns HTML fragments, instead of returning, you know, the whole HTML body, whatever. Like if my story where I said, I'm going to put a grid of results, you have to have a server side thing that can generate HTML for a grid, right? So you could do that with like a template like a Jinja, or a Django template, or chameleon template on the server, and just pull the data database bind it and instead of returning have your template contain a full bit of HTML, it's like an HTML fragment. Yeah. on your server side, exactly. In rails, they're called partials. And that's the language the rails community uses. But it's just a sub template. And so typically, what you would do in an HTML based application is you'd have your normal templates. And then they would include these sort of sub templates or partials, again, to use the rails terminology. And so the HTML is kind of pushes the factoring problem to the back end. So you factor your templates out on the back end, rather than like maybe create creating components on the front end is how someone more familiar with view might think about these things or react. Yeah, it's like the little component bit on the server side. Yeah, yeah. So you do your factoring on the back end. And then hopefully, you designing a good URL schema, a nice restful URL schema, and it all kind of makes sense with several resources, right, so forth, right? So in this example, there's just a button it just goes to slash clicked. But in my scenario, where I had five images, the URL like the H x dash post, it would be slash details slash one, yes, detail slash two. And when you render the original HTML, you can pre load into those, those embedded pieces, the right data types.

25:00 Pass on when it gets clicked or what gets interacted with, right? Yeah, exactly. So so that image is a resource, we're gonna have if we're thinking restfully, that image is a resource on the server. And so it has a has a URL associated with it, let's say images slash, one, let's just say that. And then images slash, one might have a sub resource of images slash one slash details. And so you would, you know, you render that image. And then that image slash ID slash details is what returns the details you were talking about earlier. And you probably use Ajax get in this case, because it's a, you're retrieving information without a mutation. So post is probably not an appropriate HTTP verb or action to use. And so you would get that and then you know, slam it into the div below the images, right? That's almost exactly what you would do. If you were going to write a server side only write thing, it would just pull up that details page, I want to have a back button to get to the other ones, if something like that, or maybe would reload the whole page, and then just stuff that in the bottom Yep, to the experience of writing is almost almost unchanged, right, you get to fully leverage the server side thing it is. And that's that's a great point. It's very similar to a blank, right. And the advantages here are that you don't have that clunky user experience, you have a smaller payload, that tends not to matter that much people make a bigger, bigger deal out of that than I think is necessary. Yeah. But it really retains that simplicity. And on top of that, you also have all these tools that have been developed over the last 20 plus years of web development that are suddenly available to you, again, such as caching and SQL tuning on the back end, and so forth. All that institutional knowledge that we built up about how to create good fast web applications applies using the HTMX model. In a way that is not as obvious if your front end, you know, there's a whole separate style of development for developing JSON API's at this point, that just doesn't have a lot to do with that original model. And so we're relearning things. How do you you know, that's that model is really RPC remote procedure call, I think. And so that is just a different mindset than the hypermedia infrastructure that we're used to as web app developers. Yeah, for sure. So you talked about this complexity budget for and one of the things I like about this, is, I can have already built my application. And I could decide, you know what, it would be a lot better. If instead of doing a full refresh for this part, we could just add some interactivity to this. Right. Right. It feels to me like it's very easy to go to an existing web app and add this more dynamic nature to it. Yeah, I'm certain focus areas with HTML. Yep, exactly. You know, that's, again, I advocate for that, I think, a good MVP written in the web 1.0 style can validate your app, you can start getting feedback very quickly, without this really expensive from development terms, front end investment in your technology. And then once that works out, you can start seeing how users are using your app and improving it from there. And so it lets you delay committing your complexity budget deeper into the development process. I think that's a big advantage of these lighter weight front end frameworks. Alpine j. s is another one that I think lets you do that to an extent, you can just kind of sprinkle in when you want. And in fairness, I have heard people say that view is it can also be used in this way. So I don't want to, I don't want to say that's exclusive. But yeah, if I had to pick a rich front end framework view is certainly where I feel really happy. Because while it does have the COI stuff, and it does have a lot of that style, it also has the ability to just drop in JavaScript file for Vue js, and then indicate here's a sub tag or some subset of my page. And now that's the app. Make this page go right. There's that nice aspect. But yeah, I just feel like the you still get to do all the important stuff on the server here, which is pretty cool. Yeah, probably have on the livestream says I heard about HTTP max at Django con, you really liked the project. Fire emoji. Yeah, we got a lot of mentions Django con II, and I'm hoping we'll get a bunch. The US Django con as well. And, you know, I'm not again, I since I'm kind of I have to, again, admit a little bit of an outsider in the Python community. You know, I'm hopeful that I can make more contacts and, and really help HTML help Python developers stay in Python. So yeah, do this more do provide better user experience for users, but also stay within the Python world? It's, you know, obviously just it's growing gangbusters. So yeah, for sure. Well, if your screen is willing, yeah, actual screen on here, like actual monitor is willing. Let's look at some examples. So and I have to admit I'm flying blind. Right now. My screen is blank.

30:00 All right. So but hopefully you're I'll try to describe it. Yeah, I've got my phone up so I can follow along. Yeah, perfect. Sorry, Linux center now and it's all good. It's all good for just people listening. It's not that like the screen sharing is not really like the actual whole display is having a trouble. Yeah. But luckily, so going. Yeah, I know I switched to Linux two years ago and 99% of time. It works great. But of course, on this podcast, that's Yeah, well, it's fine. It's all good. Murphy. You wasted a maximum. Yeah, maximum pain. It's a straight x. Exactly. Let me just go through a couple here that I think Whitney, I pulled them up. One of them was this active search, because I feel like this is the type of thing that is like really easy, but also really calls out for some interesting JavaScript thing. So over here, you've got a page. You don't have the outer shell bands, right body. Yeah, you know, but whatever. It's all you don't need that. Right. You've got a you got a header that says, what we're going to do is we're going to search. Yep. And then you have an HTML indicator next to the title. Yeah, presumably, when something's happening over an AJAX request, that thing spins, and then when it stops, it goes away. Is that what that means? Yeah, that's. So the class HTML indicator is a class that's dynamically indicated, or excuse me dynamically added to your webpage. And it allows you to start with an opacity of zero. And then when a class is added to it, it'll it'll transition to an opacity of one. And so that's the best pattern that I found for having a request indicator. And one of the problems that you run into man all, you know, even normal web requests, browsers these days often don't do a very good job of notifying users, something's happening, right? And so yeah, this is particularly a problem when Ajax is in play. There's no indicator to say, hey, something's going on. And so he Amex provides infrastructure for doing that sort of thing for you. And you don't have to do anything, right. Yeah, having this thing exists, it knows, okay, if I'm doing a request, somehow, some way? Well, it's happening, you do have to call out the indicator that you want to show. Now, one thing I see, I should say what attributes they're typically inherited. So if you had one indicator that you wanted to show for all Ajax requests, for example, you can put the AJAX indicator attribute on the body of your website, and then all Ajax requests will then use that because it's as with CSS attributes are inherited. And most attributes are inherited, and HTMX. And so you can you can hoist attributes up to the DOM and have them apply to things fantastic. So you can avoid repeating yourself using that technique. Okay, cool. So we've got that little indicator there. And yeah, like he said, You got to indicate which indicator you want to use. But you don't have to trigger it. Exactly. Then you've got an input, like a text input, and it has a placeholder, it just says, Please begin typing to search has an H x dash post, which is slash search, presumably, it's posting the data of it as a form, right? Yeah, it's posting it. Yeah, exactly. It's posting it and including that by default. If it's on an input, it'll include that inputs value. Nice. And then it has a trigger. Yeah. To the trigger is key up, you have changed. Yeah, that's two things right? Like, so if I Command V it, or like somehow like drag text into it or key up. So that either event is what that saying can't change, it is a little different. So key up is the event that we're responding to. And then change says only issue requests if the input value has changed. Got it? Okay. So if I somehow hit so if you hit an arrow key, for example, yeah, yeah, exactly. Right arrow key values, the value doesn't change. And you don't want to issue a request in that case. Yeah, that makes sense. The other thing you have is delay 500 milliseconds, because

33:54 it depends on what the event is. Like. It maybe doesn't matter but like, mouse move. I get a lot of those events. Just wreck the server. Yeah, uselessly. You want to say okay, like to just flash flash flash the screen like just wait till they've slowed down typing, right, exactly. So this is called D bouncing an input, right? You don't want to on every, every event, you don't want to issue a request, that would be crazy and not a good user experience. And certainly, it would be very hard on your server. And so what you can do is you can add a delay modifier to a trigger, and say, delay, wait until you until a key up. So if a key up occurs, wait 500 milliseconds. And if another key app occurs, and that 500 milliseconds, don't issue the original request. So you effectively wait for the user to stop typing before you issue a request. And there's another another option which is throttle, where which might be more appropriate for mouse movements where you say only issue a request every you know, one every second or something according to mouse moves depends very much on what you're trying to accomplish with your UX.

35:00 Those are two different techniques for it.

35:03 This portion of talk Python to me is brought to you by your base. I'm excited to welcome your base as a new sponsor of talk Python, your base has a really cool product that will dramatically improve testing and ci of your Python applications. If you could benefit from having pi test, run your tests 100 times faster or more, you need to check them out. Here's how it works. Your base observes what tests interact with which part of your application code and the first time you run it, the speed is roughly the same as normal. But the next time you run pi test is where the magic is, your base knows which parts of your application code has changed. If the code under test hasn't changed, why test it again. So your base only runs the tests that have interacted with the part of the code that has, if you change just a couple of functions, you only need to run the few relevant tests and all the others can be safely skipped. This means skipping hundreds or even 1000s of tests, most of the time making your dev test workflow and your ci builds much, much faster. All you have to do is install your base and run pi test as usual. They'll take it from there, get your free trial by visiting talk python.fm slash your base, your base test acceleration works with the tools you're already using. So give them a pip install and see the difference right away. Get started at talk python.fm slash your base.

36:23 The final thing is to set the target, which is a CSS selector. Yeah, so hash search results, which is a the ID and you've got a table with a search results. And that's it. This is the besides the server side that does the actual search response. This is the entire implementation of your dynamic search page. Right? Yeah, that's right. So what is that that's it looks like four attributes, you have four attributes to implement dynamic search, or active search, I think is what Google terms when you go to Google and start Yeah, searching. And this is a great example of something I think many web apps would benefit from. And it can be achieved very quickly, with just a small amount of HTML on the front end, and a small refactoring of the code you probably already have on the back end. Yeah, I what I really like about this is if you've already implemented the search page to return a table of results, you've already written all this code. Yep. Everything is here. Like you've have a form. You submitted the form. You've got a response you've rendered the table, you probably show the form again. Yeah, although those things are present. You just can turn it to on key down. Key up, brother. Yeah, basically make it much nicer, without almost any effort. Yeah, exactly. And again, I think this is showing how HTML access taking HTML is hypermedia and pushing it forward. Right, this am I, you know, I think in an ideal world, this would just be part of HTML. It's just it's just taking this hypermedia concept and saying let's go further with it. Because HTML is kind of stalled as hypermedia and and they're doing much with it. So that's that's very much where HTML is coming from. And that's the underpinning of the philosophical underpinning of the library. Yeah. Super cool. All right. So one of the things I love about your examples, one, this whole library has a rich set of examples, we'll go through to others, I sure. And but one, the examples are there, they're clear, they're visual, and you have a live one, right? embedded in the page. I don't have to pull up like rebel, right? or whatever to like, go figure out well, how is this really gonna work? I can just go here. So if I want to see if there's a user named Michael, I just typed him I know, but there are, there's a username Molly with EMI in the domain, and there's Jessamine EMI and her name, and so on. Right. So that's amazing. Yeah, I've tried to focus on making things as visual as possible, because I what I run into is people don't believe what you can accomplish with this library. And so I really wanted to make a jump out and say, Hey, you know, yeah, there's stuff you can do in Vue. js, that would be tough to do in HTML, or react, you know, react or whatever you're using for your front end. But nonetheless, there's a lot of stuff that would benefit a lot of web apps that can be done using this simpler model. And if you're able to, you know, the question is, is it good enough, and I think it is good enough for probably 90 to 9090 plus percent of the websites that are out there. And it certainly would improve, you know, the vast majority of websites that are out there, just a little bit of HTML. Yeah. It reminds me of what jQuery did for the web. It doesn't remind me of jQuery, but jQuery for I know, probably a lot of people view jQuery negatively as like, this sort of spaghetti code type of story these days. But when it came out, it was like, Oh, my gosh, I can sprinkle in a few things. And this becomes really amazing. Yeah, right. I get that feeling as well. It's like easy to add to something that exists. Yeah, that's right. And a, you know, this whole thing and we came I came out of the jQuery world just like you did, and so that

40:00 Thank you, you're right that there's, with jQuery, there's, there was always an incrementalist approach. You could add things incrementally. You didn't have to buy into huge bit of infrastructure, it turned into spaghetti code in the long run. I agree with those criticisms of jQuery. And so hopefully with with HTML, because of the way it's built, you're not going to run into those same issues. I think there's some conceptually there reasons why that is. So with HTMX, you tend to put the 10 put the actions on the thing that does the action. Whereas in jQuery, you would move things to a separate place, it would be over I like dollar document ready, right, there would be living somewhere else. And that was kind of sold under this idea of separation of concerns, which is a design principle for software, I've been trying to push this idea of locality of behavior, which is intention was separation of concerns. And the idea of locality of behavior is that you want to put the things that have code unit does in the code unit. So a button should say what it does, it should say I issue a post to this URL. And then I do this with the response. And that's exactly what he does. And again, that's in contrast with jQuery, where you hook up a click handler in some other place, and you would just be staring at this button wondering why it was doing what it was doing. And so locality of behavior is what I'm trying to use as terminology to describe this idea of putting stuff in line in the HTML to explain what this thing does. And there are other tools that are doing this as well that are getting popular. The two big ones are Alpine j. s, and tailwind CSS, both of those, you put your stuff in the HTML. And I think those two products pair very well with HTML. And that you can kind of do everything right there in your HTML can be a little overwhelming at first, if you're not used to that style of programming, but it has a lot of benefits associated with it. Yeah, I've never I haven't even heard about 5g. So I'm gonna definitely have to check that out. But taylan, I've heard of Intel, it's pretty interesting as well. It's like sort of a replacement for bootstrap. Yeah, but not in the same sort of abstract style. It's more like, say, like, you describe it as the way you want it to be like, I want the font to be medium. Yeah, rather than say, this is the the main text and writing text is formatted medium size. Right? You really Exactly. You inline things. So when you're looking at a button, it's you can see why it has rounded, you know, rounded curves or why it has the padding that has and so forth. I think people have started to recognize the separation of concerns, while certainly a good thing in some ways. And you know, a valid design principle has some disadvantages. And the big one that I see is this sort of spooky action at a distance where someone can change a file somewhere else. And suddenly your button doesn't work anymore, or whatever. Yeah, yeah, I think well, the separation in this scenario is Ajax stache posts, is slash search like, This describes in the exactly in the web sense of what a URL means to describe this is what I want this to be. But it doesn't describe the implementation, right. that lives in the server. Yeah, I think there's an interesting philosophy there as well. Yeah. Yeah. There is. And it's it's really that rest, the restful, uniform interface idea from the early web. It's it's, you know, I'll keep saying this, but we're, we're trying to take HTML and drive it forward as a hypertext give you more power as a hypertext developer. Yeah. Super cool. All right. Let's take a few things from the live audience. So we got Nick says, I love that this supplement server side frameworks like Django, rather than trying to replace parts of them. Yeah, yeah, absolutely. For sure. Alec has an interesting fix for your monitor. Okay, do apt install new monitor. Yeah, since you're on Linux, I can get a terminal to show I've got my laptop monitor over here, I'm literally staring at a blank at a black screen, flickers every once in a while. So I get a

43:50 quick view, I'm not gonna I'm not touching anything if it's recording.

43:55 And then Nick also says, Now we need an H x dash Python tag to run arbitrary Python in the browser. Just kidding, don't do that. With HTMX, I think that you've removed a lot of the pressure to have Python in the browser, but HTMX. And so I was hoping I was opted to you know, tell jokes aside, I was optimistic when webassembly was first proposed that it would break the dominance of JavaScript in the browser. But my experience thus far, and I have to admit I haven't looked at it in a while is that webassembly has been so low level that it's probably not going to help. Maybe that was I can't tell if that was intentional or not. But there's there Yeah, in my experience, there wasn't a good interop layer between the DOM and webassembly. Yes. And so okay.

44:41 That's majority scripting I want to do is Dom related. So it's all about the DOM. So let me give you my web assembly sidebar here and I'd love to hear your thoughts. I hear two problems with web assembly. One is this Dom story right like this could be fixed right webassembly could be evolved to have like a

45:00 Like, and here's the DOM API, right? In a real straightforward way. I know there's a lot of separation and whatnot. But I cannot believe that it couldn't be figured out Yeah, to the problem, I hear about this as well. You can have Python in the browser. And things like pi iodized, have actually done this to like compile the C into webassembly, those c Python runtime and scientific libraries into a web assembly thing. And then you can download it. And you can do limited stuff. It's limited because of the limitations of the DOM, but you can still run Python in your browser, it just so happens, it's a 10 meg download, right? Here's what I would love to see, I would love to see the major language providers, C++, Python dotnet, you just go down the list Java, rails, provide a web assembly thing against some API. And every major browser just builds that in. So my Firefox comes with Python, Ruby, Java, and dotnet. These are all like 10 or 20 meg binaries, like right the world to be like, then that whole problem of what would you download it? What if you read download whatever thought it like just they ship JavaScript? Yeah, if all they had to do is include a host of other features as webassembly, like the problem would be solved. But there's just a little too much friction along the way to make that happen, I think, yeah, it really the core problem there, I think is the core libraries that you know, that come with all these programming languages. It's one reason why rust actually does pretty well with webassembly. There, it just doesn't come with very much. Yeah, and that's a reasonable solution. If I was super passionate about Python, I might look at just writing an interpreted and it sounds like there might already be an interpreted version of Python in the browser. That's so hyper script, which is a scripting language that I'm working on is kind of a passion project that's loosely associated with HTML x is a scripting language, and it works in the browser, and it's just interpreted, and JavaScript is so fast in the browser now that you can actually get away with it. So as long as your Python wasn't, you know, trying to do scientific computing, you're just trying to do basic web scripting, you know, adding classes, to DOM elements, and so forth. You want to do Vue JS stuff, like stuff, but you don't want to write, we want to create Python classes, and then like hook Python functions. Yeah, right. Yes. That actually, you know, in my opinion, if I were going to take a look at that problem, I'd look at doing an interpreted language. Yeah. Interesting. There is skull, which is pretty interesting. And this runs Python in the browser. So like, the example on the home page is like a little turtle on an HTML canvas. Okay, this is all client side. But it's,

47:35 it's like close. It's not the same, right? So that's, I mean, that's the same for all the languages here. Alright, let's go back to this example here. Because I think there's still a lot of really good things we haven't even touched on. And we're only on what, four tags? Yeah.

47:49 So we talked about this little example here. And as I'm typing, people can see the little searching, David go and type thing and see like in the h3 thing and see the little searching bit. But all of these things I think are neat. But you kind of wonder, well, what's happening, like what's going on? Really like, especially if this is a server side thing? What's the HTML? What's the HTTP traffic with the server, and you added this little like, built in the buggery toolbar thing. It's not a debugger toolbar. It's a debugger, footer.

48:18 footer here. And as you interact with the examples, on every one of the examples, you can see, well, what is the initial traffic? What is sent over and you click on it, it has a history of all the requests that are being made, what was posted over and then what was returned from the server. And it's super clear. Yeah. Go to the last one. I could see exactly this is what's on this, you know, up at the top, if you look at the bottom, oh, there's the TR TVs that make that happen? Yeah, yeah. Again, I really wanted to focus on the examples to drive home just how easy it was and then also, what you could accomplish with the library. Yeah. Right. Cool. All right. Let's touch on a couple other examples. I pulled them up cuz I wanted to highlight them. Click to edit. Okay, let's go look at click to edit. That's a pretty good one. Yeah. No, again, I apologize. I'm on my phone. Yeah, no worries. To hear what you've got is you've got a form. And it's not form like it's like, just static text with divs. And spans do not so you've got first name is Joe. Last name is blow emails such and such. And if you hit click to edit, those things all become all the values become in text input. Yeah, I could make Joey Joe and hit submit. And in place, it becomes Joey. That's right, that effect. This is a really cool example. Right? Like instead of having forms everywhere, you can just have HTML and like a grid. And you could say, an example I would imagine maybe is a grid of responses and you want to edit one of the lines at the grid. Yep, I want to edit this entry and then boom, those all become drop down, selects, or they become date, time pickers or whatever the heck you want to make them become and then they go back

50:00 Right. Yeah, like an editable row? console? Yes, exactly. Yep. Yeah, yeah, super easy example of what's happening. If you click Edit, it returns the form HTML text. When you submit it, it returns the div span version of it. Yeah. Yeah, exactly. So you know, you're probably not going to the details of all the attributes that make this happen. But there's an Ajax get to get the form, that form gets swapped in to that little element, you don't have a big page refresh, you know, go to some other URL. And then you can click Save, and it just does a put put being the traditional way to update something or the right standard, we know the URL and you want to make a change to it, instead of a post you do a book because that's restful. Yeah, yeah, exactly. And so you use an Ajax put, and then when that put succeeds, you would render just the row again. And if that put failed for validation reasons, for example, you would just render the form with the error messages in it. And this is very similar to the way the new standard, you know, web app development in the web 1.0 model, but you managed to bring down your target to just this little form. And so you don't have to do redirects, and stuff like this anymore. Interesting. I hadn't really thought about the errors. Yeah, I hadn't thought about the error response. But for example, you could say return the form. But in your server side template, you could say, well, this one has an error. So what we're going to do is put an error message at the top, and we're going to put an error has error attribute on to the form element, which will make it glow red or something like that. Exactly. And if you wanted, so one common thing to do is to you have your error messages elsewhere, right? They're not down in that element. I like inline error messages myself, but a lot of people like to show errors at the top. And so HTML, HTML, excuse me has tools to do that, you can use what's called an out of band response. So you can have content that is streamed down that specifies This is out of band content, and it needs to go somewhere else in the DOM typically uses an ID. So you could use that to put an error message, you know, up on the header if you wanted to do that. Yeah, another common way to do this one that I like, if you're gonna have something like that is to have some sort of growl library, where it kind of like a toast notification pop up type of thing, exactly, something like that. And so for that, where you might use is the HTML has some fairly well developed response headers, and one of them is Ajax trigger. And you can use that to trigger an event with an argument. The argument in this case would be the error message to show and then you can write a little bit of code on the front end to listen for that custom event that you're triggering. And then show toast message saying, hey, okay, say no, that's cool. So there's, there's a bunch of different tools in there, depending on what you're trying to accomplish. Yeah. Alright, livestream apart says, Hey, from San Francisco. Hey, welcome to livestream. Nick Ahmed. I'm curious how this compares to two way binding with something like view, is the DOM reactive with an underlying data model so that they stay in sync? But the answer is no. So HTML, adopts the original model of the web, this restful model were hybrid, you may have heard at some point in your programming career, the acronym hate EOS, it's a bad acronym, particularly these days. But the acronym stands for hypermedia or hypertext as the engine of application state. And so there is no backing model on the client side rather, the model, the source of truth is the back end and the front end just sits there and reacts to user inputs. And whenever user input occurs, that needs to trigger a state change request is issued to the server. And then the updated state of that resource is returned via HTML. Now it kind of flows through this interaction. That's right, right. So let me give you an example. So in this click to edit thing, when I click edit on the button, it knows it's on slash contacts, contact slash one and I click the Edit what comes back as a form as h x dash put with slash contact slash one as the action right? So then when I submitted it flows that it was row one or item one I was editing on over, and then when it comes back, right, the response is, well, now it has the Edit slash one, a contact slash, one slash edit in that URL. So it kind of flows the Yeah, this is actually super hideous. Like there's many things that you find in these API's and people adopting rest, like oh, we're gonna take all the rest principles except for this hypermedia as application state that that we don't really care about. But this the more you talk about, it really is. Yeah, well, it is. It's because people this is a long conversation, but holy smokes. I've been arguing with people on the internet about this for a while. I don't think rest makes any sense when you talk about JSON, because it does to some extent, HTTP verbs Make sense? Yeah, they knew

54:47 Other than that, right? It's there's a lot more to this whole rest, maybe the representation maybe the URL layout in some cases makes sense. But when fielding wrote is that Roy fielding is where the term write his dissertation at university.

55:00 Have you ever California, Irvine is where all this terminology comes out of. And what he wrote. He was describing the web, he was describing HTML he was describing, like the way web 1.0 worked with that. And a big focus on that was this idea of stateless HTML and hypertext as the engine of application state, that being one of the crux issues within the section that's about what's called the uniform interface. We don't want you to get too much into the details of that right now. I'd be happy to talk about that maybe offline later, you know, maybe different contexts. But when you're in JSON, no, no, that's that there's hypertext isn't the engine of application state, there's a client side model, that is your application state, and now you're in a stateful. world. And you're in some ways, much closer to what thick apps used to look like back in the 90s, then you are to the original web model. It's a different model. And there are advantages and disadvantages to it. I like it a lot. I think there's a lot of power to it. And so, you know, to make a long story short, no, there's no reactive aspect here. The DOM is the source of truth, the server is really the source of truth. But the DOM, as far as the user is aware is the source of truth. And it's stateless, just like the original web model, right? The view model is super nice. I mean, you create these little JavaScript classes, and they just kind of build up their data. And it's really cool. And it binds with the DOM. But like, what if someone refreshes the page? Right? Or something like that? Right? Yeah. Oh, my gosh, it's a god. Oh, no. Right. So yeah, there can be drawbacks as well. reactivity is, is I you know, I sometimes I can be a little too hard, I think on and just the nature of the internet, but, you know, reactivity, this notion of reactive to a binding that was that's new, that's relatively new, there were UI toolkits that did something did similar stuff, but not as deeply as the current set do. And so there's something new there. And it is useful in a lot of in a lot of ways. But for a lot of apps, it's overkill. And there are disadvantages that are associated with sinking, the sinking the two models is difficult. And if you let your Dom be the source of truth, the server be the source of truth and your Dom be a stateless representation of it, then there's a huge number of advantages that come along with that. Yeah, it's for sure. Like, if you have the same page open on multiple tabs, for example, like the database is still in sync on the server. Yeah. Alright. Let's look at one more example journal a little bit to wrap up. I'm a little hesitant to show this to people because I kind of hate this. But it's also a very, there's an infinite scroll, infinite scroll, and can also be implemented as click to load. So yeah, so ambivalent towards this pattern, but it's so common, what I don't like about it is it's super hard to share it with somebody that say, okay, go to this part of the search result like, Well, where is it like, well keep scrolling down? No, like, hold on, hold down the page, you know what I mean? It's just like, hard to share, or to get back to you. Anyway, there's a lot, I don't know. But, but infinite scroll is neat. And so here, you've got a table row that says, h x dash get slash contexts slash page equals to our question mark, page equals two is a query string, and then h x trigger is revealed. It's like as you scroll down when it becomes revealed within the DOM, run this? Yep. And then swap after end. Yeah, I guess what's that mean after. And so what that means is, so you put this code on the last row, the last result of your page of results. And so what that's going to do is it's going to issue a request to the server. And then when it gets that content back, it's going to append it after the end of this element, the element This is on this table row. And so that new content, which is presumably going to be a new series of rows is going to get appended after the the last row. And so that's how you get that next set of rows. And then on the last row of that there would be, again, this when I'm revealed, the response will come back with an H x get on it, right? Yeah, so it'll come back with the H x on and they'll just keep going down the line until you finally get to a point where you don't have any more and so you don't bother encoding one of these revealed triggers. And that would just be the end of it. So I agree with you on I as as, as you are, I am ambivalent towards this, I tend to prefer paging for exactly the reasons you talked about. And I should note that there is a an attribute called Ajax push you as an Ajax Ajax push URL, excuse me, that will push the URL of the request up into the browser's history, like enter the URL. Okay. And and add it to the history. So you can use the back button and all that and it does all kind of automatically for you is it allowed deep linking? Yeah, yeah. Now, that being said, if that URL, you know, someone can copy and paste into a new tab, for example. And so you have to handle both the HTML request to that URL, as well as the normal non HTML request to that URL, and those might be very useful.

01:00:00 Yeah, but if you did that, then it would support potentially deep linking into Yep, this sort of experience. Exactly. And so and then I just finished that thought. There's a header that comes in when it's an HTML request. ajax requests true. And so you can check that header and say, Okay, this wasn't an HTC. This wasn't an HTML request. So I need to render the entire surrounding for this thing, or Oh, it was an HTML request. So I just need to render this partial. And that's a very common pattern to have a little if statement on a URL that needs to service both of these to check the header value. That's pretty cool. Yeah. Nice. Okay. So let's see. Let me I'm going to do it. I'm going to scroll here. Yeah, there we go. There we go see the indicator and downcast some more? Yeah, fantastic. Yeah, there we go. And you can obviously, you know, pull up the little debug butter. Yep. And see those behaviors here, which is great. Yeah. And again, back in agnostic, so just, this could just be normal Python on the back end, nothing fancy. Yeah. Django flask or rails, take your pick. Yep. Whatever you I You mean, it could. I've been bagging on node because I'm not a huge fan of it as a platform that I want to work on. But it could also be node, right? If people are there doing that, it could be hypertexts or whatever, on whatever you'd like. How How? Alright, so let me wrap this up with a little bit of concreteness here. Sure. So tell us really quickly about there was intercooler or now with ATMs just real quickly, what is the story with this transition? Yeah, so I created intercooler, which is the predecessor to h h. m. x is basically intercooler 2.0. And then I created intercooler back in 2013, I believe. And it was, again, I came out of the jQuery world. And so it started off basically as a jQuery plugin. And it grew to the point that I felt like Okay, I'm gonna create a separate library for this. And last year when COVID Hit, hit always had in the back of my mind that I didn't like the jQuery dependency and intercooler. And so I just were, you know, everyone was kind of at home and in order to avoid losing my mind, I said, Well, I wonder if I wonder if I could pull the intercooler or excuse me, the the jQuery dependency out intercooler. And turned out Java scripts come a long way. And I was able to do it pretty quickly. And so, as I was doing that, one other thing that I thought about, I really, you know, I learned a lot as I built intercooler gas, and I developed a much firmer sort of theoretical basis for it is like, okay, we're really we're trying to drive HTML forward. And one thing that had always annoyed me about intercooler j. s was that it was compared with, you know, angular was the big one when it was first out, but then eventually react and then and Vue js, and because it had that j s in the name, and so there was people would treat it as a JavaScript library, rather than thinking of it in these more Hyper Text oriented terms. And I was astounded to find out that HTML org was available in 2020. And, but it was, and so I grabbed it, and I was like, this is a great day, I originally called it something else, but came to my senses and said, you know, DMX really captures this. We're trying to extend HTML. So HTML is short, it it's a veil was a domain name, and it captures what you're after. Yeah, yeah. So very well. So I'm very happy with it around our conversation with a concrete example here, for this. So people might wonder like, Where is this being used out in the world? Right. I'm, obviously, I think it makes a ton of sense, especially in these little like back in internal corporate apps that don't get a ton of love, but could really benefit from this. But there's also some popular ones, like real Python comm out there is one of the most popular ones. Python websites out there, run by my good friend, Dan better. Cool. I was just talking to Dan saying, I'm going to talk to you, Carson. He's like, Oh, I love this. I actually use intercooler on the site. Okay, cool. So if you go over to the quizzes section, you will pull up one of these quizzes, and hit start these sort of like test your knowledge things. So here it says like, for example, in Python three, the maximum value for an integer is to the 63rd minus one, Oh, that's so false. And you click on it, like reveals the check answer of the thing. And then you go to the next question, or you can expand the explanation. How would you express a five, the base 16 integer? I have no idea. All right. Now, the point, not the point. But this thing, this experience of going through these these steps with the progress bar, because there's a cool progress bar in HTML, and all that stuff. Like, this is a cool use case of that type of situation. That's really nice and easy to do. Yeah. And there's a huge amount of code that's written out there, even in apps that are more dramatic and need need this reactive infrastructure and places, they're probably places within the app where that's not necessary. So you know, one common thing I'll say is, okay, maybe it's g max doesn't apply to your entire app. Maybe you're doing concurrent editing of rich, you know, using Canvas or something crazy like that. Alright, fine, but you probably have a settings page for that app. And that settings page is going to be fairly standard forms. And that's something

01:05:00 where maybe, rather than using whatever reactive component you're using to manage the really complicated state, you can tear all that out, save that complexity budget and just use HTML, just to sync with the server for your for your settings page, you know, but even you know, how many react? How many crazy apps do we use day to day, for the most part I use, you know, I go and I read blog posts, maybe I check my email, and so forth. And a lot of those apps can be improved pretty dramatically by just using some basic HTML patterns without adding huge amount of complexity. Yeah, I totally agree. Totally agree. Right, Carson, I think we're pretty much out of time. Okay, but

01:05:39 but let me always ask two questions at the end of the shows are two questions. So I hate with them before we close it out. If you're going to work on HTML, or do some other programming, what editor Do you use these days? I use WebStorm.

01:05:53 Right on Yeah, I'm JetBrains. I'm a JetBrains. guy. Yeah, same here. I'm a big fan of pi charm. And it basically the web side of its functionalities. Just WebStorm. Yeah, well, yeah. It's super nice. I encourage people to pay for their tools.

01:06:07 If you're a programmer, spend some money. I mean, they they have stuff for free, but they they do tremendous work. I know that what's the Microsoft editor has become very popular vs. Code. Yeah, but I don't know. It is what it is, Hey, you know, it's a holy war situation. So don't take me too seriously on this. But I, if you're,

01:06:26 if you're on this no random guy on the internet, to at least take a look at their JetBrains stuff. I I like your idea of you know, support and encourage the things that you want to see more of right. Oh, for sure. And then normally ask for like a Python library that people are really interested in. But in this this case, let's How about a JavaScript library or CSS library or something like that, that you think people should really check out? Like, something on NPM? or? Yeah, lander? Yeah. Like, I think, looking at tailwinds. I'm looking at Alpine j. s, if I may, we didn't really get a chance to talk about it. But hyper script is a scripting language. Oh, yeah, kind of a natural language scripting language for the front end, very front end focus. That's kind of got some interesting aspects to it. But I think, you know, rather than recommending one particular library, I'd say just that this idea of locality of behavior, looking for libraries, where you're putting the code in the code unit, rather than having a bunch of different places. And so tailwinds and Alpine Jasser to jump out at me, in addition to HTML x is being worth taking a look at. I know there's a lot of Django people, they're using that combination and are very passionate about it. Yeah, fantastic. Yeah, I know, some people certainly passionate about as well. Nick isolation says, view single file components violate the separation concerns and lead towards this locality that you're talking about, as well. Yeah, it's a great improvement. So yeah, I think front end components are kind of moved that way as well. That's exactly right. Now, you know, do I, that's, that comes with a lot of other stuff that I don't think is necessary for a lot of web apps. But there's just this move, I think. And so I'm trying to use again, locality behavior, and I've got an essay up on html.org slash talk, you can look, there's a locality of behavior essay where I'm trying to push that term and get people to adopt it when they're trying to explain to people why, Hey, why are you in lining all this code? Because, you know, they're like, Oh, this is the worst. I know, you can't, it's like, well, you can and most people and people are actually having experiencing productivity and maintenance increase increases when they do it. So I like your idea of the spooky action that just right? mechanics? Yeah. Yep. Cool. All right. phonecall action, people are psyched about a CMS. Maybe they're psyched about not doing too much JavaScript on the front end. What do you tell them? Oh, well, check out htmx.org. Please start the GitHub repository that is my primary source of compensation for leveraged MX at this point. And, you know, we have a Discord server that you can jump on as well. If you have questions, Twitter's getting more active. If you follow HTMX, there's HTML, underscore org, on Twitter, which I run, and it's getting more and more active. But the discord is friendly at this point. And so I encourage people who are interested in this to jump on there and ask questions. There's a lot of people that understand the library very well and know a lot of different backends because a CMS is backend agnostic, kind of back end needs its own sort of expert to help out with it. And so, you know, hopefully in a few years, we've built up a good set of example, libraries, but at this point, if that's not available, then the discord is probably the best place to check out. Okay, fantastic. Well, thanks again for being here. And thanks for creating this lot of nice comments in the live stream as well saying thanks for creating it. So yeah, I think you're onto something here. And I'm happy to share with people hopefully, it can superpower some of these things, oh, flask, etc apps without replacing them? Yeah, I really and I appreciate it again, you know, taking something that's obviously outside the normal Python world and give him a chance to talk to people about it, because I

01:10:00 Do you think it will help people stay in Python longer before they they feel like they have to abandon it for JavaScript? Yeah, I can remove some JavaScript guilt. Yep, exactly. Not doing the front end front. It's okay. Awesome. Okay. You don't have to use JavaScript for everything. That's true. All right. Thanks again. See you later. Have a good one. Bye. Bye. This has been another episode of talk Python. To me. Our guest on this episode was Carson from Big Sky software. And it's been brought to you by century, your bass, and assembly AI. Take some stress out of your life get notified immediately about errors in your web applications with century. Just visit talk python.fm slash century and get started for free and use the promo code python 2021. When you sign up, your base test acceleration will dramatically improve dev test workflows and ci builds of your Python applications. If you could benefit from having pi tests, run your tests 100 times faster or more you need to check them out. Get started at talk python.fm slash your base.

01:11:02 transcripts for this and all of our episodes are brought to you by assembly AI Do you need a great automatic speech to text API get human level accuracy and just a few lines of code visit talk python.fm slash assembly AI. one level up your Python we have one of the largest catalogs of Python video courses over at talk Python. Our content ranges from true beginners to deeply advanced topics like memory and async. And best of all, there's not a subscription insight. Check it out for yourself at training talk python.fm Be sure to subscribe to the show, open your favorite podcast app and search for Python. We should be right at the top. You can also find the iTunes feed at slash iTunes, the Google Play feed at slash play and the direct RSS feed at slash RSS on talk python.fm. We're live streaming most of our recordings these days. If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at talk python.fm slash YouTube. This is your host Michael Kennedy. Thanks so much for listening. I really appreciate it. Now get out there and write some Python code