Transcript: The Future of Django - Emma Delescolle

This episode is brought to you by ButtonDown, the easiest way to start, send, and grow your email newsletter.

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

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

Hi, Carlton.

Hello, Will. Today we've got with us Emma Descol, who's the author of DRF Schema Adapter,

the very classy Django, classy docs, a longtime Django community member,

and a newly elected member of the Django Technical Board

for the upcoming 6.x cycle.

Emma, thank you for coming on the show.

Thank you for joining us.

Thank you.

Hello, Will and Carlton.

Well, I'll just let the two of you talk

since you're both steering counsel

and in the hierarchy of things,

that's at the very tippy top.

You can bring us tea and biscuits then, Will.

Yes, yes.

So yeah, we're diving directly into that, right?

Well, maybe let's just start with that.

We just had elections for the 6.X Django Steering Council.

This is the first time for both of you on the board.

Maybe, Emma, 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?

Yeah, all these issues, I feel none of them are new.

But for some reason, there seems to be a renewed energy in the Django community.

Maybe a new influx of people.

Definitely, Django No Space is helping with that.

But there seems to be a renewed energy.

And some people want 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 agree. 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, FastAPI is gaining a lot of mindshare, there's Flask is still there, there's new things. So as much as we all love Django, it needs some TLC to stay relevant and perhaps answer some of these big questions that are not new ones, but it feels like the community has been a little stuck on them.

yes definitely carlton what about you you you you also ran joined well as far as i could see we all

more or less think the same thing 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 but there is a kind of i don't know how how can i

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 push to try and shake loose some of the old cruft.

And exactly how we can do that is, I think, you know, that's what we're busy trying to work out right now, right?

And one of you put in our notes here, learnings from the Ember community. Is that you, Carlton, I assume?

Well, it is. So this is where we have to cut back to Ember's background because the project that you've maintained for many years is DRF Schema Adapter, which is about making connections to Ember apps.

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

yes so um a lot of the applications that i write usually have are things that deal with a lot of

data a lot of forms and things like that 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've been part of the Odoo core team a long time ago before it was called

Odoo. And so I said, okay, let's do that in Django. And one of my first frustrations was to

have to write serializers and view sets for everything. So this is the first half of the

schema adapter. It's in some way similar to Neapolitan in a way that it lets you write

a single class that will define everything for you. And under the hood, it's just a DRS 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 my models in Ember, which are basically exactly the same thing as the serializers in Django.

And so this is the second half of TRS Schema Adapter.

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

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

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

After that, you magically have the access for a CRUD system directly in Ember.

So that's kind of like the Holy Grail, right? Write it once.

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

And yeah, I've been less involved with it lately

because I feel we're getting into a new era

and I would love to...

I've tried to change to update DRF 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, that's quite cool.

Okay, so that's DRF Schema Adapter.

And that's, but specifically we came off 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 are the kind of good things they do over in Ember?

So they do a lot of things that they like in the Ember community.

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

I think that the thing that seems to be the most relevant

to what we're doing right now is their RFC process.

So every new feature or change request goes to 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.

You start an RFC, which is similar to what we have in Django with the dep process.

It's just that we don't use the dep process that much.

While in the Enver community, the RFC process is used all the time for everything.

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

And it makes things easier to reference.

It gives you a historical overview.

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

Well, Carlton is fairly wedded to track.

So those are fighting words.

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.

no that's the difficulty for me is i'm not 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 jango project in it and when you you know particularly as the next fellow when you as you

comes in and you're like i don't know like you know 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 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 like 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 it's that's a sort that is a sort of separate question to this initial

thought about you know can we use depths more all 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

so what happens to those ideas it's it seems like ember is just more streamlined right i mean because

again as carlton was saying someone comes in with an idea and they're sent on this journey which

maybe the first time they've ever done it

and by the time they get through all that

maybe they get adept, 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

Yeah, the process is

definitely

long and complex I would say

with Django

So in your ideal world, Waver

how would you, what do you think

we can do emma because you've clearly got ideas well yeah so i i would i would encourage us to

use the depth process more but in order to to use that process more it has to to be more simple

uh right now to to 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 what do people think about it um so simplifying that process seems to be really

the the first step to go because yeah i would love to to see the the process used way more like

like it is in in amber and there's there's something about the issue tracker thing is that

you talked about duplicates like we often we there's a thing that happens with the 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 to constantly have to repeat the

same conversations and remember oh what was it that someone so said that was really and you have

to go and find it and then and if we could somehow you know one of 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 and this exists right 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 venture to say it's a solved problem i

don't know but like we're not the only ones having this pain and it it doesn't require crazy crazy

search or anything right it's just looking for the terms in your title and headline and just

auto showing what else is in the database yes and github is maybe not the the best solution

I agree. I personally have everything on a GitLab that I host myself.

I only have duplicates, copies on GitHub.

But we also have to be in face with reality that everybody has a GitHub account.

Everybody who might want to contribute 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.

We can't fight every battle.

No, exactly, exactly.

I think one thing you've talked about as well

is perhaps a contributor comes along

and they perhaps don't get the time that they need

to really be welcomed in.

And so, I mean, 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.

Definitely.

We're too close to capacity and it's a vicious circle.

People who are already involved don't really have time for people who are less involved.

And people who are less involved, there's tons of...

testimonies of people who feel that they have had a door slammed in their face

when trying to contribute to Django.

And so we have a very, very low retention of contributors,

which means that the people who stay, they have more work.

And we go round and round.

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

Yeah. And of course, it's easy to just say, raise some money, have something like the fellows for XYZ problems that we have. I mean, I wonder, just thinking of Ember, 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 so I'm not sure how they manage that in the Ember

community.

I know how they do it.

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

So there's one requirement to be part of the Ember 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 ember

or to do ember related stuff uh i'm not and that's that's 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 people then you can show other companies hey look uh this other company they

are paying somebody to work on amber um you also need companies that really rely on amber right

because uh it's possible there are there are thousands and thousands of companies that rely

on django 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 is he so but we need more of that actually we need that five percent

time that ten percent time a day a week day every two weeks to to give to django and i i think that

would be an amazing possibility to pursue and to poke companies and to say hey do you know that

you're writing it's the most useful thing you can do is well maybe it's it's i don't know if it's

formalized somewhere but also if we had a page on the django project site that listed companies

because companies do need to get something 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 jet brains which

makes PyCharm, and they're like, yeah, you can work on core Django, but I have to set the goals,

figure all that out with my manager, update it, which I'm going to. But I'm not aware of a document

of here's how to manage this within your company. Because I think 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 some return on

investment like i don't i i don't know if that idea has come up again someone can holler but

like it doesn't seem like a huge thing to list 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 well one easy perk is to have an easier time

to get the features that you want 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

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 or a third

party right third party even seems a more immediate way because often companies right 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 about this today i was thinking you know because i built i since i

stepped down as a 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

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 you know that it will keep the 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

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

to be able to say look we've got a rock solid core here um that's why i use it right i agree

the stability is important but there's this little thing it's never a huge feature but um there is

let's say there'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 um yeah sure so yeah there's little things but yeah major

features if not something that the company is going to want to add to Django most of the time?

We were talking about capacity. The obvious thing when we say is to fund a new

fellow. Could we get more money and fund an extra fellow? I kind of feel

that would buy us an amount of time. That would give us more capacity, but somehow that would

be overwhelmed. I think we need a different kind of strategy somehow, because the fellows are

are running at full capacity we could add another one that would buy us you know say a couple you

know it's like when you build an extra lane on the motorway like two years later the motorway

just as congested it was it was before um i wonder one thing i've been thinking about is

could we modularize somehow could we split because there's a 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 through the two fellows through django core with its eight month

release cycle and is do you have any thoughts on what breaking it up a little bit or yeah i do so

there's there's different models there's the the pyramid model uh like pyramids they used to have

okay this is the basics of programming but if you want to have everything there is this cookie

gutter that installs everything.

But if you want to have an API, there's

this good key gutter that installs everything.

I don't think they were very successful with that.

So I'm not sure it would be good.

There are definitely some things that I don't use in Django.

That's 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.

Yeah, yeah, yeah.

you're going to upset somebody so don't worry but the size framework for example

uh i've always it it either gets in my way when i want to build something that's just one single

website or it doesn't have the features that i need if i want to do something a sass like thing

with uh five domains accessing the same code base and everything so may this could be a candidate

to remove. There are things that are needed. There are tons of things that depend on the

size framework as it is right now. But is anybody actually using that correctly? Templates,

that's something that's going to upset somebody. You're going to upset me now, because I love

I like Django templates.

I never use Jinja.

But if we want to think down Django, do we need to have templates in Django core?

There is a lot of applications that just do Django REST framework.

So could templates be part of something else?

That's an example.

And Wagtail does it in a certain way that kind of works,

which is they remove things from Wagtail and they say,

oh, by the way, now this is a separate application.

The problem with that is that it will probably go unmaintained at some point.

Yes, right.

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 code 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 good way to to starting 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 one of the big selling points of

django is it is the ease of upgrade now and we all remember well everyone who's been using django

since the old days remembers like what it used to be like updating and there was this it was kind of

almost cultural that bragging rights i'm still running 0.96 i'm on 1.2 other you know and it

It was who was running the oldest, whereas now it's very much you're expected to be 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.

I can't remember the exact title, but it was touching on this issue.

How do we balance those two things?

It would be great.

Right now, I understand there's something that two fellows cannot do, but it would be

great if Adam Johnson's package, Django upgrade, was part of Django.

Because if we have an upgrade path, we can break things as long as we have a solution.

I just keep thinking we – one of the – maybe it's even a level higher than what we're discussing is that we just don't have the people and the money.

I mean, 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, 10 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?

It does feel a little bit like the same old conversations, but it butts up against the fact that at best you have someone like Simon Charette who can do some time, but not a ton of time.

And then the organizational stuff, no company is going to pay for you really to do the organizational stuff, which leads into, 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 these corporations.

So 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 feel like we're just asking too much of our people to do it.

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 sit 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 thing i don't know did i just did i

just waste a couple of minutes or is that something new to proceed i mean this is the

topic we're talking around right i mean emma what how would you i mean i'll do you see okay to turn

that into a question is do we need to raise more money to get more capacity so that we can ease up

the log jam that we have or do you or do you see like enough um ground that can be cleared to buy

a bit of space to give us more freedom.

I think there is ground that can be cleared to give us some freedom.

It doesn't mean that we cannot use more money.

Yeah, more money as well would always help.

More money and more time is always good.

But yeah, I've always had this feeling that the Python community in general is like this

Very purist open source compared to, you were mentioning PHP and Laravel.

They're very purist and they don't want to sell out to companies and they don't want to sell out to this or that.

And the side effect of that is, yeah, maybe they sold out.

Maybe they're just doing business, but they get money.

We don't.

This episode is brought to you by Buttondown.

That's Buttondown.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.

Buttondown 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 Buttondown 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 jango

and if you email support they'll white glove migrate your existing subscribers and archives

for free yeah i mean and look who look who's on the the python software foundation board it's

meta Microsoft, you know, examples.

Um, yeah, yeah, I feel like we should, we, we, uh, like even something on

perhaps I'm coming at this from a new angle because I'm, again, I'm now working for PyCharm,

so we're thinking about marketing. I was just this morning looking at the homepage of Flask

and FastAPI. FastAPI has, very similar to Django REST Framework, just on the homepage, boom,

companies that sponsor, right? 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'm not currently on the board. We have new board

members. I know many of them feel this way. It's just all the more jarring for me now being on the

inside of a company that makes money off of Python and Django and has a budget, but there's

not even much visibility. Part of it is people come and go in larger corporations,

but there's not even much visibility around, for example, the Django

campaign that PyCharm has done for years that I helped work with because some of the people

aren't there. I guess I just see that I have renewed energy to go to these companies and be

like, hey, 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.

And I would couple that with we bury our existing platinum sponsors of which JetBrains and others

are one, like we bury it. It's hard to find, right? It should be found in Central.

I can't find it. I go to Google to find it. So anyways, I agree that there are things that

we can do to clear the path i also think that we can still be pure without but be more

recognize the fact we compete in this world in which other frameworks

have far more resources than we do so can we call the episode there is no ethical open

source under capitalism sure why not

so just to get just to give context so i throw it back to emma the that number you you say if

we can easily make six figures that's the mythical extra fellow or that's the mythical executive

director right just there that's in that package that you just talked about there's the money to

fund the thing that we say we want which we should get the board on and you know harass them all

right i'll go i'll go paying them after this episode here's a new idea no one thought of

what if we what if we made the money but no but it's so yeah emma i was gonna throw it about if

Do you have any more thoughts that you wanted to say on this topic?

Because there's one other thing I wanted to talk about.

I guess I touched on it a little bit with mentioning the templates.

There's also this thing that with Django,

the Django project from the start has had a point of having everything in-house.

So we have everything written inside the Django project.

Um, maybe we can leverage other open source projects, uh, like, uh, click, uh, like Jinja

for the templates or, uh, click for the, uh, for the management comment and other things

like that, that would be a way to, to cut down the, um, to cut down the lines of code.

And there is always a risk by using a third party application that is 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 interesting interesting because uh just this

week there was an arm in um what's his surname for necker yeah he did he did a thing about

vendoring you know writing your own one and then there was a yeah he spoke to you carlton you you

you felt seen in that yeah yeah exactly there's um and the htmx um website a new essay appeared

on vendoring and you know arguing the opposite so what what's nice yes we could take on dependencies

maybe like we at but how far do we push that are we suddenly using the sequel alchemy or

you know well what point is it well peewee not not sequel okay right okay okay okay

emma i wanted to ask you we're talking about jingo rest framework what do you make of

jingo ninja because i would say that that's not even the hotness that that is on pace to replace

jingo rest framework for reasons that aren't completely clear to me but that seems to be

the trajectory so i'm curious your your thoughts no it is i i believe it is and i think that one

of the reasons probably not the only reason but one of the reasons is that jenga rest framework

is in maintenance mode it just stopped so the 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 jango

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

and it's faster in quotes too so yes uh i don't carlton's reacting we don't i'm just

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

We will use a monitoring.

I've never actually thought that Django, Python, or Django REST framework were that slow.

Most of, yeah, Python is not fast.

If you want something fast, go with REST, or C++, or write your web server in assembly.

But usually, it's not this slow.

What's going to be slow is your request to the database.

it's going to be your file access and all that.

So I've never felt that Django or Django REST framework

was a bottleneck when it comes to speed.

No, and I just had this last week with...

So my new company is...

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 is 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 saved a developer

time versus milliseconds later. Yeah. Carlton's making the face I have.

I'm actually going to have to fire off now because 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 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 but 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 yeah brilliant it took me months to write you know my hello world no just

so it gets so it's just so backwards it's so it's not an engineering mindset that's the thing

it's almost like a it's almost like a political question where you're just like we're just talking

past each other here it's like yeah hooray i support the eagles no i'm a cowboys man no that

what it's not engineering i don't know how many uh sports fans there are 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

thank you it's relatively new couple months old um so classy class-based views for your docs for

your code right like tell us tell us tell us more what made you take that next step of putting it

into a package because once again with everything i needed it 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 card because this is what's what i use as documentation we don't

have to argue about function-based views then good good that's another okay um and uh those are

great but when you start to build more complex application and you have a code base that is

10 years old and you need to find something sometimes uh the class-based architecture

does not let you find it easily and the way you can do it you can open a shell

manage.py shell and go from there and find what you need but having it on a website

that is generated by your code is also much much nicer so every every piece of business logic of

properties or anything that you've added on top of class-based views or janglerist framework or

models. It's right there. It's auto-documenting in your code. And even if you don't have code

comments, 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 agree yes

the only question is why hasn't anybody written this before and published it

what's your answer i don't know you must have a thought you don't know i don't know i've looked

The thing is, I've looked, or maybe I didn't know where to look,

but what I found, I found some people who've done it for Python in general

and that use Ginger for templating, for example.

But that's not fun because if you're using Django,

why load two templating engines?

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, for example, a Django model is something specific with fields and things that will not map correctly.

It will not be intuitive if you just take a Python version of this kind of tool.

Yeah, you want to represent it in a way that makes sense to a Django developer.

yeah and yeah uh maybe it's because of what you say carlton maybe nobody uses class-based

views because they hate it um whoa no no no no you must be you know i love class-based views

the criticism is about the implementation not the class-based views right the

the whole function-based view versus class-based shooting 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 base 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 dot method equals post and

then you've got everything indented a block it's it all just works out the same it's oh those are

fighting those are fighting words carlton i like it yeah i i feel like this is touching on another

Another issue that I feel we have with the Django, maybe not with the Django community,

but with the Django resources, is that there's something that Python does very well.

Python is welcoming to the newcomer.

Python is a new basic.

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.

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 this is a space where i feel that class-based views and django's implementation of

class-based views are useful it's a bit more of a 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

Django class-based views

get so little love.

Will, you're an educator.

You're in this space.

Like, what do you think?

Yeah, I mean,

what do I think about that?

I guess how many people

would sit through

an educational thing

on class-based views

as opposed to having

a specific problem

with a 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, in my books, so my books, for example, I now start with

function-based views in the beginner's 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 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, that's just 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 can i yeah can i ask does it work from a market point of view because if you think about

this 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 well you have to charge a lot more 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

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 i mean there must be a market for it

because there's all those certifications.

And you were talking about Java.

You can get a ton of certification in Java

on every different levels.

Right, you know, people, yeah,

people get it from Coursera or Meta.

I guess it's that question of a 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 almost free. I don't know. I

don't really want to get into the educational side thing. But it's the same as the open source

problem, right? It's like, you know, it's people aren't going to pay or this is the problem. The

marginal cost of delivery for open source project is approximately zero right it's you go and fetch

it off pipe pi you pip install it they cost 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 that we've

been talking about all episode this sustainability problem i feel like i'm going to get wound up on

this i mean yes there's i don't know i'm gonna shoot my mouth so emma i'm i'm gonna swing it

back to emma now emma so i i've just feel from the comment i know you've got lots of positive

ideas and lots of positive say we've been quite negative in what we've been talking about a little

bit and we've been hitting on problems and digging into those problems what's your what's your sort

of um solar punk positive out where do where do we want to go looking positively dynamically for

django now uh so in your first of all only people who don't do anything don't do anything wrong so

the fact that we've been negative it means that at least something has been done um and 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 push toward things like HTMX right now that bring the ball back into the backend camp, I'm going to say.

It's slow.

Corporations are still not on board and things like that.

But slowly, the pendulum is swinging back to server-side things, website.

and Django has a great ORM

it's got nice forms

it has some batteries included

even if they are not perfect

right now their authentication is there

authorization is there

and so it's got all the bases

for you to write your application

and let's ride that wave

and jump on that train

and stay the best framework that can be there to write your application.

Well, I'll say something positive too, which is, I mean, we are riding the Python train,

which I think anyone, that's the train you want to be on.

It's growing and growing and growing and growing.

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

PyCharm is not the biggest seller at the company.

It's IntelliJ, which is a JavaScript.

script IDE. But Python, even for a company with 100 products or whatever it is, the Python stuff

gets the most traffic. So we are riding the train up and to the right. And Django, 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.

And I'm positive by all those things, right?

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

But it is balancing those two barbells of how do we stay friendly to beginners 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 it's an interesting one

because like let's say we didn't let's say we said no we're not going to merge it into core

how do we package it with django even if we didn't merge it into core that's an interesting

well because if we could solve if we know but let me finish 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 from the UX perspective so fast API fast

API 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 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 we can play in this

space now isn't isn't there somebody who is working on taking the orm out of django i i know

this this is something that people have been talking about for 10 years but i thought i heard

somebody was actually doing it i don't know i've had heard various people talk about um making it

easier to use django in a so to use the orm in a standalone project a non-web project so 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 that would be this could be this could be the first step pip install django orm

if we could achieve that maybe um then i think we we have a recipe we should just go all plugins

like um simon willison right just plug in i'm experimenting with that oh yeah so simon did a

talk in go on no i i'm experimenting with that when one of the one of my site project right now

is a static site generator based on django um and um i am trying to have everything

be plugins. So just have the basics that does web pages. That's it. 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 plugins for a lot of things. This is one of the size

projects that I'm playing with right now. I love that idea. I was just having a conversation with

The experienced Python person who wanted to do something, update their personal site, and I won't use a gender, 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.

But this is someone who knows Django, right?

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

Yes, sign me up.

What I'm using, so I'm not writing anything special for the static part.

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

So you have to tell Distil, for example, how to find all the blog posts or all the pages.

And you decorate your URL patterns with that

and then you generate your website

and it will generate everything in a folder

and then you can FTP it wherever you want

or put it on the GitHub pages or anything.

I'm putting a link in the notes, Django Distil.

That's new to me.

I didn't know about that.

I see a little birdie told me

that might be getting a little rewrite and an update at some point like a big a big new version

yeah i haven't heard back uh i don't know if it's still on the table but well fingers it's not on

no it's not like that's my marketing hat on that could be a cool like google summer of code thing

to try to push some momentum because 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 every year

you try every web framework right 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 the bag you pull

django out 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 did pajango 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'd be like yes i can use i can use my best tools right and it's already how i'm

teaching it which is i start with urls and templates and views 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

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 uh i'd love to give a shout out to pyscript 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 you everything

server side with htmx and things like that but i feel there's still some products anything that is

long lived in a browser or anything that you would install as in as a an electron application

um it is a great fit for for by script if if you want to to write to be able to write everything

in python um by scripts is already there it's a bit slow to start so you're not going to to

use it for your blog but if you're i don't know writing a point of sale application

py scripts uh can can come here and replace javascript front-end if you want to do everything

in python how are you using it these days uh these days i'm not using it much but i did write a proof

of concept front-end framework in Pyscript that has everything it's got.

It uses SQLites for caching any requests to have a local copy of anything that it gets

back from the API.

It uses Ginger for template rendering.

It has frothing and everything.

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

And PyScript has come a long way since then.

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

If someone has the time to look into that right now,

I'm sure we can have a very nice front-end framework in PyScript.

All right. I like it.

I've seen Django running in PyScript as well.

So you look at the Rocket page there and you just think, well, there's that Postgres version that can run in it as well, run in Wasm as well.

And you could have Django running sort of fully locally or fully remotely, whichever way you like to think of it, possibly.

Yeah, I feel that it's a great, it can be a great tool for documentation and tutorials.

If on the 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.

That can be very powerful for teaching.

I'm going to have to look into this more.

yes i i've tried earlier versions of this a number of years ago and i need to give us a go again so

thank you for that you're welcome take us out i guess we should wrap yeah i guess we should wrap

i would i was gonna effuse madly about i'm as you i'm positive about the future channel i have been

there were two sort of points in my life where it was very pivotal 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 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've been excited like you.

Thank you so much for coming on.

It's been a real, real pleasure.

Well, thank you for having me.

It's been a pleasure for me too.

Thank you.

So DjangoChat.com, and we will see everyone next episode.

Bye-bye.

Join us next time.

This episode was brought to you by Button Down,

the easiest way to start, send, and grow your email newsletter.