Are you considering or struggling with replacing much of the interactivity of your Django app with
front-end JavaScript? After all, your users do expect an interactive and modern app, right?
Before you make a rash decision, you owe it to yourself to check out HTMX. It goes really well
with Django. We have Christopher Trudeau here to run us through the whole awesome list of HTMX and
Python things and tell us about his new HTMX and Django course. This is Talk Python to Me,
episode 437, recorded October 5th, 2023. Welcome to Talk Python to Me, a weekly podcast on Python.
This is your host, Michael Kennedy. Follow me on Mastodon, where I'm @mkennedy,
and follow the podcast using @talkpython, both on fosstodon.org. Keep up with the show and listen
to over seven years of past episodes at talkpython.fm. We've started streaming most of our episodes live
on YouTube. Subscribe to our YouTube channel over at talkpython.fm/youtube to get notified about
upcoming shows and be part of that episode. This episode is brought to you by IRL,
an original podcast from Mozilla. When it comes to artificial intelligence, AI, what's good for
trillion dollar companies isn't necessarily good for people. That's the theme of season seven of IRL,
Mozilla's multi-award winning podcast hosted by Bridget Todd. Season seven is all about putting
people over profit in AI. Check them out and listen to an episode at talkpython.fm/IRL.
And it's brought to you by Sentry. They have a special live event, like a mini online conference,
where you can connect with the team and take a deep dive into different products and services
every day for a week. Join them for launch week, new product releases, exclusive demos,
and discussions with experts from their community on the latest with Sentry. You'll see how Sentry's
latest product updates can make your work life easier. Visit talkpython.fm slash
sentry-launch-week to register for free. Hey, Christopher, welcome to Talk Byther Me.
Ah, it's been a little over a year. I just looked it up. It's nice to be back.
Yes, the annual appearance.
Sure. You want to make it annual? I can go for three or four, and that's a little like we'll see into the future.
We both spend a decent amount of time behind microphones these days, don't we?
I seem to. Yes, yes. It does seem to be the way it is.
It's a funny world, right?
I was just looking it up because I figured, you know, your standard interview question,
so what have you been doing? It's like, well, I've put out over a dozen courses since the last time I was on.
So, yes, as you said, it's a lot of time behind the mic, so not so much the live mic.
So if I'm doing a little nervous, say the word so too many times, it makes me more human than in my courses, I guess.
That's right. The magic of editing.
That's right.
That was a concise and quick response.
Well, it's great to have you back on the show and looking forward to talking about one of my very, very favorite topics,
HTMX at this time in the context of Django.
Yeah, I was actually just the other day listening to your episode.
What is it?
428 when you had Vincent and Gibson on and you delve into HTMX a little bit.
They seem to be big fans.
It's one of the sort of semi-gags in the course that we're going to talk about a little bit is I just kept telling people that I'm in love.
Like it really is the answer.
I'd love to see it become part of the HTML standard.
It's a much, much happier way of coding.
Makes me feel like the old days, things are much simpler with it.
Yeah, I totally agree.
And Carson Gross, the creator of it, does often say it's kind of like HTML just kind of stopped growing when JavaScript came along.
And this is what it should have been.
But well, if I've got to do it, I'll take one for the team and build HTMX for everyone.
But you're right.
It really should just be built in more or less, shouldn't it?
Yeah.
Every once in a while you come across something where you sort of look at it and you're like, wait, this is the right way.
Crap.
I've been doing it wrong for almost 30 years.
This is the right way.
So why didn't anyone tell me?
That's right.
Yeah.
It's a little bit of a, oh, wait, if I'd had this so long ago, it would have made this and this and this so much easier.
So, yeah, it's definitely a part, definitely some forward progress.
It is.
Well, you mentioned when I had the Django chat guys on the show not too long ago, that was when we talked about Django.
Surprise, surprise.
But mostly, you know, we started out with the focus of Django turning 18.
And, you know, maybe we can just start with Django itself before we dive into HTMX, because I think Django more than the other frameworks has its opinions and its styles and its way of doing things.
And so integrating with HTMX, I think, is a pretty interesting thing that, you know, other people and you've done with, as we'll talk about through this course that I'm going to mention in a moment.
But, yeah, just, you know, what are your thoughts on Django over the years and Django being, you know, old enough to vote now?
Well, you know, there's this line I came across that I've since stolen.
Somebody said, it's not a dinosaur, it's a shark.
And I love that concept, right?
It's still growing and it's still changing.
It's still very actively developed.
But, you know, I've been playing with Django 5 recently and there's nothing in there that broke any of my four code.
And if you're going to be coding with the same library over and over again, that's actually desirable, right?
You want the new features, but you don't want to have to go and redo something every single time.
You know, I don't want to knock view.
It's got some strengths.
We'll talk a little bit about that as well when we start getting into some of the HTMX stuff.
But by example, because I don't use it very frequently, it seems every time I go back, it's like, oh, they've changed how this happens and I have to rethink this, right?
And I don't run into that with Django.
It's become so large that it also addresses different problems for different people.
I love that they're adding all this asynchronous stuff.
I will probably never use it.
And I think it's great that it's out there because it solves a problem for the folks who are trying to use that kind of thing and they don't have to go off to another library.
But for those of us who don't use it, it's like, nope, that's fine.
Whatever.
It doesn't break anything.
They don't have to start from scratch.
And they keep chugging along.
And, you know, both Will and Carlton sort of commented about the community and they're right.
It's there.
You know, Django, the project site that has all of the add-ons, there's like over 4,000 different apps and libraries that you can use.
So it's not just the framework.
It's not just the core.
It's the ecosystem.
And it makes a big difference.
It makes your life a lot easier that way.
A lot of choice.
More than almost any other individual library in Python.
Django's got a massive community behind it, doesn't it?
Yeah.
Well, you know, there aren't other conferences, right?
There's PyCon and there's DjangoCon.
And everything else is go to a PyCon and talk about it in a room.
And then there's an entire conference for it.
And two of them, right?
There's Europe and the US, right?
So it's a big deal.
It is.
And it's been a while since I've been to a requests con, although I do like requests.
Yeah.
Also, you mentioned the async stuff and some of these new things.
Python and Django, it's just amazing how stable they are in the sense of two to three aside, right?
Like it's very, very, very rare.
Not never, but very rare that you have to go and fix code because a new version of Python came out.
Yeah.
It's the same thing, right?
So 3.12 just launched, been playing with the RCs for a little bit, just, you know, swap out the virtual env and my code just keeps chucking along, right?
Like there's no, I haven't run into a problem even with beta versions in years, right?
So that, and that stability is, it's important, right?
It's like you kind of said, we're still, still hurting a little bit from the scars from two to three.
So I think everybody's being cautious in the right way.
Yeah.
I think that's probably true.
Also some of those new features that maybe you won't use or I won't use or whatever.
I think they're still really important to have because I don't really hear it so much anymore, actually, but there used to be a lot of talk of like, oh, we're switching to go because of async.
We need async.
So we're switching to go and because we need, you know, and even if you individually don't use it, having those features in Django or in Python, they're really important because they kind of knock that conversation.
out, right?
They're like, oh, we had all these people love Python, but they had this one special case.
So they were forced to leave like, well, now they're not necessarily forced to leave because of that.
And I think, you know, that's positive for everyone, even if many people don't use it directly.
Yeah.
Well, for sure.
Right.
Like if, you know, if async is what was stopping you from using Django and switching to FastAPI, then, you know, now you don't necessarily have to.
Right.
And again, I'm a fan of FastAPI.
A lot of it comes down to what you're building.
And, you know, I often get the question also, well, why would I pick Django versus this versus that?
And I'm like, well, if you're, if you're building an actual project where you need web pages as well as the API, as well as this and as well as that.
Well, you can do that with FastAPI plus SQLAlchemy plus something else, but, you know, it's all self-contained in Django.
And so things tend to work better.
So those edge cases that you talk about that might cause you to go off to another library, even if they don't do it quite as well, it might just having it enough so that you don't leave is makes the difference for sure.
It does.
There's a whole show comparing Django to FastAPI right there, isn't there?
Probably.
And Django or Django Ninja.
Probably several.
Yes.
Probably, but not this show, not this one.
All right.
What's next?
Let's talk about your book next.
Sure.
So one of the things you've been up to in addition to courses is writing books, Django in action.
Almost released.
Is that right?
What's the status?
So speak in singular.
It's this is my first.
So be kind.
It's in early release.
So you're able to purchase the first.
I think we're up to seven chapters.
And essentially, if you buy the electronic edition, then you get a chapter.
About a chapter or two a month.
It kind of comes out piecemeal.
It's called Django in action.
It's on Django.
It's divided into three parts.
So part one primarily is sort of that intro stuff.
How to get projects going.
What a view is routes and all that kind of good thing.
Part two is around the tools that are built into Django.
So how to use the admin, you know, slightly more advanced topics.
And I'm currently in the process of writing part three.
And the intent of part three is how to extend your use to the third party libraries.
You know, you just mentioned Django Ninja.
So I'm hoping to have a chapter both on Ninja and a chapter on HTMX.
And both of these will guide people to, okay, great.
So now you've got Django, but you want to build X.
I need an API.
Well, how do I do that?
Well, there's Ninja and there's the DRF.
I want to have a little more functionality, a little more dynamicism.
Oh, okay.
Well, a good answer to that now is HTMX.
So this is how you wrap those things together.
So the intent is to try and cover that.
I'm sort of hoping that there's enough there in part three that folks who have done a bit of Django before are still interested in it and can pick some new things up as you go along.
And, you know, with the release of Django 5, I've been busy going back in and, you know, adding, hey, and this is what they added in 5 and this is what changes.
So trying to cover all of that.
Full publication will probably be early next year.
But if you're on the electronic copy, you can start now and go from there.
So, yeah, it's available.
And I guess while I'm on the topic, I've been getting a lot of great feedback and we've got a forum for folks who've read the book.
And it makes a big difference to me because, you know, somebody says, oh, hey, I did this and it didn't quite work.
And I'm like, oh, okay, it shouldn't.
But let's add a couple sentences about that.
So it's kind of great to have this dynamic process going and prove it as I go along, which is so.
So those folks who have been participating in the early release, I very much appreciate that feedback.
It's cool to be able to build it out in public, not just drop 300 pages of printed something.
Well, you know, it's something I'm sure you, you know, you encounter with the courses all the time, right?
Like I've got, we'll call it a particular sense of humor, shall we?
And when, you know, I put something in a course that I find funny, it's not like you're, there's no audience, right?
Like you have no idea whether or not the joke lands.
It's sort of the same thing.
Like you get, you never get any of that kind of feedback with a course and the book can very much be the same way.
So, yeah, that early release in the forum helps a little bit.
So, and so, yeah, nobody's, nobody's going to tell me whether or not I'm funny,
but they can at least catch whether or not the code works, which is useful.
Exactly.
And speaking of projects you've been working on, one of the things that kind of inspired me to have you on the show
to just dive into Django and HTMLX is you actually did a talk Python course, HTMLX and Django,
modern Python web apps, hold the JavaScript, which is awesome.
That's a really fun, just under two hours course that really shows people like how to integrate HTMLX into Django.
Yeah.
And, you know, we should shout out the, there's a sister course on there that you started out with,
with Flask.
And essentially I took the same concepts and then stuck it in the Django world.
So if you're coming from Django instead of Flask, then this, I guess it's a,
it's sort of the equivalent of translating it into Spanish.
So we cover a lot of the same kind of concepts in both courses.
We start with this video collector project.
So it's an actual project with, you know, clickable links and it allows you to sort of store videos that you see from YouTube
and shows a little image of the thumbnail and, you know, the, the, who the author is.
So a little database kind of application.
We start there with a working project and then we HTMX-ify it.
I'm just going to make words up.
Yeah.
It's a verb.
We can do it.
We're making verbs today.
Come on.
That's, it works.
In both courses, we add like a click to edit.
So you've got a little link, you click on the link and it turns into a form.
Infinite scroll.
The idea is you scroll down that content keeps getting added.
Search as you type, which to me is just such a beautiful example, right?
Like if you've already got search on the website, HTMX, it's like four lines of code.
Like it's, it's startlingly easy to do it in a dynamic fashion.
And it's complete with things like it updates the URL.
So you can do deep linking and you can do a, you know, back button goes to the previous search.
And all that basically comes by adding just a few attributes.
So that's, that's beautiful.
And then the Django version of the course also has a fourth example, which is how to take HTMX and integrate it in with bootstraps.
You've got libraries on top of libraries and how sort of that JavaScript event system works in that situation and how you can get those things going.
So, so yeah, so it's very example driven.
Let's add features and learn how HTMX works along the way.
This portion of talk Python to me is brought to you by IRL, an original podcast from Mozilla.
When it comes to artificial intelligence, AI, what's good for trillion dollar companies isn't necessarily good for people.
Can the risk and rewards be balanced?
That's the theme of season seven of IRL, Mozilla's multi award-winning podcast hosted by Bridget Todd.
Season seven is all about putting people over profit in AI.
I think you'll find episode two pretty interesting.
As you surely know, LLMs like ChatGPT are all the rage these days.
Do they seem like magic?
Well, it turns out that much of their power comes from millions of people entering and correcting data in these LLMs.
Episode two, the humans in the machine gives us a glimpse into the world of these people behind the AIs.
For policy junkies, IRL looks at the idea that we're all just guinea pigs in a big AI experiment,
like the meal planning app that suggests bizarre recipes such as Oreo vegetable stir fries and flawed technologies that compose more deadly risks when it comes to something going wrong,
like self-driving cars blocking emergency responders.
You'll also hear from people building more responsible ways to test new AI technology.
And we find out why it's taking so long to regulate this massive industry.
That's IRL season seven from Mozilla.
Check them out and listen to an episode at talkpython.fm/IRL.
The link is in your podcast player show notes.
Thank you to IRL and Mozilla for sponsoring the show.
You know what surprised me about getting into HTMX was you add all this functionality to this existing app,
kind of like you do in this course or I did in the Flask course,
and the code actually gets cleaner and simpler at the end.
Yeah.
Yes.
How can it do more and be more easy to understand and clean than the previous version, you know?
Yeah.
And, you know, we're going to spend a bunch of time talking about today, too,
is there's some libraries out there that make it even better.
And some of these I found after writing the course.
So it's sort of like, oh, well, hey, if I do that and go back, use that and I will write even less code, which is fantastic.
Yeah.
All right.
Let's, you know, not everyone has already had this love affair that you and I have had with HTMX.
So maybe you could just give us like a really quick overview of what HTMX is.
And I think maybe the way to do it would be just we could make a concrete example,
like click to edit or something like that.
We could just show like maybe you could just talk us through an example real quick.
And that would suffice is what the idea is.
Yeah.
So it's HTMX is a JavaScript library and it's a JavaScript library that if you're lucky means you'll never have to write JavaScript.
So you essentially drop it into your page.
And how it works is you apply a set of attributes to your HTML.
And those attributes affect how things work.
All of the attributes are namespaced.
They all start with HX.
And the key ones are HX get and HX post, which you can see on the example there on the button.
There's an HX get.
And essentially what happens is for a button or a link, you're replacing something like an H ref with this concept.
And when you click the button or the link that get fires an Ajax call to the server.
And the intent is instead of getting a full new page like you normally would when you click a link, it will send back a little piece.
And that little piece is then injected into the page.
And you can use different attributes to control how.
The example that's up on the screen here is using the HX swap attribute.
And that essentially says replace the entire outer div with the content that comes back from the server.
So the div with the first name, last name, email, which is just a read only, gets replaced with the form that comes down from the server.
So now essentially we've got click to edit on something that was display and now is a form.
That's the general idea.
HTMLX sets some headers so that on the server side you can tell whether or not it's actually a HTMLX call or not.
And in the Django world, this works really, really well.
So a common pattern with a Django view when you're dealing with forms is say have a get and a post inside of the same view.
So you do a get to get the page and then the post when you're actually submitting the form for that page and you keep it all together inside of the same view function.
HTMLX can do something very similar and essentially instead of checking for get or post, you check for this HTMLX header.
And then you can either send down the whole page or the little partial replacement.
And like in this example, it's the form that goes with it.
In addition to things like this form, you can attach it to say we kind of talked about searches you type.
So you can attach these kinds of attributes to say an input tag.
And then when maybe you want to bring one of those up, we've got it somewhere.
Yeah, perfect.
There's additional things that you can set that change how it behaves.
So for example, you want to activate this event when someone has typed something in.
So you're looking at the JavaScript key up event.
You only want to do it if the input has changed, not just if the event fired.
So if I'm using my arrow keys, it doesn't send something off to the server.
And then you can put a delay in so that if we get a bunch of events at the same time, it's not until there's a pause where you send it to the server.
So if somebody is rapidly typing, you don't send every single keystroke up.
In the course I also cover, you can set up conditionals on it as well.
So I've got to check in one version of one sample that checks whether or not there's actually content.
So you have to have typed at least three letters, for example.
Right.
So you can put these kinds of checks in.
And essentially, it really is very much like roundtrip 1.0 web, except what you're getting down is instead of a whole new page is you're getting a partial.
And the HTMLX library injects this in.
It's a way of doing some very 2.0 stuff in a very 1.0 way, which means you have very little JavaScript to have to write.
So personally, I have always found React to be overkill.
And that's not I'm not trying to slag React people.
Programming languages are a religious topic, right?
This isn't me saying you shouldn't.
This is me saying it doesn't work for me.
I started coding for the web back in the Perl's CGI days.
And when JavaScript was first introduced, one of the arguments for it was, oh, you don't need a tool chain, right?
It just worked.
And, you know, you just refresh the page and it goes.
So the whole concept of like TypeScript and a transpiler and web packaging and all the other stuff that's attached to modern web dev, I find exhausting.
And because of that, I've kind of always headed towards Vue because it's a little lighter weight.
But even then, I'm often doing things against recommendation.
I have been known to serve Vue JavaScript files through the Django template engine so that I can embed JSON objects.
And that's a no-no, but it's worked for me.
But I often find with Vue, even though it's lighter weight, because it's written for folks who primarily use Node, there's some assumptions in the documentation.
There's always this bit of a challenge to sort of get it to work in Django.
And what I've, you know, I've gone back and looked at everywhere I've coded with Vue.
HTMX solves like 95% to 99% of the things that I would have done with Vue, that I've done with Vue in the past.
And the only exception was I once wrote a drag and drop card game.
And I don't know if I could do that in HTMX, but pretty much everything else I could replace with HTMX.
And the amount of code I'd have to write would be a lot less.
The amount of JavaScript I'd have to write, which I've always sort of felt is a necessary evil.
It would almost just go away.
And now it would be unnecessary and still evil.
But yeah, that's me on my soapbox.
So yeah, that's the short version of it.
You've played with it a bit.
Did I miss anything?
Something you should highlight?
No, I think that was a really great summary.
The one thing I would like to throw out there that is not immediately apparent to people, but is a tremendous advantage of HTMX,
is that typical web development puts you into different mindsets for different parts of the application and context.
So I'm working on the database.
So I've got to think about database access and security in that context.
Now I'm working on server-side code.
And what can I do on the server?
What kind of code can I run on the server?
What packages do I have available?
Now I'm on the client side.
I can't do direct stuff.
I have to have an API to interact with the server.
So how do I build the API?
And there's all the restrictions of the code, regardless whether it's JavaScript or something else, in the front end.
And so you have these context switches of like, where are you in the app?
And with HTMX, it's like, everything's on the server.
Everything's in one language.
Everything's in Python and Django.
And whatever you do, you do it in Python and Django in this context or whatever your web framework is.
And the title of the course, Hold the JavaScript.
When I did the original Flask course, I got a bunch of flack from somebody on the thing that artists formerly known as Twitter.
Like, why are you hating on JavaScript?
This is just not what the world needs.
I'm like, I'm not hating on JavaScript.
I'm hating on the idea of having to write in three or four languages to accomplish one thing.
And evidence of this, like, evidence of this benefit is it's popular in the node community.
Right?
It's popular in the JavaScript community.
And they don't hate JavaScript.
But they, like us, would also like to not have two different styles of JavaScript, two different modes of JavaScript, two different contexts of code execution in just one place.
And I think it's easy to see, like, oh, how does this do something similar but cleaner than React?
It also transforms, like, where and how your code runs.
And I think that's really a big deal.
Yeah.
Well, at risk of getting too far off topic, right?
Like, the web is a giant house of cards.
And it always has been.
And our answer every single time has been, oh, let's add another layer of cards.
And we've been adding layers of cards for, you know, 20 years.
And it's shaky in places, right?
So anything that takes a couple layers off the top and simplifies how you think about things, I think, is definitely a benefit.
And like you said, HTMX is tool agnostic.
It's still agnostic, right?
So it's got nothing to do with Python.
It works with whatever your stack is.
And that in itself is something that is a thing of beauty.
Because if you're a node person, knock yourself out, right?
You want to PHP, whatever.
Go for it.
It doesn't matter.
Because essentially, it's back to the fundamental idea that HTML is based on, which is that hypertext concept of I click on something, it goes and gets a new thing and it puts it in the page.
And in this case, instead of it being the whole page, it's a partial.
It's a powerful, powerful tool.
Indeed.
Just to kind of put a finalize this whole thought here.
It's like, so Mark's out there in the audience asking.
So most business cases, use cases can be solved with HTMX.
My vote is, yeah.
Especially if you put business use cases.
If you're writing forms over data, like sort of enterprise-y apps, like 99%, right?
All the crud stuff.
Like I said, I think the only thing I would, the only place it doesn't really fit is when you're getting to the level of something like games.
And in fact, so we'll talk about it briefly, but there's a white paper on HTMX.org that talks about one of the companies that actually did a conversion.
And, you know, they had a fully running site and converted it over to HTMX and they had some big wins by doing that.
Could come back to it in a minute.
But I'm hard pressed to think of a business use case that wouldn't be improved by using HTMX instead.
Yeah.
And it's so simple that like a lot of times the use case was, well, just the web app.
It's not dynamic.
It doesn't do that.
You can add a lot of cool dynamic features to an existing app rather than like, oh, we have this really complex React app
that we're going to simplify.
I imagine usually it's kind of like a lift up the feature set then bring down as well there.
Some of this comes out of things like HTML5 as well, right?
So having email type on your input field means that there's a certain amount of validation that's happening in the browser now, right?
So things that we used to have to do in JavaScript, now the browser is taking care of some of that.
So by taking some of those kinds of features, you know, I don't have to have that check manually written on the browser side anymore.
And then adding HTMX to give that dynamicism, it just sort of tops it up, right?
So it's like I said, it's a step forward.
The one other area where HTMX seems like it's just not going to work is if you want to build offline progressive web apps.
Because offline is like the antithesis of HTMX.
Yeah.
So what I thought we could do for our conversation here would be to focus on just a bunch of tools that people can bring to bear on making working mostly with Django,
but also some of the other web frameworks like other Python web frameworks and HTMX together make that more seamless.
And we worked together to put together quite a list here, didn't we?
So there's two awesome lists we'll talk about.
So the 95% of what we're talking about, we found sourced off of these two curated lists.
The first one's called awesome HTMX.
And the second one is called awesome Python HTMX.
The first one is a collection of all languages.
So it's got a section on Python.
But, you know, as we were saying, if you're right there, HTMX from Rails.
So if you're coming from somewhere else and you want to use HTMX, there's a whole lot of pieces in here.
And it ranges from things like tools and articles and that kind of stuff.
The second one is a Python specific one, which is awesome Python HTMX.
They call themselves PyHat.
A little bit overlap between the tool sets.
But again, this is just sort of some master lists for the places you can go and get content and examples and all that kind of good stuff.
And in fact, one of the first white papers that I wanted to talk about a little bit is on the awesome Python HTMX list.
As I mentioned, there's a link to it on this list.
And as I mentioned, this is actually a case study off of HTMX.org.
It was presented at a Django con in 2022.
So if you don't feel like reading, you can go off and see the video.
But it's about a conversion.
And it took them about two months to completely convert from a React based site to HTMX.
They had zero reduction in functionality.
67% reduction in the size of the code base.
So that's significant, right?
Like that's two thirds of your code you no longer have to maintain because it's gone.
Increase the Python code by 140%, right?
So that's sort of the tradeoff, right?
We were moving some of that JavaScript stuff onto the server side.
They reduced their total JavaScript dependencies by 96%, which essentially means it's almost gone.
As a result of that, they had shorter web build times, shorter page loads, less memory.
And because of the less memory, they were also able to handle larger data sets.
So they were able to put more content on the page at a time using HTMX than React
because the amount of overhead React put on the page meant it was eating up space and it just couldn't handle it.
It's one white paper.
And of course, it's on the HTMX.org site.
So of course, it's going to be biased towards you should use HTMX.
It does show that this is being used in the real world and with a lot of success.
It's definitely something that you kind of want to look at.
I can't remember if I sent you the link, but there's another one recently that showed up on ByteCode.
This is a site that frequently linked to in the PyCoder newsletter.
A lot of really good content with the ByteCode guy there.
He's done something called...
Nope, that's not it.
It's three in real life use cases for Python and HTMX.
It's Byte with an I.
That's why.
It's the other kind of Byte.
He's a little cranky.
This is more of an anecdote than case study.
But essentially, he's gone through three kinds of projects that he's recently done with Python that are web-based and went,
oh, let's use HTMX instead.
And it's made his life easier.
And so essentially, he's just saying, hey, here are some cases where I've actually done this and it's been useful.
To the question we got earlier, really, it is that sort of, hey, I've got a form and I want the form to be slightly more dynamic.
So, hey, it would be an awful lot easier if I just stick this in and go.
And if I remember correctly, he's using FastAPI with this as well, right?
So it's not just Django or Flask.
There's lots of choices out there.
Yeah, it works really well.
Yeah, he's using FastAPI.
FastAPI works equally well with it.
And some of the tools we'll talk about are relevant as well.
So very cool.
This portion of Talk Python is brought to you by Sentry.
You've heard me sing the praises of Sentry for their error tracking and performance monitoring plenty of times on the show.
But this time is different.
They have a special live event, like a mini online conference, where you can connect with the team and take a deep dive into different products and services every day for a week.
Join them for launch week, new product releases, exclusive demos, and discussions with experts from their community on the latest with Sentry.
You'll see how Sentry's latest product updates can make your work life easier.
New announcements will be released every day on YouTube at exactly 9 a.m. Pacific time.
On Monday, November 13th, performance.
Tuesday, user feedback and session replay.
Wednesday, data resiliency and platform.
Thursday, frameworks, community, and integrations.
And finally, Friday, November 17th, open source sustainability.
I'm already signed up.
Join me at talkpython.fm/sentry.fm.
Dash launch dash week.
The link is in your podcast player show notes.
I'll see you there.
Thank you to Sentry for their continued support of Talk Python to me.
Some other things on the list I'm just seeing on the screen right now is like there's an IntelliJ,
aka PyCharm, plug-in for HTMX.
So it gives you autocomplete for all your HTMX stuff and probably for VS Code as well.
So if you're going to use one of those editors and do HTMX, you know, be sure to install that
so you get autocomplete and validation for the different things.
So cool.
All right.
Well, let's talk about maybe the big first one, Django dash HTMX.
Just brought under extensions for using Django with HTMX.
So this is the go-to.
This is not only is this the right way to do things, but this is also, in fact, talk about
this in the Django version of the course.
There's also about a half dozen libraries out there that all said, oh, we're just going to
do what he did, but we're going to do it for our library.
So this has been an inspiration to other folks as well.
It's by a gentleman named Adam Johnson, and it's essentially some Django middleware and some
utility classes.
So in Django, each view gets a request object.
This library adds a member to that request object called HTMX.
You can use that member as a Boolean.
And if it evaluates to true, then it was there's an HTMX header.
So it was an HTMX call.
And if it's false, it wasn't.
So this is what I was referring to earlier about that idea of being able to have one view
manage multiple things, because essentially you just check this Boolean and either I'm
feeding out the full page or I'm feeding out the partial.
Right.
Because the big concept in HTMX is there'll be a request for the page, which shows you the
whole thing.
But an interaction won't want all the page content.
They just want the fragment that the new version of the fragment, like the new table
row that has been edited or something like that.
Right.
That's right.
Yeah.
On the server, you got to decide what version do I give them?
This answers that question.
Exactly.
And this is so, you know, to take it back to the click to edit example that we talked about
at the top.
You know, the first call to the page, no HTMX.
It shows the content of the page, including the person's name and email address or whatever
it is.
And then when somebody clicks the link and that needs to be replaced by the form, you can use
the same view.
And that view then just returns the form as a partial rather than the whole thing.
And so checking this Boolean allows you to tell which mode am I in and how do I want to
do that?
There's other information on as well.
So you can check things like the target and the triggers.
So these are other attributes.
Didn't mention the triggers when I sort of explained things at the top.
The trigger is that event management piece that I was talking about with like searches
you type.
So the trigger says a key press or there's another one that allows you to do on scroll down.
Right.
So when the tag is revealed, then trigger the call.
So the Django HTMX will give you information about what the event was, what triggered, how
it worked, et cetera.
So if you need to make decisions or if you've got multiple HTMX things happening inside the
same page, you can suss it out that way.
Quite frankly, the Boolean mechanism is enough for me to want to install this library.
The rest of it I don't use very often, but just being able to check which mode I'm in and
not have to check that header myself is worth installing the library.
And it feels very, very Django-esque because it essentially just replaces that get post pattern
that I was talking about earlier, but instead with HTMX.
There's also some other utilities in here.
The way that HTMX works, if a URL is hit, that's a 404, it just eats it.
There's a chunk of debug JavaScript that comes with this library that you can put in so that
you actually get the Django 404 page.
So it essentially overrides the response back from the view and spits out an actual debug
page that you're used to.
So it allows you to debug your HTMX a little better.
And then there's some classes and functions for things like polling and controlling redirects
and a few other things that are also useful for typing as well.
Right.
So if you're doing a type check that you want to replace, that this call comes back
with HTMX, then you can put it inside of your typing that this is this kind of class that
comes back.
So very, very handy library.
Very strongly recommended that if you're doing Django and HTMX, this is the place to go.
Okay.
This is the big one.
All right.
Next up.
This is from the multilingual awesome list.
Django JS lib HTMX.
So this one's pretty lightweight.
It pretty much allows you to use tags to drop the library in.
So it essentially just means you're scriptifying some of the things that you're using in the
library.
I haven't used it myself.
I think a lot of it depends on how deep your pages have to go.
Personally, I would just stick this in and hard code it myself.
It's there if you want it.
Yep.
Sounds good.
HTMX Flask.
This one, I think, is really interesting.
And you might be saying, like, well, why do I?
It's Django we're talking about.
Why do I care about Flask?
But we already went through two of the examples on the HTMX.org site.
And what you see is the client side.
But there's no visibility to what the server side looks like in that example code.
But this, this will help maybe.
There are three things called HTMX Flask, Flask HTMX, and Flask HTMX with a capital.
So they all start to blur together.
There.
Yes.
This one is essentially if you at the top, if you're not listening, if you were watching,
Michael showed the HTMX site and a couple of the examples.
This is a Flask S.
They've redone all of those examples from the server in Flask.
So if you're looking for how to implement these things rather than just in pure HTML and you want to see them in the Flask server, you can go that here.
And because it ties back to the actual HTMX.org page, it allows you to sort of see how all the pieces fit and look your code up as you go.
Yeah, I think the examples are really awesome and simple on HTMX.org, but they don't, they don't tell the whole story if you're trying to actually implement it.
And if you're like, I just don't really know how to do that with my web framework.
Here's at least a Python set of examples that'll get you pretty close.
Yeah.
There's a few of these as well.
Near the tail end here, we'll talk about a couple others that there's one which is actually a board game, which is a nice top to bottom full example.
But this one essentially relates the example content off the HTMX site to your Flask server.
Nice.
All right.
Server sent events.
If you're using Starlette, this is a tech demo essentially by Jan Vlasinski.
And essentially he's using FastAPI, HTMX and Starlette.
And pages, the example is actually quite simple.
There's almost no content on it.
It's just a little bit of, it almost looks like debug.
So there's a few variables which are randomly generated inside of an asynchronous call on the server.
You run it using Yuvacorn.
And essentially when you visit the page, the values update on the fly.
So the sleep in the server code is pretty short.
It's about a third of a second.
So the debug messages go flying by rather quickly.
I bet they do.
But it gives you an idea essentially how to wire these kinds of things together.
I've never used Starlette myself.
Have you played with it at all?
Only by way of using FastAPI and LightStar.
Okay.
So they're both built on top of it, but not directly.
But, you know, server sent events are interesting because we've had traditional web interaction, which we kind of talked about already.
And then you've got web sockets for super dynamic bidirectional communication.
But a lot of times people use web sockets because they just want to receive stuff that happens on the server on the client, like a dashboard, right?
The dashboard doesn't need to update the server and broadcast.
It just wants all its pieces update live.
And so servers and events are like a lightweight web socket type thing.
And it's really cool to be able to plug that in with HTMX, I think.
Yeah.
I haven't played with it myself, but HTMX also has a polling mechanism.
So if you're not using technology on the server side that can enable this, you can get around it the other way.
Obviously, an event from the server is far less noisy than polling.
But by using, it basically gives you a couple different options.
So if you happen to be using something that isn't asynchronous and you don't want to go all the way down that path, you could also look at the polling techniques inside of HTMX to get you to solve similar kinds of problems.
Yeah.
If you're not building a massively busy website, maybe it's totally fine to just pull it, right?
Yeah.
Well, some of it also has to do with the frequency, right?
Like if it's data that only needs to update, you know, once every 30 seconds or so, then while somebody's on a page, that might be the right way to go.
Yep.
All right.
Now, we'll start pulling some items off the Pi Hat.
Sure.
Pi Hat example on here.
Yeah.
Another list here.
We started talking a little bit about this.
I've been hopping around a bit.
So that white paper that I talked about is on here and a bunch of some of the other tools that we've got as well.
Good overall list has some sort of a nice breakdown that it's got sort of the resources as in like, here are some articles you can read.
They've got a link to your Flask course.
So I think we need to do a PR here.
And we definitely got to do a PR.
And I appreciate the Jenga one in there.
We do.
I appreciate however this got here.
Thank you, people.
Yep.
But yeah, we got to do a PR.
So some good links in here to some obviously to some quality content.
That's right.
Yeah.
So there's a bunch of different ones in here.
I think probably the helper libraries is the section that has like really what people are imagining when they're thinking awesome lists, at least awesome lists for programming.
So make a like.
Yeah.
In fact, so there's three on here that I think I'm going to want to sort of cover back to back because they're all essentially the same idea.
So I mentioned that Django HTMX is like is sort of the go to way of doing the Django stuff.
And it inspired a bunch of other people.
Well, there's ASGII HTMX, Starlette HTMX and HTMX Flask.
And all three of these.
Sorry, I'm flapping around as we go along.
You're trying to keep up.
So all three of these are essentially like the Django HTMX library, but for those appropriate other libraries.
So they essentially add that meta information to the requests or in the case of ASGII to the scope.
And it's the same kind of thing.
It gives you an idea of what the header is there and what the other information is.
So if you're if you're not on Django, if you're on Flask, then HTMX Flask or ASGII HTMX will work and essentially solve the same kind of problems that Django HTMX does.
And all three of those are listed on that pie hat piece.
So that's ASGII HTMX is by Flormon Monka.
Starlette HTMX is by Felix Ingram.
And HTMX Flask is by Sergey Ponsfrixis.
Not sure how to say his last name there.
Yeah.
A lot of good work going on in this space.
All right.
How about Django HTMX patterns?
Ah, yes.
Good old spooky Lukey.
So he's got an awesome GitHub handle here.
This is Luke Plant, who is or was, I'm not sure the time frame on that, but was heavily involved with Django.
He was a core developer for a while.
And essentially, he's written up a article here on good ways of interacting with Django and HTMX.
There's some code examples to go with it.
We're going to talk in a minute about the block, render block library.
He's a fan of that approach.
Essentially, this has got good reasons for how you group your snippets together.
That idea of having your code and all your code in the same view, as well as keeping your snippets, possibly even the same file.
He talks about these kinds of things, as well as sort of hands you off to some of the toolkits that we're talking about as well to help you do this.
I'm a fan.
He's also got a great article called Django views the right way, which is,
He tends to write fairly opinionated pieces.
And of course, when you agree with his opinion, that's fantastic.
He must be brilliant.
So he's very...
Finally, someone's standing up for our way of thinking.
Exactly.
So he's very pro-function-based views.
And for folks who aren't Django people, that's a Coke versus Pepsi thing versus class-based views.
But because I tend to...
My bias heads in that direction.
He must be right.
So everything else he's written is brilliant as well.
So I've got a lot of good information in here to dig around some best practices, as well, as I said, to some references to the kinds of libraries we're talking about to make your life easier.
Yeah.
I think these kinds of things, like these pattern ideas, really help you think about, how am I going to add that into my application?
Right.
Instead of just, here's some libraries, and here's HTMLX, and here's...
How does it look right?
How do you make your Django code better and cleaner by putting this stuff together?
Yeah.
Well, and honestly, like my tongue planted firmly in my cheek with the whole function versus class thing, notwithstanding.
One of the things I love about these kinds of opinion pieces is it allows you to help sort of formulate, oh, does that fit in my version or does it not fit in my version?
And how does this map to what I'm doing?
It allows you to sort of think more deeply about the patterns that you're using as you're coding.
You might leave an article like that and go, oh, now I understand more about why I chose what I did, and I'm going to stick with it.
It might be the opposite of what that article is there, but it opens you up to other ways of thinking about these things, right?
It comes from that practice of doing it rather than, like you said, just a couple quick examples.
Another thing about patterns that I've always loved, design patterns, programming style, is when you think about a problem, if you just think about kind of the idea of the pattern, like what are the steps?
It's hard to think about it.
You're really down in the details.
But if you can think about as the whole thing that the pattern applies to and what of its benefits and trade-offs, you can think at a much higher level.
And sort of it lets you not think in detail, right?
Like you could say, well, I want to have, you know, outside the web, you can say, I want to have a way where we just have one variable, just copy of it.
It's just one and everybody shares it instead of passing it around like, okay.
Or you could say, we have a singleton.
Like, boom.
Like that one statement, just what are the benefits?
What are the drawbacks?
What are the use cases?
Like it's testing hard.
It makes reuse really easy because you just grab it.
And it's sort of like that for HTMX, right?
As you think like, oh, this pattern applies right here.
Let's go.
Or it doesn't because of.
And it becomes some of it's a vocabulary thing as well, right?
So there's this concept we're going to spend a little bit of time talking about in a minute that is the partials, which is those little snippets that I was talking about.
And in fact, if I remember correctly, the term partials has been stolen.
It's something Rails uses, right?
By using that same vocabulary, it allows you to sort of talk about these things, like you said, at that higher level concept, right?
So that the patterns help with the vocabulary, help with you communicate about those concepts rather than spending the first 10 minutes of your conversation trying to establish whether or not you're talking about the same thing.
Yes, exactly.
Exactly.
Speaking of, we have fragments and we have partials.
And this is a little bit of an alternate, like this is a Coke versus Pepsi as well.
Considering you're the maintainer of a sister library to this, maybe this one should be you.
Maybe you want to talk a little bit about Jinja partials.
Well, so my understanding here with the Jinja partials one is you can express parts of your page to contain the template data that you want.
So for example, here's a whole thing, you know, with a HTML and a head and a body.
And then it has one thing that says, this is a block and it says just a paragraph.
This is the magic number with that value.
With this thing, what you can do is you can say, just grab that thing we called content and provide the data over to it.
Because I don't want to show the whole page.
I want to show just this section of it.
And there's an essay over on HTML.org, something about the locality of behavior and things like that.
I believe it's something titled like that.
And the idea is I have my entire HTML listed all in one as if it was a static page.
And I can use the server side to grab pieces out of the HTML and make them dynamic sections, right?
Like I described, like grab this block, render it using the template engine, the Jinja2 fragments.
Okay.
So that's the, I don't know, Coke?
Coke or Pepsi?
Who gets, which one does it get?
Let's call this one the Coke style.
And that, I think, is really useful, right?
Because what is your alternative?
Have that HTML in two places?
That's not a great option, right?
You don't want to have, it's just like you wouldn't duplicate code.
You don't want to duplicate the design and the HTML and stuff that makes up the part of the page
and have inline for the main one and then a second copy just so you can make it dynamic.
So I'm not against this.
I think this is really a neat idea here to be able to grab that section and render that.
Pepsi side.
Michael's library called Jinja Partials, which says, instead of putting it all into one big place,
let's treat it more like function-based programming.
So what you can do is you can say, I'm going to define an HTML partial or piece that just has
that section that you're interested in, right?
So maybe you might have like one part that displays a particular video in our example from the course,
right?
And that thing has to be past certain bits of information, like what the video is,
so you can get the ID and so on.
And then when you use it, you kind of, instead of putting the HTML inline,
you call it like a function in the HTML.
So you would say like div, here's the thing that contains it, you know, render partial,
here's the thing.
And you call it.
So it's kind of two sides of the same coin, but like very much Coke, Pepsi is a good analogy
here.
Like this one says, I would like to maybe be able to reuse that across different pages,
just like you would a function in Python.
I might want to use it in more than one place.
And so it makes sense to have it in its own separate thing, right?
Like in this example, you might want to show a video, but you might want to do it on like a list
of videos.
And you might want to do it on a profile page where you have favorites, right?
And those wouldn't, the fragment style, you would have to duplicate that HTML.
So this one allows you to have like a nice, simple way to do that, right?
And then on the server side, it makes it simpler because I don't know if there's any examples
here.
I'm sure there is.
But on the server side, all you do is you just say the template response is the partial
and you just provide the data and you don't have to do like, if it's the full thing or
if it's a partial thing, I'm going to do different stuff on the server.
Right.
So that's the Jinja partials.
I don't have a Django partials, but you know, this, this applies for Flask, FastAPI and others.
So on the Django template library, the include tag is either slightly more powerful than the
Jinja one or just better documented.
A lot of the reasons you wrote this library, I can do with the existing Django include tag.
So there's like a tiny little use case where it doesn't overlap, but like everything,
everything in the course, for example, I was able to do quite simply with just using the
include tag.
There is a library out there that is the, what did you say it was the Coke version?
And that is the Django render block.
This is by Patrick cloak.
And essentially he's using very, something very similar to the Jinja2 fragments.
And it essentially allows you to pull out a template block from a page.
This has actually spooky lookies preferred approach.
It's in his patterns.
I think in this case, I'm a Pepsi guy.
I'm with you.
I would rather have the piece inside its own file.
But I think the reason behind having it in the blocks is essentially you can turn conditionals
on, have that one page, the whole thing gets rendered.
And then the snippets are always using the same library and you can just flag, hey, I want
this partial piece coming out of it.
Essentially, these are very, very similar concepts.
Just the Django versus the Django templating, because of course, Django is in Django as well.
So the Django native templating versus the Django piece.
And you can take either approach depending on what works for you.
Yep.
And just to wrap this up before I get a lot of email, a lot of email, there's a whole section
that says, why not just use include or macro from Django?
And there's a great long discussion here with lots of examples.
The short version is with macro, if you want to render the template alone, you have to
have a third page that just calls the macro, that just embeds the macro and then calls it
in an empty page for the template.
Why not use include?
Well, with include, you have to have the thing, the variable names in the partial match the consumer.
So it's as if you had to say, I want to function, I want to call a function, but your local variable
names have to match exactly the parameter names in every use case that you can't say like
user where there was a username.
Nope.
You can't call this function that you're supposed to call your variable local variable user.
You know, it's, it's, so there's a look at that discussion and then, then email me if
you have to.
And that's, that's why the Django one doesn't have this problem is because the include tag
in Django has a with keyword, which allows you to essentially say, I want this, this bit
of context passed in as that value.
So you can essentially, the equivalent there would be with video equals V email equals user
dot email to accomplish the same thing, which is why I could get away with not needing the
extra library.
Nice.
There is somebody down here who said, I'm not sure what their name is, but I think they
found an internal, like a deeply internal function from within Jinja.
I think I'm not sure if it's in Jinja or Flask, but you're able effectively to do the
same thing, but it's like, I don't know.
I'm not a fan of like grabbing some random internal thing and going, I think we'll probably
just use that.
You know, I also just, there's a chameleon's partial.
If you're a chameleon template person that does the same thing, it's a Jinja partial as
well.
Yeah.
When you first showed this to me, I looked it up in the Jinja docs because I don't use
Jinja as often.
And it kind of hints that this is there, but it was really, really unclear.
It just sort of gave one example and didn't explain it.
And so, yeah, it doesn't surprise me that there's something that can be done, but maybe
it's, maybe it's publicly available.
And if they got documented a little better, it might solve the problem and you could, you
know, close up that chunk of code you had to maintain.
Yeah.
I mean, I'm not necessarily in love with it.
I just, I created it because I want to have really nice clean code.
Right.
Yeah, exactly.
Of the problem.
You know, pull up the Django render block.
You already really talked about that one.
That's on the, the similar side as to the Jinja fragments.
Partial.
To fragments.
Sorry.
That's what we talked about.
That's right.
Where the, all the stuff is together.
And I think that's a good idea if you're never, ever going to use that block of that
bit of HTML and dynamic bit anywhere else.
But as soon as you are, then it's like, well, it's starting to get, I don't know.
That's my philosophy.
Yeah.
One of the reasons I use the include template, even for, I use it even just to shrink this
shrink the size of the HTML file.
Like I don't even care if it's not reused.
Sometimes I just find it easier to read because HTML is so verbose.
I sometimes just find it easier to read something that goes, oh, include row from this row file.
I'm like, oh, okay.
I don't have to think about how many divs are in the row.
I understand what's in that row.
And it allows me to read it easier.
So obviously the cost of that is a performance of compiling the template, but I'll take that
for code readability every day of the week.
Just throw more CPU at it.
Yeah.
I'm a hundred percent with you.
And yeah, you don't have to worry about whether the 17th div is matching or not.
Yeah.
All that stuff.
Yeah.
You talked about Flask HTML, the ASGI one.
HX requests.
What's this one about?
This is similar, right?
It solves the same problem, but in a different fashion.
So this is by a gentleman named Yakov Lundsen.
And essentially he's using a lot of the class-based view philosophy, not that he's actually using
class-based views, but essentially you are building out your requests, HX request handling
as classes.
And he's gone to the level of defining custom tags that you use instead of the attribute, and
it will automatically wire that together.
So you don't even have to declare your URLs.
And this is, and again, you know, back to that Coke versus Pepsi thing.
This is that sort of that, the definition between function-based and class-based, the contrast
between function and class-based.
Class has always made me a little uncomfortable because they're a little bit magic.
It often means writing less code, but if for someone who isn't used to it, they have to
go digging to understand what's happening.
He's definitely taken a bit of a magic approach here.
There's less code, but you can, you've got this magical wiring of change email as you've
got up on the screen, getting wired to the actual HX change email underneath and being
able to find all that code.
So if you're a class-based view person, this will probably feel very, very natural and a
good approach to take.
If you're not already intimately familiar with class-based views, this wouldn't be somewhere
where I would send you.
I'm going to add more overhead to figure out how to put all that together than just to use
the other libraries.
Yeah.
That's right.
Well, we have a lot of things we've been going through, but I think we're getting close
to the end of the list here.
Django dashboards.
Yeah.
Actually, why don't we just skip down to a Wella Club and maybe we can cap it out right
there?
Because I thought it's probably a really good example.
Multilingual version, the original.
So this is, if you want to go one place to see everything working together, this is the
place to go.
So this is also by Adam Johnson.
So he's the same guy who does Django HTMX.
A Wella is a Nambian game that is kind of similar to another game called Hus.
I will admit I couldn't fully wrap my head around the rules of the game.
It's essentially like a little board with holes in it and there's stones in the board.
There's a good picture up there.
Good.
And the rules are you on your turn, you have to move some of your stones.
And if you move them correctly, you're done.
Your turn is done.
If you don't move them correctly, you can take other people's stones, whatever.
So it's one of those very simple games with a lot of strategy.
And like I said, I didn't quite fully wrap my head around the game, but that's not what
I was here for.
He's written a HTMX based version on the web here.
You've got a fully automated computer opponents.
You can play against the computer.
It has the layout of the board with the number of rows and stones.
And then there's a number for how many stones are in each hole.
And if you click one of the links, the one of the numbers,
it automatically moves the stones according to the rules.
And all of this, of course, as you can imagine, is updated through HTMX.
It even has the base version of this ships with the Django debug toolbar on so you can watch
what is going on.
And then in the background, because it will host multiple games at a time, we were talking
a bit about that polling concept.
It's using the HTMX's polling mechanism.
And in the top right hand corner, there's a little report of how many games are in progress
at the moment.
So I really, really liked this example.
So there's other examples that are good on the list, but most of them are toys.
They either show off something like an event coming from the server and, you know, no cleanliness.
One of the other examples I played with was like a little book database.
And, you know, it worked.
But if you typed in a number in a place that was a name in a place where it was supposed to
have number, it would crash.
This is actually a working application.
And so you've got a nice solid example to how everything works, all the different attributes
and go.
So if you're comfortable enough with, if you're new to Django, then maybe this isn't where you
start.
But if you're comfortable with Django and you really just want to see a one place where
all the HX parts are working together and it's a fun way to learn something, this would
definitely be the example I would use.
Excellent.
Yeah, it looks like quite a cool way to build things with HTMX.
I'm not even sure I would have thought HTMX totally applies to this level of kind of
interactivity because it says you can do player versus player games with the polling trigger
and stuff like that.
It's a pretty deep example.
But of course, you kind of expect it out of the HTMX, Django HTMX guy, right?
So and actually, so as an aside, there's also a relatively decent demo inside of that library
as well.
So if you grab, if you get clone Django HTMX, there's an examples directory that also has not
quite as comprehensive this, but that's another good place to start as well if you're looking
for sample code.
So plenty of good stuff out there with good real world purpose.
Cool.
Well, quite the look inside of HTMX, Christopher.
Thank you.
Yeah, it's been fun.
Yeah.
So many things these days to make it work with Django.
When I started out, like many of these libraries didn't exist.
I would have probably just grabbed one and used it had I had it at the time, you know?
It definitely makes a big difference.
And the HTMX community is, I accidentally found out very, very vibrant.
Somebody found the future table of contents of my book and posted on, as you said, the artist
formerly known as Twitter.
Hey, there's an HTMX chapter coming in this Django book.
And my feed just exploded for the next three days of everybody going, yay, HTMX.
So there's a very strong and excited community out there that's playing with this tool.
And as I said, it makes a real big difference in your ability to build stuff quickly and effectively.
Sure does.
And speaking to the long-term sustainability, right at the top of the HTMX.org page, it says,
we're excited to announce that HTMX has been accepted into the first class of the GitHub
open source accelerator.
So more momentum for HTMX.
Excellent.
All right.
Final call to action.
People want to get started with this stuff.
They want to dive into it a little bit more.
What do you tell them?
Start with the page you've got up right now, for sure.
HTMX.org is a good place to go.
And, you know, at risk of sounding like an infomercial, we have a couple of really high
quality courses that you could also check out.
Yeah.
It would definitely be places to go with things.
And of course, you know, we'll link in the show notes to all those lists.
But there's a lot of content there if you just kind of want to go digging and play around.
Yeah.
We only just touched on a little tiny bit of it.
So plenty more to go into.
Lots of interviews.
Lots of examples.
Lots of blog posts and articles that you can go check out.
And your book.
Your book will be out in the spring.
So people can check that out as well.
Appreciate it.
Yes.
Yeah.
Thank you so much for being on the show.
Always nice to catch up with you.
Glad to be here.
Yeah.
See you.
Bye.
This has been another episode of Talk Python to Me.
Thank you to our sponsors.
Be sure to check out what they're offering.
It really helps support the show.
When it comes to artificial intelligence, AI, what's good for trillion dollar companies isn't
necessarily good for people.
That's the theme of season seven of IRL, Mozilla's multi-award winning podcast hosted by Bridget
Todd.
Season seven is all about putting people over profit in AI.
Check them out and listen to an episode at talkpython.fm/IRL.
Century.
They have a special live event like a mini online conference where you can connect with the team
and take a deep dive into different products and services every day for a week.
Join them for launch week.
New product releases, exclusive demos and discussions with experts from their community on the latest
with Century.
You'll see how Century's latest product updates can make your work life easier.
Visit talkpython.fm/century dash launch dash week to register for free.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at talkpython.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.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 /itunes, the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.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 talkpython.fm/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.
I'll see you next time.