Transcript: Django’s Rough Edges - Keryn Knight

I'm Carlton Gibson, joined to serve by Will Vincent.

Hello, Will.

Hello, Will.

Hello, Kez, thanks for coming on.

Appreciate it.

Wanted to have you on for a while.

Um let's let's start.

We always kick off with your backstory.

So tell us about uh about you and how you got into programming and how you found Django.

Um, managed to get my first job doing that kind of thing that led to more kind of full stack work where I'd you know be involved in the back end and a lot of the front end back when the front end was much simpler than it is today, you must stress that, and started out doing like PHP backend stuff, and ultimately in around 2010, uh sat down to try and make something more maintainable when we were working in a

web development agency.

Obviously, there's a lot of juggling of projects there.

We were looking for something that kind of fit the bill and was easier to onboard and revisit later.

And we revisited a whole bunch of different frameworks, cross-languages, and ultimately settled on Django as having the least cons of all of them.

And I've been using it ever since.

Obviously, everyone supplements these things with your relatively standard CMS or CRM kind of work, uh, because that's reasonably quick to turn around if it isn't too complex.

But you had things like WordPress kind of taking control of those kind of markets, uh certainly for the CMS stuff anyway.

So that meant that we moved more into kind of bespoke uh aspects, whether that was tailoring a whole back office system or building a REST API on top of some complex uh job system.

We really kind of ended up running the gamma in terms of the range of things we would take on, uh, some more successfully than others, inevitably, but it did become very uh varied, I would say.

And so the the I wanted to ask you then how you got into contributing Jenga, because you've you know you've been you're just very active and you you come in on particular issues and make very insightful comments.

And as I look through the issue history, you've been doing that for a long time.

It was probably around 2013, 2014 when I actually found something that might be considered an issue.

Um the the longer I've worked with it, obviously I've become more familiar with the kinds of things that are likely to be considered bugs and the kinds of things which are likely to be no, this is actually a problem in in user land.

Um I would say that you know one of the things is to just keep trying.

Fully 50% of my tickets over my career must have been closed as won't fix because they were some misunderstanding I had or something that had been re-red elsewhere in a previous ticket or something, but it's a case of just continuing to kind of try your hand at it.

It's it's not a difficult thing, particularly, and the most that really happens is someone closes it as inevitably not relevant.

That's the worst that happens.

Uh the best that happens is you either you get a new feature that you really after, or you fix a bug that affects you and a bunch of other people.

And I think how I ended up starting that contribution excuse me, contribution process was really just a couple of things I encountered that I thought were errors, and they weren't.

They were my errors or they were a third-party library's errors.

But it begins that process of actually talking uh with the community about how things progress and whether it's right that they are not in core or are in core, and it's you know, it's uh potluck for me sometimes as to whether it's uh it's gonna get accepted, and that's always interesting if nothing else, because you can't have everything in but much as you'd like to, and there's obviously whole

cohorts within the community that have divergent ideas about what should be in there and what shouldn't be in there, and they can become quite polarizing.

So stri straddling that middle ground of what makes the cut is is always an interesting thing to try and establish.

Yeah, okay.

That's something that you know I do, but not very often, and yet you're quite frequently there with ah, you know, and if you configure a script this particular way, it you know, this happens.

There's there's whole aspects of of Django and indeed Python that I'm not as well versed in as I might hope to be.

The uh ORM has come on leaps and bounds over the years, and there's bits of that now that I've never used because of that.

But there's also other things where I have used settings.configure to do something outside of a normal management command, and I've had to become aware of the foibles of doing so.

And because that's the less common approach, it's more valuable for me to step in in those kind of things where it hasn't necessarily been considered because it's off the beaten path.

If it's if it's the if it's the common 80% use case, then everyone's already going to be thinking of those things anyway.

So there's there's not much I'm gonna say that's interesting or poignant towards it.

Fair enough.

Uh what what how has it changed?

Uh I mean, just big picture, because a lot of people are new to Django and don't don't have that history, you know.

Just what what have you seen that you like and dislike in terms of the change in that time?

So I've already missed the boat on probably the biggest change in Django's history.

Um I think some of the kind of bigger ticket items that have really helped the overall community have been things like the bringing into core of a migrations module, which was previously South, and the new migrations module is more flexible and also more robust, and that's certainly not to do disservice of South.

We all used it uh prior to the inbuilt migrations.

Um and the splitting out of like the template template backends so that you can use Ginger or Mako or whatever else you'd like to use.

I think that was a that was a great step along with uh the introduction of app configs.

I think by and large those aren't necessarily used as much as people might have expected.

I mean for certainly for beginners.

It's like because I cover it in my book, and I'm like, you can do all these things, but you you know, you won't necessarily like I don't see it used a lot at at the uh you know more beginner level that I teach.

And of course, Ginger specifically being so similar in look and feel to Django, people don't necessarily know why they might want to reach for that, and the answer to that is usually just a sheer performance one because it compiles bytecode differently and magically, and I don't understand it, but it's cool.

But I th I think the the app config one specifically didn't happen in the way anyone foresaw because there was a long time where the concept of a default app config meant no one had to adapt, and I think the overall adaptation has now happened in Django itself to force that and finally deprecate that.

So I think we may now see more dependence on things like an app config that wasn't there before, but that also comes with its own slight tricky intricacies.

But those are those are the big ticket items I can think of in terms of what's actually kind of progressed, and I don't mean incrementally in terms of like, as I say, the the kind of modelling of database stuff that's improved leaps and bounds.

Uh, you know, the introduction of subquery syntax to actually manually build those was a pre-uh revolutionary thing because it allowed a lot more flexibility in what you could do that wasn't magically done behind the scenes for you.

But I don't know, I don't know enough about those because they keep improving incrementally, and I might be on the last uh long-term support version.

I don't necessarily see, oh, okay, I can use this for that until I get round to the next one.

So there's bits I'm less familiar with.

Um it's like a ha, there's just all the I the a the RM has become like, oh wow, there's it it's very sophisticated compared to what it is, and it's like it's kind of hard to learn these things because the docs can be a bit terse.

But the more we can focus on what these improvements actually bring to the table, the more the users can get their head around it.

But yes, the Expressions API is exceptionally powerful, and I probably don't make as much use of it as I'd like to because I haven't fully thought through how to do it in that way.

Because I have that long history of using it, I'm used to doing it a certain way to work around the fact it wasn't there, and now I can do it, but I'm not thinking about it because it's too new, so to speak, in terms of my overall trajectory using it.

It's uh in in many ways, it's easier for a new learner to come on board and get used to the modern way of doing these things because by the time they are starting it, the incremental journey has already gone so far.

But it also means that yeah, you can end up not out of date necessarily, but stuck in your ways.

There's nothing wrong with being stuck in your ways.

That's fine.

Oh sorry, Carlton.

Well, I was just gonna segue off.

Um you mentioned the the new features of Python.

So um while we while we're talking about new features of Django and Chains, what do you what's your sort of take on the the way Python's evolved?

doesn't necessarily make sense in that first kind of almost prototypal phase where you're first building something out.

And I'm thinking especially of uh type annotations, they've become very popular recently through things like uh MyPy, and there's a couple of others whose names I've forgotten that do type checking.

Those add a huge amount of verbiage to the average Python project for the safety of making sure it's doing the right thing.

But that's that's exceptionally difficult to reason about for a new learner.

Um, there's also things like the walrus operator turning up, which I've used it more than I thought I would, which is a

Um you know there's I've there's use cases for it that I didn't think I'd have, but by the same token, it is the introduction of another type of declaring a variable, and now a new user has to learn that.

So I think Python's in a tricky position overall in that it's trying to adapt and become more modern, but it may ultimately be leaving new users in the dust as a result.

Maybe it's not his name, maybe it's you know, just but it one of the great things it fits the right size for your head and you can hold it all in.

I don't know if it still is, uh, especially with the kind of introduction of the whole async.io ecosystem, and I think that's somewhat fractured, which is always going to be a difficult one to deal with.

But in intrinsically, through the kind of 2.0 to 3.0 release cycle, you could hold it in your head, and that became slightly truer again when uh 3.3 came around and we had things like Unicode literals again.

But it is still expanding, and there may come an inflection point where you've alienated your new audience, and you're then left with power users, I suppose we would be, but who know all of that syntax and have internalized all of those things.

It's a difficult boundary to straw to straddle.

ared to say PHP or Go, where you're just compiling a static binary, and that's always been one of Python's problems, and I think that hasn't changed particularly.

It's got better in some ways, it's got worse in some ways.

Now we talk about the async IO situation and we talk about red and blue functions and how those affect the overall ecosystem, and ultimately it is still a transitionary period for Django.

I I know at some point in the future it will be entirely async IO all the way if you want it, and at some point in the future it will become that by default, but it's still a process we're going through in terms of getting that adaptation all the way through the whole chain, which is you know substantial, it's a full stack framework for the back end, so there's a lot of moving parts and there's a lot of things that can change

at runtime, which makes it slightly complicated to even figure out if it is synchronous or asynchronous.

It's uh it's somewhere down the line.

I don't know.

I mean yeah, maybe.

I mean, in principle, why not?

Because in in in principle, it should be um slightly less resource intensive to um use asynchronous IR.

Um there's a context switching cost, but you know, if we can if we can make it async all the way down, then you know you should be able to declare a sync view at the top if you want to.

I mean the one the why not asynchronous asynchronous code?

It's because it's more difficult to write and it's more difficult to reason about.

So 90% of view code that you write should you should just be using sync Django like you've always been using, because that's going to be the simplest to write, the simplest to maintain, and it's gonna be as performant as you need it.

Then why do we need async an asynchronous story?

Well, Django's you know a full stack web framework.

It it's there to have all the batteries, and you don't want to change web framework just because you need high throughput for you know a particular endpoint or you you want to make some parallel API requests or something.

I don't know what you know, but we need a story there.

Do we need to be the fastest web framework in the block?

You know, no, we don't.

Um so I don't know.

I don't know what hell where it'll end up.

I do see though that you know, for instance, to get we've got an async view dispatch um thing in place now, but we still have to sh um kind of uh uh wrap the the synchronous signals that you know request started, request finished, those still synchronous, so we have to wrap those in a sync to async um wrapper, and that goes out to a thread, and okay, there's a slight context cost there.

Um could can we get rid of that?

Yeah, there's a PR to get rid of that, but there's a performance overhead, it's really complex, and it's like okay, and it takes a long time to sit down with these PRs and really work through exactly what's going on and exactly why it's slower, or exactly why it's quicker, or exactly what the error conditions are.

And so it's gonna take a little while.

Um, I'll agree with that bit.

I mean, I've I was a studied history in college, so I always like to look at past examples.

I mean, there is a life cycle to programming languages, and the fact that Python was a teaching language and then kind of got adopted early by Google, and you know, in many ways, right, the data science people made the shift from two to three happen because the website that was kind of a mess, but we had all these new people come in.

But that does seem a fundamental tension of for a language, right?

It's like who drives the use, it's power users.

Um you have more, I think, background than I do.

I I'm just trying to think if there's examples of other languages that have gone too far in the power user side and lost people.

I mean, I think at PHP, PHP has gotten a lot better um over time, I would I would say.

But I'm sure there's

Um, you know, I le I left before it had a package manager and composer, I left before de facto standard frameworks came out in terms of like Laravel and Symphony.

Yeah.

So they kind of revitalized its uh kind of availability in terms of doing big back-end systems, I would say.

PHP always had the benefit of being exceptionally easy to write and easy to run, and it mixed concerns within one file often, but that was fantastic because it allowed people to actually see their results.

It grew up with the advent of PHP 5 through 7, it developed all of these extra features, taking them from other languages and other frameworks and other ecosystems, and I think it very much is in a good place now.

It's you know it's reasonably performant, it's got a great story across any ecosystem niche you might want to fill these days.

I would think, in terms of the kind of language familiarity I have, Pearl would probably be the one that I would think has sort of entered into the end of its lifetime.

And that's not to say it's a bad language and it's not to say people aren't still using it to do incredible things.

It's a great text processing language, but it's one of those things where its time in the sun has waxed and waned whilst Python is still kind of currently over the last 10 years very much in that middle ground.

Python has seen a huge increase because of things like the machine learning and uh all of that kind of stuff that that I don't really understand.

I it's it's an entire part of the ecosystem that is beyond my understanding, but there's a lot of cool stuff happening with like PyTorch and TensorFlow, and people are using it as a as a glue language, and that enables the pickup where people don't necessarily have a full understanding of the language, they can still write the things they need to write.

I think you know, in the in the long term over the next 10 years, we may find that some of that dissipates because those use cases will be fit by a different language, but we may also find that it just gets codified as Python is the language to do X, Y, or Z because it's been doing it for so long, because it has a decent API for it, what have you.

It's it's still, I think, too early to say that Python is on its way out in any fashion.

I I wouldn't uh I wouldn't bet on that particularly, but it's it's an interesting period, and it's become more interesting over the 3.x release cycle with all the new stuff we've got as a result of that.

Time will tell.

You can't bang out your 30-line pie script that does what you want it to.

But I also don't necessarily want to write them because historically, being nominal typing, they've seemed like the wrong kind of fit for what I'd like to do.

Python is a duct duct typing-based language, and more recently we've got structural typing in terms of protocols, and I think that that's a great addition, but unfortunately it is still relatively recent, so a lot of the type annotations you see out there will be the old this is an integer, this is a class of x, y, or z, where perhaps they could be more flexible.

And I think that's that's probably part of the reason that Django itself doesn't have type annotations.

If you if you look at the various stub projects for it, they are exquisitely detailed but exceptionally complex because of that duct typing that means you can pass anything in that fits a certain structure.

And just taking the example of a user, you know, where a function takes a user object, a Django user object, like the type in was horrific.

Um because and because it can be an abstract user, an abstract base user, you know, it it's just too many types.

And so, you know, you might create an alias where you say a user is in fact this this horrible thing, but it's like wow, that's that really is quite flexible in what's accepted in this function.

Yeah.

Yeah.

Yeah.

Actually, no, he just joined a company full-time, but he's uses Laravel, and so he's always forwarding me things about Laravel, and and they've there's huge advancements there.

Sometimes I I feel like the people I know in the Django world were a little bit myopic in terms of you know, there's fast API, but non-Python language frameworks.

Like Laravel has a lot that's interesting, but the model where it's um just one person owns it and runs it so they can just make decisions is sort of this you know balancing act.

It's sometimes it's nice they can just do it and monetize, and they don't have a Django Software Foundation board.

Um, but there's less of a community or it's a different type of community.

So that's interesting for me to see.

He's constantly sending me all these features that they can do and monetize, and um sometimes I'm jealous that they can move faster, but I I also think about what you know, what's the cost?

I mean, because it's a one it's a one-man operation ultimately still.

Um, and I wonder how sustainable that can be.

ing quite quickly, but you have to balance that with the amount of churn that produces.

Uh Django is an exceptionally old framework by modern standards, it's been around like 15, 16 years or something now at this point.

So there's there's a lot of users, and a lot of us are used to doing things in a certain way.

Certainly, there are things I wish Django had done differently, and or I wish Django would jump in and produce something that hits that 80% case that I see it's missing, but it's more democratic in that if it's all just ultimately contributions from the community putting them into track and the mailing list and talking about those things.

And the we have the uh Django enhancement proposals thing to make sure that if something big is coming into core, it's well spec'd out, and I don't I don't know what Laraville has in terms of that, but you can see that they are moving fast across a lot of different fronts, and it's it's an interestingly different community in that aspect, and yeah, absolutely there's parts of that I'm super jealous of because they move fast, but there's also a part

of me that's like, thank goodness Django doesn't move fast.

Yes, I might wish it had X, Y, or Z functionality or it had done this differently, but it's a very stable framework overall.

The number of times I've had real issues changing things on an upgrade cycle are because of third-party dependencies.

Most of the changes internal to Django are one, they're in the release notes and well covered there, but additionally they are relatively minor because it's got that incremental path and it doesn't really subscribe to semantic versioning, so you just upgrade to the next one.

The biggest change is when you go from long-term support to long-term support, and even that's mostly just warnings.

So it's uh yeah.

I would say I wish there were things Django would do and faster, but I entirely get why it doesn't, and certainly it hasn't stopped me using it over these last 10 years, so hopefully great effect.

Do you think do you uh do you think there are limitations to that approach?

That's certainly how migration started out, that's how static files started out, uh, and there were various community provided ginger integrations, for example, to cover off the things we talked about earlier.

I think the problem with r relying so much on third parties is one, you're then beholden to an even smaller cohort of maintainers because a lot of these third party packages won't have yeah, there's just one person.

Absolutely.

Um so you become dependent on a smaller number of maintainers, you become dependent on a larger divergent set of maintainers who obviously have different priorities and they have you know lives that they want to live independent of their open source contributions, and ultimately, whilst it does sometimes pave the way for things to come into Django proper, it does also mean that Django itself doesn't have an answer

for that.

And the biggest, you know, one of one of the biggest areas now served by Django itself, I would say, is REST APIs using REST framework.

Previously we had things like uh Tasty Pie very early on, uh there was a couple of others, but REST framework seems to have taken the mind share overall, and that's great because it means the community works entirely within that ecosystem, but it's still a disappointment that when you come to say to a new user, let's use Django for this, then they ask about that story

How do how do REST APIs work?

What does it have there?

The answer is it doesn't have that.

I mean it has it absolutely has the kind of underlying primitives, uh, but it doesn't have the full story, so you have to reach out for that third package, and then you're into that uh kind of maintenance aspect that I talked about.

So uh as with everything, it's a it's a difficult balancing act, and the notion of increasing what's in core, I think, has been diminishing over time because core has had some things uh ejected out of it.

I think the there's a couple of little packages, form tools, I think, was one that got made into a separate package because it's not the most common use case.

But I think there are some things where Django is missing a story for the 80% in that 80-20% rule that it could be serving, and I I don't think there's a good answer to that because it's a lot of extra burden to take on for a very small kind of core set of people who are working on it day in, day out, and it's a lot of extra burden.

But when you evaluate it against saying to people there's nothing built in for that, especially when the web has changed so much over these last 15 years.

When when Dango first came onto the scene, it was revolutionary for the Python community in the same way Rails was for the Ruby community, and I think in some aspects that's less true now, and you see that in the competing frameworks that are kind of capturing mind share today, like FastAPI or Black Sheep or what have you.

Django now provides a template language and always has, but that's not even necessarily making up the majority of use cases.

It may still be, I don't have any data on it, but certainly there's a lot of REST-driven APIs for a given value of REST, and those aren't going to be using the kind of template language backend anywhere near as much.

So it's it's always a hard thing to balance that, and I don't have to sit in a position where I make the judgment, which is fantastic for me.

Um, one to add um to extract the uh request parsing into us into a kind of separate class because we've got the the multi-part parser, so you know, form data comes in, but to to make that kind of pluggable so you could have a JSON parser in there, and then we could have content negotiation, and then at that point it becomes okay, you could accept JSON requests and um form encoded requests, and okay, that looks starts to look more resty, and then you know the serializer story we don't quite have, but you know, there's no reason why that

couldn't be bought in, and then you've got 80% of what Restraimot gives you with the you know the generic views and

As you say, the content negotiation, the parsing of the request body, these are all things that we can make work, and once you do even the forms API, I think could probably be adapted successfully, because one thing people don't necessarily fully understand about the forms API in terms of internally is it's a reasonably good API for validating a dictionary, which is perfect because

most web requests these days are perhaps nested, but they're just dictionaries of here's some data.

Now, the forms API itself doesn't currently allow you to have nested dictionaries, but there's no reason it couldn't, and I've been thinking about how I might tackle that because yeah, I think once you have that and you've got body parsing and you've got content negotiation, you've got like three-quarters of what people actually want.

And the Forms API then has enough rich metadata inside of it that you could do stuff like generate an open API schema for the whole thing, and you get you know a Rolling Stone effect, it'll have knock-on effects for everything.

REST framework would be able to become lighter, as would TastyPie.

And so those extra dependencies you do have would have less surface area, and more eyes would be on those other bits because they're now in Django proper.

So that's that's you know a promising thing.

Do you have a question, Will?

But well okay.

All right, fine.

So, Kes, the other thing I wanted to really talk to you was about was um you've done lots of tickets on optimizing, you know, little bits of Django or on profiling bits on the template engine you're working on speeding that up.

You mentioned that earlier that Ginger's faster.

Well, okay, let's make the DTL faster.

Um, can you talk talk about you know how you go about how you approach an optimization ticket and you know your thoughts there and the work the process you go?

Because I find it really interesting.

You open these really detailed tickets that spell out you know some real cle clear gains that then make it easy to review and easy to think, oh yeah, let's get that in.

The uh the the tickets you see that I'm asking you to consider in terms of merging are the ones that have proved successful.

I've been down so many dead ends that it's unreal.

Um I have so many notes just floating around with numbers in that don't prove anything.

Yeah, you'd

There's whole other there's pages of notes around okay, well, can I try and speed this up, not targeting any specific area, but just a thing that looks like maybe I could speed it up?

And the answer is no, because because of consideration X, Y, or Z that I hadn't seen elsewhere, or because I'm not super familiar with that bit of the API and the way it's used, and I have to wait 500 seconds for the entire test suite to fail, essentially, and say no, that was wrong.

So by no means is is it a 100% success rate, it's mostly a case of finding a section of the code that I think probably could have some speed up applied and seeing if after that speed up is applied is it even worth it.

Because again, even if I make a change and it's 50 nanoseconds faster on my machine, if it's in a piece of the framework that's not a hot loop essentially, it's a a waste of time to really deal with it.

If it's called once per process and I'm saving 50 nanoseconds, it's probably not worth actually wasting the time on because everyone's already got a whole bunch of things to look at and work on.

So it's got to be relatively frequently used or a pathological case, and then it has to show actual meaningful value.

And deriving that meaningful value is it's it's difficult because measuring things is not easy.

Uh, I won't say I get it right 100% of the time, but if it looks repeatable across multiple runs, if it looks like I can come back and rerun it in two days' time and it may not have the same numbers, but it's got the same kind of overall difference, that's when I consider opening a ticket.

And so that that means a lot of data collection, and it means writing any individual ticket about it takes quite a lot of time because I need to make sure I'm getting the data right and explaining why that data is relevant, and ultimately all of that might be to save a couple of microseconds here or there, but it happens a lot, and so that build-up allows it to actually have a real difference in in production, so to speak.

But it is exceptionally it is exceptionally hit and miss.

I won't I won't try and paint it as always 100% successful.

No, no, no.

It's like code's compiling.

We don't really have that in Python, but the test suite, you know, if it's

we do when you're running

the test.

So yeah.

Uh as I say, I think it takes me about 500 seconds to run them uh without using the parallel runner.

So it's it's a significant chunk.

I'll go and have a coffee and uh see what I come back to.

And if it's good news, maybe there's a ticket.

If there's not, then I will hang my head in shame and move on to something else and see or see if there's another way to do it.

I was actually gonna I I I forget where I saw maybe I saw this just looking at you before this interview, but a couple weeks ago I wanted to put it in the Django newsletter.

Um, and Jeff Trippett was like, oh, it seems kind of alpha, but I wanted to put a note being like still still alpha, but um that looks very cool.

Like, can you talk about where that's at?

Like, can I put it in the newsletter?

Are you comfortable with a lot of people looking at it?

Um it's it's still in that alpha stage of I'm still thinking through all of the ways I'd like to display the information and figuring out all of the different pieces of information that Django's existing error pages display.

And the only reason I'm looking at it is because those error pages have stayed substantially the same for most of Django's lifetime, but the web has moved on, we have better understandings of things like accessibility, we've got things like dark mode, uh, people who have preferred reduced motion.

All of these things mean that there's probably something to be done in terms of improving the error pages, and the reason I call it subjectively better is because I'm not as well versed in accessibility as I'd like to be, uh, and it's a lot of experimentation that I'm doing there.

Hopefully, you know, hopefully one might be able to say they're objectively better, but I certainly wouldn't make that claim because I don't have a full scope of how it should be and how it actually works for the users.

It's currently just me playing around with it.

It's it's in a promising state, it's currently using Tailwind to uh output all the CSS mostly as an exercise in getting familiar with that because that's relatively new and I hadn't had a chance to play with that particularly.

But ultimately, I would be ditching that in favour of actually just embedding all the CSS in the file.

It's yeah, it's it's in progress, it's very much alpha.

I think it's cool, I'm kind of enthusiastic for it, but if nothing else, I'd like it to spark a conversation about improving the error messages and all of that uh surrounding stuff.

I don't necessarily think as it is, it would ever end up in core, though I you know would be thrilled to have that.

But if it at least if when I park it, it has achieved the job of someone better investigating and providing new error messages and new error pages, then that would be a job well done.

And I've in doing it, I've looked at uh a number of other error pages, whether they are kind of from competing frameworks or what happens if you Google error page or debug page on Google Images and just seeing what other people display and how they might display it.

So there's probably some aspects of it that are cribbed from somewhere else, but I don't know where.

And it's just trying to make something in general that bit easier to parse.

And I think that was easier for the Django error pages under Django 2 when we didn't have stacking exceptions, whereas now an exception being displayed can be very long in terms of the individual frames because zero division error was caused by Unicode error somewhere else.

So yeah, I'm hopeful for it, but we'll see where it goes.

I wouldn't recommend people use it yet, though.

We had uh Karen Tracy on a few weeks ago, and uh she her book was written like a decade ago, and they're they're they're almost unchanged from from what she covers in that book.

I think you know any anyone who comes back to Django having five years off can still read that same error page.

It's not drifted by any substantial amount, it's just improved incrementally over that time, which is fundamentally what Django does.

Fantastic.

I had one one more, but do you have a something you want to Matt?

No, no, no.

Well, I was just gonna say what you're saying about Python and its evolution.

I mean, we we the Django Software Foundation think a lot about Django and how to make it secure.

And I'm the treasurer, so I'm looking at the books and trying to think how much money do we need?

You know, we always talk about expanding things or keeping it small.

But you know, I would say big picture pulling APIs in at some point to core in some way.

That's a no-brainer.

I think that will happen.

We'll probably need to expand the number of fellows.

I mean, we we are we the DSF is lucky that Carlton and Marius are so good and so efficient that it's not an issue right now.

But at some point we'll have other fellows, at some point we might want to expand.

We could always raise more money if we needed to to fund things.

Um, so these are kind of the questions uh from the DSF level we think about, you know, how do we make Django better?

But I would say for beginners, anyway, so my wish list, I would say bringing APIs in in some form.

CMS, I mean, you know, Laravel has APIs and CMS.

Wagtail's amazing, it's kind of the default now.

Um, I don't know if that needs to be brought in the same way APIs does.

Um, but then deployment.

Deployment's the deployment, and maybe a I should at some point write a another to official tutorial that kind of gets people kind of what I have in my books, but something that says here's how to write and launch a Django uh project for beginners.

Because that's that's missing a bit now, partly because deployment is tricky, and also because uh subjectively like saying, well, what's the default you can, you know, what are the settings configs, like how what's good enough to put live.

Um but I think those three things, if there was more about CMS and the official docs, bring the APIs in and a s a way to build and deploy a project from the official docs, I think those would all help, and certainly some of those are doable.

But I'm curious what your list is.

I put put that out there as that's me ruminating publicly.

But certainly having an answer for building the majority of an API would be one of the top ones.

I think it would be nice to have, and it's a risky proposition, but I think it would be nice to have an answer to how to do the front-end ecosystem.

There's there's a number of competing packages in terms of how do I bolt Webpack onto it, how do I make use of uh Babel or TypeScript, and because the front end has become such a separate beast than it was previously, and it's got its own ecosystem and its own configuration to deal with, that's still a difficult thing to get your head around if you're not fully de

ep within it.

Now, I think Rails has had more uh attempts at doing that.

I think it has sprockets and the asset pipeline and stuff, and they change things more frequently, uh, as far as I'm aware, and the front-end ecosystem has moved at a very quick pace over these last five or six years, ultimately.

So adding something like that into core would be a risky proposition because you may end up switching out two versions later for the current in thing, but perhaps that's settling down with things like ES Build and SWC that allow you to kind of make use of JavaScript modules or tailwind packages, so maybe that is becoming something where you can finally

add something in and not just risk it needing tearing out in two versions time.

I think that would be a good thing to have an answer for, and I think at the moment it's fine that the answer is use this popular third-party package because it's so changeable, but I think one day perhaps when that when it all settles down and things have stabilized fully, if it ever happens, that would be a cool thing to have.

Have you used that?

Do you have thoughts on that?

I have used the previous version of Carson's Intercooler.

Yes, I used that uh on a number of projects, and uh I think I have a package for that somewhere as well, um, just to kind of make the Django side of it more useful and more built-in.

Uh I I really liked Intercooler, and I think whilst HTMX isn't a big change from what Intercooler was, I think it's happening at the right time in terms of he seems to be having much more success uh finding an audience for HTMX than Intercooler, which was always possibly a little too early for its time.

It was you know competing with Angular and Ember and React as the things that had the zeitgeist at the time, and now I think we're not necessarily seeing a pushback on that, but with things like HTMX and AlpineJS, and then you've got the various live view things that Phoenix has, and I think Larabel's got an equivalent, you're seeing more decoupling again.

So, where we where we might have had a full offline first React front end, some people are pushing back into we can do a lot of it on the server and just add in that interactivity we need via this small package, and I think that scales relatively well.

Your your system has to be very interactive or very complex to not be able to get by at the very least with some combination of the two, and I think most people with a middling amount of development experience of something of that ilk would know when to stop doing that and move to a fully separate front end and a fully separate back end, or merge the two completely.

And that's always a different inflection point because it depends on the project, depends on what it's doing.

Is it so interactive that it's WebSockets and streaming diffs all the way down, or is it just an occasional Ajax update to refresh some chart or other?

But I I think it's a super cool project, and whilst I've not used it, having used the previous one to do uh a couple of projects, I'm I'm really enthused by that one.

A lot of newcomers come to me and say, I have to use APIs and React or View and just every you know bag of tricks.

And I always say, Well, you incrementally get there.

You know, start with start with just Django, do stuff in the templates, only switch to APIs later unless you're experienced or know you need it.

And so HTMX just keeps pushing that out, which certainly for people learning or on smaller projects, if you don't really need it, it's a whole other world to to manage.

So I think that's that's good for all of web, but especially for Django.

That helps there's more you can do with just default Django.

But yeah, I I'm a big fan of the kind of progressive enhancement route.

I think as well, the you you know you talked earlier about um extending the forms API maybe into you know a RESTY serializer type um domain.

And what I find is really nice with HTMX is the ability to push, oh I'm still using form.

Oh, I'm still using form, oh I'm still using a form.

And you get to the, you know, maybe with a sprinkler of Alpine, and instead of instead of sending um JSON data, you just send form data, you know, with the JavaScript's got the form object.

It's like, oh, I'm still using a form.

You know, it's like I haven't actually got to the point where I needed JSON at all yet.

And then, you know, if we can then just get the forms that one step further out such that they can sensibly interact with JSON, you know, in and out, then actually it's like, oh wow, the surface area of what we're able to cover with the that core traditional Django stuff just grows to cover the 80%.

I think I think it does cover most use cases at that point.

Then, yeah, okay, specialist endpoint, you know, blah blah blah.

But that's why I'm excited by it.

I think it it knows me to do really quite straightforward Django for much longer than I've been able to do for years, like literally half a dozen years of oh no, now you've got to, you know, you've got to jump into this front-end world and it's straight to the API.

No, I wouldn't why would I go straight to the API?

It's it's really changed um the phenomenology of building a website in a way that I find very attractive.

So yeah.

Having having been around for long enough that that's where I started doing it, and then there's that middle ground of everything becoming an API, and now we're maybe seeing it go back the other way slightly.

There was a simplicity to it, and whilst you know a lot of users now expect more interactivity and expect all of the extra stuff that the front end can do that it previously couldn't, there is there is that successful middle ground where yeah, it's still just a form coming back, and it's just augmented with the validation error of this field, and that validation is correct for their current content language, and it's in the right position, and

it hasn't had to be duplicated in the front end.

There's there's a a simplicity to that, and it's it's really nice to see that kind of thing come back.

And I think for Django specifically, that's been helped somewhat by the whole forms API becoming template-based, where previously it was all just strings.

Being all strings made it difficult to add classes, it made it difficult to add these extra data attributes that Alpine and HTMX want to add onto things.

Whereas now with the forms API fully within the template system, it's relatively easy to always augment it with this tailwind class, this bootstrap class, this HTMX attribute, this Alpine X data, and so it's allowed it to become more seamless than it otherwise would have been.

I don't think I'd have enjoyed working on a project that used Alpine or HTMX or Intercooler if I had to manually output all of the things or augment them all in the Python widgets themselves.

So I think I think that's dovetailed quite nicely.

But it was a static site, and they just had I think it was jQuery or something for the forms and connect to a backend and they put it together quickly and it worked and it scaled to you know 350 million people or whatever.

And a lot of people were like, wow, that's that's amazing, you can do that.

And it's like, yeah, you can do that.

Like that's it doesn't need to be this big beast.

They had to like subdomain the US Postal Service website because it's its own thing, but it's like, yeah, you can be simple and scale, and it doesn't need to be, you know, because everything is so much of the web is just a form.

And yes.

Anyways.

And yeah, I think sometimes the performance and scalability thing falls by the wayside.

You know, Django's not the most uh scalable thing in the world because it's backed by Python.

Python's getting faster, so Django will get faster, cool, that's fantastic, but it's never gonna compete with something written in C or something, but it doesn't need to, because the actual performance and scalability for a lot of the web is as you say, just some form over a database or over an external API, and so much of it is data entry in in some fashion that uh as

long as you can horizontally scale out reasonably well, your big bottleneck's probably still gonna be your database.

Well that's why the as a last thing, um CRUD, the concept of CRUD for beginners new to web development, when I tell them and show them that everything is 99% of the web is CRUD, w that's a real aha moment for people when they realize, ah, Facebook, CRUD, Twitter, CRUD, like every site, um, it helps kind of piece together and provide a context that newcomers, you know, you don't think about if you're just using the web.

And once you get there, it's like, oh, it's not that hard to create these sites because you're doing 90% of it is the same.

You're just changing the skin and it's a little bit different.

But um anyways, that's that's something I enjoy showing people.

And you know, it takes sort of five or six, but when they see, oh wow, like it's all kind of the same, it's like exactly like that's what I'm trying to get you to.

It's not overwhelming.

Like there are these niches and deep areas, but it's kind of the same thing over and over again.

But you don't until you build it, you don't think about it.

You know, if you exclude exclude things like web sockets and all of that, the web's verbs are just other words for crud.

Possibly they're better words than CRUD because they don't form a bad sounding acronym, but uh the acronym is at least catchy that once you hear it you understand what it means.

Fair enough.

So, Case, thank you for coming on, and thank you for all that you do for Django.

It's you know you're silent hero, but you know, thank you for anyway.

You're the you're the silent hero, you do all of it.

Yeah, don't think I don't see it.

Anyway, right, that was uh Django Chat.

Uh thanks for joining us, folks.

Join us again next time with um DjangoChat.com and Chat Django on Twitter.

Take care.

Bye bye.

Bye bye.