Django: Looking Forward to the Next 20 years

Speaker 1: It's my honor to introduce our speaker for today, Emma, who has been part of the Django community for over a decade and has contributed to open source projects for nearly 20 years now. Thank you. Thank you so much, Emma, for joining in today. Talking about more, as a co-maintainer and co-author of DRF Schema Adapter and other source open source libraries. You'll find Emma sharing her knowledge and passion with developers all across the globe as an amazing, amazing and frequent speaker at conferences, Django Cons, workshops. And most of the times also inspiring folks with insight for articles and blog posts, as you might have seen in your emails Coming all the way from Belgium, Emma is here today at JangoNot

Speaker 1: Space Session 3 to share her valuable experience with us. on Django looking forward to the next 20 years. The stage is all yours, Emma.

Speaker 2: Thank you for that wonderful introduction. Um so yeah, we're here to speak about Django and looking forward to the next 20 years. If you've seen any of my uh latest talks You might be disappointed to know that I will not have any AI generated images, but I have plenty of hot takes for you And I will be glad to discuss all of those hot takes if you want to talk about them with me. Uh this is all the places where you can reach me. I'm also on the Django Note space. um Discord so you can ping me there and uh I'm more than happy to change my mind on any of those

Speaker 2: if if you want to to talk about them. Other than that, my name is Emma. I think everything that had to be said has already been said. So I will skip the the introduction slide And to get started, uh I I would like to ask you a question and you can answer in in chat. And To look at the next 20 years, um I'd like to first look at the present and and I want to know why and how you did so uh get started with Django. Maybe it was because of the of the great admin or maybe it was because you had a project with your school or your employer that required you to

Speaker 2: use Django or maybe it's just because Django is the best Python framework that there is. Or you did a Django Girls workshop or something else And uh you you that's how you got started with Django. So if you could just drop a line in chat or just say out loud how you you got started with with Django. I I'm really curious too. To know where you all come from. So I've got someone that got assigned a Django project at at work.

Speaker 2: Somebody else. Uh Say that Django was the obvious choice when they started working with um Django. Um Um yeah, um this is this is one common way to to get uh to get into Django is just because this is something that you you have to to do uh for work. Um Lilian attended a DjangoCon and became really in uh invested. So that's also really nice. So now that you've all shared, I I want to to share with you how I got started with using Django. s like

Speaker 2: someone else in in chat, um I was uh I I did some PHP for a while and I was shopping for a a new framework and I was looking at at a bunch of framework. You you will probably recognize some of the names in there. You might not recognize some other names because they are old or They disappeared in the meantime. And the thing that made me really uh stick with Django and and start getting invested in Django is that I I fell in love with the admin. This this was the the the major deciding factor with uh Django but also

Speaker 2: like a lot of um Python Uh with Django there was one and only one obvious solution and by that I mean library for every concern. If I needed to do something with Django, there was a library for that that I could use with Django And the documentation was uh quite complete and this was something rare at the time. And I also like how the RM worked. If you worked with uh other uh if you've worked with other RRMs like SQL Alchemy uh for example, you know that not all RRMs are created equal. And I liked the one with Django. I also liked that There was uh inheritance instead of blueprints, blueprints that you will find in in things like uh Laravelle

Speaker 2: that somebody mentioned. Um the way migration worked was also really nice, although it was not part of Django Core at the time, it was uh Django South that was doing migration. And I liked the way Python worked in general. But today why am I still using Django? Uh I cannot say that the admin is the best admin that there is out there anymore. There are other frameworks that do admin at least as nice as Django and some of them better. There is not anymore one and only one object solution for each uh issue with Django. There's um

Speaker 2: two, three, five, ten packages for a different uh approach like thrust or components and things like that. And the documentation in Django is still quite extensive, but other um projects have brought other approaches to documentations and have made them a bit clearer than what Django is. I often find myself when I'm reading the Django documentation I I am quite lost sometimes uh going from page to page and having seventeen documentation pages open at once because I was looking for one thing. I still like the inheritance over blueprints, the D RM, the migration and Python, but the the real reasons why I I've stuck with uh Django

Speaker 2: is uh probably the personal investment I've put in Django. So the libraries I've written, the experience I've acquired, and also the the community. So that's you here and the the great Django community in general. Um And uh today Django is almost 20 years old and that is great, uh, but we should not pat ourselves on the back too too hard here. because there's a lot of projects in in Python that are 20 years old. There's Plone and there's track that is used by Django to track issues

Speaker 2: There is Pelican, which is a statics website generator. There's also Cherry Pi. There's quite a few projects in Python that are 20 years old. And some of those projects are still thriving. Uh some of them are not thriving as much. And one of the reasons for that is that when you get a community around a project, there are people that stay around in the community, but there's also people that leave for many different reasons. And sometimes there's new people that are coming into the into the project, but not always. And um From the introduction, I I can see that uh some of you are pretty new to the to the Django framework.

Speaker 2: And um but whether you're new or not so new, I want to to thank you for being here because you are part of what makes uh Django the the community and um I want to especially um thank the Django nuts and the stars because you are the the people who are keeping Django alive by showing such interest in in in doing things with with Django and and moving Django forwards. So as I was saying, twenty euros in in Python is not that rare And in twenty years the the world evolves quite quite a bit. Recently I've been to a city that I hadn't been to in twenty

Speaker 2: years and I didn't recognize anything. Everything around me had changed And unfortunately when I look at Django and how it was 10, 15 years ago, I sometimes don't see that many changes. Um there 's since the two point two s for since the two point X series I've seen async as a major change, but It's still not fully there, unfortunately. There's been slow and steady improvements in the URM, and that's great because as I said, this is a port of Django that I loved. But when talking to uh fellows and ex-fellows, I hear a lot that nowadays what gets into Django releases

Speaker 2: is more bug fixes than feature, than new features even if there are new features that are steadily coming slowly in every area, there is more big bug fixes and features. And this is what brought me to writing this article: Stability Without Stagnation. And stability without stagnation is the motto for Amber. js. Uh if you don't know Ember. js, it's a front-end JavaScript framework that is a bit younger than Django, but has been quite in sync with this release cycle with Django since the 1. x series. It 's got a vibrant and welcoming community, a bit like Django.

Speaker 2: It is also pignonated and comes with batteries included. And during this comparison, I I looked at several aspects of post framework that were similar or different. And one of the the aspects that I want to dive into today is the different teams that are part of the greater structure of the project. And one thing I noted is that Django has mostly one technical team, which is the steering council. And Django uh and Ember sorry has many of them. There is the steering committee, which would be similar to the steering council. But they also have a framework core team, a tooling team, a data team, and a learning core team.

Speaker 2: And in the current state of Django, this this really sounds like a luxury, having so many committees and boards and teams or however you you want to call them. But uh and at some point it it might have looked like Twango couldn't do something like that because uh there was not that many people who wanted to to get involved uh at such level. But the the recent uh DSF board election give me uh joy and hope that uh more people want to get involved with Django because uh I believe it was the most uh candidates uh since a long time for a Django related election.

Speaker 2: And so so I'm I 'm I 'm quite glad about that. And one of the things that this luxury of having so many teams and and and committees uh offers is what I want to call co code ownership. Meaning that uh in Amber if you want to talk about Um the URM, there are a set of people that you know will know the URM in and out and that you can talk to them about it, you can raise issues, questions. talk about hey how how could we do this differently? If you have questions about the the CLI tools or like management comment in in Django you can you can find somebody there and and ask them

Speaker 2: And this is great just for for speaking, but it is also great for merging code and and reviewing code. And so I here I I have uh another hot take and I want to put a a big huge disclaimer. This is not uh this has nothing to do with the people were involved with this pull request. Um Jake is doing an amazing work recently with Django and pushing a lot of du of stuff. It's more uh a a critique of the of the process and how things have come to pass i in Django. So for a little bit of context, I'm talking about the merge the pull request that

Speaker 2: was merged yesterday about bringing a uh simple block tag decorator in Django. And um if I when I look closer at at the code that that was merged This is basically the the code that there is. I know that there is a scroll bar and that not everything fits on the screen. But the the most important stuff is here at the top. And this is the the new code that was added as part of of this merge request. And If you look at that code and I go to the next slide, this is another method of the same class, the template library

Speaker 2: class. That was already there. This is the code for the simple tag. And if you look at a bit more in that class, you will see that there is yet another place with very similar code. And so what I want to to highlight here is that but but when you do a pull request, what people see people who are reviewing that pull request what they see is the new code, the modified code. They don't always uh see they don't see the existing code. So unless somebody is very familiar with that specific piece of code, there are things that they might miss. Like here for the fact that basically we have three times the same method

Speaker 2: with very slight changes that has been defined. And if that was happening in one of my projects, I would probably raise a little flag and say, hey, uh probably it's time for refactoring here and maybe we want to but That similar code somewhere in another method and call that or do do something differently. But this is something that is only possible if People have ownership of the code and know exactly what they're reviewing and are very familiar with that part of the code. And so this morning I I reached out to to Jake and and I asked him, well, did did you look at at the rest of of the class and and did you

Speaker 2: uh think about refactoring this? Um and it all and if you did, why didn't you? And and basically he told me that he wanted to keep the the pull request as lightweight as possible. So refactoring what's outside the scope of the pull request. And uh unfortunately this is something that I've Seeing a lot, I've experienced it myself. I I currently have a merge request, uh pull request open somewhere. Um that uh the i in in a comment somebody asked why aren't you doing this and that and that in that in that full request and my answer was I want to keep it as lightweight as possible so that there is no bike shedding possible uh on on this merk merge

Speaker 2: request. And um this is uh and this is something that that happens a lot. And so um Unfortunately, this in this case this leads to um more work probably in the future because now that this full request of Jake has been merged I I am after this call, I'm going to open an issue to say, hey, uh maybe it's time to refactor here. Um And this means that there's going to be another review process and more time spent and probably a bit of back shedding thrown in in the middle. um and and and things like that.

Speaker 2: But before going any further uh on that, uh I want to to ask you to uh Go in chat or open your mic and and tell me if you yourself have spotted something like that some in Django because right now you're sp Spending a lot of time inside of Django, uh inside the code itself. So I know that uh during uh Simon's session on Monday somebody mentioned something about um row locking that might no be legacy because all the databases support it or if you've seen things that you you that don't feel right and and that you think should probably re be revisited inside a code of Django.

Speaker 3: I know there's been a lot of talk about um redoing like the start project command and like the the initial code like that Um regarding your something that could benefit from a more modern approach, I I would say that the community is looking at

Speaker 2: Yeah, that that's a great example. Uh when I I wrote about something that could benefit a more modern approach, I was uh thinking about the not so recent anymore, but the change to using Passcript instead of using uh OS module uh that that appeared in in Django. So I I'm going to to to go to to the next unless somebody else wants to to mention something they've seen.

Speaker 4: I don't know this area too well, but I think I've heard about the the templating. Um it's not easy to work with and There I think there was a forum discussion about making it easier to extend the templating system. Instead of like having to override an entire page every time you implement it

Speaker 2: Yeah, I've I've seen some some talks about the template and and this this about the the template tag Uh here is is is probably part part of that. Also yes, uh support for partial templates. Um Now the the warning I I want to to raise now is that if if you're going to to be um creating issues uh on on the uh on Django's track saying hey this this should be refactored and uh We could change that change this to make it more modern or something. Uh very likely answer will be that you need to create a depth

Speaker 2: and that is not an issue. To be raised directly in the tracker, but that you should create a dAP and launch a discussion in the forum. And the dApps is another point of comparison I had in my article And because Ember has something very similar to the DAP process, it's they call it an RFC process. And there are some differences between the RSC process and the debt process. One is the barrier to entry. Um for a lot of different small reasons, creating a depth in Django is more complicated than creating an RFC

Speaker 2: in in Amber And in my opinion, this contribu this creates a a barrier to contribute. And and barriers to contributions can can be good. because they help to keep the sanity of uh the fellows who have to to review the the pull request and and the issues. But if this barrier is too high, it it can also prevent people to want to contribute. And I feel that we see this with Django because when we look at the number of depths in Django, there is 14 accepted depths. I believe there are two in-progress depths. And when you look at Ember you see that they

Speaker 2: have over a thousand RFCs that are either in progress or have been accepted. or or going there. So it's it's a very, very different uh scale there. And Um making debts more accessible in the midterm is something that I I would like to see because debts are hard, it's a complex process You need to uh start a discussion on the forum, you have to spend the mental energy to deal with the backshedd that goes with the discussion, you have to find a shepherd to to help you uh you have to brush upon your RST because

Speaker 2: uh it's written in in RST um and all in all when you add all those steps uh it it makes it hard to to even get started uh to to do uh a depth so i i'm curious uh c can you do a quick show of hands uh to to see As who is familiar with the debt process in Django, first of all. Yeah, I see one hand, two hands Okay. And um among those people who has ever written a depth successfully?

Speaker 2: So so I see no hands at all. So I I I I I think this this this is a hot take, but I think this this proves my my point. Um yeah, I see Alex's comments. Uh and and it feels like Very little people feel ready to write a dAP. I I I've seen somebody who's currently on the DSF boards uh say recently that they were not confident writing a dApp. Um and maybe um those things that I mentioned, those uh refactoring uh and small things, maybe they're good candidates for depths because they might be easier to sell

Speaker 2: than uh a whole new feature. Uh new features are har are hard to to sell. And maybe creating um maintenance steps would be a a good place to to start. Um And the reason I'm trying to sell this step process and try to encourage you to uh raise issues that might turn into uh maintenance steps is that One of the things that I would love for stars that are have graduated for the from the Django project is to be able to hold other contributors' hands in the creation of DAPS

Speaker 2: to uh help people get their foot into contributing to Django and and adding feature and one way the best way to to be familiar with the depth process and be able to help others uh write depths is to have written some depths uh yourself. And I also want you to to be careful there. I I'm pushing you to um to write devs and to and so that you can help others, but you need also to be mindful of your own time. I think that having people to guide others, writing them. Writing depths can be very useful to to avoid wasting time, but you should also be careful not to waste your own time in in helping too much people.

Speaker 2: uh in writing depths that you don't believe in and things like that. So if if you do just this and start writing depth and are able to help others be very careful and mindful to also not get burnt in there and spend too much time and get discouraged later. But All in all, some people say that Django is done and and I believe that Django is not done. Uh In French there is a saying, uh it says qui n'avance pas recul, which means that if you stand still, uh you fall behind. And uh I I believe that Django is

Speaker 2: is at a very pivotal time in its history where it needs to to move forward again in order not to to to fall behind. And there's a lot of places uh where um There are small improvements that can be done. There is the maintenance that I talked about, but there is also tooling debug upgrades. Right now, there's for example for the upgrade, there is this uh great package, Django upgrade I'm not sure what's going to happen uh now that uh Adam step stepped down from the from the committee. Uh there 's a lot of small things that can be done with forms, with Ajax components, the admin. all those things. So

Speaker 2: um in the midterm I really want to make this hard thing, the debt process less hard. But in the short term, I think if we can uh help people get involved in this process and just by sheer fact of seeing, oh no we have a hundred deaths Maybe this will not sound so scary to to a lot of people and maybe some other people with will get involved. Uh so I guess I'm about at the end of my time and uh it is no time for questions.

Speaker 1: Thank you, Emma. This was amazing talk.

Speaker 2: Thank you.

Speaker 1: So, yes, we if you have any questions, feel free to unmute yourself, raise your hands, and unmute yourself and or put them in chat. Yes, Tim, please go ahead.

Speaker 3: Fantastic talk. I really enjoyed it. Um regarding the depths and the maintenance depths, would you see that as us I'm assuming you're familiar with the debt process because you You did the comparison, but like would you see that as us needing to refactor the debt process or do we need to create like for the maintenance depth, like would that be a separate slim down version of the existing one?

Speaker 2: So as things stands right now, uh I think that it would be great to to start with the full BEP process for for maintenance. It's not ideal, but get things moving. Um in the future I am a strong believer that the debt process needs to be refactored. Um You mentioned uh somebody raising the language barrier because the the language used in the in the depth one is is quite high and might not be accessible to someone who's not a native English speaker. Uh I have seen uh Sarah say that uh she was not ready to write a dab.

Speaker 2: So for me this is A signal that says, yes, there's something wrong with the debt process. So the debt process needs to be recycled. And um I hope that this is something that the next um uh steering council can uh tackle. Um But I don't think it's going to go smoothly. I think this is going to take time. And while this is going on There is no reason to to delay things and and try to to go further.

Speaker 3: Lovely. Thank you.

Speaker 1: Okay. The next question is up from Alex. Do you believe part of the stagnation is due to the steering council technically not having that many written obligations other than voting in depths? Do you think the council should be amended to have more soft obligations like shepherding or commenting on features?

Speaker 2: Yes, so I I've recently looked at the obligation of the the steering console and my my reaction there was okay but this looks a lot Like this work is already done by the fellows and there is uh not much left to do for the steering council. So yes, I I I would love for the steering council to be more involved. Uh like in steering itself like the name implies and and show the direction for for the the Django for Django for the future uh releases for the next maybe not the next twenty years but for the next two or five years. Um and This

Speaker 2: uh it would be great uh if uh they could shepherd uh more depths. Uh I don't know if in the current situation I feel confident requiring requiring that from the steering console as we've established that the process is is difficult and and so many people don't feel confident with it. But uh yes, I would love also to see something like um feature requests from the steering council. So say identify, hey, this is something that is missing in Django. Uh we'd like people would like to work on this step forward. So reversing the debt process instead of having uh

Speaker 2: people come up with features and say, hey, I want to have this merged in Django, having Django say hey, we would like to have those feet this feature Does someone want to help? Yeah.

Speaker 1: Hope this answers your questions, Alex. On the same note, you mentioned uh features, right? There was in your blog post your touch base on feature flags too. Would you like to enlighten on that?

Speaker 2: Yes, so what one way of um moving forwards and bringing new stuff to to a project without breaking everything, uh and so keeping the stability is having feature flags so that uh some some uh new features and some uh new behavior can can be introduced uh in the project they can be tested by the community at large without um impacting uh the the large user base that relies on the stability of the project. Um so f features lacked is uh a known way of doing that. Um For bigger things, I I'm also thinking

Speaker 2: of uh introdu introducing duplicates. So I'm going to take the admin as an example because uh it's it's the elephant in in the Jenkins room. Um there 's very few people that are uh familiar with how the the admin works and I I would even say that the Django admin is not written in Django. Uh as it is not comparable to anything else in Django. And for example, we could have um move the have the admin and have a a Django Contript new admin where people start uh adding new um

Speaker 2: new features and and start refactoring that code and keep the old admin and the new admin in the code and have that behind the feature flag. Do you want your project to use the old admin or do you do your Do you want to use the brand new uh admin that's going to break every two weeks? But you agree with that and you want to help uh improve that? Um and this could be uh I I've taken the admin because it's a really big part, but this could be uh used for example for the start start project. We could keep the old stored project content and next to the the old stored project we could have brand new stored project And people could try using it uh

Speaker 2: and and going forward. I believe that this is um a more viable approach than uh having uh asking people to create third-party libraries and saying hey maybe your third party library will be included in the in in Django core later on because uh there's first of all a a visibility problem. Uh if I'm brand new to the Django community I can publish 15 packages, nobody will ever see them unless they stumble upon it on GitHub or something. And um also there's to my knowledge there's very little libraries that have been actually included in Django. There is Django braces.

Speaker 2: And um that's pretty much it. Uh South was not integrated in Django, it was picked but it was rewritten into Django core. It was not the same. library. So yeah, this this kind of uh feature extended feature flag is something that I would see would be useful to help Django move forward

Speaker 1: That's really thought provoking, thank you. Uh do we have any more questions? Okay, so we have a question from Lillian. Can you tell us more about the learning core team at Ember?

Speaker 2: Uh I can try to tell you a little bit more about them. So they 're in charge of uh among other things, they're in charge of the documentation websites Um that is quite nice if you if you go look at the at the Android documentation. It's one of the best documented projects I know. Um they also spent a lot of time on Discords. Uh Amber as a very active Discord. And um There's people who spent uh huge probably an unhealthy amount of time there, uh

Speaker 2: answering questions and uh If if if you are uh new or experienced, if you go to the Django Discord and have uh a correct question, a well-formed question about Amber, you will find somebody um And that will answer you. I believe they're also uh involved in organizing other things like uh workshops. and things like that. Um but I I don't want to to say uh anything that I'm not sure about. The the learning team is about ten people. to to give you uh an idea, so the the learning core team is larger than the Django

Speaker 2: steering console. So this is this is something that is taken quite seriously.

Speaker 1: Interesting. Okay. Thank you so much, Emma, for broadening all these amazing, amazing perspectives. Thank you so much for joining in today. You

Speaker 2: 're welcome.