Have you heard about HTMX? We've discussed it a time or two on the show.
We're back with another episode on HTMX, this time with a real-world success story and lessons
learned. We have Sheena O'Connell on to tell us how she moved from a React Django app to pure
Django with HTMX. This is Talk Python to Me, episode 484, recorded October 29th, 2024.
Are you ready for your host, here he is!
You're listening to Michael Kennedy on Talk Python to Me. Live from Portland, Oregon,
and this segment was made with Python.
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 accounts over at fosstodon.org, and keep up with the show and listen to over nine years of
episodes at talkpython.fm. If you want to be part of our live episodes, you can find the live streams
over on YouTube. Subscribe to our YouTube channel over at talkpython.fm/youtube and get notified
about upcoming shows. This episode is sponsored by Posit Connect from the makers of Shiny. Publish,
share, and deploy all of your data projects that you're creating using Python. Streamlit,
Dash, Shiny, Bokeh, FastAPI, Flask, Quarto, Reports, Dashboards, and APIs. Posit Connect supports all of
them. Try Posit Connect for free by going to talkpython.fm/Posit, P-O-S-I-T.
And this episode is brought to you by Bluehost. Do you need a website fast? Get Bluehost. Their AI
builds your WordPress site in minutes, and their built-in tools optimize your growth. Don't wait.
Visit talkpython.fm/bluehost to get started. Gina, welcome to Talk Python to me.
Thanks so much. Happy to be here.
I'm happy to have you here. We've got an awesome topic queued up. One that I just, I don't know if
I'll ever get tired of coming back to this because I'm just such a fan of simplicity and getting stuff
done and not like, let's see how many layers of things we can pile on. And by that, I mean,
HTMX as a success story for going from a whole bunch of front-end stuff, a bunch of different
multi, multiple apps, you know, JavaScript front-end, Django back-end, talking to each other,
but kind of being separate as well. Oh, yeah.
And just switching to HTMX. And you wrote up a really cool essay on this that we're going to
dive into, so, and share your experience.
Pretty fantastic experience overall. I was really surprised by HTMX when I came across it the first
time because there are so many fashionable front-end libraries and frameworks. So when I heard about it,
I was like, oh, it's another one of those, whatever. And then I went to a DjangoCon, I think it was 2022,
and I saw a talk from Chris May, who's in the audience, and that's got me excited about it. And
yeah, that's kind of when my whole story started. What I had been doing before was working with,
so I had this team, and we were building a thing, and we had a React front-end. So on the front,
that's a normal thing. Like if you wanted a modern front-end application, you'd use something like
React or Vue or one of the many competitors. And then on the back end, we had Django. And I think that's
like a fairly normal, fairly accepted way to do things, or it has been for a long time.
But I think it's like, I think it's a little faulty. I think that front-end web development has
been in a little bit of a complexity death spiral for the last little while. And like, sometimes it's
useful, sometimes it's really helpful. But like for some things, you need certain tools in the front
end, I think. But yeah, I think it's, things have been going in the complexity for a direction for a
long time. And HTML solves a lot of problems.
Right. Well, you think back, you know, think back to the jQuery days. How did you use jQuery? You
included a CDN, or if you're wild, you might download it and include it in your own static content. And
then you just started using it, right? And just layers and layers have just been building. And
JavaScript of 2024 era looks nothing like 10 years ago, 15 years ago, JavaScript.
Yeah. I would say it's one of the more complicated programming environments compared to something
like C++, right? Because there's so many steps in there, so many implicit linkings and stuff.
Yeah, there's a lot of dark magic under the hood. It's very hard to know what's going on. And
I think like one of the challenges is that a lot of people used to get into web dev as their gateway
drug to programming. Like they'd start off with web dev and then branch out from there. But now web dev is
like this magic weird box with so many layers. And I think it's, it's sort of messed a lot of people
up. It's a challenge to get started in the way that people used to get started. And it's like the barrier
to entry level programmers used to need to be here. And now it's here. And yeah, there's a lot of key
things to the ecosystem as a whole. But yeah, like all the build steps, all the magic things that happen
under the hood. And the fact that you have to like tasks switch between completely different applications
and completely different like ways of thinking. So for me, I've always loved Django. It's so good.
So with the thing that I was building, I wanted Django because I needed to build a thing really,
really fast. And so my efficiency was important. And then it was like, I need a good front end. And
react was, was a clear choice at the time, but it means like switching, like, like for me to work
on this thing, I need to keep holding the Django application and the react application in my head
and how they talk. And it's not just react. It's like Redux and Saga and side effects and asynchronous
goodies. And, and then on the Django side, it's all of that. And Django is, I think much simpler to get
your head around than react. Actually, it's a tricky thing. It definitely is a tricky thing. And one thing I
would just like to put out early before we get too much mail is this is not necessarily a,
a hate on JavaScript. Oh no, no. There are people in the node space that are super fans of HTMX. And I
think what is not obvious about the benefits of HTMX, as we get into it, we'll, we'll talk about some of
these things, but you were just touching on then, like you've got this react front end, it has its own
state. It also has its own capability. So it's running in the client side. So it can't talk to file systems or the
database. It can only talk to APIs. On the other hand, you've got the Django app, which probably is
not talking to APIs, but talks to the database talks to, you know, the server levels things. And you've
got to, as you're working on this app, think, okay, I'm in this context. That means no database. I'm in
this context. That means primarily just database. Right. And it's just, you have these two worlds.
And if you could say, can I just write in one of them? Yes. And the JavaScript people might even
pick like, I just want to stay in JavaScript, but always node or always at least, you know, pick one
of the styles of programming and not just constantly switch back and forth between these. You have
browser capabilities, you have server capabilities, you have browser information. Like just, that is just not
productive. It's not the best. Right. And so as much as you can avoid that, and as we'll see,
HTML is super easy about keeping it in one place. Right. So that's, I think that's one of the big
things that people should, should be honing in on as we talk about this. What do you think?
If I came across as hating on JavaScript, I think JavaScript did. I use it a lot where it's needed.
I think it is a fantastic tool in the toolbox that I'm on sides with you, that it's just the
complexity of switching contexts all the time. It slows you down and it's a lot to keep in your head.
And so it's like, for me, when I was working on this application and needing to switch contexts all the
time, it's like, like you can't just make a thing. Like you have to like do the dance to make the
thing. And it's. Instead of four different chained file watchers to do their things and stuff. Right.
So it just like adds a little bit of a, like you're slower than, that you would like to be. There's like
more tedium than there should be. It'd be nice if you could just like build the thing quickly in a
simple way and it just works and is beautiful. And HTML kind of allows that along with other tools.
Yeah. So for me, that context switching was like a painful, painful thing. And for the team I was
working with as well, like I had a bunch of juniors on my team and it was so hard to get them productive
because it was like, okay, do you want to be productive on the back end? Or do you want to be
productive on the front end? And then on the front end, like that was complicated because of the,
again, React, Redux, Redux saga. So, so they were all just like suffering. And then.
To put real features into place, you've got to do a vertical slice, right? Which hits most,
if not all, you know, you probably, you probably have to touch the React front end.
Yeah.
You probably need some new tiny bits of UI design. So CSS and maybe some
SAS build step there. And you know, like then you're doing the server side bits and then you're
doing a database migration and it's just like, it's end to end, right?
Yeah. And for some people that's not even reasonable to expect them to have all of those
skills, those end to end skills. And then it's like, you have to make your team complicated. You
have to have a back end team and a front end team and they need to now integrate with each other. And so
like the team resembles the team stack.
Yeah.
Yeah. That's interesting. Yeah. We have a group for this later, a group for that later. And you know,
look, if you're a huge company, maybe that actually makes tons of sense. Maybe I'm not,
I'm not saying it does, but it may, but when you're a small company, it just doesn't. Right.
Right.
When you're building something, you do need to think about the team that's going to be building
it. The skills right now, the skills that they're going to have in the future, the skills that you're
going to need to pull into the team in the future. And so it's, I don't know if it makes sense to,
well, in my context, it didn't make sense to, to split up the team. If I had the tools to allow
everybody to be in the same place from the beginning, that would have been freaking fantastic.
Yeah, absolutely. That would be awesome. Let's talk a bit about HTML. So we, we said,
Hey, we've been talking about this by and sort of broad terms, but let's be a little bit specific.
And maybe you could tell us like, what is this HTML and why is it, why is it not just a different
flavor of reactor view or something? And then maybe we could talk to you a few examples.
The way I explain HTML to myself is that like, imagine looking at HTML, HTML is with us. It's,
it's going to be with us forever, maybe not forever, but for a very long time. What, what if we like
There've been many, yeah, there've been many attempts to replace it and they were all bad.
Yeah. Yeah. So it's, it's probably going to stick around for the foreseeable future and it's everywhere.
And what if we could just augment it slightly so that it could do what we needed it to do in the
modern web. Like we, like since HTML got invented, like it's quite a simple tool, but now we need to
do all this extra stuff because people expect all sorts of like interactivity in the user interfaces.
They expect asynchronous workloads and things like that. And what if HTML could do that? And it can
do that. And it's not actually that hard to make it do that. You just need to add a few extra attributes.
And so what HTML is, is a really, really small JavaScript library. And you just include it as a
script tag in your page and then it's there and it's available and it's installed just like the old,
the good old days of jQuery. And yeah, you could just go back and throw it in a CD and if you wanted,
couldn't you? That's right. I hadn't really thought about it. From there, you, you just have these extra
attributes on your HTML tags that do different things. So for example, like, so HTML says a lot of
different stuff, but if you were to like 80, 20 years and look at the parts that are the most used,
then basically the stuff you'll use the most are like tying into events, like click event handlers or
whatnot. And then when you click on the thing or whatever, it'll send in a request to a backend and
the backend responds with an HTML fragment. And then you swap that fragment into your page somewhere.
So if you were to look at the, the HTML documentation, the, the hello world of HTML is a button and the
button says, has the attributes HX post clicked. So it's saying like, when you click on the button,
then send a post request to a URL that's like forward slash click. So you can decide where,
like what HTTP method you're using and where it's going and what event you're tying into. And then
when the response arrives, then you do something with it. And the response is HTML. It's not a JSON response that you,
they need to like turn into HTML. It's, it's plain old normal HTML. So it's super simple to write. And then you,
you take that HTML and you put it somewhere on the page. So maybe you swap the current buttons that you just clicked with,
with the HTML that was returned, or maybe you take it and you put it like at the end of another element. You can, you can, you can, you can,
you can, you can, you can, you can, you can, you can pre-pen stuff. You can replace entire elements. You can replace the internals of elements. And that little pattern is actually really, really powerful. And you can tie into all sorts of different events. So there's like interacting with individual elements, like a click or a form submission.
You can say like on load or like on scroll or all sorts of different things. So, so events. Yeah.
Absolutely. So one of the motivations that Carl Carson Gross puts there is why should a and form only be able to make HTTP requests? Why should you only be able to click and have click and submit events, trigger them, right? And all these things, you know,
So it's kind of like just extending some of these niche features. Like you can click a button, but not an image in HTML to, to all the pieces. And then like you said, exchanging fragments of HTML, right? Like just instead of sending JSON back and then having the client side, turn that into HTML, just do it on the server and stick it where it goes. Right. Basically that's it.
Basically that's it.
It's, it's dead simple to code as well, which is, which is fantastic. So it's a simple, you're just server side rendering some HTML like we used to a long time ago. So it feels, it feels very familiar to people who got into web dev a long time ago. The code itself is very, very easy to write. Like initially you might like scratch your head. It's unfamiliar, but give yourself a couple of hours and it'll start to feel familiar. It's yeah. It's lovely to work in.
Yeah. I would also encourage people that want to get started with this and play with this. The examples that they have on the website are pretty comprehensive, right? If you scroll through, I don't know how many there are, maybe 20 or so.
Yeah. More than that. It's a lot.
Yeah. There's a lot of them here. And then, so if you go into each one of them, it'll show you basically some interesting things. So if you go to the first one, the click to edit, it says, here's a bit of static HTML, like a label and a div, and then a button that says click to edit.
And all it has is HX get, and it says edit this thing. Right. And when you go and click it, like there's a little example at the bottom, you click it. That's all fun. But if you open up the bottom, there's like a little history of interactions.
And like, I don't know what you call it, but like a web history that shows what's transferred. So when you, you click edit, here's what the response was. And it shows the HTML fragment, which in itself is a new HX has HX events. And then when it saves it, it goes back to the static and so on. And I think it's a really pretty easy way to get a sense for what it is. What do you think?
Yeah, yeah. Yeah, I think so. I think so. Those examples are great. I think like one thing that I like to do is use HTML and a thing called Alpine JS together.
So for me, HTML is great for when the data needs to be passed back and forth. But like for something like this, I'd probably use something like Alpine just to say like, show and hide, hide the form.
Yeah, it's also fantastic. So you don't like strictly need it, I suppose, but it does save on like some back and forth. And it does make things a little bit more like in one place, a little bit more like locality of behaviors, a useful thing.
So now we're looking at Alpine JS hello world. And this is cool because it also it's like HTML in that it just adds a couple of extra attributes to your HTML tags.
And the 80/20 of this is that you can define variables and those variables are like this, like a state, and they are defined within the scope of the place where you defined it.
So if you if you have like div x data equals open false and as a JSON object, then it's like within the scope of the stuff, we have this thing called open and its initial value is false.
And then you can do things like click on a button to to change open to true or to toggle to toggle open.
So you can have it like show form true or false. And then you can say then you can like say here it says span extra equals open.
So we only show that under certain circumstances. And you can also have like not open or you can have like it speaks JavaScript.
So you can do some interesting things in there as well.
Yeah, this is pretty interesting. This is yeah, this is something I have not really used, but I do hear Alpine and HTML X mentioned together frequently.
They do have a similar vibe.
Yeah, yeah, they do. They do. Yeah, I've enjoyed a lot. I tend to just use it for like small, simple things, but those small, simple things add up.
And so for example, if you have menus that open and close and things like that, you might you might want to use something like this.
Yeah, or event handling, like if you click this button, change the state to this and then it triggers the binding to open and close sections and so on. Yeah.
Yeah. Yeah. Okay. Interesting.
This portion of talk Python to me is brought to you by Posit, the makers of Shiny, formerly RStudio and especially Shiny for Python.
Let me ask you a question. Are you building awesome things? Of course you are. You're a developer or data scientist.
That's what we do. And you should check out Posit Connect. Posit Connect is a way for you to publish, share and deploy all the data products that you're building using Python.
People ask me the same question all the time. Michael, I have some cool data science project or notebook that I built.
How do I share it with my users, stakeholders, teammates? Do I need to learn FastAPI or Flask or maybe Vue or React.js?
React.js? Hold on now. Those are cool technologies and I'm sure you'd benefit from them, but maybe stay focused on the data project.
Let Posit Connect handle that side of things. With Posit Connect, you can rapidly and securely deploy the things you build in Python.
Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quarto, ports, dashboards and APIs. Posit Connect supports all of them.
And Posit Connect comes with all the bells and whistles to satisfy IT and other enterprise requirements.
Make deployment the easiest step in your workflow with Posit Connect.
For a limited time, you can try Posit Connect for free for three months by going to talkpython.fm/posit.
That's talkpython.fm/posit. The link is in your podcast player show notes.
Thank you to the team at Posit for supporting Talk Python.
One example that I can give from over that stuff that I'm working on is I'm definitely using HTMLX over at Talk Python Training, right, for our courses.
And I added this little tag cloud.
It's not quite a cloud, but a bunch of different things you can explore.
So when you load this page, actually, one of the things that's really challenging is it has the price in your local currency.
So it figures out where your IP, where you live.
And that currency, the prices of those things, you know, outside of the US change a lot.
And it's super, sometimes it can be really slow to figure out what the price of every course is, if there's sales and you're in this country and that applies in this way.
So all these prices are all calculated with HTMLX.
So it loads normally without the prices, then probably by the time you get to it, the prices are already there automatically.
And then as you click around, you get this is all like as you click these little tags up here, you can even click on the HTMLX tag and see you have three HTMLX courses, right, with last Django and one that's just kind of uses it.
But all of this stuff, this is no JavaScript on this page, at least not doing any of that is all just HTMLX, right?
Yeah, that's great.
Beautifully good. It's so good.
I've certainly enjoyed working with it.
But let's talk a bit about your right of like, let's talk about, you know, spend the rest of time on your story, how you started using HTMLX.
I mean, you've given us some of the sense, but let's talk about the app that you were building, right?
You had this team of fairly junior developers.
What's the story?
At the time I was working for a nonprofit training provider in South Africa.
And we used to have everybody on premises in this place called JP's town, which is really a dodgy place.
And it was great.
It was, it was a lot of fun.
But then COVID happened.
And so we had to figure out how to support everybody remotely.
And so it built an LMS.
So initially we like looked around that LMS means learner management system.
We had a whole lot of learners.
We had, I think there were about 150 at the time.
And we needed to figure out like how to support them from home.
We couldn't just be like, come back next year because the like, partially we couldn't let them down.
Partially the funding model wouldn't work and all sorts of things.
So we need, it was an insane time.
It's kind of normalized in our history because it's, we've moved past it, but we got to remember that's an, that was a disturbing time.
So many people have horror stories from, from then I was like, this was hard.
It was like super, super stressful, but in the end we ended up with this cool thing.
So like a lot of LMSs exist.
You can get one off the shelf and they're a lot like very clever textbooks that track learners over time.
But for us, we're training, we are training software developers.
And so we wanted something more than a textbook.
We wanted to train professionals.
And so we ended up building this thing from the learners perspective.
It was a Kanban board and then they could move cards around on the board to do different things.
They could like start a project and then we'd create a repo for them and make, add them as a collaborator and protect the main branch and all of that good stuff.
And then we could get them to review each other and could track all that and display it in the front end.
Right.
Try to teach them get in GitHub and PRs and all that.
Yeah.
So the time they got to work, like they're always very nervous getting into their first job.
And then they'd say like, this is familiar.
Like we know how this, and that was really, really cool.
I'm teaching people stuff here actually.
That's weird.
Yeah.
It was great.
Exactly.
That's cool.
Yeah.
So I built this thing out and managed to keep training the people and it worked.
then it was like, okay, this thing is pretty rough around the edges because we built it in self-defense.
And we're like, I hope this works.
So we needed to, to build more on it.
And we were hiring a lot of junior developers because we were training like very, very beginner stuff.
So if you want to teach a person what a return statement is or what a loop is or anything like that, then you don't need a senior developer or like a senior lecturer.
You need somebody who understands what a loop is and what a, what a return statement is.
So we had like all these juniors running around, like helping out and they needed to build stuff with their own growth as well.
And their own, like if they don't build stuff and they, and then built and it's sad.
So, so yeah, they were trying to get them productive on the stack, but it was very, very difficult.
So for me, I'd been working on react applications and I've been working on Django.
And so for me, it was fine.
I could just like, I could keep the whole thing in my head, but yeah, it was just, it was just really tough for them.
Um, I think there is a little bit of an art to making a junior developer productive, but like, I just was not figuring it out.
So I tried this for a while and then one day went to a Django con us and I saw Chris May's talk that spoke about HTMX.
And I was just like, maybe this is worth a try.
Um, I was like, okay, I'm just going to proof of concept it and see if I can build the weirdest parts of our application in HTMX.
If you're asking, will it work?
You're like, this is the most crazy interactive bit.
And if it can do this, the other stuff is easy.
Like switching from logged in to log out or whatever.
I was like, yeah, okay, that's nothing.
Right.
Most of our functionality was around this Kanban board.
So I was like, all right, let me just make some cards and make some columns and see if I can shift stuff around.
And it all worked out really well.
And it wasn't, it wasn't super hard.
Like I think one of the, one of the challenges with HTMX is that it's very easy to build like spaghetti templates.
Cause you have like the main template and all these partials and you need to, and then all these URLs that are pointing to the partial.
So it's, so it is possible to get yourself in a bit of a tangle there.
So you need to arrange things nicely.
But yeah, the process was so smooth that I was like, let me try this.
So our application was this Django app on the back, exposing a bunch of APIs with Django REST framework.
And so the idea was to just, instead of like, we'd, we'd leave the react app as is, and we'd keep on working.
Meanwhile, we'd, we just build out some like perfectly normal Django views to do the HTMX stuff.
And then we could move everybody over to the new, the new application.
So the new front end was part of the original Django app.
So we didn't, we didn't rebuild absolutely everything.
We just rebuilt that part.
And generally speaking, if somebody suggests rebuilding a thing, I worry.
Like usually it's a bad idea.
Usually it's like, yeah, a fool or something.
Yes.
I've had to stop myself many times.
Do you know that David, Dylan BD it is?
Yeah.
I'll put a link in here.
He's got some, some amazing parodies and one's it's a six and a half minute parody of American Pie.
We're going to do the big rewrite.
And it's, it's glorious.
So I'll link it, but you should be afraid, right?
This is something that like, we're going to rewrite it.
And basically the song is here's the eight version, the eight different languages.
This thing's previously been written in, you know, it's with some things working times, even if it's not perfect.
You just.
Yeah.
And it was also like rewriting it in order to optimize for this team that was mostly juniors.
And so I was like, is this like, is this me being crazy?
Like there was a lot of, yeah, I was, I was very unsure.
So I tried everything out and, and it worked and it was fun.
And it was like, like straightforward to write for this like small thing.
And then I was like, let me see how the team works on this.
So I gave them a bunch of little tasks to do.
I was like, implement this, try that.
And everybody was productive.
How did they receive it?
When you, when you introduced this idea to them after they'd been living in react and redux and all these things.
They were happy with it.
I think at first a little bit skeptical, but then once I started going, like I did get feedback from them.
I make a point of getting feedback from them.
And they were like, this HTMX thing is way better.
So that's great.
Like, wait, what's the trick?
Why does this work?
So they went with it, but, and then they succeeded and they were happy and productive, which is great.
And like, even people who needed like way too much of my support, like people who I had to like really sit with and pair with, like just to do like anything.
They were suddenly able to do stuff that was meaningful.
So I think for me, that's one of the things that's so exciting about HTMX.
It's like, I've been working and training for so long and I've been like fighting the fight of like getting junior developers job ready for so long that like I'm, I'm aware of many problems in the tech education ecosystem and the junior hiring ecosystem.
And like the fact that entry level positions are like too hard for people, like it's a problem.
And now we have tools that make web developments approachable again.
So like I'm singing this HTMX song because I think it's going to change the industry in, in some pretty big ways.
I think it's already making waves, but I'd like them to happen faster and bigger.
Yeah, I think it will as well.
And, you know, I think the current web frameworks are really good and work really well with it.
But I wonder if I wouldn't be surprised to see kind of like FastAPI came along and just said Pydantic is the essence of this thing.
And Pydantic changed a lot of data exchange, a lot of data validation.
And I wonder if some framework comes along and just says HTMX is just ground up part of this thing.
All right.
That'd be interesting to see what that looks like.
That would be interesting.
I think there are definitely useful patterns and how to, how to do different things.
And people are building tools around it or tools that complements it in useful ways.
So we spoke about Alpine JS.
There's another thing called template partials from Carlton Gibson.
And he, and that's really, really great.
Something like this is super needed to make the code go from like, all right, we can do this too.
Oh, that's nice.
Yeah.
This really unspaghetti fires it, which is fantastic.
Like this is one of my favorites at the moment.
I have one that I created for a Jinja card Jinja, Jinja, Jinja partials, and also a chameleon one.
So since I'm, I wasn't using for that, that course example, this is actually chameleon.
So I use the chameleon partials, but something like this is required and you know, Carlton does great work, right?
Yeah.
Known for it.
So you're using this as part of, as part of your, your site.
So not that original site.
I only heard about this later on, but now I use it on everything.
Yeah.
On all of my HTMX things.
I use this.
Right.
Tell the Django people, what does this do?
Like why, why do you need Django template partial?
Django template partials instead of just Django templates.
So it's just about organizing your code in a way that's a bit cleaner.
So if you think about how you would render templates from your different views, if you had like a main page and then that page had a bunch of HTMX things happening that, that made calls to the back end to different views.
And those different views.
And those different views use different templates.
Then even though that all those templates are associated with the same page, it kind of ends up being a bit of a mess.
You've got like a lot of different, like partial templates.
So you need a cool naming convention for that.
So you need to see the pages as a template.
But you need to switch between files all the time to see what things are associated with each other.
Let's say you've got like five pages and each of them have like five different partials associated with them.
Suddenly it's a lot of files and you need to organize things somehow.
So what Django template partials does is it allows you to like, like, say you've got like a main page file to do list, right?
Right. You could define a partial template for a to do item within that same file and it won't get rendered until you say render this thing.
So you can like when you render your template for the first time, you can just say, OK, loop over the to do items and use this partial in place and render the things.
And that's great.
But then the other thing that you can do is that you can like in a view, you can choose to render a template, but you can choose to render a partial within that template as well.
And so let's say you've got like a little form that says add a new to do list item.
Then you'd submit that form and then the view would look for the partial within the page that you care about and it'll render that.
And so it just ends up being that like everything is tidy and together and it makes sense because like the to do list items are only used in this page and those items are only used in that page.
One of the big challenges that you'll quickly run into with this style, this HTML partial exchange style is when you show the page originally, you want just the server rendered version, which includes, let's say, your to do items.
So you need the HTML for the to do items in the main page.
But then when you make changes to it, you need a little fragment of that same HTML to put a new to do item in there or to edit one or something.
And if you're not careful, well, then you have multiple copies of those laying around and somebody updates the design for one and then it doesn't update the partial one that you wrote, which is a copy.
It's it's not pretty.
So finding a way for reuse like this Django templates partials, it's pretty required, I think, if you're going to stay sane.
It's like functions are required to write code.
You know, it's it's pretty much like that. Right.
I think so. Like you can get away with just using like lots of files and you could keep things dry with lots of files, but it gets like it's very spaghetti unless you're you put a lot of effort into organizing it and then keeping it organized because people make PRs do like all weird things.
So, yeah, it's it's not good to have to like monitor that everything's organized.
It would be better if it was just there done by default, like the next to the behavior is correct.
Yeah. Yeah.
So to grab grab a file, a library for that.
This portion of talk Python to me is brought to you by Bluehost.
Got ideas, but no idea how to build a website.
Get Bluehost with their AI design tool.
You can quickly generate a high quality, fast loading WordPress site instantly.
Once you've nailed the look, just hit enter and your site goes live.
It's really that simple.
And it doesn't matter whether you're a hobbyist, entrepreneur or just starting your side hustle.
Bluehost has you covered with built in marketing and e-commerce tools to help you grow and scale your website for the long haul.
Since you're listening to my show, you probably know Python, but sometimes it's better to focus on what you're creating rather than a custom built website and add another month till you launch your idea.
When you upgrade to Bluehost cloud, you get a hundred percent of time and 24 seven support to ensure your site stays online through heavy traffic.
Bluehost really makes building your dream website easier than ever.
So what's stopping you?
You've already got the vision.
Make it real.
Visit talkpython.fm/bluehost right now and get started today.
And thank you to Bluehost for supporting the show.
Let's talk about the before and after stack.
So before you talked about react, but tell us all the pieces involved and then what does it look like today?
So Redux was for just state management.
And then I used Redux saga for mostly for data fetching stuff so that I could handle like loading spinners and I could see like different, like the status of different requests over time and that kind of thing.
Then I used material UI because my front end make pretty skills aren't the strongest.
So I wanted a component library that would just work and that was the chosen one.
Then on the back end, it was Django.
Django REST framework is fairly well known.
Then I used a thing called Django Guardian because I needed object level permissions on the different model instances.
So for example, so we had this Kanban board and there were cards on this board that the people could move around and different people would have different permission to different cards.
So we had things like one learner would be working on a card and then they'd ask for a review and then another learner should be able to review that.
But we wouldn't want to let just any learner look at their code because then it would cause all sorts of problems.
So it's like, okay, this person has finished this project so we can add them as a reviewer on this card.
And so we needed to be like pretty particular about like which of our users could see different things.
It wasn't super straight, obvious, straightforward and that this person can see this.
It was like this person can for these reasons.
Django Guardian is really, really cool.
And then Postgres.
That's a cool library.
You know, maybe people could find a nice use for that one.
Like that's, that's the one that's new to me.
Yeah.
That's really nice.
And you can even do things like when you query a database and you say, fetch me all the cards, you can do something like,
fetch me all the cards that Bob can see.
And so long as it's configured well, then, then it can do that sort of thing, which is very, very helpful.
Wow.
That's really cool.
So you don't have to go get all the cards and then, yeah.
Yeah.
Who have all these different permissions and then like construct some query that comes up with it.
Yeah.
Very nice.
I love it.
And that plugs into DRF as well.
So like your, your serializer or your view set.
So I haven't worked in it in a while, but the query that's a lot of data.
But the query that gets, gets used when you access like a list API endpoint, you could just apply that automatically as well.
So if you, so you don't need to, yeah, you don't need to build it in that, in that case either.
So it plugs into all of the things.
It's a little bit weird at first to get used to.
And then, and then it's just fantastic.
And now I'm guessing much of the front end stuff is probably not there.
The old application still exists, but it's not, but it's like the HTML based version would just be a drop in replacement.
So I go to this URL instead kind of thing.
Yeah.
Now that it's done.
You said you used to work there, but you don't work there anymore.
Is that right?
Oh yeah.
Not anymore.
As of a few months ago.
I guess that's recent enough to say sort of, how is it going now?
Right?
How are, how's it being used?
How are people, you know, is it still going strong as the technology?
I hope that they're still building on it.
There was some, some weird things happening at the organization before I left.
So yeah, I expect, I hope that everything is still going smoothly, but I haven't been plugged in for a while.
Let's give a, maybe a quick shout out to this video, this other Django con talk.
Gosh, why is, I need to sign into my YouTube premium on this browser, but this real world SaaS product example from this guy in France, David Gilead.
Yeah.
That, that one you said was a pretty good example.
If you need like a walkthrough case.
Yeah.
So that one, I didn't see it live.
I saw a video of it after the fact, but it is like the ultimate HTMLX demo.
It shows, this guy really makes it dance.
It's, it's quite an amazing thing to see.
So highly recommend that.
Yeah.
This guy, David goes through and says, you know, here's our complex SaaS product and let me walk you through all the features.
I feel like this would be a pretty good one.
Everyone, your article as well.
And then this video, if, if you want to say, make a case to your team, like, Hey everyone, can we consider doing this?
And yeah, I'm sure right off the bat, you'll get some folks.
So, well, no, we have to use react.
We have to use this.
It's interactive.
This, you interact with that part and it changes that part.
How are we going to possibly pull that off?
It's like, yeah, no, that's, that's totally possible.
Yeah.
I think the main arguments people have against it are like scale, but that argument doesn't make super, a lot of sense to me.
I think it might be complexity scale that they're concerned about, but I think things like template partials solve a lot of that problem.
And then there's, can it do the things?
And this solves that problem.
And then is it really, is it really so much better for the team?
Is the other question?
Is it just another fashion?
Is it just another fad?
And that's something that's sometimes hard to get across.
I think that my article will do a good job of explaining why it's a good idea.
Cause I had to explain this to non-technical stakeholders.
I was like, okay, I I'm making this crazy decision and this is why.
And so I think I've got the argument down.
Go, go read that article if you need to convince someone.
But I think the other thing to mention is the, the full stack that I moved to in the end.
Yeah.
So HTMX we spoke about Django.
We spoke about an Alpine.
We spoke about now, if you are running a.
A react front end or whatever you would test the front end in a react way.
Like you would use tools that are appropriate for that.
So, and so you need to think about different ways to, to test things.
Would that be like Selenium or something?
Or what are we talking?
So I like play, right?
Quite a lot.
So you could do it with, but that would be a, like, it would include some pain.
Playwright is very, very lovely to, to work with.
So it's like Selenium only with all sorts of useful test goodies built in.
So like you can get it to take videos of your failed tests and it's got useful flags for like running your tests on different browsers.
And you can like keep a trace of things.
It's got interesting debugging stuff built in and you can just run it with pytest.
And so yeah, playwright is a big part of it as well.
Yeah, playwright is really nice.
You know, one thing that just occurred to me around the testing, if you've got a rich JavaScript front end sort of thing, you have to use something like playwright or Selenium where it does a full browser request render of the page to interact with it.
Right.
And you can also do that with HTMLX.
But a lot of these web frameworks, you can just in your, your web test code, you can say, create like a, a testing instance of my server.
Right.
And then make it do this request and then see what the response came back without nearly the same overhead.
And because this stuff all happens on the server, I guess you could just write a unit test, like a web test against a fragment response.
Right.
Yeah, you can.
So you can, you can write little unit tests that check different things like that.
But since a lot of the interactivity is defined within the HTML tags, your unit tests won't, they won't be able to cover like if the unit fix this and that happens.
And so that's where, that's where something like playwright will come in.
Yeah.
You'll still need that to, but maybe less playwright is needed than otherwise is what I was thinking.
Yeah, definitely.
I think one of the, the anti patterns I've seen is too much playwright where they're just like, want to use playwright for everything.
And then your tests are ridiculously slow.
And it's like, you could have just, you don't even need to test the view.
There was this function that you wanted to test.
Exactly.
You're not Shakespeare.
You don't need that much playwright.
Come on.
Yeah.
Playwright is a cool thing.
I definitely recommend it.
Yeah.
And it plugs into Django really smoothly as well.
So you don't actually, so playwright, it spins up a browser and points it at a running instance of an application in order to like test the things.
But with Django and pytest, you can use a fixture to spin up like test version of your, of your application.
It's kind of like run servers running there in your tests anyway.
So it integrates very, very smoothly.
Yeah.
It makes it very convenient.
Yeah, absolutely.
You know, one of the things you wrote a lot about, and you, you mentioned this, but you kind of flew past it a little bit was you said, am I crazy for optimizing for junior developers?
Right.
On the other hand, optimizing for simplicity, even if you're, you're an expert, right?
You don't, just cause you can do all the steps and all the complexity doesn't mean you should constantly be doing those steps.
Right.
I think there's a case for optimizing for simplicity here.
What do you think?
I completely agree.
I mean, if you, if you can just like take the, the cognitive load of developing your app and then make it like simple.
So you can focus on actually solving problems instead of wiring, I suppose.
And life gets a lot, gets a lot easier.
So yeah, simplicity rocks.
It's, it's fast to develop, but things like, like HTMLX make your code way, way smaller than, than it would otherwise be.
So it's not just simple.
It's not just that it's less convoluted.
There's also less of it.
And so there's less to test.
There's, there's less stuff that can, can cause bugs.
And most of the like front end interactivity is handled by another library that's really well tested.
And you're just doing these like tiny little things that are easy to reason about.
And so it's just, it's robust and clean.
So yeah, I do think it's worth optimizing for simplicity.
I mean, it made, it made everybody more productive, the juniors and me as well.
So top notch.
I'm constantly in pursuit of, of trying to keep things simple.
You know, if you go over to the HTMX site, I don't know if you've, you've looked at this section, but they've got a, you know, Kirsten has this essay section, which, you know, it's not quite a blog, but it's kind of a blog.
You know, it does, it's not, not in order.
It's in sort of category, whatever.
And these are all nice.
One thing that's nice is he has a, on the other hand, here's a couple of examples why people didn't pick it.
Right.
But he's got a whole section on complexity.
Very, very bad.
Yeah.
But if you keep going, there's a bunch of memes.
The memes are so good, aren't they?
They are fantastic.
And one of these super definitely applies is, you know, there's one that says HTML plus a backend for like the, you know, it's got this bell curve for the beginners.
Like, Oh, this is what I want that as you get a little bit better.
You're like, Oh, I need all this, all this complexity and all these layers.
And then, you know, sort of the, the Jedi Knight at the end is yeah.
HTML in the backend.
I have going, going through this path and like, you don't waste any.
These two ends.
Yeah.
I don't necessarily want to characterize beginners.
It looked like this, this character in this meme, but you know, I think the meme still speaks, speaks to this somewhat.
Right.
Yeah.
Definitely.
Yeah.
I think it's about like when I, when I teach people to code, when I teach people like the very basics of code and like something I see with very junior developers is that they try to show off and be like, look how fancy I can make my code.
I can do all of these complicated things.
And then you get them to think more like Jedi's and say, like, don't waste any moves.
Like, like how you wouldn't be flailing about like, this is kind of like flailing.
And HTML, HTML, HTML does that for you.
It just lets you like move directly towards your goal instead of having to like move around it.
Yeah.
It's pretty glorious.
So I know that you do a lot of teaching.
Maybe, you said you work for this local company that was, you did the come on board out for and so on.
Now, what are you up to?
I'm teaching just differently.
It was really cool working there.
I was there for a long time, like five years in total, which is really long.
And it was super successful.
So like since 2020, basically everybody who passed our courses ended up getting good jobs, like very, very close to a hundred percent of the people who passed.
And the people who didn't pass was like actually kind of small, like 7%.
And then there's lots of reasons for that.
But yeah, I learned a ton from being there.
That was in person, but pre COVID, right?
Yeah.
So post COVID, we actually got way, way better because we had better monitoring of individuals and we could do things like track people's cards on their board, moving around.
And then from that, you can say like, Oh, this piece of content is dodgy.
Like it would give us as educators, a lot of feedback about what we were doing.
Cause if a person was stuck and you're like, I explained this thing.
Great.
And then they're still stuck.
You're like, I didn't explain this thing.
Great.
Like the way that the teaching mechanism was built was like really good for the students.
But like, if, if we as educators didn't do a good job on something, we'd know about it and we'd have to fix it.
And I think that's honed the craft quite a lot.
So I learned a bunch there.
Now what I'm doing is I want to spread those skills in different ways.
So there's a whole lot to what I'm doing.
One thing I want to do is help educators themselves.
So I've got this thing called the guild of educators, cause I always wanted to guilt.
And, it's got a whole lot of people in there who are like, it's a free community.
Come and join.
It's a bunch of education nerds who, who talk about education with each other.
It's a support structure because I think educators need support structures and it's a place to share, share learnings and share resources and opportunities and things like that.
So it's still very new, but that's one part of it.
Um, I want to offer teacher training and things like that, but I also just like,
Just like, we have junior developers.
You have people got to start somewhere with teaching and teaching online.
It's different.
All that.
It's hard because they aren't really good resources for tech educators.
There's like, if you dig into the literature on how learning works and how teaching works, it's like, it's all either very academic.
And so it's a little bit hard to pass and it's not like, it's just not packaged well for the people who need it or it's packaged in the wrong way.
So I came across a code school recently who I was like, how do you handle your teacher training?
And they're like, we outsource it to these guys.
And they showed me this other organization that does teacher training.
And it's like, I dug through their courses and one of their selling point points was like our teacher training courses are so versatile that they can be used for florists and personal trainers.
So I was like, yeah, maybe not appropriate for, for what we're up to here, but that's what people are relying on.
And that's like the best that the industry has to offer.
So I think there's a big hole in the education space and I want to want to work to fill that.
Yeah. So that's part of what I'm doing.
And the other part is offering technical training.
And this is partially because you've got to like practice the craft partially because I want to create opportunities for educators to get good partially because I like really like teaching the stuff.
So there's all different reasons why I'm teaching.
So right now I'm building out a bunch of small workshops that cover different skills and are fairly standalone.
And those are Lego blocks that will combine into something much bigger in the future.
But for now, the first workshop that I have on offer is all about Django and HTMLX.
So it's pretty exciting.
So it talks about the stack that we just spoke about.
We didn't mention Tailwind, but Tailwind is great as well.
It means that I can make front ends that look reasonable.
That's right.
You said you had used material UI previously to make it goodish.
And Tailwind is what used in the new version.
Yeah, I'm really enjoying Tailwind.
Yeah.
So the idea with this little workshop, I ran it as part of DjangoCon US recently.
It was super cool.
I got, I don't know, there were way too many people there, which was great.
But also it was a lot of problems resolved.
It was like, whoa, all of you.
That was super cool and went really well.
The basic idea is that I want to show how to build a crowd application using the stack of tools in a way that sets people up to be able to build their own stuff.
And part of the workshop is, in fact, taking these tools and building your own thing.
So for people who are kind of early on their career, in their career, they can get some, like the starts of decent portfolio projects out of it.
People built all sorts of interesting things.
The one person built their own personal learner management system for like their own learning, which was really lovely.
Somebody built a music store.
Somebody else built a, what was it, like a chore manager for their family so that they don't fight so much.
It was great.
Oh, that's interesting.
Yeah.
And all with Django, HTMLX and Alpine JS and the others.
And the other thing that's cool about this is it's a CRUD application.
I'm teaching people the bits and pieces that build a CRUD app.
And like most of the internet is CRUD applications because it's for the audience.
Like if anybody hasn't heard of CRUD, it's create, read, update, delete.
Like that's most of what you need to do on the internet.
And so if you get the patterns down for like a simple CRUD app, then you can do some pretty hardcore things with it.
So yeah, this is, so it's covering that.
The workshop is small.
So it's like, I'm, I'm keeping things very, very small intention intentionally because I believe in the power of teachers.
And I want to make sure that everybody gets attention and then gets the support that they need.
And also because of the people who tend to come to these kinds of things have different backgrounds.
So some people need help here.
Some people need help there.
And so you need to keep like a good ratio of teachers to students.
So yeah, expert led, high support, small group, all of that good stuff.
Quite exciting.
That's very cool.
I'll link to this workshop in the show notes.
People want to check it out.
And it's out of time, but it's remote.
So people can attend from wherever, right?
You don't have to be near you.
Yeah.
So you don't need to be in South Africa.
In fact, I made it in U.S. Eastern time because strangely enough, most of the people who read my blog are in the U.S.
So it's U.S. and South Africa and it shifts and changes around.
But part of the reason I'm marketing it to the U.S. is because I want to be able to fund training Africans.
And like there just isn't as much money on the side of the world.
So, yeah, I want to be able to make doing good in the tech education space into something that's financially sustainable.
So that's why the U.S. and that is why it's priced in dollars.
Yeah.
So you guys can have a discount code.
Talk Python.
Talk underscore Python.
I think that was the one I said.
Let me just share.
Yeah, I'll put it in show notes.
People can find it there.
Awesome.
So you'll get 10% off.
And then I also want to give like another 10% to something.
So Foxly wanted me to give 10% from their discount code to the DSF.
So that's another code that's out there.
So that's fantastic.
I've definitely benefited a lot from the DSF.
So that's really, really cool.
So since this is your podcast, should the further 10% go to the DSF or the PSF or the DjangoCon Africa event?
I vote DjangoCon Africa.
Fantastic.
I was hoping that you'd say that.
Yeah, I love DjangoCon Africa.
It's so freaking cool.
Speaking of a conference and talks and stuff, Kim out in the audience says, in a few weeks, a really good talk Sina gave at South Africa PyCon a few weeks ago should be online.
Power to the people who teach people to code.
So that's cool, right?
Yeah, that's cool, right?
Yeah, that's the longest title I've had for a talk ever.
Thanks, Kim.
Yeah, so I did that talk at PyCon South Africa and I also did it, I did a longer version of it at DjangoCon US as a keynote.
So I was super, super happy that I got that opportunity.
It's so cool.
But yeah, it just talks about kind of how I think about teaching and how I, that's how I think about teaching and the mechanisms that we set up.
So, so like, how does mastery based learning work and how do you actually get, how do you engineer a education system so that it sets people up for success and not like either frustration or boredom?
Because there's a lot of, a lot of things that are weird about the traditional systems.
Yeah, so it talks about that, but then it also shares a bunch of lessons for individual educators on the ground.
So that thing that I was talking about earlier about how we as educators in the system were getting like a ton of feedback about our own, the quality of our work that gave us space to, to figure out a lot of like hard hitting things.
So it's, it's kind of the 80, 20 of what teachers or would be teachers should, should focus on.
And I think it's powerful because a lot of like everybody teaches.
I mean, you teach people, teach new team members.
Like there's a lot of volunteer teachers as well, which is great.
I mean, there's stuff like, I think we, I think doing this kind of these presentations, this, this kind of teaching is a super cheat code for leveling up your own skills.
Yeah, definitely.
There's this thing called protege effect, which is a well studied thing.
So when people say teaching is a great way to learn, it's, they're not just being squishy.
Like it's legit.
It's really, really legit.
And there's, there are a lot of mechanisms behind it.
It's like one of the simple ones is that teaching is spaced repetition and recall.
And that helps you remember your stuff.
Another one is like, people will ask you weird questions that you wouldn't expect.
And so you look at your own knowledge from a different direction and you build better mental frameworks or more robust mental frameworks.
Like some people are good at building mental frameworks and some people aren't as good.
And a good way to like get a person to build good mental frameworks is to ask them weird, like left side questions about the stuff they know and get them to look at things from different angles.
And then you get that from, from the people you're teaching.
It's yeah, it's really, it's a beautiful thing.
Yeah, it really is.
It definitely rounds out your knowledge and makes you think deeply about some of these ideas that you just maybe glossed over.
Yeah.
This is probably a good place to leave it.
Let's, I want to give out one more resource real quick for people is just awesome.
HTMLX over on GitHub.
I don't know if you poked around this, but it's got many, many examples of tools and libraries for HTMLX and Python, but also in a ton of other languages.
So that's super cool.
Apparently there's a flashtmxtailwind one and one for sockets or maybe HTMLX over web sockets.
I don't know.
These are all look pretty cool.
So people can check them out.
But yeah, and I definitely want to recommend people check out your essay and yeah, they can take these ideas and run with them.
Yeah.
Cool.
Well, Gina, thanks for being on the show.
It's been great to talk to you.
Yeah, it's been great to talk to you too.
This was a lot of fun.
It was.
Bye.
Cheers.
Thank you for 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.
This episode is sponsored by Posit Connect from the makers of Shiny.
Publish, share and deploy all of your data projects that you're creating using Python.
Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quarto, Reports, Dashboards and APIs.
Posit Connect supports all of them.
Try Posit Connect for free by going to talkpython.fm/posit.
P-O-S-I-T.
And this episode is brought to you by Bluehost.
Do you need a website fast?
Get Bluehost.
Their AI builds your WordPress site in minutes and their built-in tools optimize your growth.
Don't wait.
Visit talkpython.fm/bluehost to get started.
Want to 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 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.
We'll see you next time.
Bye.
you
Thank you.