Have you heard of Django? It's this little web framework that, well, kicked off much of Python's
significance in the web space back in 2005. And that makes Django officially an adult. That's
right, Django is now 18, and Django continues to lead the way on how communities should be done for
individual projects such as web frameworks. We have Carlton Gibson and Wilvison back on the show
this episode to discuss a bit of Django history, Django trends in 2023, a little bit of HTMX and
Django, and lots more. This is Talk Python to Me, episode 428, recorded July 26th, 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. Be careful with impersonating accounts on other instances. There are many.
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.com to get notified about upcoming shows and be part of that episode.
This episode is brought to you by Sentry and us over at Talk Python Training. Please check out what
we're both offering during our segments. It really helps support the show.
Will Carlton, welcome to Talk Python to Me. It's awesome to have you both back on the show.
Thank you for having us on again, Michael.
Yes, thank you. It's always fun.
It's always fun to have other podcasters on the show. We'll talk a bit about your podcast
in a moment. Maybe just do a quick introduction. I know people probably know you from your show,
Django Chat. They know you from being on Talk Python previously, but for those who don't. Will,
we'll go first.
Sure. So, William Vincent, I have three books on Django, most notably Django for Beginners.
I run a site, learndjango.com. I just got off three years being on the board of Django. So,
Django is run by a nonprofit. I run a weekly newsletter on Django, Django News. Too many things.
So, yeah, most of my time is spent doing some consulting and a lot of teaching and learning
about Django. So, I'm very happy to be at that stage.
It's a good combination, right?
If you can make it work, it is. Yeah, if you need that sort of cycle of,
you know, I need to learn too and be interested.
Yes.
I like learning and teaching.
One of the challenges that I think people can fall into on the traps is if you just teach,
it's hard to have that. It looks like a good idea, but let me tell you, it's a bad idea.
And here's the three reasons. And here are the tears that I've shed because I tried this way.
You need a little hands-on. Like for me, it's running all the infrastructure and APIs and mobile
app stuff at Talk Python, which is plenty to get the tears. I've pulled out plenty of hair, but you know,
like I think consulting plus teaching is a really common mix for that. You like it?
Yeah, I do. I mean, so I've been working on, so I have this site, learnjango.com that I'm trying to
consolidate everything onto that site. And so that's been an effort I've been working on in earnest the
last couple of months. And so it's actually been really fun to just be an engineer for a change.
And I kind of wish I could find a me to help me when I get stuck, but there is no being,
as Carlton will share something, you know, being stuck is part of the game, but it's, it's uniquely
satisfying and frustrating to code because everything is solvable. But I, you know, still,
I find things that stopped me for a couple of days and I'm just like, it brings me back to like the
first, you know, couple of months of coding and like the terror of like, I'm not smart enough. I can't do
this, but I know that I'll get it done and I do get it done. So you get the yin and yang, but it's
uniquely satisfying to do the commit and it's done, right? Whereas even, even a podcast,
it's in the bank, but it's not quite the same binary feeling of accomplishment.
That's true. The getting stuck is frustrating, but also it means you're about to level up,
right? You're going to figure out something. Yeah.
I try to be excited about it because I know if I'm stuck, then lots of other people are gonna be stuck
or a lot of times I'm stuck on one little thing. And it's really, cause there's some other thing I,
some fundamental that I didn't know as well as I thought I did. So we can talk about that,
but I have, I have thoughts on all of that. So yeah, it's a nice, it's a nice mix to do.
And more importantly, now I have friends and peers who, when I get stuck, I can ask them. So
Carlton, of course, is one of them, you know, Django, former Django fellow, a couple others.
It's important to, you know, we can talk about this, but when you're learning, learning how to ask a
good question on Stack Overflow or Django has its own forum, which is a great resource forum
that Django project.com, you know, but the next stage is like, I did a walk, I slept on it,
like knowing when to ping a friend, cause you don't want to ping a friend all the time,
but sometimes it's like, okay, like this is, I'm truly stuck. There's no point like wasting a week
or two on this. Yeah, for sure. That's a really nice stage to get to. And it's also helpful to help
other people too, cause you're thinking about something and someone gives you something they're
stuck on. You're like, Oh, boom, that's that. And then you're like, Hey, I'm working on, you know,
something that's stuck. So anyways, having a community is really, really levels you up too.
And also people who can relate to good and bad things about code. Django is very stable,
but has a host of new features, many of which I haven't actually used. Carlton can talk about them.
So it's important to have community, right? Not just be in your own room with your computer fighting
with it. Yeah. Yeah. Any trouble or good or bad thing you've had many, many other people have had,
you just have to find them. Unlike the movie stereotypes, it's, it's way more social,
this coding thing. It is before. Yeah. But before I let Carlton introduce himself,
just a quick comment from the audience to make you feel good a bit from Bishon, who says the first
book I read on Django was William's book. So thank you. Thank you. I appreciate that. Yeah. I just,
one last point and then I want Carlton to talk, but I wrote three books, Django for Beginners,
APIs, Professionals that first came out in 2018 and 19. And then I've updated all three of them every
year since then. So on the one hand, it's been four years. I haven't had a new book,
but it's also, I've written what? Or you've had 12 new books.
12 new books. Yeah. I mean, I really have. I really have. It's, it doesn't feel quite as
satisfying, but I know that I have a built-in audience and I've, so it's a weird dynamic to
be in a situation where it's sustainable to maintain and update your stuff. I mean, I'm sure you can relate.
You have all these different courses, right? That's the thing that falls off. You do the effort,
you get the course out and then it goes out of date or it could be made better, but-
Or Pydantic 2 comes out.
Django every eight months comes out. Yeah. So it's, yeah,
I try to think of the positive of it. It is, I feel like the book is so much better,
but a lay person or family members or friends are like, when's the new book coming out? It's like,
I just, I just did it. Like, yeah.
Yeah, indeed. Carlton.
Who are you, Carlton?
Welcome. Who are you?
Who am I? Well, my name's Carlton. I do a podcast with Will. So basically,
I've just stepped down as a Django fellow. So I've spent the last five years being a Django fellow,
which means I was contracted by the Django Software Foundation to help maintain Django itself. And they
have a couple of fellows and I was one of them for that period. And I've stepped down in order to go
back to building things with Django rather than working kind of just on Django. It's, so it's a kind of,
you know, after five years, that's, that was a good time period. And it's time for me to go back to building
things with Django. I've been using Django forever and I've, I'm a maintainer on a lot of projects in the
ecosystem. So I've worked on Django as framework, Django Filter, Django Crispy Form, Django Compressor,
Django AppCon. I've maintained the channels package. You know, I do quite a lot in that.
So your code runs on many, many servers, you should say.
More than like, I like to think about like, so one thing when I was a fellow, we were always, people always
give us a bit of grief about how conservative Django is. It's very stable and very, you know, we're very cautious
about making backwards incompatible changes. We try not to do that. We've got a solid deprecation policy,
got the long-term support policies. And then at DjangoCon last year, somebody read out the numbers,
the download numbers. It's not, you know, it's not necessarily the most downloaded package,
but it's millions, millions of downloads, millions of projects that are using it.
And you really can't break it. That's always really like humbling and really kind of,
yeah, actually all the work we put into making sure that the product is stable is, that's good work.
That's important work.
Yeah. Threads is using it, Carlton. You're helping out Mark Zuckerberg.
Yeah, yeah. Well, I'll be using a fork of it. We can get into that, but yeah.
I was looking at a comment on the forum. I got a little heart from somebody asked on the Django forum,
does Django scale or can I run it on lots of systems? And I'm like, well, you do know that Instagram was built on it.
You know, they're still using that core request response cycle.
And, you know, my comment was, you're not going to serve more traffic than Instagram.
So yes, Threads is built on that core request response, but it's still essentially Django.
Maybe not everyone is up on what Threads is. No, not a parallels programming thing, but a Twitter clone from Meta and Facebook, right?
Apparently so, yes.
We have an interview, maybe we can put in the show notes with Carl Mayer, who was original core Django developer who then went to Instagram.
So he spoke for an hour about, so initially it was just, it was pure Django.
And then as they scaled, they did things like they ripped out the ORM and they changed this and that, but there is still a core of it, the request response cycle that's in there.
That's another interesting thing is Django, when you get to massive, massive size, a lot of companies, you know, they have thousands of engineers, right?
We have, we Django has just the community. So as soon as you hop off the guardrails, then you're kind of on your own.
And that's sort of separate debate on whether it's worth or not, but you can, you can get quite large and it's interesting.
By contrast, like I believe Shopify is still on rails, I believe, or seem to have gone much longer.
Carlton, yeah, you have something to add?
Well, I don't think it's really, I mean, I know Instagram moved away from the ORM, but that was quite a long time ago.
If you look at octopus and kraken, they're still basically using something that's basically vanilla Django to do, you know, massive projects.
And so, you know, what it was back in, you know, 1.6, 1.7, 1.8, when Instagram were needing to pull away from what Django is, is a lot different from what Django is at 2.2, 3, 3, 4, now 4.2.
Going to be 5, yeah.
I wonder if they regret that. I wonder, not necessarily, maybe it was the right choice at the time, but do they kind of wish, like wish they had access.
If nothing else, to fork version 5 instead of version 1.6.
I wish they'd, I wish there'd been a bit more pushback on Django from thinking about, because what, what was it that caused them to change?
I think the move from it being able to root string names, strings as view names, like, and having to import the view itself.
And I think at that point, like, for Instagram to rewrite the whole stack, it was, it was too much.
And in the end, they kind of forked, but it would have been great if we could have kept them on board.
I think, yeah, for Instagram, they can, they can, it's, they got enough engineering chops, but it would have been much nicer for Django if we could have kept them on board, I think.
Well, maybe like a quick positive shout out for the whole meta as a larger organization.
They seem to be doing a lot for Python these days, you know.
For Python, yes.
They're really working a lot on, you know, Sam Gross's initiative on NoGill and the Faster Python and Cinder.
And, you know, all that probably does come out of some of the foundational stuff for Instagram and running Django there.
Yeah, and I think Carlton is still involved in very much in pushing Python forwards and, you know, what they're trying to do.
So, you know, all QDots do them.
It's, it's very easy to dog on the big corporation so they don't pay enough of that.
But it's important to recognize when they do contribute that, yes, actually, that's a good thing.
Yeah, there's plenty that need dogging on, like a lot.
Most.
We still have support for Oracle in Django, for example.
Interesting.
But Carlton, deployment, there's something else you're working on.
Well, yes.
I mean, so I've been, so one thing I wanted to quit or step down as fellow and get to work on is my button tool, which is my simple deployment tool.
So it's, it's quite vanilla.
It's old school.
It uses virtual private server.
It uses Ansible.
It's all on AWS.
And then I'm building UI and tooling on front of that.
Slightly delayed because I've had personal issues that have taken me up.
You know, my plan was sit down in April, get on with it.
My son's been ill for a while.
So that's, that's just on the back burner.
The priority with all of these things is look after yourself.
And in the situation we've been, I haven't had time to work on it particularly, but that will be the autumn now.
And that's, that's kind of, yeah, I've been talking about it for a while.
Time to actually ship it and have some capacity to ship it.
But can we, can we do, can we give it a, maybe it's different angle of pitch, which is that, so it's built on.
So deployment is trick.
We can talk about this, you know, going from local to production is hard.
And when, who do you use these days, right?
Like there's AWS, there's Azure, there's kind of Google.
There still is Heroku.
There's new entrants like Fly and some other ones.
But what do you really need?
Like if you're with Django, you want someone who knows Django, who just like puts a layer on top of someone that's not going away like AWS.
And essentially, as I understand it, Button is a Django fellow saying, here's, you have a Django app, you want to put it online.
Let me solve all the hard things, do all the hard work for you.
And it's a beautiful UI on something that's not going to change.
Yeah, here we go.
To have it.
Because all the, it's interesting.
I updated my books.
I updated away from Heroku to Fly for the new update because Heroku eliminated their free tier.
And I personally have really liked what Fly.io is doing, but it's hard to scale these companies.
Like it's not, it's non-trivial to build what they have.
And yet if you're AWS, right, all you're going to do is add, add, add, add features when big enterprise clients want things.
And so at some point it becomes unusable for a solo person or a small startup.
So I'm a fan of what Carlton's doing.
Yeah, you want something scary.
Just go to the AWS console dashboard.
Yeah, exactly.
You're like, well, where do I start?
What should I use?
There should be enough of a thing.
I have a Python web app or I have a JavaScript, whatever JavaScript people do, like a, you know, a Rails app.
Like I just want to get it up and have it not break.
But this came, so this, the idea for Button came out of exactly those, those kind of thoughts was every week on Django chat, we'd have someone come on and deployment would always come up.
And it would be like some elaborate story about what they're doing.
And it's like, well, actually, if you keep it simple and keep it neat, first of all, here's how I deploy and here's how I get my clients to deploy.
And this is how I deploy many projects over many years.
And it's continually evolving.
And then on the other hand, when you go to the AWS console, though, it's like this, ah, too much.
You don't need 58 services and every configuration option under the button, under the sun.
But it's nice to be able to break out of that, you know, if you do need to scale or you do need to do it.
So anyway, this is my, you know, project.
If it wasn't for life circumstances, I'd be slightly further along, but it's going to be the fall now.
It's going to be, you know, the shit's coming on nicely.
And the idea is a simple, a simple approach and with a nice UI on top of it that you can use.
Well, you definitely have our wishes for your son to get well soon.
So that's rough.
Yeah, that's rough when your kid is sick.
It's been a, yeah, it's been a full on year.
It's been ill over a year now and it's just ongoing.
And so, you know, that was another part of why I stepped down as fellow.
I needed to take a bit of time just for the family.
Absolutely.
I think back to the button for a second, btn.dev, by the way.
You can sign up for the mailing list or the alpha is available too.
Nice.
I'm constantly trying to push Carlton's stuff because he always downplays everything he's doing.
I'm like, come on, man.
Yeah, but I've got that natural developer shyness.
I have to wait.
I have to polish it and wait till it's perfect.
And he's British.
Yeah, and I'm British.
So I'm nice and reserved.
And anyway, Mike, were you going to make a question?
It's exciting.
And we were just talking about it.
We were just hyping people up about it.
How it's cool to have these huge deployments running tons of traffic, doing all sorts of
amazing things with like, yeah, we scaled our servers.
So we went from 500 to 300 with this trick.
Yes, that's a cool thing that pushes the envelope that makes a lot of stuff possible with frameworks
like Django and language like Python.
But on the other hand, most of us are not Instagram.
You're not Microsoft.
You're not Google.
You're not all these.
And having or let's say you're not Netflix.
I actually think that like what AWS console looks like has a lot to do with how Netflix
works, probably given how early adopters they were.
But I just think it's worth emphasizing.
Push button.
Get it running on a simple server.
Make it secure.
Keep it up.
You know, zero downtime deploy type stuff.
CICD, a push show brand.
All those types of things.
That's more than enough for most people, not just on your hobby projects, but on company
business.
Does your website get a thousand visitors a day?
It doesn't need five servers with failover and Kubernetes clusters and sharded databases.
And like it just doesn't.
Right.
And so having that option, something like button, it's pretty cool, I think.
Yeah, that's exactly it.
Like as you speak there, you're just singing to the choir for me.
It's like, you know, you can get a small box, get a slightly bigger box if you need to.
Get a slightly bigger box than that.
You can go get quite, you can get an awful lot of box for not very much money.
And then maybe two boxes.
Yeah, yeah, yeah, exactly.
But this, the kind of architecture I go for, you can scale to a very big site.
And I know in recent years, Stack Overflow moved to a, you know, much more modern and
fancy thing.
But for a long, long, long, long time, they were running on the same kind of big database,
couple of front end web servers, a load balancer, and nothing more than that.
And you're not going to serve more traffic than Stack Overflow ever.
Like nobody, not nobody, but basically nobody's going to serve.
More traffic than that.
So that's where I'm coming from.
And it's not for everybody.
And there's lots of people who've got opinions, but it's for people who haven't got an opinion.
It's like, if you don't know, if you don't know how to deploy and you don't really have,
if you're not already in the game, then well, this is how I do it.
And you can choose to do it the same way.
Sure.
I'm really excited about it.
And I have been talking about it for a long time and not having the capacity to work on it.
And now I, bar family situation, I have that capacity.
And so I'm looking forward to getting it out.
This portion of Talk Python to Me is brought to you by Sentry.
You know that Sentry captures the errors that would otherwise go unnoticed.
Of course, they have incredible support for basically any Python framework.
They have direct integrations with Flask, Django, FastAPI, and even things like AWS Lambda and Celery.
But did you know they also have native integrations with mobile app frameworks?
Whether you're building an Android or iOS app or both, you can gain complete visibility into your application's correctness,
both on the mobile side and server side.
We just completely rewrote Talk Python's mobile apps for taking our courses.
And we massively benefited from having Sentry integration right from the start.
We used Flutter for our native mobile framework.
And with Sentry, it was literally just two lines of code to start capturing errors as soon as they happen.
Of course, we don't love errors, but we do love making our users happy.
Solving problems as soon as possible with Sentry on the mobile Flutter code
and the Python server side code together made understanding error reports a breeze.
So whether you're building Python server side apps or mobile apps or both,
give Sentry a try to get a complete view of your app's correctness.
Thank you to Sentry for sponsoring the show and helping us ship more reliable mobile apps to all of you.
Well, I think it's more broadly, one of the things we're going to talk about is HTMX.
And I think there is these more iterative tools.
You don't need to jump to React if you just want a little thing.
You don't need to go Kubernetes.
I heard back in that was done.
It was just all APIs now.
Come on.
It's all front-end.
I put a toot up the other day that they convinced me otherwise meme.
Django is a front-end framework.
I'm busy writing an application.
I'm using HTMX.
I'm using Alpine.
I'm using Tailwind.
I'm doing it all in Django.
I'm doing it all in Django templates.
And it's like, you know, I'm hardly doing any of the exciting back-end stuff that we love Django for.
It's all front-end.
And it's just vanilla Django.
It is.
That's the thing that people who are learning, they're a full-stack developer and they're like,
APIs, I got to do it all.
And I mean, you must have this, Michael, with people.
You're students.
But I have this a lot of times.
People who are new say, oh, I want this and that functionality.
And I'm often like, don't go to APIs unless you need to.
Because if you're a professional Django developer on a team of more than 10 people, yeah, you're
going to write APIs because there will be front-end people who just do front-end.
But when it's just you.
And even if there's not front-end, there might be a mobile app.
That's our primary case of APIs.
Or you might have a public API for users or other companies to work with.
It doesn't have to be that you're not doing server-side.
But for a solo person or a small thing, don't just leap to it because it adds so much.
complexity.
Do you use Tornado or use an older Python thing?
Pyramid, okay.
I've considered switching to something like FastAPI or something like that.
But then I look and I'm like, you know, it's like a real thin layer over just what would
be the same anyway.
And scalability is totally good.
I mean, it works.
It works, too.
It'll run for months without me touching it.
The chances the website go down and it's not my fault because I deployed something is almost
zero.
Like really, really, really close to zero.
Either that or something's gone wrong in the data center.
But like the website itself.
And so, yeah, I chose that eight years ago and I'm still cruising with it.
It's great.
I had a client ask me about HA.
HA, sorry.
High availability.
One time they were like, oh, don't we need multiple servers and multiple this or another?
I'm like, well, how many nines do we need?
I don't know.
I can't remember the exact number now off the top of my head.
But you're already at three nines, even just deploying on the kind of worst setup in the
world.
Because the number of the amount of downtime you'll have will be sub few minutes because
and it will be exactly that.
You deployed something wrong and then you revert it.
Yeah, exactly.
Like, oh, my gosh, quick.
But we have I think people necessarily don't fully appreciate how much really high end technology
for so little money we have accessible to us with these cloud providers.
We have the best data centers in the world for ten dollars.
Right.
You know what I mean?
It's not like, well, these people like you have the same thing that Netflix is using.
And for a while, they're doing a third of the traffic of the Internet.
Yes.
Yeah, exactly.
So three nines gives you nine hours off a year and you won't even have nine hours off a year.
Like, yeah, that's highly unlikely.
Yeah.
You know, something goes down and you don't fix it.
But like it's literally if you deploy, you fix it quickly.
But you get that kind of uptime without having to have multiple availability zones and
all the failover and all the things that, you know, they like to sell.
Yeah.
And yet getting to that point for people who are new, just the act of local versus production
database stops people like every single person.
Right.
They build the site like it's a blog and then they deploy it and they're like, where's my
blog?
And it's like, oh, that database is different than this database.
Like, you know, after a while, I get used to the idea.
But it's like the code is there.
Why isn't the data there?
Right.
And then so it's just this scale of up to how many nines do you need.
But most people are focused on just put something up online and add continuous integration.
Like, I mean, really, what are the basics?
But they're not basic when you're doing it the first couple of times.
No, they're not basic.
They're not basic at all.
So having something that kind of automates that.
I think another thing is, you know, you have different team members or if you are an individual
developer, maybe getting something up on the web.
I know people I've spoken to about how daunting it is going from zero web apps published to
one is a major challenge.
Right.
Like, I don't know Linux.
I don't know the terminal.
I don't do SSH.
I don't understand the security.
I don't understand the best practices.
Like, I just can't, you know.
Well, and that's something I emphasize in my books is getting something as fast as possible.
It was a little bit smoother with Heroku than Fly, but Fly is still pretty.
Like, I take some shortcuts, but I say they're shortcuts.
You know, this isn't the most secure thing ever.
But just getting something up that first time because it doesn't have to be crazy complicated.
And I think the sooner you're dealing with a real live website, the better for many reasons.
But yeah, that first one.
You know, you've spent all this time building your application.
You're finally ready to put it online.
And then it's like, oh, learn about servers and learn about firewalls and learn about
rewrite rules and learn about permissions and groups and users and
Caching.
Yeah.
Well, I just say Django has a deployment checklist to help with this.
But I still think, and others may agree with me in the community, that the local to production
gap is a big one that Django could do things to address.
For example, like everything defaults to local setup.
The deployment checklist, yes, a great resource.
I spend a lot of time in my books covering this, if you want, you know, handholding.
Oh, and it's not just a checklist on the, like on the web that you look at.
You can run manage.py, you know, space check dash dash.
Yeah, it's a management command.
And there's a whole, I guess would be the, I think, 12 or something now, sort of the, like,
really don't launch it without this.
These aren't even optimizations.
This is like, just don't leak secrets everywhere.
Yeah.
But still for Django, I think for a lot of places, there's a tension, right?
Between how friendly you are to beginners versus advanced users.
And I think Django overall has done a very good job of still being friendly to beginners,
but every, most technologies over time, you know, move towards where the hardcore users
are because that's who's kind of doing this stuff.
So that's a tension Django feels, Python, others.
You know, how do you still keep it beginner friendly, but the people who are in charge want
different things often?
That's a real tension in programming and frameworks and all sorts of things.
And I also think that that's why Python is so popular, honestly, right?
You can do C++, you can do Rust.
Like, these are really great for advanced people.
You can do, you know, BB6 or super simple old school things that are great, easy for beginners.
But like, Python is easy for beginners, but you can kind of bring in some more advanced stuff.
You can bring in async.
You can bring in generators.
You can bring in ORMs, but you don't have to, where a lot of languages are like, guess
what?
We're going to start with a void voice, void star star.
We're going to go from there, you know?
Well, the old saying was second best for everything.
And I think that's not, you know, I think it's first best a number of places now too.
I agree.
I think people say that, but I think honestly, it's really, if it's not the first best,
it is on par with the other first best, right?
It is a front running contender for a thing where I would say it probably is, you know,
the undisputed king is in data science and machine learning.
Yeah, it's all the libraries.
There's not a competitor out there that is near the level of depth in the ecosystem.
Well, because there's R and R doesn't have open source in the community that Python does.
Yeah.
That seems to be, I mean, most like here in Boston, a lot of friends are scientists and
it's either R or Python and they all kind of want to use Python, but sometimes they use
R, but Python just can do more things.
So depending on what you need.
The next episode I'm going to release, which I've already recorded, but haven't released.
So you all don't know about it necessarily is shining for Python, which is pretty interesting.
Like that's the R web story coming to Python, which I think is just more cool stuff you can
do in Python, honestly.
Actually, I need to check the Python version of that.
Cause one of the, we just had DjangoCon Europe earlier this year.
And one of the people who came up to me is someone who worked for the, what do you say?
The UK government on their putting systems together.
And he had bought my books to get his team to move away.
Maybe started with double O or something or other.
I don't know.
No, not that cool.
You just COVID information, you know, health stuff, NH, NHIS.
Is that, is that, yeah.
Nathan Holt, NHS.
NHS.
They were able, so he had said though, that they were able to use R and use the, what
is it called?
The webby to put things online, but for interactivity, they, that's where they hit problems.
So he and his team of 12 had moved a lot of stuff over to Django for the, just more interactivity
of it all.
But this is, you know, something the British government was doing to, so I'm, yeah, it's an
area I want to learn more about, you know, shiny and how all that works, because it's always
been like, why can't you just take a Jupyter notebook and put it online?
I mean, you write, like often put it online.
So I'm trying to understand that too, because the data science space is so big in the web
space feels small in comparison, but yeah, I look forward to that episode.
My quick takeaway talking to Joe there was, they really thought about how to make it the
Pythonic way.
And it seems like they really embraced it and not just, well, we'll get it to run on Python,
but it seems like it's going to be a good option for people out there.
So that's really cool.
I want to make sure that we talk about some of the history of Django and the future of Django,
but I know something that all three of us are super excited about is HTML.
So let's, and we were talking about the front end stuff and the back end.
And so I don't typically share jokes on Talk Python that much.
It's more Python bites the show at the end there, but there's this great meme and it has
the backend dev and it has HTML two people on the HTML.
When speaking to the backend dev says, look at me, look at me.
HTML is talking to you.
This is full stack.
Now you're full stack.
Now, come on.
You're not just a backend developer.
You're full stack because you're doing HTMLX.
And I think, you know, it's funny.
Also the thing called X that is kind of Twitter and half X and partially branded that, that is
a whole different joke.
But I think just this, this joke up here, it really touches on, on something that I think
makes Django makes blast, make all the Python web frameworks way more holistic and important
back coming back to build these apps, right?
It's not just like, well, we have to use reacts or we're going to push you to just write JSON
and points and, and so on and so on.
And like, no, you can actually flip that and just embrace Python more with HTMLX.
Who wants to start riffing on HTMLX and Django?
Carlton, you go ahead.
This is more of your.
No, it's exactly that.
So, I mean, two years ago, three years ago, it was all like, oh, Python's existential threat
because everything's going to be rewritten in JavaScript because, you know, everything
on the front end is JavaScript.
And so it doesn't make sense having these two languages.
So it's all going to just flip over and Python's going to disappear in a puff of JavaScript.
Well, now it's kind of like, well, really?
Is that, is that what I see happening?
Not, no.
What I see is the super established mature web frameworks showing the real strength
of the, the HTML tooling and the hypermedia tooling that they've, you know, it's, it's,
it's just so fully developed.
I mean, Django is 18 years old this summer, right?
So there's a lot of history there.
There's a lot of development time gone in.
There's a lot of richness.
And once you start using HTMLX, it really is.
It's like, oh, do you know what?
This just fits the patterns that Django wants you to use.
You know, it, like it works with Django forms and you just, you know, oh, look, it's just
a form view.
And it's just, all I do is add this little header in and oh, look, I changed the template
maybe.
And oh, look, it's, it's a fully interactive, rich client that the users can't tell the difference
between that and a full SBA built with Rack.
Or perhaps they can because it loads quicker because it's not, it's actually faster.
And one of the great reasons for switching to SBAs was they were meant to be quicker.
But the reality is after all these years, they're loading so much JavaScript into the
page and doing so much work in the browser in order to get the, the, the HTML to be interactive
that in fact, they feel slower to the user.
So for people who don't know, HTMLX lets you put attributes on HTML, not complicated stuff.
Like if you had an image, you could say hx-get and give it a URL.
And you could say hx-target is some other thing.
So if you click on that image, it'll go, if this context talked Django, pull back a fragment
of HTML and pop it with possible animations and transitions and stuff into another section
for like a master detail, like list details, view story.
And it's just as nice as most single page app, most friend and frameworks.
It's, I suppose if the thing completely loaded all the different data and had zero server interaction,
but then the startup time of that would be completely bad, like you said, Carlton.
So it's fantastic.
And let's go back to like the, the beginner and the people doing simple stuff.
HTMLX is not just for beginners, but it really works well for them because they no longer have
to learn a different framework or never different language and a framework like JavaScript and
view.
They don't have to write APIs.
They just do the thing they're doing.
And all of a sudden all this cool interactivity comes in.
Right.
Yeah.
And like for a decade, it hasn't felt to me, you know, I'm 20 years in the business.
I know how to do quite a lot, but for a decade or so, it hasn't felt to me feasible to be building
web good, high quality, professional quality web applications, single-handed.
But it feels like that again.
It feels like, do you know what?
I don't need a whole team here.
And with interest rates going up and inflation going up, you know, money being tight now,
I honestly think there is a real big commercial competitive advantage coming back to sort of
the backend.
And that's not just Django, but Django and Flask and, you know, Rails even, if you want a different
language.
But those kind of stacks where you can produce a really competent crud backend in very little
time, and then you can produce the front end that's rich enough and feels good and feels
developed for a fraction of the team size.
One, two developers instead of five, 10 developers.
This portion of Talk Python to me is brought to you by us over at Talk Python Training.
Let me tell you about one of our really popular courses.
HTMX plus Flask, modern Python web apps hold the JavaScript.
HTMX is one of the hottest properties in web development today.
And for good reason.
You might even remember all the stuff we talked about with Carson Gross back on episode 321.
HTMX, along with the libraries and techniques we introduced in our new course, will have you
writing the best Python web apps you've ever written.
Clean, fast, and interactive, all without that front end overhead.
If you're a Python web developer that has wanted to build more dynamic, interactive apps, but
don't want to or can't write a significant portion of your app in rich front end JavaScript
frameworks, you'll absolutely love HTMX.
Check it out over at talkpython.fm/HTMX or just click the link in your podcast player show notes.
I think it also speaks to the wisdom, I would say, of, so Django has a templating language,
but it's deliberately basic.
You can use Jinja and Django by design because 18 years ago, the idea was, well, we're not a
front end framework.
Who knows what's going to happen?
And that provides the opportunity for HTMX comes along, just slide it right in.
Like Django is not, doesn't have all this stuff built on top of it trying to do that too.
So that can be a frustration for beginners that why doesn't, why don't the templates do more?
They actually do a lot, but it opens it up to HTMX.
And then there's, you know, Django has third party package systems.
So there's one that Adam Johnson, who's a member of the community has Django HTMX that has
extensions.
Like basically everything you want to do, you can kind of copy and paste it in.
I mean, understand what you're doing, but so this is, yeah, Django HTMX is a great resource,
but it's not, it's not rocket science.
It's not, you know, you're not reinventing the wheel, right?
You have a list view, detail view.
You want to do auto scroll.
You want to do some validation on a form.
It's the same solved problems out there.
You just have to know where to go.
You can go quite far with it.
Yeah.
That would be an interesting question of where do you really need to not use it?
I mean, certainly even in a team setting, like it's just such less complexity and it's arguably
faster and it gets you what you need.
Where do you not use it?
So I'm building a quite rich drag and drop interface for a tool.
It's pretty complex.
It's pretty interactive.
And I'm using Alpine to do that on the page.
And then, but when it comes back to the server request, then dropping back to HTMX to send
the things and get a chunk back.
And I can quite often replace either a part or all of the Alpine component with the stuff
from the HTMX.
So it's still using rich JavaScript in the client where you need it.
But you go an awful long way before you need that, you know, and you're dropping in forms
and you've got a nested list view and you're dropping, you're fetching that nested list view
and dropping that in place.
And that's in a modal, which is perhaps powered by Alpine.
And it looks rich and smooth and it's everything you want.
But the amount of code is very minimal.
It's progressive too, right?
I mean, Vue.js, when it first came on the scene, I forget if it's still doing this, but
like its whole thing was the progressive, you know, you don't need the full React bundle.
You can kind of ramp your way in.
And so I think there's just more ways to get from here to there.
And you don't have to just go to APIs and the full-blown thing.
And I have to admit, last week, or perhaps the week before, I was sitting there going,
I was doing everything at HTMX and I was like, I need a full page load here.
I need it to refresh the whole page.
How do I do that?
And I had to step away, go and get a coffee.
And as I was boiling the kettle, I was like, oh, I could just submit the form normally.
I'll fall back to just doing what the browser does by default.
Oh, yeah.
Okay.
You just always have to think if it's getting clever, like you're missing something.
Yeah.
No, it was exactly that.
It's like, I was so in the zone that I'd forgotten the base technology I was using.
I did a talk at PyBay Food Cart Edition a couple of years ago, and I was talking about
it on X, whatever that thing.
And we're going to have to figure this out.
That thing might be gone pretty soon, but we'll see.
Anyway, I was talking about it and I said, look, you can write these awesome web apps with
Python.
You don't have to use JavaScript and somebody's like, Michael, that's really insensitive.
People, you shouldn't be degrading the JavaScript developers and that's not the message.
It's the message that the language you choose, whatever it is, you can just embrace that and
do a lot more.
And the biggest example of that is that this is a popular framework in the node community,
right?
Which is JavaScript, right?
And the big value here is that you don't have to also have APIs.
You don't have to also have a front end and a back end framework in the context, right?
Like you guys probably know is teaching and help people deploy stuff.
It's like, well, there's what your front end can do.
And then there's the security of the browser and there's all the constraints of that.
And then your back end server, oh, it can talk to the database directly and it could do these
other things.
But with HTMX, like your front end code executes in the same context as your back end code.
So you don't have to have like two security models, two runtime models, two all these two
conceptual ways of like, well, what's happening here?
So that means this.
Like, no, it all happens in one place.
And that's even valuable if you were doing node in JavaScript.
Yeah, no, absolutely.
I think there's a, on the HTMX website, there's an awesome essay.
It could be the intercooler, but it talks about this impedance between the two sides.
And the example it gives is GraphQL, I think.
And the GraphQL gives amazing power onto the front end and you construct all these queries,
but are they safe?
And are they, who knows?
And what companies end up, often end up doing is whitelisting the query.
So it's in fact, you can't leverage the full expressive GraphQL in the client because it's
only a certain number of queries which are allowed in order to get over this security problem.
Those essays there are just phenomenal.
We should mention, so Carlton's given two talks this year, one of them at DjangoCon Europe.
He touches upon the locality of behavior.
I just put in the show notes for you, Michael.
It's one of the essays, but some of his projects, I saw everyone around me was writing down,
perhaps you want to expound on that idea, Carlton, because it's not necessarily a new idea,
but it really seemed to resonate at DjangoCon with people.
The talk was called Yak Shaving to Where the Puck's Going to Be.
And it was about, it's just been about what I've been doing since I stepped down as a fellow
in end of March.
So April, I sat down to start writing software.
I had with Django again, rather than on Django, as I said at the beginning.
And the hook that I built the whole talk around was HTMLX and this idea of locality behavior.
And so the example that I gave in the talk, which is from the essay there, is HTMLX has
got just the one HTML file open versus a jQuery example, which is very similar, but it's over
two files.
And it's not the only consideration.
But in that one case, you've got one file open versus two files open.
Well, there's better locality of behavior where you've got one file open.
And that really, when I read that essay, it really struck a bell with me.
For years, I've been talking to clients about this.
And you've got a form, a Django form, and it's perhaps only got four lines or three lines.
It's virtually nothing.
And it'll be off on its own in a separate forms.py file rather than next to the view you're
working on.
And so you have to go and open that second forms.py file to see the form.
And it's always just declares the fields.
And that's all it does.
And then you go back to the view.
And you have to kind of remember it was if you just move that form kind of next to the
view, all of a sudden, it's all within one screen on your editor.
And it's much easier to understand.
And then your speed of development increases.
And the more I've been playing with this, the more I've used this, it's just like, yeah,
actually, I'm able to work much faster by focus, particularly of a new code.
Like when your code starts to get bigger and more gnarly and more curly, and there's more
bits to it, then okay, you want to break it out so that it remains maintainable.
But when you're first working on it, and there isn't much of it, and it's constantly in flux,
keeping it all together, it just helps you go faster.
It's this idea of locality of behavior.
It's phenomenal.
I'm just a massive fan of it.
Yeah, it's really a brilliant framework.
And so for Django people, Django-htmx, that's where the magic is to get it easily integrated?
Yeah.
So the basics of that is a middleware, which will add an htmx attribute to the request object,
which lets you query it.
So is this an htmx request?
Has it got this header?
Is it wanting to redirect?
Is it wanting to do a full page refresh?
Is it got the various headers that htmx sends that will embed those and a few other niceties
as well?
But yeah, you may as well use that.
That's a good package from Adam, who's one of the cool...
Adam knows what he's talking about.
Nice.
All right.
Django, 18.
18 years old.
Yes.
Amazingly.
It's old enough to vote.
Yeah, old enough to vote.
Yeah.
It is old enough to vote.
Not to drink yet, so it's not going to get into trouble on the server for a few more years.
It is on its holiday in Europe.
Yeah, okay.
Well, that's true.
Yes.
Okay.
In Europe, it actually, it totally is.
I remember when we lived there, my daughters were 16 and we took them out for their 16th
birthday.
So yeah.
Yeah.
But in the US, we have these rules, you know.
Two things.
So Django has major releases updated every eight months.
So 4.2 came out in April, 5.0 come out in December.
In between, there's 4.2.1, 4.2.2.
This is all the work the fellows, Carlton, would do.
But there's also, so in the Django News newsletter, there is almost every day, there is a new PR
accepted and merged into Django.
So on the Django News newsletter, one of the things we have now is a section highlighting
like the changes this week.
And I think last week, there were 18 new PRs.
And that's not just someone opening it up.
That's like open, discussed, accepted, reviewed.
Like there's so much activity going on.
So even as it's 18 years old and it is mature, there is still just so much happening.
And I think that's one of the messages, Carlton, I try to get to people is like, it's not just
this static thing at all.
There's so much that's happening.
And yet it won't break on you, unlike some other newer technologies.
I mean, talk about the influx of tickets.
Just why does Django need fellows?
The reason it needs fellows is because there's basically five new tickets every single day.
There's over 1,000 new tickets a year, 1,200 new tickets a year, every year.
And they keep getting handled.
They keep getting dealt with.
The PRs keep getting merged.
The security releases keep coming.
And without the fellows, it just wouldn't have happened.
Django would have sort of just ground into an ever bigger ball of unanswered tickets, unresponded
things.
And so it's a project of such a size that without the paid role, it just wouldn't be maintainable.
Some of these do get resolved.
I mean, how long was Lily's one on database constraints?
That was like 13 years, 12, 13 years.
Tell that story.
This is one of my favorite features of Django 5.0 that's coming out.
So we haven't even talked about Django 4.2, but Django 5.0 is coming out soon.
And in there, so there's some really big ones.
There's database defaults.
So on a model field, you've always been able to declare a default value.
So if there isn't one, give it a date time field, give it now as a classic default.
But from 5.0, you'll be able to declare those as database defaults, which may not sound like
much.
But A, it's quicker.
It's moving work into the database.
But B, not every connection to your database goes via your Django application.
So you're able to have database level default.
And so if there is a script which isn't using the Django ORM, then you still get the value
of that.
And that ties in with work that's been done on constraints with database constraints have
been massively powered up.
And they'll even now, you know, your form generation will generate validators that are based on the
database constraints.
And it's just so much richness coming in.
I think, I really think we're also going to get database cascades in Django 5.0.
It's nearly ready.
There's a month or so before the feature freeze.
I think it's going to go in, in which case we're going to have DB defaults and DB level cascades,
both, you know, added to Django.
Both of those, it's a decade or more in the resolving in a new release.
And it's just, oh, wow, that's really exciting.
Yeah, for a lot of people, a lot of companies, the database is the source of truth for the
apps, right?
And like, sure, your code may talk to it, but what is in the database?
Like there are people whose job it is to defend the schema.
They call them DBAs, right?
So Django 4.2 added DB comments.
So you could add schema level comments to your model fields to explain the use of the model
field.
Again, it's for those scenarios.
Yeah.
For people who are serious about the databases, these features are just massively important.
Yeah, I think it's certainly worth considering that there will be other apps, there will be
other tools, and maybe even data science, right?
The data science angle is huge.
Often wants to now talk to the database.
And even if it's in Python, it's unlikely that in Jupyter, you're going to pull in your
ORM.
You're probably using some other data science oriented library to talk to that.
And so pushing those defaults down is valuable.
Well, so Michael, you're as situated as anyone to answer this.
Carlton and I are in the Django world, but how do we bridge the data science to web?
It doesn't need to be Django world.
Like what do they need to be on the web?
And if so, like what's holding them back?
Because it just feels like this mega, megaton star of data science and this tiny little web
thing.
But like, how do they share stuff?
How do they interact with it?
Yeah.
You've got your notebook and then you want to publish it somewhere, right?
Like, yeah.
Or just share it, share your information.
Or you have a database of COVID things.
For example, in the UK, you want to put online, but let people make change in some way or make
requests.
I mean, the data isn't generally static.
So I think there's two answers from my perspective.
I think there's, there are the frameworks that are doing that.
And that would be things like streamlit dash, not dashly, but the other dashboarding one.
There's panel, I'd say streamlit, probably start with that one, right?
So those kinds of things where you can get like kind of a simplified view that's kind
of an interactive thing.
You wouldn't look at it like we're looking at this Django site and go, yeah, it looks like,
it feels like this, right?
It doesn't feel like that.
It feels like you pushed a kind of a interactive generic UI up.
But I think that's a pretty good answer for a lot of people.
I think another is honestly, the stuff with HTMX, right?
You need a lot of interactivity in many of these things, these data screen screens and
like to get that interactivity often.
But you also need it to remember.
Yeah, yeah.
I mean, you need it to remember.
We computed this stuff and I want it to like get me the other info.
And you kind of need, just because how long it takes to do a lot of the computation, you
want a somewhat stateful type of behavior.
And I think HTMX with Plotly or something like that, even Matplotlib, I've done some
Matplotlib stuff and just like returned it as an image in different areas.
And yeah.
What do you, Carlton, what do you think?
Yeah, no, I'm nodding.
That's a good approach because, you know, you can quite easily put in a little loading
indicator there and it'll, when the HTML is ready and just, even if it took the same
amount of time by just putting in that little animation while it loads, it feels as if it's
responsive and doing something and it's, it's not rocket science, but.
A little HX dash indicator.
Yeah.
I was nodding particularly when you said just use Matplotlib and pull it in as an image.
It's like, yeah, that works.
That goes an awful long way doing that kind of thing.
I wasn't familiar with Streamlit.
That's really cool.
I mean, it makes sense.
I'm like, there's got to be someone, some people doing this, solving this problem.
But yeah, Streamlit is really, really interesting.
Basically you put deck, you have like a regular script that's not even a web thing and you put
decorators onto the functions and it says, oh, this parameter here is going to be a
combo box or something.
And it knows how to like wire the, it's some voodoo, but it's cool.
But it does look like a Streamlit app, right?
It doesn't look like, well, here's my own custom website.
It's like, well, here's my Streamlit app that I built for you.
Right.
So there's.
But I mean, and yet, you know, many people are using Tailwind now.
And so every site looks like a Tailwind site and before it was bootstrapped and before,
you know, so it's like, we can't get too high on our horse about it, you know, because
at the end of the day, it's like, it just needs to look modern-ish and like move on.
Yeah, absolutely.
Absolutely.
And getting something out is super important.
Okay.
So Django is, I would say it is the oldest popular Python web framework period, right?
There may have been ones before, but it certainly seems to be of the few that are like really,
really popular.
The one that's been around the longest.
What's amazing for me about it is the way the community kind of keeps refreshing itself.
Like it's not like the founders of Django are still merging every commit and every PR far
from it.
But, you know, I think Simon Willison made a commit in either 4.1 or 4.2.
I can't remember.
It was his first one for six years.
He doesn't even live in Lawrence anymore.
I mean, come on.
None of them do.
Exactly.
What right has he got?
But the point being is that it was set up deliberately to like hand it on and let it go.
And it's, I think Django is probably on its fourth or even fifth cohort of generation of kind of maintainers
now and yeah, that's a whole fresh batch of faces in the community who are doing new and exciting things.
And it's just so wonderful to see because you get old and long in the tooth and think, oh, I'm worried about the future of Django.
No, Django is doing great.
At DjangoCon, we talk about Django things.
And one of the things we don't necessarily describe to others is what makes Django different than other frameworks out there.
And it is the community.
You know, I mean, like Flask is an amazing resource and David Lord and people do great work, but there's no Flask cons.
There's no, it's its own thing.
But Django is relatively unique in that it has, it's a nonprofit.
It has fellows.
It has conferences.
It has this whole ecosystem, third-party packages.
You know, so there's the saying, you know, come for the framework, stay for the community.
It really is true, but you can't get that across to someone who just looks at the Django website, which looks like what it is, which it hasn't been redone in a number of years.
Right.
You think, oh, maybe it's a little bit of a stale, crusty Python thing.
It's like, no, it's alive.
There's changes every day.
You're just not seeing it.
And it's hard to, you're HTMX, right?
Like Carson does amazing work, but I think it's pretty much just him, right?
It's not this community of dozens and dozens of people.
And so one of the exciting things for Carlton and me is we're both transitioning away a little bit, but still helping bring in new people.
And that's healthy, right?
Like we know a bit, but sometimes I get, you know, I know the things that kind of I would like to change that may not change as quickly.
And then new people have great ideas and enthusiasm.
And it's like, yes, let me support you because I don't want to get stale with this.
Project Vaughn asks a pretty good question, which I think is a good question for any really large project that's been around a long time.
It's like, how do you get more involved with Django?
For someone who's not proficient in Django, like super, super proficient, given that it's a mature project, it's really hard to get that first PR written.
One thing that often comes up, oh, there's no ease, there's no low hanging fruit.
It's a mature framework.
There's nothing easy to do.
And it's like, well, yes and no.
Yes and no.
There are very few like nothing fixes, you know, that an absolute beginner can just come in and get, because they get snapped up really quickly and they just don't hang around for very long.
But we've got something like 800 open accepted tickets on Django.
Now of those 800 tickets, some of them are truly hard, like adding database defaults, which took a dozen years and five Django con sprints and, you know, who knows what to actually get over the line.
That's truly hard.
But most of the tickets aren't like that.
Most of the tickets are no harder than a problem that you're solving in your everyday Django or Python programming work.
And what they need is time and love.
And so Django cons, I've run Django cons sprints.
I've run a kind of getting contributed workshop.
And the goal of it, you've only got a couple of hours.
It's only like half a morning.
And the goal is not to necessarily get your PR in, but it's just to get you to look at a ticket in a bit of depth, get set up with a test suite, you know, install it, get set up.
But get involved in a ticket and come to understand that ticket and realize that actually after that, a couple of hours of thinking about that ticket, you are literally the world expert on that ticket.
And even though you're not like, oh, it's established.
I'm not a Django fellow.
I'm not an established contributor.
You, as the world expert on that ticket, you have a valid opinion and your insight will be valuable.
And yes, you have to dig around and you have to learn some source code.
But you'll have an idea and it's going to be on the right track.
And if you put the time and work and love in, you'll be able to resolve that ticket.
And once people have had that experience, then it's like, oh, I can do another one and I can do another one.
And it can become the little side hobby.
And actually then I'm a Django contributor.
So it's take your time, pick a ticket, really focus on it, become the world expert.
And in so doing, even if you don't resolve the ticket, you will learn an awful lot about Django.
You think you know Django by developing Django apps all day.
Well, you start digging around in the code, I'll guarantee you'll know it a lot better afterwards.
So that would be what I say is find a ticket that grabs you and just take that little bit of time to really understand it.
Yeah, that's great advice.
I guess there's probably sprints you could drop into at some conferences.
Yeah.
So after the Django cons, there's two days of sprints.
Stay around.
There's a really great opportunity to meet people who are contributing and to get into contributing and be able to sit in the same room as somebody and say, well, you know, how do I get started?
How, you know, that is a good, a good play.
But can I just sit there and look over your shoulder as you two work on this?
Yes.
Let me be.
That was the most recent Django con.
So there's Django con US, Django con Europe.
There's going to be a Django con Africa this year for the first time.
But the most recent Django con US, I was at a sprint talking with David Lord, who's the lead maintainer on Flask.
And he had a question about something or other.
And someone was like, oh, like Simon Wilson knows about that.
So I was like, oh, grab Simon over.
And they'd never met.
And now it's like, oh, like, so if you can stay for the sprints, it seems like the nothing part.
It's actually I'd almost take the sprints over the conference if you could, because it's literally just like anyone you want to talk to.
And you don't have to, you know, like, what are you working on?
Or, yeah, they're like the best part.
But maybe it seems intimidating, but it's really not.
And to Carlton's point, the community really is welcoming.
So even especially if you're inexperienced, if you're making an effort and people can see that they will be encouraging and want to loop you in.
There's also I should mention there's a new link program called Django Knot that's trying to pilot having some mentors to give this kind of hands on help a little bit.
That's a new program.
It's only, I think, six people right now, but there's they're trying to foster more mentoring of this type.
But it is a challenge for a mature framework, right?
You probably can't just go fix HTML.
It's probably a little more meaty, but it's not all hard just because it's there.
It's just that it got stuck for whatever reason.
It needs, as Carlton said, that of someone to come in and put a couple hours and then be the world expert.
Absolutely.
So what's the async story Django these days?
How's it looking?
It's looking really good.
Well, do we get to talk about 4.2?
Yes.
Django 4.2 brought in async support for streaming responses.
So within the core framework itself, you can do service and events or, you know, you can have a request come in.
You can keep it open without blocking the worker and you can periodically send messages down.
That's really quite exciting in 4.2.
And with the other thing that came in 4.2 was Psycho PG3, which allows async database connections.
And so there's a link in the show notes there of somebody put together exactly what I was hoping for, which was the chat, the chat example, but done 100% async.
So without blocking the blocking ORM call with the service and events, so instead of long polling or without having to use an add-on like channels, which, you know, add-on channels is great if you need it.
But isn't it cool that you can do service and events just in Django?
And then in 5.0, which is coming, we're going to have HTTP disconnect handling in, so those long-lived requests, if the client disconnects, you'll get an asyncio cancel there in your view and you'll be able to respond to it and do any cleanup.
We've also, in 5.0, we're going to have async signals, which gives you an 100% async request-response pathway if you want it, because before the only blocking bit there was the signals, which were synced.
So you still had to do this sync to async, jump into a thread pool to dispatch the signals.
But that, if you've got async signal handles, will all be async as well.
So the entire request-response flow can be async.
And then sessions is going to be async in 5.0 as well.
Auth is going to be async as well in 5.0.
So those kind of core flows are, this is on top of the async interface to the ORM, which was added.
You know, it's all fleshing out.
And there's a few decorators, which, you know, aren't yet done, but they'll be done over the next few releases.
It's really enriched.
And it's like, yes, yes, five, six years, seven years of work has gone into this.
And it's really maturing nicely.
So I think async in Django is a very, very exciting time.
So when people say, I want a FastAPI, right?
That's always the thing.
Well, why not just use FastAPI?
Well, no.
If you want to use FastAPI, go use FastAPI.
But if you're using Django, but you need a couple of these endpoints, which you need higher throughput or, you know, a real-time or two-directional traffic or whatever, you shouldn't have to switch red framework just to have a couple of these endpoints, right?
It's like Python needs to be in every area because you shouldn't have to switch language just because you need, I don't know what, to be a bit more serious about things.
So Python needs to be able to account for those more serious use cases.
Well, same with Django.
It needs an async story because you shouldn't have to change your web framework just for, you know, service center events or I don't know what other async, you know, a bit of real-time.
Almost nothing waits on other things like web frameworks do.
They wait on database calls.
They wait on the network.
They wait on caches, you know, like Redis.
They wait on maybe calling other APIs.
Like, almost everything they do is coordinating other systems and waiting and then turning that to HTML or JSON.
And so having rich async support is fantastic.
Yeah, no, I mean, it's really coming on.
And there are still, you know, there are bits inside, you know, I don't know if you need the, I don't know, user passage test, decorate, permissions decorator.
Is that yet async defy?
I'm not sure if it is.
But okay, that's not, we haven't got to, maybe we have, I need to check, but we haven't got to that bit yet.
But okay, those kind of bits, we'll get there with those.
But that kind of call, I'm building something on the request response cycle with auth, with sessions.
Yeah, that's all now done.
And so it's really maturing.
Getting short on time here, guys.
It's so nice to have you be in charge of this, I should say, right?
Because whenever there's those pauses, like my instinct is to jump in and like, look at our notes.
But like, just like, nope, you're captain of the ship.
It's so nice.
Yeah.
We're just out for a sunset cruise in the whole boat.
We're coming back to the harbor.
So what else about the future, right?
We talked about Django being 18, a lot of the cool ideas and projects and resources.
But what about the future, some of which we just covered is really exciting.
Maybe we haven't given time to yet.
I'm personally excited about the new people getting involved.
I know that's not as tangible for folks, but coming from Django Cons, coming, like I just stepped off the board as treasurer for three years.
I know who the new treasurer is, the current president.
Like, I'm really excited about the new people.
And so I don't, for a while during COVID, I think some of us had concerns about like, you know, how do we keep this afloat and not have everything crash and burn?
But I don't have those concerns anymore.
Yeah, yeah, yeah, yeah.
Just the fact that if you want something in Python that solves almost every web problem you have and has a really supportive community, Django is still there for you.
And so I guess that's the big one.
It's just, and I think from a marketing side, it's just how do we express that it's still cool and interesting and powerful and yet won't break on you.
It doesn't seem as shiny and new as the next whatever.
But it's, you know, it's like if you look on Hacker News every like six months, someone's like, wow, Django is like still around.
Oh, it's like kind of solves all these problems we have with this new JavaScript this or that.
And it's like, yeah, it's still just doing its thing.
So I would say the community side.
I mean, also like I've got projects.
If you want to learn Django, I mean, like, let me, there's a lot of resources to learn it.
There's a number, there's videos.
You have videos, books, tutorials, like some of these newer technologies.
It's harder.
There's not a community and it's harder to find the resources.
You know, there's a lot of strength in being around for a while and yet not being totally stale.
So that would be my tagline for Django.
How's that?
I kind of go off that.
I think actually it is cool.
And it's about as cool as it's been for a while.
I said in my DjangoCon Europe talk that I'm as excited about the framework and where it's going now as I have been for many years.
Since I said since the DRF Kickstarter, if you remember that back in the day.
There are over the last few releases, and I don't just mean 4.2 and 5.0 coming up.
I mean, like the last 3.2, 4.0, 4.1, like last few years, there've been a number of threads, not just the async stuff.
There's been massive changes to the forms, templating.
There's been all these changes to the ORM that are powering up every single release.
And they've all come together.
And there are patterns now to be discovered.
And it's like I said, I'm stepping down in part because of life, but in part to get back to working with Django rather than just on Django.
I want to play with all of these new toys that we've built over the last few releases.
And I want to discover those patterns and see them codified and see them come out in the community.
And it's just a massively fertile time.
And so that's what I'm excited about.
That's where we're going.
And I can't say every release Django literally gobsmacked by how many new features you think are there won't be any in the new one.
But 5.0 is coming out.
And it's just hitting you out of the park again.
And it's like, wow, we've only just had 4.2.
4.2 is not even old yet.
5.0 is not even in alpha.
And we're already thinking, oh, can we run it off main?
Because it's so exciting.
The future is so many things have come together.
And the future is just really exciting.
I feel like I would be bored by now with Django.
I've only been doing it for over a decade.
But if anything, there's just so many new features.
But also, I'm understanding built-in functionality even better to solve problems that I just didn't have before.
So at some point, maybe I'll be like, oh, I know it all.
But I feel the opposite.
I feel like, whoa, I had no idea.
Just one concrete example.
Doing all the work with templates and HTMLX.
And coming to see the patterns about creating, again, fresh for the first time and really using templates for the first time in half a decade.
It's like, okay, ah, yes, I create a template tag here.
And I do it this way.
And I put a mapper in here to create a kind of view model type thing.
So I pass in an ORM model object into the template tag.
And then in the template tag, I map it to what I need in the actual template itself.
Then the template comes in.
It's like, oh, that's a really good and powerful pattern.
And it's really encapsulated and neat.
And it makes my template expressive.
And oh, rediscovering these things.
And then being able to say, right, okay, well, what changes does the Django template language need that it hasn't had in quite a few years because no one was using it?
And yeah, it's just a massively fertile time.
It is.
And it's no coincidence that we've been hitting on HTMLX so much because it really puts the power of frameworks like Django back front and center in how you think about building and structuring your web apps.
It's not like, well, there's this thing in the backend and then we're going to go do these other languages.
It's like, you know, actually it could be all.
And there's a bunch of cool features and capabilities that we've been talking about.
And you can use them throughout your app if you leverage something like, not necessarily, but something like HTMLX, which is really cool, I think.
For me, it works just with the grain of the framework.
It's like, this is the way I would do it if I was writing in 2005.
And I do it exactly the same in 2023.
And it just works.
And it's, you know, responsive and dynamic and all these nice things that, you know, clients want.
Absolutely.
All right.
Let's leave it there, guys.
Thank you so much for covering all this and celebrating Django's 18th birthday.
18th birthday, yeah.
Yeah, it's awesome.
It is an adult and it's a cool framework for sure.
With really, I think it's the community behind it, especially the fellows and all the board and stuff.
It makes it really unique and is certainly worth considering as part of the framework, right?
As you said.
Okay.
With that, let's round this out with just a final shout out to what you guys have around Django.
For example, the Django chat podcast, right?
Which is excellent.
Give us a shout about that.
You know, Will, tell us about Learn Django and maybe Button.dev or whatever else you want to throw in.
I should say Django chat.com.
You're sort of the godfather of it because you gave me a lot of good advice when we were starting out in the early days around things and that there might be a market for it.
So thank you for that.
You're welcome.
It's going strong.
It's a great show.
I enjoy listening to the episodes.
We're going to be back in the fall with new episodes.
And then learnjango.com.
That's my main website.
If you want to learn Django, access books, lots of free tutorials, premium ones coming.
That's sort of an all-in-one resource.
And I think there's also a link to Django-news, which is a weekly Django newsletter with new news that's happening, new projects, new tutorials, not just mine.
So that's something I've been doing with Jeff Triplett for a number of years now.
And that's a good way to stay in tune with what's happening.
Yeah, that's kind of an essential resource, I'd say.
And then Button, Carlton.
Yeah, so okay.
So I've got a website and I've got a blog somewhere.
So button, btn.dev, that'll be live in the autumn now.
But you can follow me on Fosadon or the Fediverse.
And on my website, there's an RSS feed, which you could subscribe to if you fancy that.
My other big projects at the moment is working on a set of opinionated CRUD views for Django called Neapolitan, which is a bit of fun.
I'm having a lot of fun with that.
So watch my DjangoCon Europe talk for an introduction of that.
And then I'm working on a package called DjangoTemplatePartials as well, which is about getting template fragments into the DjangoTemplate language, which again...
I was going to ask you about that.
I know.
Now that he's not a fellow, he can do all the things he always wanted to.
Yeah, when I started using this with...
Oh, yes.
And I'm like, man, you have got to come up with a way to reuse HTML almost like functions.
So I came up with JinjaPartials.
So what is yours called?
DjangoTemplatePartials.
TemplatePartials.
DjangoTemplatePartials.
Oh, oh.
You need a spacer.
I think I put a link in the notes.
But yeah.
Yeah, there you are.
There you are.
So that's my take.
And it just enables you to define reusable components.
There's a couple of pull requests open, which will just change the API there slightly.
And then we'll start to think about rolling into Django.
Hopefully for now, it's going to be Django 5.1.
There's no chance of me getting in for 5.0 this summer.
But it's the same idea.
And the point with it is it's integrated with the Django template loader.
So all you do in your view is change your template name variable.
And you still return your template response, same as you always had with the context.
There's no adjusting your view logic.
It's almost transparent to the view layer.
And there are, you know, I've seen people writing logic where they pass the HX vowels, which is where you pass extra parameters in your request from the client, which you could then specify the partial with.
And then your view logic wouldn't change at all.
That's out of scope for Django template partials.
But it's a possibility.
But the point being that you just, it's this for me or something like it is how Django wants you to do partials with the Django template language.
Obviously with Jinja, there's an option as well with Django.
Useful outside of HTMLX required for HTMLX, basically, right?
Yeah.
I mean, because what's the other way?
The problem with it is you then have, if you don't have inline partials, you have to move it to a separate template.
And then you have to include that template in the other template.
And that's great at a certain level of complexity.
But again, it's this locality behavior thing.
When you're first starting, you don't want that heavy weight kind of in your creative flow.
You're making progress.
And all of a sudden, you have to put the brakes on to create a new file, move it open.
What's the file name again?
Oh, I've spelled it wrong.
Oh, it didn't load.
Oh, because it was in the wrong file.
You don't want all of that.
You just want inline that bit.
Be reusable, please.
Yeah, very cool.
Yeah, this is different.
Mine doesn't embrace the locality behavior as much as yours does.
So people should check this out.
This is interesting.
Obviously, mine doesn't work with Django either.
So it doesn't really matter.
Well, it works with Jinja, though, right?
It works with Jinja, right?
Yeah, yeah, yeah.
Right.
So the Django templates have swappable backends.
So you can use the Jinja backend to use Jinja templates with Django if that's your cup of tea.
We got to end this podcast.
But if you're looking at moving a Flask project over to Django, that would be a way to not touch
the HTML very much, right?
Yes, exactly.
Because you could carry on using your same templates more.
You might need one or two edits to the, what's it called?
The Django environment, the Jinja environment or something to, I don't know.
Thank you guys for being on the show.
It's always a great time to catch up with you.
Yeah, thank you for having us.
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.
Take some stress out of your life.
Get notified immediately about errors and performance issues in your web or mobile applications with
Sentry.
Just visit talkpython.fm/sentry and get started for free.
And be sure to use the promo code talkpython, all one word.
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.
You
Thank you.