Transcript: The Future of Django - Emma Delescolle

Hi, welcome to another episode of Django Chat, a podcast on the Django web framework.

I'm Carlton Gibson, joined as ever by Will Vinson.

Hello, Will.

Hello, Will.

Hello, Will and Carlton.

That's that's at the very tippy top.

Like uh you we just had elections for the 6.x Django Steering Council.

Uh this is the first time for both of you on the on the board.

Maybe Emma, over to you.

Why did you decide to run?

And I know you've written a lot about some of the issues Django has.

So what are your goals for the board?

Um maybe a new influx of people, definitely.

Uh Django Node Space is helping with that, but there seems to be uh a renewed energy, and some people want uh to change things.

So I feel that right now is the time to do it.

And more so, if we don't do it right now, maybe it will be too late later.

I think there is a lot of momentum in Django, which is refreshing.

And at the same time, the web space is changing, right?

There's you know, fast API is gaining a lot of mind share, there's Flask is still there, there's new things.

So as much as we all love Django, it needs some TLC to to stay relevant and perhaps answer some of these big questions that are not new ones, but uh it feels like the community has been a little stuck on them.

You you you also ran, joined?

Like Django's done very well and it's it's you know 20 years old this year, and that's amazing.

And then there's there is a kind of I don't know how how can I how how would I phrase it?

It seems like we're going going slightly slower every year, every every time.

We can just go slightly slower because we kind of accrete more mass and there's more difficulty in doing new things.

And then exactly as Emma said, with the new community members coming in, there's a there's a push to try and shake loose some of the old craft, and exactly how we can do that is I think you know, that's what we're we're busy trying to work out right now, right?

Is that you, Carlton?

I assume.

So perhaps if you give us a bit of background of that and you know how all that works, and then how you're involved in the Ember community or how you've seen the Ember community, and then that we can your ideas for bringing some of the things that they do there, maybe to the Django community.

Uh think uh invoicing uh plus plus.

Um and so at some point I decided to write it in Django compared to other stuff.

I've used Odoo and Triton before I I've been part of the Odoo core team uh a long time ago before it was called Odoo.

Um and so I said, okay, let's let's do that in Django.

And um one of my first frustrations was to have to write serializers and uh view sets for everything.

So this is the first half of the schema adapter.

It's um in some ways similar to Neapolitan, in a way that it lets you write a single class that will define uh everything for you.

Um and under the hood is just a DR schema adapter view set.

But then I was also frustrated because I was using Ember as a front end for that, and I also had to rewrite uh my models in Ember, which are basically exactly the same thing as the serializers in Django.

Um and so this is the the second half of the schema adapter.

It's it's an it's an adaptive system that lets you take uh a serializer and transform that into front-end code, whether it be for Ember, which is basically the the only one that has been uh maintained over time.

But when we started the project, there were there were a few of us that got together and some people wrote uh adapters for Angular and for React.

Um and so the the TLDR is that you write your model, you write an endpoint in Django, and that's all you have to do.

You uh after that you magically have the access for a credit system directly in Amber.

Write it once.

And honestly, it's been working quite well for me for for years.

And yeah, I've been less involved with it lately because uh I feel we're getting into a a newer era, and I would love to uh I've tried to change to update the schema adapter for that, but it's not going to work.

So I'm thinking of starting from scratch to have something similar but with HTMX.

Okay, so that's DRF adapter, um schema adapter, and that's um, but specifically we came onto this because there's some things that they do in the Ember community that you think might be, you know, at least ideas or templates for us to do in the Django community.

So what what are the kind of good things they do over in Ember?

I I've always thought that the Ember community and the Django community were kind of kindred spirits in in in some ways.

Um I I think that the thing that seems to be the most relevant to what we're doing right now is their RFC process.

So they um every every new feature or change request goes through an RFC, whether it's a small thing or if it's a big thing, whether it's a core maintainer that wants to add a feature, or whether it's somebody that nobody has ever heard of.

Um start an RFC, which is similar to what we have in Django is the DAP process.

Um it's just that we don't reuse the DEP process that much.

Uh while in the other community, the the RFC process is used all the time for for everything.

Um and one of the things that I find really positive is that there then everything happens in GitHub for them.

Um and it makes uh things uh easier to reference, uh, it gives you an historical overview.

It's easy to point out, hey, this is a duplicate of this issue, and things like that.

I think to be fair, it's more the history, right?

That would be the main point, Carlton.

There's 20 years of history that would be lost if we switched over.

Is that I'm not I don't mind track.

I'm not, you know, I don't particularly like GitHub per se because I feel it would be nice if it wasn't owned by its current owners.

Um but that's a slightly separate discussion um to have.

The the thing that track has is the entire history of the Django project in it.

And when you, you know, particularly as the next fellow, when you an issue comes in and you're like, I don't know, like you know, some some weird thing about the the back end of the admin when it generates a form.

I'm like, I have no idea about this.

The the the track is an amazing resource for digging through and doing the archaeology and finding out, oh, it's big why it is because of this.

And the filters and all the rest that the track has make um GitHub's search look like a joke, to be honest.

I've um spent a lot of time working on DRF, and it's a project with probably less than 10% of the history of Django, and it's much easier to find history on Django using track than it ever is to find anything on DRF.

Um, and so it's not that I'm wedded to track per se, but I am wedded to the ability to find the right piece of history when you need it to work out a decision.

But yeah, um that's that's a s sort that is a sort of separate question too.

This initial uh thought about you know, can we use depths more or the ideas approach?

Because lots of people have ideas, right?

And they come to Django and they open an issue on track and then they're immediately sent to the forum, and then they don't necessarily get a reply on the forum, and then uh so what happens to those ideas?

I mean, because again, as Carlton was saying, someone comes in with an idea and they're sent on this journey, which that may be the first time they've ever done it, and by the time they get through all that, maybe they get a depth, maybe they don't.

And then I feel like most of the enthusiasm or time and energy they've had has been extinguished on the process rather than on the end result.

Because you've clearly got ideas.

So well,

Uh right now to create a draft depth, you already need a list of things.

Like you need a team and things like that, which is probably overkill just to say, hey, I've got this idea.

What do people think about it?

Um so simple simplifying that process seems to be really the the first step to go.

Because yeah, I I would love to to see the the process used way more like like it is in Amber.

Like we often there's a thing that happens with the discussion-based approach, and it's not just on the forum, because it used to be on the Google, um, Google group, the Django developers mailing list.

But this thing that happened would be like a conversation would happen, and nine months later, the same conversation would happen, and then nine months after that, the same conversation happened.

And it's quite tiring to constantly have to repeat the same conversations and remember, oh, what was it that so and so said that was really and you have to go and find it.

And then and if we could somehow, you know, one something like a you know, GitHub's not my favorite, but a GitHub project where we could identify duplicates and all the rest.

That's that's got to be a step up from the way we're doing it now, it seems.

We need something like that.

I don't know what.

I mean, it exists in GitHub.

I've I've just joined a new company that uses this tool called U-Track, where you start typing something and it auto-populates.

Did you mean um yeah, it's yeah, it's doable.

It's a it's a I I venture to say it's a solved problem.

I don't know.

It's just looking for the terms and your title and headline and just auto-showing what else is in the database.

I I agree.

I only have duplicates, copies on GitHub, but we also have to be in phase with reality that everybody has a GitHub account.

Uh everybody who might want to contribute to to Django has already a GitHub account, and probably they spend quite a bit of time there because either this is what they work with every day or they are involved in some other projects and things like that.

So even if it's not ideal, it's probably not a bad choice either.

Um I think one thing you've talked about as well is perhaps that you know a contributor comes along and they perhaps don't get the time that they need to really be welcomed in.

And um so I mean I'd I'd ask your thoughts on that, but also I mean, do you think we're just running too close to capacity so that we don't have the time?

Definitely we are we're too close to capacity and it's it's a vicious circle.

Um people were already involved don't really have time for people who are less involved, and people who are less involved.

Uh there's tons of um testimonies of people who feel that they have had a door slammed in interface when trying to contribute to Django.

Um and so we have a very, very low retention of contributors, which means that the people who stay, they have more work.

And and and we go round and round.

And at some point we we have to to break that cycle somewhere.

I mean, I wonder, just thinking of Ember, are there is there anything we can unpack in this conversation around how other communities manage it?

Because these feel endemic to open source projects where you do end up with a handful of people keeping it going and they just get kind of tired and um

I know how they do it, I know I don't know how they got to that point.

Uh so there's one requirement uh to be part of the Amber core team is that you have to have a full-time job.

You cannot be full-time open source maintainer.

So, what happens is that most of the people who are on the core team are paid by their employer to write Amber or to do Amber related stuff.

Uh and I I'm not I and that's that's the the part that I don't know how they got to to have that.

Uh I believe it's just a matter of getting a few people to have that.

And once you have a few few people, then you can show other companies, hey, look, uh, this other company, they are paying somebody to work on Amber.

Because um it's possible

Uh like we don't, you know, like so.

I mean, you know, to take Simon Charette, he's given time by Zapier to work on the ORM.

He's he so but we need more of that actually.

We need that 5% time, that 10% time a day a week, day every two weeks to to give to Django.

And I think I think that would be an amazing possibility to pursue and to poke companies and to say, hey, do you know that you're you're relying on us?

The most useful thing you can do is

I think you know, marketing whatever people need something.

If there was somewhere that said these companies, someone is paid to work on Django, maybe that's I mean, for example, like I've just I've just started working at Jeff Rains, which makes PyCharm, and they're like, Yeah, you can um you can work on core Django, but I have to figure you know, set the goals, figure all that out with my manager, update it, um which I'm going to.

But you know, there isn't a I'm not aware of like a document of here's how to manage this within your company.

Because I think most company or many many good employers would if you said five, ten percent, I want to contribute back to Django, but you need to spell it out for them what they get from it.

Um it's not just that they get to keep the employee.

They need

I don't know.

And then maybe that's unfair to companies that don't have it, but that feels like the kind of stuff that gets us in the way rather than people wanting to do it or or companies that rely on Django, it's just the the ease of mechanism of doing what we what we want, like the depths.

So if you're a company that you're paying a somebody to work one day a week on Django, given the amount of time it takes to get a feature in Django, there's you you increase your chances like by 20 times by paying somebody to do it.

And if you rely on Django for your business and you want a specific feature, that's that's a good way to get it.

Third party even seems a more immediate way because often companies write, that's the pathway in.

So if they're already working on a third party package, yeah, I'm just agreeing with what you said.

I was thinking you know because I built I since I stepped down this fellow I've started a new company I've built it on Django.

I now depend on Django again as you know as a foundation of my business.

And I was thinking what actually is is important to me and it's to be honest it's not features.

It's the stability and knowing that security patches will get done and that it you know that it'll keep the that it will keep going that's really important.

Okay that it's got the features that it has I don't want them taken away but any anything it hasn't got I I can think I can just add that on the side right it's not so important to me but what is important to me and important to my business partner important to clients is that to be able to say look we've got a rock solid core here um that's why I use it

s this little thing that doesn't work like you need it to work in Django.

So what you do is you copy paste it to your own library to your own code you change three lines and every time there is a new release of Django you have to check that those three lines have not changed in Django because if they have you need to change your code and that's the kind of thing that becomes really annoying after a couple years.

Yeah sure so yeah there's little things but yeah major features is not something that the company is going to want to add to Django most of the time.

I think we need a different kind of strategy somehow because the fellows are running at full capacity we could add another one that would buy us you know say a couple of you know it's like when you build an extra lane on the motorway like two years later the motorway's just as congested as it was as it was before um I wonder one thing I've been thinking about is could we modulize somehow could we split because there's this single point of failure right there's this or not single point of failure there's this single point of throughput everything has to go through the mergers th

rough the two fellows through Django core with its eight month release cycle and is do you do you have any thoughts on breaking it up a little bit or

ything.

I don't think they were very successful with that so I'm not sure uh it would be it would be good.

There are definitely some things that I don't use in Django that's uh there's uh the and I'm sure that when I'm going to say it some people are going to come to me and say hey I use that all the time and it works great.

But the

So may this could be a candidate to to remove there are things that are there that are needed there are tons of things that depend on the size framework as it is right now.

But is everybody is anybody actually using that correctly um templates that's something that's going to upset uh somebody but does

ations that just do Django Rest framework so could templates be part of something else um that's that that's an example and the uh Wagtail does it in a certain way that's kind of works which is they remove things from Wagtail and they say oh by the way now this is a separate application uh the problem with that with that is that it will probably go un

maintained at some point um but there is a way that works that doesn't break anybody's code say oh you're updating from this version to that version so now you need to add this extra package in your requirements that's it uh so that's that's a way that we can remove things uh we've been talking um recently about trying to uh look at the c

ode in Django and try maybe refactor some some of the things that are there there's it's not it's not going to be half of Django's code that's going to disappear by refactoring things but there are things that can go away and this is something when working on the on legacy codes usually this is a a good way to to start thing when you start somewhere you see something that doesn't you're writing

new code and you see next to your code or you're using in your new code something that's not great well improve it and sometimes it breaks things and we have to be ready for that.

And there was this it was kind of almost cultural that the bragging writes oh I'm still running 0.96 I'm I'm on 1.2 you know and it was who who was running the oldest whereas now it's very much you're expected to be on a on a supported version and it's so easy to update there's no excuse for not keeping rolling how do we balance those two you wrote a great blog post about this about you know I can't remember the exact title but it was it was touching on this issue.

How do we balance those two those two things perhaps you know

I mean we're like if you look around for example like I just met PHP I didn't realize has a foundation only as of a couple years ago like three years ago and one of my colleagues runs it and they have you know ten people paid to work on PHP.

Now okay that's a language not a framework but look at Laravel which again doesn't have a community has one person that makes money hand over foot um separate from raising venture capital money but they just have they just have people they just have a lot more people and I felt this when I was on the board that there is a shift from Django exists to exist and Django exists to kind of thrive and those of us who've been

around for a while can actually make things happen, right?

Instead of it does feel a little bit like the same old conversations but it butts up against the fact that at best you have someone um like Simon Scherette who can do some time but not a ton of time and then the organizational stuff nobody no company is going to pay for you really to do the organizational stuff which leads into um I know the current board multiple people would like to have an executive director but it's volunteers meeting once

a month trying to meet the needs of a big corp that has you know there's people whose career is presenting this properly to uh to these corporations.

So I'm I'm musing out loud.

I guess I just I keep wishing there was a way we could shake that money tree because it just I I feel like we're just asking too much of of our people to do it.

Um so that's not a question.

That's just a rant I guess.

But you know I I feel like we take it upon ourselves like why can't I do more the the say you know Adam the same people are just pulled in to solve these problems and ultimately until one of us is able to work on it in a more full time capacity with whatever funding it's it's just too much of a a a thing.

I don't know did I just did I just waste a couple of minutes or is that something new to proceed

space to to give us more freedom?

And but yeah there is I I've always had this feeling that the the Python community in general is like this very purist open source compared to you were mentioning PHP and Laravel.

And the the side effect of that is yeah they maybe they they sold out maybe they're just doing business but they get money we don't

That's buttonown.com email software for developers like you there are hundreds of email marketing software services out there and they all pretty much offer the same thing collect and clean addresses send out broadcasts or drip campaigns get analytics so you can see what's resonating and what's not.

Buttonown is designed to hook into the tools that you already care about everything from static site generators like Jekyll or Hugo to payment platforms like Stripe and Memberful.

You can hook your site up to button down with just a form element or a simple rest call.

Write emails in Markdown and then get on with the actual work you're supposed to do.

New customers can save 50% off their first year with Button down using the coupon code Django and if you email support they'll white glove migrate your existing subscribers and archives for free.

Fast API has very similar to Django Rest framework just on the homepage boom companies that sponsor right like what is it worth to a company to be on the Django project homepage and we say it requires this minimum amount there's only so many spots there's no way we couldn't raise six figures doing that.

And again I I'm not currently on the board we have new board members I know many of them feel this way like it's just all the more jarring for me now being on the inside of a company that you know makes money off of Python and Django and has a budget but there's not even much visibility you know part of it is people come and go in larger corporations but there's not even much visibility around for example the Django um campaign that PyCharm has done for years that I helped work with you know because

some of the people aren't there you know I guess I just see that I I have renewed energy to kind of like go to these companies and be like hey like you've got 2025 marketing goals you're spending money on Google and other things throw a little here and be on the Django homepage I don't think that upsets anyone um and I would couple that with we bury our existing platinum sponsors of which JetBrains and others are one like we bury it.

start has had a point of having everything in-house uh so we have everything written inside the Django project um maybe we can leverage other open source projects uh like uh click uh like ginja for the templates or uh click for the uh for the management comment and other things like that that would be uh a

way to to cut down the to cut down the lines of code and there is always a risk by using a third party application that it's not going to to get maintained and things like that.

But is it really that bad?

Let's say we use click and click doesn't get maintained anymore then we have to bring click in oh well that's the situation we started with so it's not that big of a deal.

SQL Alchemy right okay

the reasons probably not the only reason but one of the reasons is that Django Rest framework is in maintenance mode.

So the pe people who are using it are going to keep using it if you have to choose a new framework today a new REST framework today to to write your Django application which one are you going to go with the one that is actively developed or the one is that's in maintenance mode chances are that you're going to go with the actively developed one.

it you're gonna just trigger me on my synthetic benchmarks rant any second now I agree

Most of yeah Python is not fast.

If you want something so fast go with Rust or go or C or write your web server in assembly.

But usually it's not the this layer that's slow.

What's going to be slow is your request to the database is going to be your file access and all that.

So I've never felt that uh Django or Django Rest framework was a bottleneck when it comes to speed.

And I I just had this last week with uh so my new company is the the platform is built on Java.

Java IntelliJ is the main product.

So there's a lot of Java developers.

And you know, they tend to be older.

And you know, at lunch, one of them was telling me Python's slow and web is slow.

And I was like, what are you talking about, man?

Like abstractions are bad to that point.

Like, why so I think part of it is people not people come in focused on the language and they don't know the web at all, they don't understand what infrastructure is and you know, arbitrary benchmarks.

You know, I did I did pause it.

I was like, well, what is an extra minute save the developer time versus milliseconds later and um yeah Carlton's making the face I have?

I'm I'm actually gonna have to fire off now because this this whole fascination with speed, it's like a fascination with scale.

It's ridiculous.

Sorry, define your metrics that you need to hit.

Define the performance that you're looking for.

And does your application fit inside that app the inside those performance metrics?

Absolutely a Django app or a Flask app or a you know whatever Python web framework will fit in that as well as anything else, exactly because what Emma's talking about.

Your bottleneck is not your web framework, right?

It's the connections to the database and your limits to you know scalability are there, not you know, which web framework to use or which programming language you wrote you use it.

You know, I'm going really low level.

Hey, yeah, brilliant.

It took me months to write, you know, my hello world.

No.

It's so it's not an engineering mindset.

That's the thing.

It's it's

No, I'm a Cowboys fan.

No, like what?

Um well, Emma, I wanted to ask you about Django Classy Classy Doc, if we can shift gears.

Yes.

Um this is an amazing project.

Thanks.

Um, so classy, class-based views for your docs, for your code, right?

Like, tell us tell us more.

What made you take that next step of putting it into a package?

I wanted it for me, and it's much easier for it to be in a package.

And when I work with Django, I either have CCBV or CDRF open on on the screen next to my code because this is what I use as documentation.

Good.

And the way you can do it, you can open a shell, uh manage.py shell, and go from there and find what you need, but uh having it on a website that uh is generated by your code is also much much nicer.

So every every piece of business logic of uh properties or anything that you've added on top of class-based views or Django Rest framework or models, uh it's it's right there.

It's auto-documenting uh in your in your code.

And uh even if you don't have code comments, if if you have doc strings and everything, it's really, really powerful.

Even if you don't have doc strings, just being able to say, oh, this is defined in that file, and this is the code that I'm calling right now, it's super helpful while you're working.

Yes.

You must

Uh you

I don't know.

I've looked, I I've I've the thing is I've seen, I I've looked, or maybe I didn't know where to look, but for what I found, I found some people who've done it for Python in general.

Um and that use Ginger for templating, for example.

And but that's not fun because for using Django, why load two templating engines?

I I didn't find anything specific to Django, and that was fine-tuned for Django.

There's probably a lot of progress I still can do there on fine-tuning for Django, but uh, for example, a Django model is something with specific with fields and things that that will not map correctly, or it will not be intuitive if you just take a Python version of this kind of tool.

Yeah.

Maybe nobody uses class-based views because they hate it.

Um, no, no, no, no.

The criticism is about the implementation, not the class-based views, right?

The whole function-based view versus class-based view thing, that's just a myth.

That's like, oh, I don't like the extra indentation you get in a class, but then in your function-based view, you've got if if no, but no, but no, but that's what that's the sort of what the complaint comes down to.

And then it's like, but hang on, in your function view, you've got if request.method equals post, and then you've got everything indented a block.

It's it all just works out the same.

I like it.

Python is welcoming to the newcomer who is Python is a new basic.

If you want to, if you're eight-year-old, you want to start programming, start with Python.

But if you have 30 years experience and you want to do things more advanced, Python is still a great language for you.

Um and in Django, we have focused a lot of energy in making Django welcoming to newcomers and easy to approach.

But once you get to mid or senior level and try to find resources, it starts becoming harder.

And this is a space where I feel that class-based use and Django's implementation of class-based use are useful.

It's a bit more often more advanced topics, but there is roughly zero, not zero, but very little tutorials and resources for people who've reached that level.

Once you're at that level, basically you're on your own.

And uh that that might be one of the reasons why uh Django class-based views gets so so little love.

You've you've in this space.

Like, what do you think?

I guess how many people would sit through an educational thing on class-based views as opposed to having a specific problem with the generic class-based view and then kind of stumble through and find classy class-based views.

I suspect most people are in the latter category, though I'd certainly be happy to.

I mean, I in my books, so my books, for example, I I now start with function-based views and the beginners one and then work into class-based views.

That was something I'd just started with class-based views in earlier editions.

For the more advanced cases, I do I do have things where I show how I found something.

I show searching in the source code, I show classy class-based views, but I'm guilty of not having gone, I guess, deeper on it myself.

I suppose it would need, I would need to think of good examples of, you know, build a blog, build a bookstore where you can have fun playing around with the class-based views a bit, because I think most people work backwards, problem they want solved, and then the teaching, they'll accept it along the way.

But to just be more comfortable with class-based views, I haven't figured out how to do that.

But I don't know if anyone else has either.

I mean, I guess that's I that this is the problem too with educational content in general, is that I feel like beginner intermediate, it's okay.

Advanced stuff is very difficult to think about because everyone does it so differently.

It's difficult to it needs to be more, I guess, pedagogical, more about teaching rather than helping someone, you know, build a pro project.

I think.

Does it work from a market point of view?

Because if you think about the smart addressable market size, there's an awful lot of beginners and there's some intermediates and there's very few advanced people.

So if you write, if you create content for advanced people, you're automatically limiting like you can.

Whether or not you can I mean, you know, I don't want to make this about that topic, but like I did just accept a full-time job um to give people a sense of how big the market is for Django educational materials.

You know, I'm still doing it, but uh you know that's part of the problem.

Uh in you were talking about Java.

You can get a ton of certification in Java on every different levels.

So right.

Um I I I guess it's that question of a certif certification to fulfill a requirement for a job or to just be good enough versus you know, for me and other content, you're paying your own money and time to get better, so you really have to want it.

It has to be that much better to pay $50 for something of mine when you could get lots of other stuff for for almost free.

Um I don't know.

I don't really want to get into the educational side thing, but but

It's like you know, is people aren't gonna pay, or this is the the problem.

The marginal cost of delivery for open source project is approximately zero, right?

It's you go and fetch it off Py PR, you pip install it, it costs the Django developers nothing.

And so there's a kind of economic grind to the bottom where nobody pays for open source, and we end up in this look we've been talking about all episode this sustainability problem.

I mean, yes, there's I don't know.

I'm gonna shoot my mouth out.

Emma, so I I've just feel from the comment I know you've got lots of positive ideas and lots of positive to say.

But we've been quite negative in what we've been talking about a little bit, and we've we've been hitting on problems and digging into those problems.

What's your what's your sort of um solar punk positive output?

Where do where do we want to go looking positively dynamically for Django now?

So the fact that we've been negative, it means that at least something has been done.

Um and uh where I want to go is that I I feel that Django can is probably still a framework for for the future.

There is a tremendous uh push toward things like HTMX right now that bring uh the ball back into the back-end uh camp, I'm going to say.

Um it's slow, corporations are still not on board and things like that, but quite slowly the the pendulum is swinging back to server-side uh things, website, and uh Django has a great ORM, it's got nice forms, it has uh some batteries included, uh, even if they are not perfect right now.

They're uh authentication is there, um authorization is there, and so it's got all the basis for for you to to write your your application.

Uh and let's let's ride that wave and uh jump on that train and stay the best framework that can be there to uh to to write your application.

It's growing and growing and growing and growing.

I even even internally, I was just looking at marketing stuff for for PyCharm, like at JetBrains.

PyCharm is not the biggest seller uh at the company, it's IntelliJ, which is a JavaScript uh IDE.

But Python is the even even for a company with a hundred prod products or whatever it is, like the Python stuff gets the most traffic, right?

So we are riding the train up and to the right.

And Django, you know, I know there's different metrics of which GitHub stars or different surveys.

I still think practically speaking, Django is far in advance in terms of real developers on real projects using it.

Um so I'm positive by all those things, right?

Like it's it would be hard if we were like waging this battle and those those trend lines were going in the opposite direction.

Um but it is it is balancing those two barbells of how do we stay friendly to beginners and and make the batteries not imposing um at the same time do stuff for the people who yeah, are using it and want it to be better and slight, you know, Django up Django upgrade, right?

I mean we should have that.

How do we package it with Django even if we didn't merge it into core?

That's an interesting thing because if we could solve if we no, but let me finish saying if we can solve that problem, then we can also solve the other problem, which is how do we pull bits out of Django without them disappearing, right?

It's so as if there is limited capacity in core for quick things, big things to come in because we're limited state.

Well, okay, what can we do?

So it from the UX perspective, so fast API, fast API is by default, you do pip install, fast API or UV these days, but pip install fast API square bracket standard, right?

And you get various bits that come with it.

If you just want the the the core bit, then you just install the core bit by itself.

But we could why couldn't we do something similar in Django?

I know it's not what we've done historically, but you know, Django, pip install Django, square brackets, bells and whistles.

I don't know.

It's just an idea, but uh we can play in this space now.

I I know this this is something that people have been talking about for 10 years, but I I thought I heard somebody was actually doing it.

I've have heard various people talk about um making it easier to use Django in a stand uh to use the ORM in a standalone project, a non-web project.

So you you know you could use the ORM in your in your command line tool a bit more simply than currently.

You kind of at the moment you have to know the black magic to get it to it, works, it's not very hard, but you have to know it, and it's not really documented.

But wouldn't it be nice if you could use the ORM everywhere?

Peep install Django ORM.

Um if we could achieve that, um I think we we have a recipe.

Just plug in.

So Simon did a talk in Goon.

One one of the one of my site projects right now is a static site generator based on Django.

Um and um I am trying to have everything be plug-in.

So just have the basics uh that does web pages.

That's it.

That that would be the core.

And then you have plugins for teams, and you have teams and layouts, and you have plugins for blog, and you have plugins for collections, and and plugins for a lot of things.

This this is one of the size projects I'm playing with right now.

I was just having a conversation with an experienced Python person who wanted to do something, per update their personal site, and uh I won't use agenda, was mentioning different options, and I said, Well, why not just Django?

And well, I don't want to pay hosting costs.

Okay, well, why not Pelican?

Well, it's not quite what I want, you know.

But this is someone who knows Django, right?

So if the if someone could wave that wand and go local Django static pages you can deploy on wherever.

So the Yes, sign me up.

I'm using Distil, uh which is a a tool you you have to to decorate your your URLs with it.

Uh so you have to tell Distel, for example, how to find all the blog posts or all the pages.

Um and you decorate your URL patterns uh with that, and then you generate your website, and it will generate everything um in a folder, and then you can FTP it wherever you want or to or put it on GitHub pages or anything.

Django Distel.

That's new to me.

I didn't know about that.

Uh I don't know if it's still on the table, but

well, fingers crossed.

No, it's not like that's

That could be a cool like Google Summer of Code thing to try to push some momentum because uh you know, how do we promote Django?

Lots of people want a static site.

And again, no disrespect to Pelican or other ones out there, but if you can just use Django for both and solve the hosting cost thing, seems like a good idea to me.

Yes, Carlton?

You go and you give it a try, you give it a play, you see what it's about.

But when it comes down to actually getting things done, what do you pull out of the bag?

You pull Django out of the bag because you're that much more efficient with it, that much more you know, familiar, you know every little corner, you know all the nuances.

So for Django to have a static site story that was kind of you know modern, up to date, and well supported, that would be a great addition to the tool belt.

It'll be like, yes, I can use I can use my best tools for that.

I we do a couple projects, we don't even touch the database.

And I've even I've seen how off-putting deployment can be.

I used to show deployment progressively more complex with every project.

I've moved it entirely to the end of my beginner's book because so many enough people told me that they just skipped that stuff.

Um so I think separating it out, modular, modularizing that, I'm in favor.

Um well, we're somehow we've come up to almost an hour.

I feel like there were other things.

Is there any any things we specific things we didn't talk about, Emma, that you wanted to shout out while you have a microphone?

Um so PyScript is is a way to to run Python in the front end.

And we've mentioned that things are getting back to everything server-side, uh, with HTMX and things like that.

But I feel there's still some products.

Anything that is long-lived in the browser, anything that you would install as in as an electron application, um it is a great fit for PyScript.

If if you want to write to be able to write everything in Python, um PyScript is already there.

It's a bit slow to start, so you're not going to use it for your blog.

But if you're, I don't know, writing a point-of-sale application, PyScripts uh can can come here and replace JavaScript frontend if you want to do everything in Python.

Um that has uh that it that has everything.

It's got uh uh it uses SQLites for caching uh any requests uh to have a local copy of anything that it gets back from the API, it uses Ginger for uh template rendering, um it uses it has routing and everything.

And I I did that, it was the early days of of PyScript.

Uh and PyScript has come a long way uh from there from since then.

So at that time there were bits that were a bit junky and and not very pretty.

Uh if someone has the time to look into that right now, I'm sure we can have a very nice front-end framework in in PyScript.

I like it.

If if on a documentation website you have the website load a full Django and pull you into the shell and say, hey, now you can type this comment and this is what's going to happen, or you can run migrations.

Here's what's going to happen.

You don't need to install Python locally, you don't need anything, you don't even need a computer, you can do that on your phone.

Uh that that can be very powerful for teaching.

Yes, I I've tried earlier versions of this a number of years ago, and I need to get give us a go again.

So thank you for that.

You're welcome.

I guess we should wrap.

Yeah, well, I give guess we should wrap up.

I have been there were two sort of points in my life where it was very pivotable.

One was around the birth of DRF and the Kickstarter around that, and you know, I jumped on the beer using DRF and helping that.

And then the second was this modern this this switch in the last few years that you were talking about to HTMX and Alpine and these other technologies that are more lightweight and more Django developer friendly.

So I I've been excited like you.

Thank you so much for coming on.

It's been a real real pleasure.

It's been a pleasure for me too.

So DjangoChat.com, and we'll see everyone next episode.

Bye bye.

This episode was brought to you by Button Down, the easiest way to start, send, and grow your email newsletter.