20 years after a scrappy newsroom team hacked together a framework to ship stories fast, Django remains the Python web framework that ships real apps responsibly.
In this anniversary roundtable with its creators and longtime stewards, Simon Wilson, Adrian Holovaty, Will Vincent, Jeff Triplett, and Tiavod Kolas, we trace the path from the Lawrence Journal world to version 1.0, DjangoCon, and the Django Software Foundation.
Unpack how a BSD license and a culture of docs, tests, and mentorship grew a global community, and revisit lessons from deployments like Instagram.
We talk modern Django too, ASGI and async, HTMX-friendly patterns, building APIs with DRF and Django Ninja, and how Django pairs with React and Serverless without losing its batteries-included soul.
You'll hear about Django Girls, Django Nauts, and the Django Fellowship that keeps momentum going, plus where Django fits in today's AI stacks.
Finally, we look ahead at the next decade of speed, security, and sustainability for Django.
This is Talk Python To Me, episode 518, recorded August 18th, 2025.
It's time to unite. We started in pyramid cruising. 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 brought to you entirely by Sentry. It's a bit of an episode takeover, if you will. Sentry has two excellent and exciting services to tell you about. Sear, your agentic AI debugging assistant, which takes all the data already gathered by Sentry to help discover the problems and even propose fixes as GitHub PRs. And the other is AI agent monitoring, which adds deep observability to your AI agents in your app. If you're adding AI and LLM features to your Python apps, you'll want to know about AI agent monitoring. I'll tell you more about both of these later in the episode. And remember, however you happen to sign up for Sentry, if you do, use our code TALKPYTHON, one word, all caps.
Let's get to the interview.
Hello, everyone.
Welcome to Talk Python To Me.
I'm so excited to be celebrating Django's 20th birthday.
What a milestone.
We have Will Vincent, we have Adrian, we have Theobald, Jeff, we have Simon.
Many of the original people have the origin of Django here to talk about it.
So, you know, welcome all of you.
Thanks, Michael.
Yeah, you bet.
It's going to be a lot of fun to go back to some stories and maybe also see where things are going after 20 years.
It's still going strong, to be sure.
So what an accomplishment.
Let's just start with a real quick, who am I, introduction from each of you.
Just give us the elevator pitch on you and your Django life.
And we'll go around the Brady Bunches in order, I suppose, here on the screen.
So Will, welcome.
Okay.
So we'll go from least to most important.
So I'm a developer advocate at JetBrains, some Django books, a podcast.
I think that's enough.
We have more important people to come.
All right.
Adrian, welcome.
First time to have you on the show. Happy to have you.
Hi, I'm Adrian, one of the creators of Django many years ago, precisely 20, a long time web developer.
And yeah, it's basically it.
I'm Simon. I'm Adrian's intern, effectively.
We built the first version of Django during my year long paid internship at the Longest Journal World in Kansas.
It was my university had a year in industry thing, which meant I could get a visa.
And yeah, we worked on what we called the CMS at the time.
We didn't know that it was a web framework.
We thought it was a tool for building local newspaper.
Yeah.
Almost got named TPS, which would be amazing.
Well, I'm a...
Oh, go ahead.
Sorry.
I was going to say, Simon, you're almost more well-known for your AI stuff these days.
You've been...
Last couple of years.
Like, last two years.
You've been in the news so much.
I see you everywhere now.
It's like, congratulations on having two...
Yeah.
I mean, that was...
was. The trick there is I have a blog and not everyone else gave up on blogging, but I kept going. And so when AI started up, I was the only person blogging about AI, which turns out gets you invited to all of the weird Silicon Valley mansion parties and things. So yeah, that's been an
interesting little twist over the past couple of years. Yeah. Jeff Triplett, I'm so sorry to cut
you off. Happy to have you. No, no, no. All good. I thought it was pretty free for him, but I came to Lawrence, Kansas two years after these two had left, maybe three years after these two had left To work at the newspaper, I've stuck around.
Probably one of the few people left that stuck around that worked at the journal world.
Me and Frank Wiles, who's over here someplace.
I'm on the Django Software Foundation Board of Directors.
I've helped with DjangoCon US for, I think, 11 years now.
And do a newsletter with Will and a bunch of random Django projects.
So that's me.
Jeff, were you there for the whole of Media for Media?
The commercial arm of the newspaper doing Django stuff?
About three years of it.
It just had moved across the street to the Little Red building they called Little Red.
And so I think I moved when I moved here was within probably like a month or two of that starting in the building.
Awesome. I'd love to I'd love to hear little stories from that era of Django.
I missed that entirely.
I'm on the board with Jeff. I'm the president of the foundation, Django Software Foundation for 2025.
And I've been involved with Django for only 10 years, only 10 years.
So much less than everyone is here.
Yeah. Outside that, I'm a dev.
I'm on the core team for an open source project called Wagtail, which is a CMS as well built on Django.
Yeah, welcome.
And Wagtail is a really cool project.
I think people who are looking to take the CMS idea and level it up even more.
And you know, I've got a little bit of Wagtail related career history.
Wagtail came out of a company called Torchbox.
I worked for Torchbox for about six months to a year quite early on, working on one of the first Django projects that Torchbox worked on.
And it was a carbon calculator that we were building.
I have nothing to do with Wagtail at all.
That was probably 10 years after I left Torchbox.
But I know the Torchbox team really well.
We should also, I mean, Jeff, amongst other things, you run Django packages.org right now.
And I think Wagtail is number one or two with Django REST framework for most downloaded.
It's something like that.
It's one of the top three.
I feel confident saying that.
Maybe you don't.
I do.
Yeah, it's downloaded a lot.
I don't know if it's top 25.
Tebow with it.
I think it's in the top 100.
We did a post, right?
So, you know, you're close.
Okay, Tebow.
Amongst 20,000 or so plus.
But, yeah.
Yeah, yeah, of Django ones.
Wait, of Django ones?
Oh.
What is that?
There's like 4,000 now, Jeff?
Something like that?
I think there's probably like 16,000, 20,000.
But I think we're tracking like the top 4,000 or 5,000.
It's what people...
I never wanted to add code.
They just pulled everything in just to have a lot of numbers.
So, it's still like user submitted and ran.
Oh, it is the most important thing.
But Tebow, GitHub stars.
That's the most important thing.
How many is it for Wagtail?
But yeah, I think we just like almost at 20,000.
I'm pretty sure if you're on here listening to this show, stars right now will be at 20,000 in like a week.
Yeah, it's really high in downloads as well.
But you know, the Django ecosystem is really big these days and CMS only definitely in a smaller portion of it.
Oh, there you go.
Very, very, very popular.
That's amazing.
So let's start at the beginning, folks.
I have on the screen here a picture of the University of Kansas where I also have a connection to.
I actually went here and got my undergraduate degree in math at this school.
And I love my time in Lawrence.
I think it's a lovely town, but it's also the home of Lawrence Journal World, right?
Tell us who wants to start the story.
Like what's the origin story here?
Probably it makes sense for me to start it.
Yeah, I think so.
Let's do it.
Back in 2002 slash 2003, early 2003, I joined that newspaper as a web developer.
There was the guy who ran it was this guy called Rob Curley, who was seen as this big tech innovator in the news industry.
And he was sort of recruited me and put together a great team of awesome, awesome web developers, believe it or not, in this tiny little newspaper in the middle of Kansas.
We were tasked with building interactive database driven apps for the newspaper, which at that time was unheard of.
Even these days, it's kind of weird for a newspaper to have developers on its staff.
And at the time I was using PHP and yeah, fast forward, maybe a year into the job, we had an opening to hire another developer and I posted a job entry on my blog and Simon read it all the way in the UK.
And we followed each other's blogs back when that was like the social media of the day.
To be fair.
Much more interesting than social media of today.
At the time, I felt like there were about 100 people blogging about web development.
And we were two of those.
Yeah, and we all followed everyone.
Did you guys have a blog role?
Oh, yeah, absolutely.
I think we were both massive fans of Mark Pilgrim.
Mark Pilgrim was the web development of Python blogger that we were paying attention to.
Unfortunately, he's not around anyway.
I mean, he's alive, but he stopped blogging many, many years ago.
Yeah, he wrote an online book called Dive into Python.
And we both read that and we're like, oh, what's this Python thing?
And thanks to the kindness or possibly ignorance of our boss, we just started using Python one day.
We didn't really have to get much buy-in or anything.
And we'd started making little bits and pieces in Python, never really with the intent of making a framework.
But over time, at some point, we just decided, okay, we're switching to Python.
No more PHP.
just going to do everything in this new thing. And I remember the key thing for us is how do
you deploy Python? Well, there was modpython, the Apache module, and we were just a little bit nervous about it because not many other people were using it. And so we're thinking, okay, well, we can try modpython, but what if it doesn't work? So, okay, well, if we have an abstraction layer between our code and modpython, like a request and a response object, then if modpython doesn't work out, we can swap it out for something else. We didn't, modpython worked great, But that abstraction layer, I think that was the origins of Django, that tiny little layer between R code and mod python, just in case. Classic thing you shouldn't do in programming, right? You're not going to need it. You don't need the abstraction layer, but we built one anyway. And fast forward 20 years and maybe that was a good idea after all.
Is mod python still around? It's got to be, right?
I don't know. I mean, modwhiskey, it was replaced by modwhiskey many years ago.
But yeah, I don't know actually. I've not checked in on the ModPython project in a while.
It's been last commit eight months ago to ModPython on GitHub.
Oh, very smart.
Yeah, yeah.
That sounds alive.
Yeah, yeah, it's definitely alive.
And now we have WSGI and ASGI and that's sort of carrying on the same theme in a way.
You know, WSGI kind of came out of the work we were doing in that we were working on Django, at the Journal World. The mailing list popped up, the Python web-sig mailing list. This mailing list popped up. We were very active on that initially, trying to pitch our request and response objects.
We did not win with our response request objects, and Whiskey came out of that instead. But yeah, that was definitely... Whiskey came out of that early era of what we were trying to achieve with with the stuff we were doing.
So we built up this series of libraries slash tools slash, I guess it turned into a framework.
And we started thinking, oh, this is kind of interesting.
Personally, speaking for myself, I was like, oh, I'm probably not going to work here forever, but I would love to keep using this.
So that sort of started planting the seed about open sourcing it.
But I think very few people today know that even 20 years ago, there was this meme that there are way too many Python web frameworks.
So we went to PyCon US and it had to have been 2004.
And there was a keynote where the speaker said, she showed a slide that was like a tag cloud of all the Python web framework names.
And there were like 50 of them.
So Simon and I were sitting there like,
oh shoot, we made yet another one.
We're fools.
We're so stupid.
We're embarrassed.
But I ended up doing a lightning talk at that PyCon and showed what we had.
It didn't have a name yet.
And, you know, people came up to me afterward and said, oh, please open source.
We're very interested in this.
It looks very promising open source, even though it's yet another Python web framework.
So I guess extrapolating a lesson from that, it's never too late to make stuff.
I think another fact there is that Ruby on Rails had come out maybe six months before that PyCon.
Like Ruby on Rails was the absolute buzz of everything in the web development industry at the time.
And there was an open question like, what's Python's answer to Ruby on Rails?
And so it's possible that the Django timing was really good on that front.
I believe that Rails helped influence the newspaper to open source Django.
Was that part of the conversation then?
Well, I remember making a list of 10 to 20 reasons why we should open source it and really thinking hard about it, probably lost some sleep about it.
And we went into the meeting with Rob to make our pitch.
And we only got to like five reasons.
And finally he was like, yeah, let's do it.
So, I mean, endless, infinite credit to him for being cool.
And I mean, the company took advantage of open source a lot.
And I think the higher ups knew it because it also owned a cable company that did a lot of stuff with Linux and all sorts of crazy cable company software that was open source.
Which was made Frank, right?
That was Frank Wiles at the cable company driving all of that stuff.
Yeah, you know, I think it's worth pointing out as well. One, Adrian, you're making me nostalgic just to think about tag clouds. Okay. They were such a thing back in the early 2000s. It's a usability nightmare. I know. Any kind of data or information out of that thing.
It really is.
I think I use, oh my God, Delicious a lot, and you'll get tag clouds out of it and all sorts of stuff.
But that's not why I'm bringing this up.
More in that timeframe, open sourcing something was not the clear choice it is today.
At least it was really more of a push, I think.
Legal liabilities, giving away our IP.
Like it was a different time.
There was open source, but not like today.
This portion of Talk Python To Me is brought to you by Centuries Seer.
I'm excited to share a new tool from Sentry, Seer.
Seer is your AI-driven pair programmer that finds, diagnoses, and fixes code issues in your Python app faster than ever.
If you're already using Sentry, you are already using Sentry, right?
Then using Seer is as simple as enabling a feature on your already existing project.
Seer taps into all the rich context Sentry has about an error.
Stack traces, logs, commit history, performance data, essentially everything.
Then it employs its agentic AI code capabilities to figure out what is wrong.
It's like having a senior developer pair programming with you on bug fixes.
Sear then proposes a solution, generating a patch for your code and even opening a GitHub pull request.
This leaves the developers in charge because it's up to them to actually approve the PR.
But it can reduce the time from error detection to fix dramatically.
Developers who've tried it found it can fix errors in one shot that would have taken them hours to debug.
SEER boasts a 94.5% accuracy in identifying root causes.
SEER also prioritizes actionable issues with an actionability score, so you know what to fix first.
This transforms sentry errors into actionable fixes, turning a pile of error reports into an ordered to-do list.
If you could use an always-on-call AI agent to help track down errors and propose fixes before you even have time to read the notification, check out Sentry's Seer.
Just visit talkpython.fm/seer, S-E-E-R.
The link is in your podcast player's show notes.
Be sure to use our code, TALKPYTHON.
One word, all caps.
Thank you to Sentry for supporting Talk Pythonemy.
Well, also, the publisher of the newspaper at the time still used a mechanical typewriter to write up his things.
He was legendary for it.
But my understanding is that he got into it.
The argument that was convincing to the newspaper was, "We benefit from this community.
We should give back to this community." That evidently was part of the pitch.
It just took off.
I feel like that newspaper did very well from that one decision that they made back then.
Yeah, I mean, here we are this many years later talking about it on a podcast, right? Like already, a lot of people know about it. And a lot of people, all of you on the call, but many, many, many others have contributed back to Django to make so much better. If that was just an internal CMS that you guys left there, how many external contributors would you have? Right? Not that many.
Well, one thing, actually, I'm curious while the two of you are here, I heard a story that there were some efforts to monetize it that didn't pan out.
Jeff, maybe you were there for that.
Is that true?
Were there some efforts to package it up and sell it to newspapers in some capacity as a premium product, I think?
Am I making that up?
That was after my time, I think.
Are you talking about?
Maybe Frank mentioned that.
I thought there was something around.
Yeah, this was Ellington.
I think we should.
Oh, I guess.
Yeah.
Sorry.
to Jeff who um yeah this is kind of my era I guess then was um and I still feel like I'm new to Django because I felt like and I've been around for 18 years but like I just I saw these guys code so much and then I came into that era so to me it felt like next gen Star Trek versus now the originals um and so yeah when I started we had hundreds of newspapers were buying Ellington which was basically like what was it the first or second Django app ever written and they basically created a CMS to run your newspaper and then they also had something called marketplace which was almost like an online Craigslist or business directory.
And so I came in to kind of help manage some of the inventory and do a lot of data imports and stuff for newspapers.
Like we had all of Massachusetts at one point.
There was a lot of kind of that, they went that direction with it.
And I left before that kind of had shuttered and I think they sold it to a big company to buy it.
And I think Ellington still runs to this day.
At DjangoCon every two or three years, somebody will approach and say, we want to open source Ellington.
Would you like to, could we do this at DjangoCon?
We always say, "Yeah, that'd be really cool." Then six years has gone by and it happens every so often.
I hope that code gets to see the light of day because it was hundreds of apps by the time we worked on it for hundreds of newspapers.
I feel like the product was fantastic and the market was great, but it's a terrible market to be selling into.
In the late 2000s, early 2010s, if you're selling to local newspapers, which are blinking out of existence at a rate of knots.
My hunch is that the marketplace challenges were down to that.
It was selling into a shrinking industry, which is a difficult thing to do.
Yeah, I think they were hitting a brick wall for sure.
You mentioned Rails earlier and PHP.
And two things come to mind.
I have an embarrassing email I sent to Simon at one point because I followed your PHP blog.
And also Matt Croydon, who later became my boss at Media for Media.
And I did not.
I saw a couple of things.
I think you were so into Django, you weren't really posting about Django.
And so I think I emailed you once to say, have you seen this thing called Django?
It looks pretty cool.
Now that you're doing Python, I think you may like it.
And so if you ever check your Gmail, it may be there.
We don't have to do anything live on the air.
But yeah, I to this day think, oh man, that was kind of wild.
What brought me to Django though was I did get the Rails book because they very quickly created a Ruby on Rails book.
It was kind of the main way to learn how to use it because their website kind of sucked as far as documentation went.
And as I was going through it, so much was boilerplate just to get anything running in Rails.
And so the Django admin was just so beautifully designed and well done that to me, it was just this win of like, this looks better than anything I could do by hand.
And it's largely stood the test of time for 20 years.
I remember like Wilson Miner I had met a couple of times had done some of that work or most of that work.
He did all of that design work and he designed the original Django website.
And I think that's one of the main reasons that we got a lot of traction was because the design of the site and the documentation were so good, especially considering the context.
I mean, that back in those times, it was par for the course for an open source project to have to be completely on style, like a normal, like browser default H1 Craigslist background.
This design isn't the one that Wilson did.
The one that's archived that or get to go back.
But it was pretty timeless at the time, though.
It was amazing.
And I feel like the admin has evolved a lot, but it still has that sort of...
It feels like the Wilson minor design today, even 20 years later.
Wilson was there the same time I was at the Journal World, and he then went on to early Facebook.
He was, he's bounced around Silicon Valley.
Yeah.
Redesigned Apple.com, I think too.
He worked with me at EveryBlock for a few years.
He's now working on Apple Music.
I didn't know that.
Excellent.
As of last time we talked to him, which was recent-ish.
Yeah, that's quite neat.
Trying to pull it up here in the Wayback Machine.
We'll see what I can get.
I think the other thing I...
How about this, guys?
Is this the OG?
There we go.
Yep, yep.
That's the one.
And that, to be fair, that looks good by today's standard.
You know, I feel like I would not be at all upset to publish a website look like that in 2025.
Yeah, that is pretty timeless.
That's cool.
Wait, I see the...
Oh, go ahead, Simon.
Oh, it's good. The other thing that's worth mentioning with Django, Django's documentation has always been fantastic. And I think that's basically because it was Jacob Kaplan Moss had a, he was a literature major and you have Adrian, who's a journalism major. And it turns out if you put a journalist and somebody who like put that talent on your documentation, you get really
good documentation. There was, that was a double-edged sword because it took a few years for any publisher to be interested in publishing a book about Django because the standard line was always, oh, the docs are good enough.
Everyone just, there's no market for it.
Well, but at the same time, I wanted to ask, I mean, because there was the link there to the Django book, which I have the URL now and Jeff and I run, it lists all the Django books.
But I mean, the two of you wrote that.
I thought that was a great book.
I think you, it was in print, right?
But it was mainly open source, Adrian?
Yeah, it was both.
It was free online and it was published by A-Press.
There were a couple of editions, yeah.
The interesting question for Paul Everett out there in the audience is, In the first years, did your team also have to admin the newspaper site?
Like, did you DevOps before DevOps was a thing?
Or how did you run it?
The cloud stuff wasn't that big back then.
No, we had our own physical servers.
In the basement.
The team was in the basement.
You could probably hear them.
Your programmers.
And yeah, there was a room in the basement with physical servers.
And oh, I've forgotten their names now.
I think Frank helped.
Well, they were named after characters in Beatles songs.
One was Mr. Mustard.
One was Pam from Polytheon Pam.
Yes. Yep. But yeah, and Frank and Nick from Sunflat Cable helped us wire those up. But yeah, it was a fit. There was an Apple server in there as well. That was the media server,
I think. It was doing like imagery sizing. Yeah, it was like a 2U box or something. I forget. It was actually like a physical server that now, because I'd never seen one before in person.
XServe. It was an XServe. Yeah. Also, I remember that room had a wire that was the AP News wire, Like I didn't realize there was a physical wire that the news came in on from the Associated Press.
And when you hear it came in over the wire, that was the wire?
That was the wire.
We had the actual wire in our basement.
Yeah.
Incredible.
Well, Simon and I were lucky because we didn't really have any sysadmin experience, but there were some really experienced guys, Frank and Nick, who worked at the company and actually did some training with us.
I remember going into their dark room.
All the lights were like turned off.
You could only see like these Unix shells.
I was like, whoa, I'm really learning the good stuff.
And this is the same Frank.
This is Frank Wiles, who he's been president of the Django Software Foundation in the past.
And he's still very heavily involved with Django to this day.
Yeah.
All right.
Let's talk about 2008.
A lot of stuff happened around 2008.
That was the timeframe a little bit before then Django's open source.
But maybe you'll have to tell me, maybe a little bit inspired by Ruby on Rails.
There's a lot of, in Ruby on Rails, a lot of convention over configuration, a lot of magic.
And Django used to have a little more implicit magic.
And there was the, when Django went to, around when it went to 1.0, there was the magic removal.
And it was the first DjangoCon, all those things.
Tell us about that, whoever wants to take it.
I can talk to DjangoCon a little bit, the very first DjangoCon.
I was working for a radio station in London that was doing a big Django project.
One of my co-workers there was this chap, Rob Lofthouse, who very foolishly stepped up and said, "Well, okay.
Everyone says there should be a conference and no one's arranging a conference.
I'll arrange a conference.
How hard can it be?" The answer is everyone in the school understands it's very, very, very hard.
He managed to pull it off.
The big thing there was that Google offered to host it.
We got the venue and the catering and everything was in Google's campus in Mountain View.
Was 2008, was that the year of the first DjangoCon?
I think it was, right?
I think it was.
And yeah, we pulled together a conference.
The videos from that conference were all available on YouTube, actually.
I rewatched one of the panels quite recently, just out of interest.
It was really fascinating seeing there are people on those panels, like Russell Keith mcgee was on the database migrations panel and he was just like one of the people who was trying to solve database migrations back then and of course he's been an enormous fixture in the python and django community ever since um but yeah that was that was really fun that was uh like how many of
us were that jeff were you at the first django conference i was i was barely working at the journal world like maybe six months or a year or something so yeah i just just kind of experienced at all as a nobody. So it was great. And I think my biggest contribution to that conference was,
so I was working on a migration system called demigrations and Andrew Godwin was working on, I think he was calling it South back then. the, like his migration and we had Russell Keith and I got, I managed to, I made the pitch for Andrew, who was just a student at university at time to be flown to California to present at this conference. I think it may have been his first ever conference talk. And he has been to and spoken at every Django and Python conference since.
So I like to think I helped just provide that little spark to get his speaking career started.
But yeah, it was a very, very notable moment, that first DjangoCon.
I had a mind-blowing moment there. A guy from, I think it was Japan, came up to me. He didn't speak a word of English and he gave me his book that he had written about Django whoa and and he just like bowed and and went away and that's I still think about that and it still kind of brings a tear to me it's like what it's it's mind-blowing that people all around the world that you've never met who speak languages you don't speak use your code like it I still it's been 20 years I still can't even like 100% come to terms with it it's really cool yeah I thought
you're gonna go a different direction and you're gonna say when Cal Henderson put that sign up of the unicorn like that was going to forever be the moment but i don't know if you want to expand well
that's the downside of that first jango con there was a q a with me and jacob and i think it was me i said are there any pony requests and that was intended to mean are there any feature ideas sort of open suggestions and evidently that was the um the impetus for the idea of the jango pony which I despise.
I think it's so dumb and I think that's directly related to me retiring from the project, frankly.
Oh no!
I know it's funny in a way but it's also infuriating to me.
I think it's so stupid and unprofessional and the type of humor is just dumb.
No wit at all.
I'll stop my rant.
That'll be on my own.
Whenever I start my own podcast I'm going to have the first episode on why the Django pony sucks.
Wait, what should it be though?
What would you like it to be?
Do you have thoughts?
I think you underestimated.
I would have guessed it would have went like a it should at least be playing a guitar people love
celebrating this for that event and occasion
qualified people Timo I have one of your stickers on my fridge
that's one of the things I did for the 20th birthday
I designed a new pony
to distribute to people around the world you might have seen one at the Amsterdam event people really like the mascots
a bag of the stickers was passed to me and I passed it along.
To the trash can. No, just kidding.
This portion of Talk Python To Me is brought to you by Sentry's AI agent monitoring.
Are you building AI capabilities into your Python applications?
Whether you're using open AI, local LLMs, or something else, visibility into your AI agent's behavior, performance, and cost is critical.
You will definitely want to give Sentry's brand new AI agent monitoring a look.
AI agent monitoring gives you transparent observability into every step of your AI features so you can debug, optimize, and control the cost with confidence.
You'll get full observability into every step of your AI agents.
That is model calls, prompts, external tool usage, and custom logic steps.
AI agent monitoring captures every step of an AI agent's workflow from the user's input to the final response.
And your app will have a dedicated AI agent's dashboard showing traces and timelines for each agent run.
You'll get alerts on model errors, latency spikes, token usage surges, and API failures protecting both performance and cost.
It's plug-and-play Python SDK integration.
Open AI for now for Django, Flask, and FastAPI apps with more AI platforms coming soon.
In summary, AI agent monitoring turns the often black box behavior of AI in your app into transparent, debuggable processes.
If you're adding AI capabilities to your Python app, give Sentry's AI agent monitoring the look.
Just visit talkpython.fm/sentryagents to get started and be sure to use our code TALKPYTHON, one word, all caps.
The link is in your podcast player's show notes.
Thank you to Sentry for supporting Talk Python and me.
another notable thing that happened in 2008 other than the housing crisis crash that wrecked a bunch of things was the foundation right the jingo software foundation and i think more broadly i think one of the things that makes you know i talked to a lot of different people about different web frameworks and the thing that really makes jingo stick and stand out i think is one the admin thing but the other is the community around jingo and we're talking about the jingo conference the foundation it's just unlike other things there's there's a whole community that you get into when you go into django not just some apis you use you know what i mean so uh who wants to take the
tell us about how the foundation got started so that was i was there uh so the there was the question of who owns the code um it was i think technically owned by the lawrence journal world correct me if I'm wrong. And so that wasn't going to last forever. So we needed to find for legal, you know, ownership reasons, an entity to own it. We didn't want to go the route of Ruby on Rails, copyright David Hennemeyer Hanson. I think that's just really cringe. So it's good to have an organization as part of it. So yeah, we set up 501c3 if that's the right one that we use. I forget.
And yeah, that's basically the origin story. From my perspective, I'm sure there's a lot more
subtlety to it oh gosh do you want to weigh in yeah i was only barely started that time so
like i definitely relate to you know the community around django you were all telling why you got involved and when and how and for me it was it was whacked as a day job but then what got me to stick around is actually django girls and organizing some of those local workshops and you know having organizations like this like alongside the django project not even the main thing is definitely only possible because we've had such a like long running open source foundation. There's lots of aspects of the foundation we could discuss, but definitely, you know, that kind of longevity
for community run open source is rare and to be cherished. Yeah. Maybe you could tell us a little bit like what was it when it started and what is it now? Like how has it changed over the time, over the years? I'm going to put in a plug for the Django Fellows program. I feel like the Django
Fellows program has been an absolutely astonishingly effective part of the mission of the foundation.
For people who aren't familiar with that, the Django Software Foundation employs fellows who are paid contributors who work on the bits of open source maintenance that aren't necessarily so glamorous. They do bug issue, they do code review and handle security incidents and bug triage and all of these different things. And thanks to them, Django has a release schedule that operates like clockwork. Like Django, there's a new release that comes out when they said it was going to come out.
Code gets reviewed, bugs get trashed. It's a wonderful, wonderful thing. It's unique because most open source projects that are run like that have a company behind them. There are people who have a full-time job and there's a company that's commercially supporting that. Django does not have a commercial sponsor in that respect. It has this nonprofit that people fund and that employs these these fellows and the fellows keep everything ticking long. I keep on saying to other open source projects, if you can figure out a pattern to use that's similar to the Django fellows, that's absolutely worth doing. The Python Software Foundation has a developer in residence program now, or several developers in residence, which were inspired by the Django fellows program.
I think it's been really influential. And it's notable because there are very few major open source projects that don't have a company behind them. The other one that comes up a lot is Postgres, Postgres is very much a community-organized program.
If you look at the way Postgres works, a lot of the key maintainers have their own consultancies.
So they've got a good way of financially sustaining the work that they're doing.
I think the Django Fellows Program, which was introduced...
When was that?
That was at least 10 years ago the Fellows Program started.
I think it's been an enormous success.
Yeah, absolutely.
Another thing that I think is really interesting, it's a little bit newer, but is the Django Knots program, right?
And Django Girls as well, shout out to them.
You know, so many people I've talked to are like, I got into Python because I wanted to do Django, which for you all is probably a little bit mind-blowing as well.
Like, they didn't use Django because they were Python,
but the other way around.
The first time I met somebody who said, oh yeah, I got into Python because of Django.
And I was absolutely bowled away.
I always assumed you'd have to be a proficient Python programmer before you could start picking up something like Django.
It turns out it was the other way around.
People would get in from, Because partly because the Django documentation was so good.
But yeah, that's so many people got their start in the Python community as web developers who dabbled with Django and then got into Python from there.
Yeah.
Kenneth, love it on the audience because I learned Python through Django.
Very cool.
When I chaired DjangoCon US, I'd always ask the audience.
For one, like I was always a nervous speaker.
And so anytime you ask the audience to do something, it like takes my nerves away.
But I'd always ask who learned Python by learning Django.
And over half the room every year would always raise their hands up.
So it was a heck of a gateway to learn Python.
on. Also, we just hired our third fellow Jacob Walls last week, who I think starts this next Monday. So Django's up to three fellows now. And it's just been, the load is just incredible. So trying to keep up. I think our existing fellows have over a thousand tickets that they're trying to sort through. And if people are watching and want to help fund, contact Tebow and I,
and we will definitely help you in the USF to support more fellows.
We'll give you our annual reports, which details everything the foundation does,
And more on the other side.
Well, I just want to make one point on that because, I mean, T-Bone and Jeff, you know now, but the finances for a long time, like when I was treasurer in 2020 for three years, the total budget was under $200,000.
And that was almost all fellows.
So like the total budget for everything, including grants, legal stuff, hosting.
I think now maybe it's $250,000, $300,000, but it's, you know, to your point, Simon, it's not funded by a corporation.
It's tiny.
And people don't realize that aside from the fellows, everything else is volunteers, right?
Even the conferences.
It's not, you know, PyCon, US, EuroPython have a lot of volunteers, but they also have paid employees.
Like Django Cons are all volunteers.
Yeah, they're all volunteer based.
The PSF runs a staff of about, I used to be on the PSF board.
Simon's on the board.
I'm on the board.
Yeah.
Last time I saw, they probably have about, what, 2 million in salaries a year because of so many people.
You've got like five or six developer in residence, at least probably what, like 12 to 13 people, maybe 14 people on staff.
That's about right.
Yeah.
It's interesting how much the PSF is an accounting organization because it turns out accounting, especially if you're a nonprofit with like with a whole bunch of organizations who use the PSF as their fiscal sponsor to help them with their nonprofit accounting.
There's a lot of there's a lot of accounting and logistical works that goes into an organization like the PSF.
And PyCon US is run by the PSF as well, which is a 2,500 person conference these days.
That gets very complicated.
Yeah, so the DSF runs on shoestring size budget compared to the PSF.
But Django is a pretty good amount of the community, though.
So that's kind of one of the things we're doing is by getting that third fellow.
And part of it, too, is we've ran, not to nerd out on expenses for a while, but the DSF for a long time has ran with over $200,000 in the bank.
And to me, that's just not doing much with our money.
So I know that we're also doing investments and stuff as well.
But I think getting that third fellow was something that was just long overdue for the number of people that we have.
If one fellow goes on vacation for a while and leave, it's just too much for one person to keep the foundation, keep security releases, releases going.
So it was kind of long overdue, but I'm happy we're able to pull it off this year.
Yeah, that's great.
My favorite talk at JaggerCon last year was Jacob Kaplan Mosk gave a keynote about what the DSF would do with a million dollars.
Like if the DSF could go up to a million dollars a year, what would they spend that money on?
As also a pitch for why you should be sponsoring the DSF.
I recommend people watch that if you want to get a feel for how that organization was shaped at least sort of 10 months ago.
I think there's a huge impact that just having one or two people whose full-time job is to go into the corner, the dark corners of some open source project that's just not that interesting.
Nobody really wants to go mess with, but just start hacking away on those and, you know, really putting the polish on stuff that is not as exciting as other pieces.
And so there's not, you know, you said it's not that big relative to the PSF, but put the PSF aside, any other open source Python project, it's a really huge pool that you're working with relative to how many other projects even have fellows.
Not many, if any.
Yeah.
Super, super cool.
So let's talk about some of the more recent things.
I know that at least personally, when the Instagram keynote came out a couple of years ago at PyCon, or maybe more than a couple, it was 2017, I think.
But around that timeframe, just realizing how big some of the deployments of Django were, how much traffic people were serving through them.
When it first came out, you probably didn't think on that scale.
No, Instagram, Pinterest, NASA.
Yeah, no, that was... The goal was to build newspaper websites, right? We wanted to be able to build... I loved Django's original tagline was "Web development on journalism deadlines". That's always been my favorite description of the project.
Nice. Who else wants to chime in on this idea? Like this is just... It blew my mind. I'm like, wow.
One thing I will say is a thread, Instagram's Twitter clone came out what last year or the year before. That's a Django app. I met one of the engineers of mine. It's just a classic Django app that Facebook launched just a few years ago.
I believe technically they have their own fork. They didn't just download Django 4.0.
I feel like at that scale, if you haven't got your own fork, I'd be very surprised.
But yeah. For me, it runs on center. Sorry. I think I'm a brief
I mean, one interesting thing.
500 milliseconds behind all of you.
For me, as far as scale, there's also the number of projects out there.
I've been doing the counting to figure out our impacts.
And I think we're at around the 500,000 live Django sites and apps out there from the numbers I could find.
And also specific types of outreach.
So governments, for example, seeing how many central governments of all the countries around the world basically use it.
And when I say use it, it's not just like the one project.
They have teams whose role is just to manage 10, 20, 50.
I think right now, Brazil, of all countries, I don't have a connection there, had like 84 sites I could detect in a single environment using Django.
Just imagine that times all the countries.
Wow.
You know, one of the things that's always fun for me to do is to go to the GitHub repo, right?
And I've got Django with 85,000 stars and 32,000 forks.
That's a really interesting number.
That's way more forks to stars than an average project, by the way.
But if you go down the side here, you can see they now track how many contributors and used by 1.997 million projects.
That is a lot.
Now, that's just on GitHub, right?
That are public repositories that we can know about and stuff.
And used by could be a student project, not a government entity.
But still, that's pretty wild.
Very impressive.
Let's talk about some of the more recent transitions.
I mean, I feel like the speed of major version releases is picking up.
You know, we had the first three years, 2005 to 2008 for one.
Then it was like one for a while, and then two, and then three, then four, then five.
You guys are maybe working on six.
I don't know.
And also adopting some of the lot of changes coming in Python, right?
Like async and await and that kind of stuff.
How has that been?
How did it start?
In some ways, it's really tricky because people really love Django as it is.
And from that standpoint, you have to make sure that such a big group of people agree on what exactly the future of Python means.
So, you know, definitely mentioned AsyncAway. It's one of the big ones.
API, is it in Django Core? Is it not?
Mobile web, how much we get involved with that?
These days, it's like the HTMLX that people really want to see Django support well.
And I guess also AI to some extent. I don't know if we want to get there.
But I guess for us, I think it's also, if it's not in core, we definitely have so many packages out there that we just try and curate a bit more these days, make sure they work well together.
So that also helps a lot.
Yeah.
I think the package curation is really important.
I would actually like to see Python in the standard library smaller and then recommend more stuff to keep the flexibility open so they could move faster, focus more.
So what I find tricky about this one, Django has always been a batteries-included framework, And that's because in 2004, 2005, PyPI and PIPA didn't really exist.
So if you weren't batteries included, then people had to, it was very high friction for people to glue together the pieces that they needed.
And of course, today, I feel like Python packaging is incredibly good shape.
Like you could ship a web framework today that was entirely dependent on other things.
So then the value from the Django thing comes down more to everything being, that there's a Django promise that the stuff in Django core will continue to work. You're not going to have a situation where Python 3.15 comes out and Django templates stop working, but the ORM still works because everything is maintained in the one place by that single team. And I love that. I love that you just know that all of the pieces of Django are going to continue to work together. And the moment you add external packages, there's that little bit of risk. What if that external package that you're using becomes unmaintained in the future? So I'd quite like to see just a little of a sort of adoption of crucial packages under the Django software foundation, but not as part of Django itself. I want separate packages that maintain that promise to be maintained. Because we have fellows, which means that we can actually do that kind of work. But it's also a very big commitment to take on. It's an interesting pattern that I'd like to see explored a little bit more,
I think. Yeah, it's easy to forget that it wasn't always there. Sorry, Will, go ahead.
I was just going to ask Adrian and Simon. I mean, even today, batteries included web frameworks are not that common. It's still the trend, more micro frameworks. I'm curious what your take is on that. I mean, like FastAPI, right? That's a lightweight framework. It seems, I'm always shocked there aren't more batteries included frameworks in PICA language. Maybe it's too difficult to do, but micro frameworks seem more common. There's sort of only one batteries included option for programming language.
I feel like the sales pitch, like you get to pick the best pieces for the components for your project, always sounds great.
Obviously, you don't want one thing that dictates what you're going to use for all of the different things.
You'd much rather pick and choose the things that are most valuable.
But the trade-off that people don't talk about much is the fact that now every single one of those selections is getting you further away from that sort of community standards.
There's more risk of future maintenance problems.
There's more work that you have to do to wire things together.
But I feel like the biggest innovation in the open source world in the past 15 years has been packaging.
Like every programming language has a PyPI style packaging solution of some sort.
You've got cargo and you've got the Ruby gems and all of those kinds of things.
And that pattern mostly works really, really well.
But I just keep on coming back to that feeling that with Django, I know it's all going to work.
And I know it's going to work far into the future.
And that feels really valuable to me.
Good, Adrian.
For my answer, I think I'd have to evaluate it on a case-by-case basis, but the way I would evaluate it is to look at the origin of the project.
Was it extracted from something from the real world or was it built either as an academic or for fun exercise?
What was the reason for its existence?
And generally, I trust stuff that was extracted from real production sites more.
That's just my own preference.
It's also sort of to flip it around. I never really cared whether someone used Django or not. I would evaluate you on your product, not based on like the web framework you use. Who cares really what web framework you use? And I think that kind of ethos may be seeped into Django at some point unintentionally. I mean, I never intentionally sort of made that, had that philosophy communicated, but yeah.
I always felt like one of the most interesting difference between Rails and Django is that Rails was extracted from Basecamp.
They built Basecamp and they pulled the framework out of it.
I feel like Django was kind of reverse extracted from Lawrence.com because we had Lawrence.com.
It was PHP and MySQL.
And the goal with Django was always to get it to a point where it was good enough that it could replace the PHP in Lawrence.com.
So everything that we were building was always like, what would Lawrence.com need in this new thing for us to replace it?
And the end result was a framework that you could build Lawrence.com in.
Lawrence.com was the entertainment website for the newspaper.
It's the best local entertainment website for any city that has ever existed.
I will very confidently state that.
I've never lived in a city with a website as good for figuring out what the things to do in a town are.
And that was Adrian's biggest project, Lawrence Journal World, was always Lawrence.com and evolving Django up to the point where it could power that site.
It's what got me here.
Like I saw that site living 200 miles away and went to San Francisco and kind of looked at Y Combinator and was like, you know, this is only 200 miles.
Like they've got something good going here and that site especially.
I think to a Django's batteries, Django, I think 20 years ago, Django, there was a lot of things that you had to do the Django way.
And I think there's been so much concerted effort, especially the first 12 to 14 years.
It's so much as pluggable that like if you don't like the batteries, I don't know what you're missing.
Like Django is still a really good core.
Don't use the admin if you don't want it.
I think most of the problems I see, the foundation and the community, I think there's like a lot of lore that comes with Django.
And it's like lore of like, maybe it's harder to change certain things on the website than it really needs to be or is.
And I think this last year, we've definitely pushed back on, like, if you do a search on the Django docs now and you look for REST, you wouldn't know that Django is a REST framework or has the ability to do that by looking at the docs.
And so these were just technical challenges of like certain steering council members have written articles and stuff, blog posts saying like, you can do rest with Django.
There's some good third party packages to do it.
In the past, we've kind of been like apprehensive to want to recommend third party packages through docs.
I think that's just one of those.
It sounds weird when I say it out loud.
At least it does to me.
And I think once we have these discussions, then we start like realizing that, well, we have a website that everybody comes to.
There's very specifically doc sections and there's blog, but there's no search that pulls stuff in together.
And so the steering council and different members have been trying to make search work across everything.
And then that way you can get hits from rest and you can get hits for third party packages that the steering council recommends just because they're good packages everybody should use.
And so I think some of the lore and some of the, hey, these things have been done this certain way doesn't mean we want to keep doing them.
It's just probably somebody had an afternoon or a night and they made search work a particular way.
And that was really good for the docs.
but like sometime look up REST and look at PHP.
There's actually more hits for PHP on the Django website than there are REST
unless you get into like Sphinx, you know, restructured text.
So, but those are challenges that until we talk about and we realize, and I think like that's the advent of a FastAPI kind of taking off is I think like Django didn't have a great REST story by looking at the docs and looking at information.
At PyCon US this year, I had dozens of people ask me, how do I use the Django ORM from FastAPI?
And it's like, why?
You don't have to.
Django is async enough that you don't need to do that.
That's hard.
And that kind of sucks to do.
So why?
And those are things we're focusing and talking about internally too.
Yeah.
Talking about search and search across different things, somewhat directly to you, Jeff, but all of you, and maybe Simon as well, is like, what about just like chat.djangoproject.com and do some rag on it and let people have a conversation with Django?
You know what?
We don't even need it because Django is stable enough that every chatbot out there knows Django inside out already. One of the great benefits of having great documentation and lots of examples for 20 years that is stable is, yeah, you can, GPT-5 will spit out a full Django project and just
get it all right. So yeah, I completely disagree. I think we need a big sponsor who can come in, whether it's Anthropic or OpenAI or somebody else. We need a big sponsor, a title sponsor, even in fact that can help give the money for this and donate the chat.
Because even though you're right that it isn't ingrained, you still have that delay between because Django kicks out a new version or two a year.
And so there's always that lag of nine months or a year.
And most of it recommends the most popular version, not the latest version or something like that.
Right.
Exactly.
Yeah.
Because I see a lot of demos where they're actually building Django apps using these, these tools.
And so we're selling AI by virtue of Django and Django's docs being so good.
Or occasionally one of these things will say that Sound Slice has a feature that it doesn't have, and then Adrian has to build the feature.
Oh, God.
Oh, you guys, in the chat, it's coming on here.
We have Frank Wasson, but our chatbot can have a cool personality.
And Kenneth loves to insert a random name every once in a while or something, you know, pony style.
Adrian, what is the story behind that?
Oh, it has nothing to do with Django.
So yeah, just the 30 second version is ChatGPT was telling people about my site, my company sounds like having a feature that doesn't actually exist.
And it was happening like dozens of times per day.
And so we had this inbound set of users who had a wrong expectation.
So we ended up just writing the feature to appease the ChatGPT gods, which I think is the first time that at least to my knowledge of uh yeah product decisions being influenced by
misinformation from llms i just love that it's easier to just build the feature than to get the
misinformation corrected like there is no he's got to backfill it he's got to backfill it
incredible all right um that's crazy i let's let's do two more quick topics like somewhat lightning round, we have about six minutes left for this show. So one, there's been, you guys mentioned it a couple of times, and it's also just kind of going back and forth in the audience here, that the whole REST idea. So we've got, you know, Tom Christie doing amazing work with Django REST framework. We've also, I think, you know, people who do talk about FastAPI and how do I use the ORM with it, like Django Ninja, which is really, really close to FastAPI and so on. That's one side, that's a really positive side of things with Django. And the other side I think is, you know, I'm not a super fan of, but it's, it's something a lot of people do is, well, can we just make the backend a dumb crud API thing? And let me just write everything in JavaScript on the front end, which I'm not as much of a fan of. I think a lot of people choose that because they've been told that's how it's supposed to be. I don't think it needs to be that way.
So what do you all feel about that? And sort of the, how this has an impact for Django, Because if people just see the backend as an API that's just a dumb thing, then a lot of the value that Django brings, I think, starts to vanish.
You've got things like HTML and so on.
So, yeah, what are your thoughts on all this?
I think one of the hardest problems in computer science right now is talking a front-end team out of building everything as a pure JavaScript app, especially if that's developers who onboarded in web development over the past five to ten years.
It's infuriating because my impression is that it just takes longer and you get more bugs and it's harder to build useful software.
The one thing I will say is that HTMX has been a huge breath of fresh air on this front.
HTMX gives you your single page applications.
It's all stuff that's rendered server-side in templates.
It fits really well with Django.
There's a great Django extension for looking into HTMX.
And I feel like that, the pendulum has just started swinging slightly back away from the everything must be rendered in JavaScript thing, partly because of the work that the HTMX people have been doing.
So that I felt pretty good about.
I'm going to point to Adrian now because SoundSlice is a pure JavaScript front-end app, and it should be based on what it does, right?
Yeah, it's interactive sheet music.
So it's sheet music that's rendered entirely in your browser, responsive, blah, blah, blah, with an editor, a lot of crazy JavaScript.
But yeah, I mean, this is a whole other podcast episode about the horribleness of modern web development.
I feel very lucky that I came up 20 years ago when before it got so insane.
But yeah, I have sort of a related comment, which is I would like to see Django be a stronger advocate for the web in general.
It doesn't matter if you're talking to developers or people using tech products.
the expectation has been shifting away from the web to the phone for many, many reasons.
And I don't like that.
I'm pretty sure that most, if not all of the people on this chat don't like that either.
And I don't really see a lot of effort being pushed in that direction.
So just to sprinkle a little idea here.
I personally wish that progressive web apps were more front and center, giving you an option at least like, okay, you have to be on the phone,
but could we package it up a little more?
There's a really exciting development there that's finally beginning to be rolled out.
There's this thing called view transitions in CSS, where you can have a little bit of CSS that says, "And when the user goes from one page to another, keep the navigation bar in the same place and do a quick blur effect for this piece here." It means that...
And it's been supported in Chrome for a few years.
It's finally rolling out through the browsers.
It means you can build something that feels like a slick app with page transitions and so forth, but it's not.
It's just boring old HTML and CSS.
No JavaScript required at all.
Gives you that experience much faster to load.
And I have been itching to see this start showing up.
And I think it's finally this year, I feel, is the year where the browser support is good enough that we can start really depending on this.
And yeah, because it gives you that app-like experience on a boring old website, which is, I feel like, that's the thing that we all want.
So back to part of Adrian's piece, and sorry, Tebow, real quick.
My second thing I have to pitch is because of what Adrian was saying.
I think because systematically we, you know, we are really lucky to be around for 20 years because we've had nothing but volunteer leadership in years.
One thing we want to do is find an executive director, somebody that can run the foundation.
The biggest reason goes back to Adrian's point.
I think that we sometimes don't get a seat at the table when it comes to web standards, when it comes to these conversations, is because it's the cycling of Thibaut being the president now.
It was Frank before.
It was Anna from Africa.
We've had many really good presidents over the years.
But it's really hard to work with foundations and nonprofits when you don't have a set person.
Even our fellows seem to rotate every three to four years.
And so that's part of like Django growing up, which is something I would love to see us do.
And then Thibault, I love the fact that this started off in the middle of like the day.
And now it is like perfectly cycled to like dark.
Yeah, I guess it was high and curve you as president.
Go ahead.
To me, there's a developer experience and like keeping devs happy.
So, you know, when we say our people go to React or whichever like JS heavy, It's also because they think they need it to build whatever complexity that they are after, but also because they think it has good DX, I assume.
So when we say like the REST framework or the Django Ninja, to me, it's this as well, that we have to be aware of what's the evolving standards for what devs want to do with their web.
And I guess how we can make Django meet that, whether it's better types, better CLI, better packaging, more Rust, maybe, whichever.
Will, do you want to get a quick word in on this everything's a front-end thing now before we move on to the last bit?
Oh, sure. I'm just going to say, and this probably goes back to Adrian and Simon, like all of them,
it seems very wise to keep the front-end light because there was certainly 10 years ago a lot of pressure to integrate React or Vue or Angular or something.
But the fact that it's remained just the Django templates means HTMX can rise and we can have more innovation.
And just shout out, Carson Gross of HTMX is giving the keynote at DjangoCon US in three weeks.
So even though he's not a Django developer, he's in fact more of a, he's a professor who does Java and obviously JavaScript.
It still slides into Django in a way that if Django had built out the front end story, we wouldn't be able to.
I love how that also fits.
DjangoCon has had a long tradition of having a keynote from somebody from outside the community, which started in 2008 with Cal Henderson at DjangoCon over in Mountain View.
Was that the why I hate Django?
Because there was that whole history of, I feel like there should be another one of those, you know?
Absolutely, yeah.
But that's great.
That's a fantastic keynote for DjangoCon, I think.
Yeah, and coming up in Chicago, right?
Pretty soon.
So if you are in or would like to be, go check it out, right?
That's part of that community thing I talked about.
And people listening who are not watching, listening, not watching, they don't realize that you did this outside.
And there's a great comment from Kojo saying, It's really cool that you're using in real life dark mode.
It's great.
All right, let's close it out with this, everyone.
We're pretty much out of time.
20 years, you know, amazing, amazing stuff.
We're celebrating Django having its birthday, right?
But it's going to live on for a long time.
There's a ton of code.
There's a ton of things people are doing with Django.
Even if you guys step away at some point, it's still going to be going.
So give me your, you know, going around and starting with Will, I guess.
Give me your forward-looking thoughts on Django.
over the next five, 10 years?
Well, I think it's integrating with AI, broadly defined, however that means, because in a way related to Adrian's point, like the boring old web has never been more relevant, even though we're focused on chatbots right now, you still need all the other things.
And Django can integrate into that.
And I think it's always kind of a marketing problem for Django because we don't have one person in charge or a company behind it.
So telling the story of we've been here, there's still double digit PRs.
It has async in many areas.
And I worry that the next generation of web developers just skip it because they don't know what it already has.
And they have this presumption that it's too hard to learn, which it's not.
Yeah, absolutely.
Is it me?
It is you.
I don't have any.
I hear you're boring about the web.
What's going on now?
Tell us about what do you see for the future?
For the future.
Yeah, I'm actually, perhaps ironically, like the worst person to ask because I have worked on the same app for almost 13 straight years full time now.
I use Django every day and it does everything I need.
So I'm very happy with the current state.
And I think, like I said earlier, if it were up to me, the thing I would focus on is more philosophical or trying to promote the concept of the web versus non-web stuff.
Because if the web goes away, Django goes away.
I mean, it's inherent.
A lot of beautiful things go away, yeah.
A lot of beautiful things go away.
So I think that would be my hope for the next five years.
Yeah, I've done combat with the App Store review people, both Apple and Google, and it is not pretty.
We do not want the web.
There's definitely AI in there and definitely the web.
I really like that you mentioned the view transitions.
I think if web technologies get that much better in the next five years or so, we can match what's possible with a mobile dev, but not only match it, but in terms of accessibility and how many people you can reach with a web app.
We can go far, far beyond.
So I guess to me for that, the other side is having a foundation behind Django that's probably a bit more professional, that takes it a bit more seriously, that we're the people looking after the framework for millions of devs at this point.
And as you said, the people in this room, we come and go, that's very natural.
So just making sure that we have the pipelines.
So hopefully five, 10 more years, you know, the Django node space you mentioned earlier, that's the people who will be the presidents and people having this podcast maybe in 10 years time.
Yeah, absolutely. Jeff?
I'm really curious to see what Rust's impact is.
I think Python is just getting so much faster, so much better.
And I know there's some really smart people working on like WebAssembly and Rust.
And I dream of a day when a Django view can be the same thing in your browser as it is on the server.
And I think when we look at like talking to a query set, your browser, you know, doing data exchange, serialization, JSON, something.
I feel like in the next five years, there's this there's this opportunity that whatever Python is becoming, whatever Django is becoming that like, you know, it's less about how are we going to use React and render?
I hate React, by the way.
You've got to put that plug in.
But I'm just really curious to see like how these things can kind of mold together as, you know, developer experiences have gotten a lot better because of tooling and Rust.
There's just this whole new world that I see as far as these technologies that start to marry the two together in a way that we just haven't been able to do for a while.
But we're starting to see glimpses of it.
For sure.
Simon, final word for...
I'm going to double down a little bit on the WebAssembly stuff is so exciting.
Pyodide, the thing that lets you run Python in your browser, is now at least 10 years old.
It's very, very good.
It's about a two megabyte download.
A few years ago, I'd have said two megabyte downloads is too much.
These days, 2 megabyte download for a web page is hardly anything at all.
But I feel like the thing that I love most about Django these days is it is reliable.
It's so dependable.
Nobody ever picks Django for a project and regrets it because Django, it's mature, it's stable, it's well documented.
It moves at a sensible place.
Long may that continue.
I love the idea that Django becomes...
And Django for many years has been a great default technology for you to use as a project.
And if we double down on that, which I think is what we're doing already, that's fantastic for me.
I love that idea that you can always pick Django.
It will always do what you need it to do.
There will never be any nasty surprises or sort of regrets from working with that.
And if we can tap into things like free-threaded Python is coming along now, which is very well, it means maybe we don't have to rewrite everything as async things just to handle large concurrency.
There's all of that kind of stuff, the WebAssembly stuff.
It feels like the Python ecosystem is in a really good shape.
And Django sits very close to the center of that ecosystem.
And I'm really excited about that.
I love that we can continue to provide the best default option for building great things.
Yeah, totally agree.
All right, everyone.
Thank you so much for being here.
Happy birthday, Django.
Thanks, Michael.
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.
This episode is brought to you entirely by Sentry.
It's a bit of an episode takeover, if you will.
Sentry has two excellent and exciting services to tell you about.
Sear, your agentic AI debugging assistant, which takes all the data already gathered by Sentry to help discover the problems and even propose fixes as GitHub PRs.
And the other is AI agent monitoring, which adds deep observability to your AI agents in your app.
If you're adding AI and LLM features to your Python apps, you'll want to know about AI agent monitoring.
I'll tell you more about both of these later in the episode.
And remember, however you happen to sign up for Sentry, if you do, use our code TALKPYTHON, one word, all caps.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at TALKPYTHON.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show, open your favorite podcast app, and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy. Thanks so much for listening. I really appreciate it.
Now get out there and write some Python code.
I'm out.