Improving Django - Adam Hill

Speaker 1: Hi, welcome to another episode of Django Chat, podcast on the Django web framework? Still a web framework. I'm Carlton Gibson, joined as ever by Will Vincent. Hello, Will.

Speaker 2: Hey Carlton.

Speaker 1: Hello, Will. And today with us we've got Adam Hill. We're really excited to have you on. Thanks for coming on, Adam.

Speaker 3: Thanks for inviting me.

Speaker 2: So we were just talking offline about your podcast, Django Brew. How's that going?

Speaker 3: It's going great. So uh This started after the Django Khan in Durham. So my friend Sangeeta and I went to it and I was just like, hey, we should we should start this podcast and talk about Django because there aren't enough of them floating around and so uh it turns out that scheduling and actually making time to do it is challenging and then editing afterwards is also uh time consuming, but we have put out a couple of them and um they're really fun to do. I don't know if anyone listens to them. That's not really the point. The point is just to

Speaker 2: I I listen to them.

Speaker 3: Okay, great.

Speaker 1: I'm always impressed with your production uh value as well. You have things like sample code that goes with the episode and I'm like, well, sample code with the episode, that's a step up.

Speaker 3: Yeah, we try to we try to edit them. Uh you know, we have bloopers at the end, which is honestly my favorite part, because it just shows how silly we are and how bad we are at this. But um yeah, it's been pretty fun. But Uh the other day I was asking on Mastodon if anyone knew how to make the editing a little bit cleaner and easier. And actually I think Will, you and a couple other people chimed in about Um off, I think is how you pronounce it. And it's sort of like a AI way to get rid of all the filler words that I am very prone to say, like ums and ahs and And things like that.

Speaker 2: So we had the creator on back in God, 2020, 2019. Um so we've I we we've been using it from the beginning and it's still he's still working on it and it's still great and I still am like, uh do I still need to pay for this? Because there's tools built into Riverside and other things, but it's still better.

Speaker 1: It's almost like pre-AI. AI, right?

Speaker 2: Yeah, yeah, yeah. It's real.

Speaker 3: Yeah, it works it works great. Um we also use Riverside and we were trying to use their editing and it was pretty janky. It didn't work as well as I wanted it to, and so um but this alphonic thing works great.

Speaker 2: Yeah, we uh God, I'm I'm just pulling it up. Yeah, June 2019, episode 18. Carlton, you remember that seven years ago?

Speaker 1: I remembered the recording, but like seven years ago.

Speaker 2: He actually had a bad microphone. It was like the one time we were like, okay, if anyone like just like don't give a whole speech and for whatever reason it was slightly off. I mean, not that he doesn't know audio But I remember having a sense of like, oh, I was slipping there. And I had to do a lot of

Speaker 1: an audio geek to turn up with like, you know, decent kit, but no.

Speaker 2: Yeah, yeah. Probably now it would handle it, but I had to do a bunch of I I was doing a bunch of EQ stuff. Anyways, yeah, it's it's great to see the podcast. I mean, I'm curious how your journey will go because like uh when when we started off doing this, I was trying to make it like NPR here in the US and make it just perfect. And then you just slowly kind of let go of things and and actually Michael Kennedy of TalkPython, he was great at telling me just where that line is and you know, you still need to have high enough quality, it's not distracting, but it people People just want to hear what you have to say in a non-distracting way. And if and they want to have another episode, not have you spend 20 hours on an episode and then burn out from that.

Speaker 3: Yeah, that makes sense. Um yeah, the consistency I think is the is the hard part. Uh because I have a lot of stuff going on, which I will probably cover some of those things, but um you know, making time to to do it. And I think the the podcasts that I listen to the most are on a weekly cadence. Um but I just can't. Do that and that that's just that's really hard to do. So

Speaker 2: it's it's better not to burn out. And I would say too, like I when we switched to Riverside this fall, I thought I hoped that, oh, we'll just do everything there and it'll be more efficient. And I think I put out one episode like that. And then my wife was like, It sounds different, the audio version. Cause it didn't sound as good because I didn't run it through Alphonic. I didn't do all the tightening I do in garage bands, so I still do both now, which I think is worth it. Sorry Carlton, you're gonna say something.

Speaker 1: conversation for any project that you have going, be it a podcast, be it a blog, be it a an open source project, whatever. You have to do it in a way that is sustainable. And you know it can be the same if you've got an Instagram. account you you know you see people putting so much effort into a 30-second video it's like can you really do that or can you do something that might not be as high production value but is you and is sustainable because In the end, it's no fun if you're killing yourself to trying to produce something that's uh, you know, against prote professional production teams when you're one person, you know, one or two person bat.

Speaker 3: Yeah, this makes me think about um Django Unicorn, which I spent well, I started in twenty twenty. I just looked back and I was like My gosh, it's so long ago.

Speaker 2: But

Speaker 3: um so basically it is uh interactive component library for Django, so you can make, you know, things that kind of interact and you don't have to write JavaScript and it started with just like a simple idea. Um, and then, you know, I consistently made changes to it and made it better. But at some point, probably a couple of years ago, I kind of burned out on it because it wasn't like a sustainable thing that I was I was doing and it got popular enough that uh people were using it in production and then were upset when there were bugs and I was like, Well, I've got, you know, a life and a job and stuff. Uh so I think that really rings true what you're talking about, Carlton, for the for the open source maintainers, you know, just being able to

Speaker 3: Um have something that you can you can just be consistent with and and not burn out on it is uh it's really tricky, I think.

Speaker 1: Well you've mentioned it, so I mean you've got a million projects and we've let's talk about some of them, but like Django Unicorn's probably your your sort of biggest and one. Tell us about it and You know, where where is it at the at the moment? 'Cause I see I've seen recent activity.

Speaker 3: You know, I like I said, I sort of took a little bit of a break there and I put out a call for a maintainer, so trying to get some help and Um oh I also started the process to get it moved into Django Commons, uh which is sort of like a community organization that kind of helps with Django libraries. Uh because I was kinda I was getting frustrated, I would say, of just like all the bug reports and uh just feeling responsible for this thing that You know, I put out a lot of stuff and mostly I'm just prototyping and trying things out. I just want to see how it goes. And this kind of took a life uh took a uh took on a life of its own.

Speaker 3: Um, but uh there's someone from Django Not Space, uh Johanin Johanen, and he reached out and said that he would help me uh maintain it and so now there's a lot more activity we got um he has a roadmap for uh 1. 0 which I'm really excited about and he's squashing a lot of bugs. So I think one of the lessons in here for me around just being able to maintain these big projects is having other people help out and not feeling like it's just on me to do everything. So I don't know if you felt like that with Django template partials, Carlton, or or anything.

Speaker 1: Not so much with template partials because it was a very small package and you know it had a fixed it had a fixed scope. But um, you know, we said on the the um the last episode with Fahan was on that um uh you th there's no way that I could have um i I know there was no way because I started the project several times. was have done the work to get it into Django without the Google Summer Pro project. So that I did need him for that sense. But with other projects I've worked on um you know, channels I've tried y over the years to bring people on. I've had people come on and they've they've stayed for a while then disappeared and that's something that it's like I'd really like it if we had we have got an active community around it but it's not quite how I want. Django Filter, I've looked after that myself for many years because it's just the right size for me. I it needs very little updates and and whatnot. But Rest Framework I really felt that, you know, it was kind of stuck and now that's moving into Django Commons as well for similar reasons.

Speaker 1: I think The bottom line is you've got your project. Are you really going to be maintaining it by yourself in 20 years' time? No, you're not. So you're not going to be answering every issue. You're not going to be interested in merging the pull request. So you need to th at least have some idea of well can I be open to new contributors? And I think Chang'an Ought space is just phenomenal for that because it's bringing youngsters into the community and like getting over those first few steps, which are really hard, it's really intimidating, you know, if you turn up with zero experience and to a repo, well you're gonna struggle to get the mentorship you need there because the maintainer probably doesn't have the time to take you under their wing.

Speaker 2: Same for um I'll just shout out to the Django News newsletter that Jeff Triplett and I do. We have generally people from Django Not Space who come in and do the updates to Django where they list It's usually double digit and um and I'm so thankful that people do that. And but I think it's also a great entryway. It's you know it's Easier than some other tasks you can do. You can contribute to Django. You can get experience. And so I mean that section would not exist without Djangonaut Space and the people who manage it and do it. So it's another great thing.

Speaker 3: Well one thing about that that I really enjoy when I read that newsletter is it shows how much is happening in Django and what new things are happening.

Speaker 2: I'm always like there's nothing nothing's happening and then it's like eight articles and we're like moving some the next week. Like it's crazy. It Yeah.

Speaker 3: Well, and all the PRs that get, you know, merged in and everything. It's like i I think that is one thing that we as the Django community have maybe not done as good a job as I would like is sort of showing all the activity and uh making sure that people know that Django is evolving and is uh continuing to push forward. Um so I really I really love that.

Speaker 1: So you mentioned the that that one of the topics I wanted to pick your ear on there is like 'Cause I think Django's quite dynamic, but that's because I'm very close to the code base and I see all the changes that get load in loaded in every release. And I literally every major release, I'm like, wow, that's another absolutely amazing release. But there's also a lot of frustration, or felt or perceived frustration, or whatever, about Django moving too slowly, or I don't know what. What's your what are your thoughts in there? Because and what can we do and I don't know. You might I know you've got half ideas at least.

Speaker 3: Uh yeah, I mean I think part of the have you ever been on Reddit, Carlton? No, I've never read it, but

Speaker 2: he's familiar with it. He won't cop to it.

Speaker 1: My my children go and read it and I'm just like they 're like it's the only source of truth. I'm like it's not a source of truth.

Speaker 2: I'm turning into your kids now. You know, they take it down. You know, I just yeah. Sorry, go ahead.

Speaker 3: Uh that was a joke, but but yeah, I mean I think I think it's hard because when you're inside the project, you do see everything that is happening. Um but We I think historically haven't done a great job of marketing all those things. And so, you know, I think if you look at the the homepage, um it's not always clear like when the new releases are now it's on the sidebar, um, or like what the actual features are of Django, or let's say Django tasks now got introduced in 6. 0, like that should, in my opinion, be a lot of fanfare around that and just like here here are the new features. These are the things that are getting pushed forward with Django.

Speaker 3: I know there's um a social media working group. They're doing a good job of pushing some of that. Um but there are other things that I would expect, I think, um, from a from a major web framework, like a like an email list where we announce new things. I know this is sort of like a bug of the thing.

Speaker 2: I'm like a quiet, quiet, quiet death over here. Keep going. Yep. Yeah.

Speaker 3: Um so I know that a lot of this has already been talked about a lot and and It hasn't happened for for reasons. Um, that's fine. I'm just bringing up that, you know, I do think it would be beneficial for Django going forward.

Speaker 2: I think we should say it. I mean, I'll give a shout out to Sarah Boyce, uh Django fellow. She's giving a talk at this uh PyCharm TV Unplug Day in about a month that you're going to be at Carlton. And her talk is titled Django Has a Marketing Problem So we we'll do our best to promote that. Can we can we show the you mentioned the homepage. You've done some work on this. Can we can we talk about That URL link, is that okay? I can share it for people. All right. So I mean

Speaker 3: put it in the show notes.

Speaker 2: Well, I can do better than that. Um

Speaker 1: Can you get it on screen? Cool.

Speaker 2: Yes. Watch this. Watch this. Sorry, audio people But but Adam did all this work on this interactive we'll put the link in homepage that looks I mean just look at it like Oh my God.

Speaker 3: It's

Speaker 2: it's more than okay. It has everything we want. And it's you know, and I think I, you know, t why why don't things happen? You know, partly We have volunteers, right? We have we have a new board, we have new people there. Like, I mean Jeff Triplett is the new president. He's doing tons of stuff. I think we just have a capacity problem. So we all agree or mostly agree on what should be done. And then it's like, okay, and who's gonna do it? Um so

Speaker 3: Yeah, I mean I I think we talked about this on the last podcast episode that I was on, which I don't remember when that was, but um you know I think the Django community is great and I love that it's all volunteer and um it feels very egalitarian. I do think it makes it hard to push big um big features forward or big new ideas forward because uh it's a lot of people have opinions about things and it just I think it's a little challenging.

Speaker 2: I think there's also an ownership thing, I would say. I mean, so right, code. You add code in. There's always a question of how big or small to make core. You know, if you update the f the website, okay, well then you're gonna be there for a little bit, but then it's someone else's or the community's problem eventually. So I think people who are in positions of uh authority are very aware of the costs of changing anything. And I think that and I speak for myself too, it can make you a little bit gun shy to That's probably the wrong metaphor, but you know, a little bit reticent to um to do things because you're also immediately thinking of what's the parachute of obligations coming with any change. But maybe I don't know, maybe DjangoCon Europe, we can get people to swap the link for this homepage and like put it up for a week and see what see what people think.

Speaker 3: Absolutely.

Speaker 1: I agree.

Speaker 3: The only thing I would say is like the homepage is just my, you know, my first attempt of like, I think these are the things that should be on there.

Speaker 2: Yeah.

Speaker 3: I there probably should be some, you know, back and forth with people who are interested and who have opinions about like, oh, this should be different or we shouldn't change the top nav because like now it's too hard. Um so I don't I don't think that I have a hundred percent like the perfect solution for these things. I just I um I made a a Django forum post and I was like, hey, does anyone want to work on this? And there was a lot of conversation in there and not a lot of um actual like okay and this is what we're gonna do. And my personality is is wired to just like do things and then see what happens and So that was my like, oh, okay, I'm just gonna make this thing

Speaker 3: and then see if there's a a reaction and see what we can what we can do going forward.

Speaker 1: This is the same on the code side, right? It's like we've been talking about getting content negotiation into the request object for a decade. We've been talking about updating the homepage for a decade. It's just really hard to do because Django's a slow moving beast. And on the on the code side, it's why I'm so militant about just throw it in the third party package because you can create something, you can show it up, you can see if there's a reaction. Whereas if you're like, no, this has to go straight into court, the chances of it happening are you know, minuscule because there's just so many barriers to so much inertia. Whereas if you put it in a third party package, there is a chance that it can get adapted, y you know, as Django tasks or template partial shows.

Speaker 3: Yeah. Well the other thing I wanted to shout out was um the Django New Features project board on GitHub I think is a a great new addition to sort of surface these things 'cause I think a lot of people have ideas about what should what should be added to Django and what shouldn't be. And this is sort of like putting it to the marketplace, so to speak, of just like, are there people who are interested in this? Are there people who want to sponsor it uh going forward. And so uh I really love that.

Speaker 1: Well that's good because I mean from a steering council perspective we didn't know it was an experiment. We were like we had a problem. We got a problem that um, you know, people would go to track with new feature ideas and they'd all get closed as won't fix and you know that was no good that wasn't any good for the fellows and it wasn't any good for the people proposing it. And so, you know, we came up with this idea collectively and we refined it and, you know, a lot of work. went in on that and it seem it it's nice to hear, you know, that you think it's going well.

Speaker 2: Here it is. We'll we'll put a link to it, but it's

Speaker 1: Well the the egg goes we had over that mermaid diagram, I'll tell you. The flow chart.

Speaker 2: The flow chart I just s f flitted by in half a second. Yeah. Can we um I'll just while I have this up, um, you also have this Django API frameworks repo that's relatively new. Can can you talk about that?

Speaker 3: Yeah, sure. So there was a uh keynote at the last Django Con in Chicago from Zaggs, I think, about um Adding well it was around like all the all the use cases of Django. So you can have Django as a a cron, you know, management task runner, you can have it as a a website, you can have it as a API. At the end, there were some proposals of like we should make uh REST API more inside of core. So the thing that comes up a lot is like, oh, why don't we just merge DRF into Django? Which I have opinions about, but it it it's neither here nor there. But it made me wonder about

Speaker 3: uh all the ways all the different API frameworks for Django because I knew of three at the time. And so I wanted a way to basically see how they all worked. And um I have benchmarks in there. I don't know if the benchmarks are super useful I I will say I was a little, you know, offended uh in the podcast with Far Firehan when you were talking about, oh, benchmarks are only for beginner developers. I'm like I think they're I think they might be beneficial for everybody, but that's okay. Um You

Speaker 1: gotta have 'em, but they're all so useless at the same time, right? It's

Speaker 3: Yeah, I think I think the problem is that they are a nice thing to point to for people. And so I think it kind of comes back to my marketing conversation from before is like it's really good marketing if you can say like we're the fastest um framework. And if you have if there's nuance to that, it becomes harder to convince people to use Django. Um, I'm not saying we have to be the fastest. I'm just saying like It would be great if we were, because that is a way to market Django to other people.

Speaker 1: We don't have to be fastest as well. We just need to be not load slower.

Speaker 3: Mm-hmm.

Speaker 1: And what what I like to do?

Speaker 2: Come on, Carlton. Come on.

Speaker 1: Okay, so I've got a project

Speaker 2: I gave Carlton advice on naming for this.

Speaker 1: Uh I've got a project that's in a uh Google Doc which I'm like, okay, let's just joke call it the Fast Django project, whereas it's lining up to do exactly these kind of benchmarks that I've seen Adam doing, that I've seen Fahhan doing. Um that I've seen Andros doing. Andros who's the um creator of Django Live View, he's been doing these um kind of benchmarks as well. And I was like, wow That's amazing because there's other people doing the benchmarks. I don't I don't have to is my main my main thing's I've got, you know, am I gonna get to it? Not till later in the year, right? I'm I'm just not gonna get to this at all. But So to see other people doing it. But then to see like Fahhan in particular, he sort of started it. He picked up um Django uh what is it? He picked up Message Spec and just created some serializers around message spec. And just by doing that We were able he was able to show that Django will run, you know, as fast or, you know,

Speaker 1: same ballpark as FastAPI or all the other frameworks without making any other changes. Right? And it's like we we don't necessarily have to be the fastest, but we have to be not load slower.

Speaker 3: Yeah, we just need to be close.

Speaker 1: Yeah, and the big problem with using the last generation serializer is that we're always going to come out low slower because every time they create they do the field lookups and it's just not, you know, that's just not how modern approaches work. So uh anyway, I'm really excited to see all these benchmarks. I'm I'm really excited. I was surprised when you jumped in Adam because I think of you as a front-end kind of person and then this is more back end, right?

Speaker 3: Yeah, this is uh I thought that was interesting that that you mentioned that. I don't think of myself as a front-end person at all. I I do think of myself as sort of like a developer experience sort of person. Like I just want like a good developer experience, which I think Django has in some places. And then there are like paper cuts all over uh in other places. So I mostly try to think about like how can we smooth out the first person who is starting Django or the person who like creates a lot of Django apps. Like I make a lot of Django apps and I copy and paste the same thing everywhere. I'm like, this probably there's probably a better way to do this.

Speaker 1: Yeah, yeah, no, fair enough. Why do I say your front end person?

Speaker 2: Angles. Can we talk about angles?

Speaker 1: Well no well yeah we'll get let's get let's drop angles in at the end of the list so Adam can spin off on it. But like you've got your um unsock CSS site, your onsock JS site, you've got Um Jang Django U uh Unicorn, you've got and then Djangles, DJ Jangles. What's tell us about that one, Coman?

Speaker 3: Yeah, so Djangles or jangles, I guess. Uh

Speaker 1: it rhymes with spangles if you say jangles. Yeah, I like that.

Speaker 3: And you can do little sparkle hands uh after it. Um It was I was looking at Django Cotton and uh they have so that's another component uh framework on top of Django uh and They had added uh a nice like HTML, it looks like an HTML element. It's like C dash and then whatever your component name is. And I looked at that and I was like, well, that's interesting. Like I wonder how they they did that. And it's basically um uh a template loader that looks at HTML and then converts that to a a template tag, a regular Django template tag. So you don't have your your curly and then the percent um

Speaker 3: Django, you know, normal Django syntax. And as what happens when I look at things and my brain starts firing, I was like, oh, like I wonder if we could just do that for everything, for every Django template tag. And so that's sort of how it started. I was like, well, it can be, you know, bracket DJ dash and then include and then whatever the name of your include is. And so I started with all the the Django template tags, the built-in ones. And if you look at it, it looks just like HTML syntax. Like you it doesn't look like Django template language at all Um, which I think is kind of nice. It gives you your syntax highlighting and everything. It just everything kind of works.

Speaker 3: You don't have um like indent and um d dent problems like because it you know normally it doesn't know where things are. So I started with that and then I have some integrations uh for most of the component libraries like uh Django Components and um Django Bird and Django template partials and then the new Django template partials for 6. 0. Um so you can use those as you want to. And then there's like a smattering of other things inside that library. Just everything that's basically template. focused um ways to call code without making a uh a temporary

Speaker 3: or like a a smaller template tag And I did something around uh date filters because in the Django template tag for date is uses like a weird syntax, it's not like the Python um syntax and I understand why, but it still is bothersome to me. So like I made something for that, so. Yeah, it's sorta like a it's a grab bag of a bunch of stuff, but it's all all around templates.

Speaker 1: I'm uh with that that uh date filter syntax I'm I don't I never minded because I could never remember either of them so I had to look them up either way. So it's like, well okay, I'll just I'm looking up I'm looking it up, it doesn't matter which of

Speaker 3: I mean saying, but uh I still want it to be the Python one.

Speaker 1: Yeah, fair enough, fair enough. So okay, you give uh you So with the whole that whole Django sting, like what what are your kind of what does Django need in the front the the front end? Because the w another part of that um that keynote that you mentioned from DjangoCon US was that um Django needs a better front end story. you know, do we do we need to, you know, tie ourselves to view or or react?

Speaker 3: I mean, I I would say no. I think this is where community kinda can step in and and help shape those um those questions. I I think I've listened to you long enough or both of you long enough to be like, I don't think we should you know, hire ourselves to React or View or Angular or some other, you know, framework

Speaker 1: that

Speaker 3: that seems like a bad idea. I do think probably we need a way to inside of core call out to other libraries, other the way I was thinking about it the other day was um, you know, there's database backends, right? So core Does it need to support? I mean, I know it has like Postgres and SQLite and things like that, but you can have a database backend that is a third-party library and it calls out to that and that's what it uses. So There's an API inside of Django that says like this is how you deal with front-end um projects or front-end frameworks, and then it calls out to those things.

Speaker 2: That's interesting. Yeah.

Speaker 3: I use Django Compressor a lot. It's kinda like the filters, I think, um, idea, but um I don't know if there's any any appetite for having something like Django Compressor. I know there's Django pipeline. There's a couple of sort of like asset management things. Um so Core functionality seems useful, but like time does something specific doesn't to me.

Speaker 1: So I mean compressor's a good example because I've been using compressor forever, like literally forever. And I've used it with jQuery, I've used it with um uh backbone, I've used it with Ember, I've used it with React, I've used it with sort of Webpack, with Vete, I've used with Elm, I'm I've used run Tailwind through it. The the list goes on. And the the trick the trick is it's got this lovely pre processor setting where you can just add your your your your media type for whatever, X tailwind, and then you can um give it a command that it runs when it finds that to to t to run the the tailwind back end or whatever it is, the webpack constructor you've got um got going on. And that turns out to be really, really, really lightweight and really, really flexible. And it's not that Django Compressor has to

Speaker 1: um have support for React or support for Webpack or support for Elm or support it's just that you share you basically shell out to the tools and that lovely ability to just define how you shell out very very in a very lightweight way has meant that it's been sustainable more for me for a long, long time. Now Dang Dang Compressor needs to handle imports and import maps and all these new new fangled things that we th um and um you know ES modules that you know and uh are now very commonplace that Jan Compressor still doesn't handle. But With given that that need for modernization, it's it's come an awful long way with a very light um API. So surely we can do similar.

Speaker 3: Yeah. Yeah, I think the other thing around this same topic is uh white noise and having something in Django Core, which it doesn't need to solve all the things that white noise solves, but There's probably us there's, you know, uh an eighty percent that Django could probably do. It's cash headers and um you know, it seems like that would be really useful for most deployed Django apps and I think the the frame that I have around some of this stuff is like what are the what are the third-party apps that I always include in every Django application that I that I make? And it is white noise.

Speaker 3: Django compressor and there's probably like three or four other ones. Like how can I make that list smaller? Or I think it would be useful to make that list smaller. Um, I think it gets a little complicated because like that keynote was talking about, Django can be used in lots of different ways. So Uh the way that I'm sort of thinking about it is there are different use cases. You have Django as a web framework for web applications. You have Django for just running tasks, you have Django just for APIs. And like maybe we don't need to solve all of them, but maybe we need a good story for like different use cases that people are trying to use Django for instead of trying to solve like

Speaker 3: boil the ocean.

Speaker 1: Yeah, that did that that's kind of the notion I've used, this term battery packs. for is that y I want the API's battery pack or I want the CMS battery pack or I want the you know whatever. I want the React battery battery pack. I think that there are standard sets of functionality that go together.

Speaker 3: Yeah, the the Django templates um there's Django templates when you do uh start app and start project, which are confusingly named to me because it's It's too many templates. Um but those seem like that would be the solution for those, but it doesn't seem like they have as much um use in the community as I would expect or Maybe they're not as easy to find or something, but um I don't know what have you seen around that.

Speaker 1: Steering council have provisionally approved a depth for implementation about improving the start project. Command, um Tom Carrick put this forward and it's you know the idea is to be is to um improve the story about how you create your own template, the story about how you use templates, have two or three you know, example templates that are more powered up and have a better start project template which is a bit more user-friendly for beginners. Um, you know, the whole start project, start app, adapt to start installed apps, that that bit of getting very first going. W we could rub that away, right? We could make that, you know, one command and there's your project that's ready. So there is a provisionally approved depth for that. It just just needs implementing. But like we're agreed that that is a a go.

Speaker 2: That's good. I mean, this is the whole batteries versus magic thing, right? I mean, I think we're all talking around a newcomer wants magic. They just want something to work. And Django gives you batteries. Which are super powerful, but you have to kind of know how to use them. So I mean there's I've been ideas, I mean Jeff Drip would have mentioned, you know, maybe there's I I kind of like, you know, to go on Adam, what you were saying about how we have back-end support. Maybe there's like some middle ground between a third-party package and official back-end support, right? Where you could add flags, right? So you could do start project dash dash production. Or maybe even start project dash dash production dash atom and it's like how you like to do it or or something, right? Because even as trivial as it seems, a third party is like just enough friction sometimes to get in the way.

Speaker 2: of stuff. But I don't know. It's hard to know. Like I mean st starter projects, I have this thing called lithium now that used to be Django X that I constantly think about where is the line, because I want it to be easy to use. So right now it's basically Django all off. I mean, it's got it's got bootstrapped. It's very basic, but still very helpful. And Then there's like what I would use, which is like way more complex, but there's definitely a at least one grade in the middle, which is, you know, has white noise, has a whole bunch of stuff where I'm like, I think eighty percent of people could use this, right? And yeah, I don't know, I guess it's being comfortable with an 80% case and just putting it out there. But then people have to find it, you know, and then you have to market it and uh I don't know. Then then we then we all lose momentum, right? Because the thrill of making and discovery is just like

Speaker 2: weeded away by like, do I need to market a free thing? Really?

Speaker 3: Yeah, that gets challenging as well. Um so I did I was I saw the depth for the starter projects. And I I made a a library called uh Django New, so Django dash new, because I had seen that there was a project called Fast API New, and I was like, well. We could we could do something like that. Um so that is my sort of opinionated way of starting Django projects, but it is um it's less opinionated than some of the starter starter projects that are out there. Um but it's still got opinions because i it kind of has to. Um but that sort of that takes that idea of different

Speaker 3: um use cases to an extreme, which is just like there are flags for web. For API, for tasks, and for one other one I forget, like data or something.

Speaker 2: Yeah, data worker. Yeah, API data website. Yeah.

Speaker 3: So like based on whatever those things are, it just spits out, you know, a Django, a Django project. Um, the next step to me is being able to install third-party apps really easily. So like when someone needs to add in white noise, you have to go to the white noise uh manual page or you know docs and say okay I have to add it to installed apps and then I need to maybe there's a middleware And then I need to do um, you know, for some apps it's like, oh, I gotta go to Urals. And which Urals do I go to? Because there might be more than one year. Yeah, like it's just I think it gets back to that like uh smoothing out the

Speaker 3: the install process for for new people or smoothing out just the like I'm ramping up a new Django app. I think there's lots of ways that we can make that better. And um it's something that I think about a lot. So a lot of my things kind of

Speaker 2: right?

Speaker 3: Yeah, yeah.

Speaker 2: I mean l like you know, pilots have this. I mean the talk idea I've proposed, so we'll see if I get to give it a uh Django and Python conferences this year is around deployment. And I think it's it's exactly this idea of like, okay, like I have a sense of like 80%, boom, boom, boom, boom, here they all are and let me talk through them so you have a idea for them, but then you need the checklist. And you know, cause and there are checks in Django. Um, I'd say most people have no idea that that check exists, but you know, I want to finally put some effort to being like There's not a lot of argument around like you gotta handle your static assets. Like a lot of people use white noise. If you don't want to use white noise, you can do something more custom, but you know, just go down the list of I don't know, it's ten, twelve things. Um at least so people can look at it and see

Speaker 2: what are these ones. Because I think the other issue is a lot of people all three of us create a lot of new projects. I'd say most Django developers don't. You know, they work on the same one for years and so they don't Feel this pain in the same way as, you know, someone who spins things up for fun or as a consultancy does. That's that's something else I'm very aware of. There'll be Yeah. P steering council members sometimes who haven't started a new Django project in years, right? I mean they're still working on Django, but They're feeling different pain points. And they're also not dealing with deployment, right? I think that's like the quick take on my talk, besides here's the checklist of deployment, is also Why isn't this more of an issue? It's because in a production setting, someone's done it and you're just using it. Or even you did it a couple years ago and you've forgotten about it. It's not something every time you load up

Speaker 2: your project you have to deal with. And so it's easily forgotten or not thought of, which means that when you're a newcomer, you're doubly frustrated by why isn't it documented? Why isn't it easier? And it's because it's not, you know, it's not like fiddling around with your views, which I do every day.

Speaker 1: Yeah. I mean I I burned into my soul is that thing where I've got my first Django project working locally and then was like, right, how do I get this online? And I was like, oh no, there's the same time again in learning how to put a Django project.

Speaker 2: Even something is I still make this mistake of, you know, I have it working locally, I deploy it, and then I go in and like, you know, the d I didn't do the command to migrate the database on production. Cause I'm like, wait, why doesn't it work? You know, it's like, oh God, now I have to like Migrate the Yeah. Do all this stuff. Yeah, if you're not doing it all the time, you lose that uh that sense.

Speaker 1: No? Okay. Adam, you've got several more projects. I want to talk to you particularly about Coltrane, because I think Coltrane is quite a cool little little beast. So tell us tell us a little bit about that and how's that going?

Speaker 3: Yeah, so that was born from I needed to or I wanted to Basically have markdown files inside of a Django app and have them render as HTML. So that's how it started I had a lot of side projects and I would write documentation and it didn't really need to be formatted like super well and I wanted to just write it in in Markdown and then show up on the site easily. So uh there is a markdown renderer inside of there. I've switched between a couple, but um that's how it started And then at some point I sort of started thinking, oh, I could take all this markdown and I can make a static site out of this.

Speaker 3: Instead of being inside of a regular Django app, it would just render out as static HTML. And so there's also a static site builder in there. I know there's a couple of different solutions in Django. Um that people have built for for static sites, but this is my take on it. Um and so it kinda it it kind of solves both of those those purposes. I don't use the static site generator as much from my own personal stuff because I almost always am deploying a Django app, so I just want to render out that that markdown. And then after that, I started playing with different ways to have different template tags and different ways to like structure

Speaker 3: the the markdown so basically in one repo I can deploy it to two different sites and then have them rendered differently. because I needed I needed like one deployable but like rendering in different ways so I I kinda like built out this little site framework. Um but yeah, that's that's that's the gist of it.

Speaker 1: So it's like a full multi-platform content management system, basically.

Speaker 3: I mean I w I don't know if I'd call it a CMS, but um you know it's it's pretty close. Uh you can have um you use like Template hierarchies and stuff like that, and you can you can build it out.

Speaker 2: I'm gonna have to try this again because I'm still stuck on Jekyll for my personal site because I just can't be bothered and for some freason Pelican just feels like too much of a lift.

Speaker 3: Well, so yeah, so the initial initial thought was from um who is the guy who does The CLI, the rich and is it Will

Speaker 1: Will, yeah.

Speaker 2: Um

Speaker 3: Twitter at some point Will was like uh you know, I want to use Python for my for my static site, but you know, I don't I don't want to use Hugo or Jekyll anymore. And so I was like, well, I mean Django Django can do all this. We don't need to like rebuild the wheel. And um and so that's that's where it started.

Speaker 2: I think the cost thing is really important with uh sorry Carlton, the c just quickly say like I want people to use Python and Django, but not everyone wants to Host a database for a blog, you know, and you don't have to, right? Because you can put it on GitHub pages, you can put it on Netlify, and so I s yeah, INF give this another try because I still think there's that space. Like when I I can see when I tell when people are like, oh I want to have my own site. I'm like, oh it's easy. You can do it in Django. But I'm like, but then you gotta host it. And I just see the like enthusiasm. fade away, even if it's like, oh, it's just hero you know, some hosted thing, lose them. But if it's just drag and drop or GitHub hosting. Yeah, that's a big barrier. So yeah, Carlton.

Speaker 1: I know um Emma Delascole is keen on um having a static site generator. Some i it cl i either in Django or close to Django button there there's a uh Django distill package which is very mature and I think the the author there is keen to, you know, modernize it and make and and get it in. I mean I'd I'll just throw you a softball at him. You think there's that, you know, having Django better static site story is something we could do f for our users?

Speaker 3: Yeah, I mean I I think that that is a use case that a lot of people will need is um generating a bunch of static pages. It is a little bit different than how I normally think about Django, which is like dynamic, um, database oriented, you know. web applications, but there is probably a a set of people that that would really benefit from just generating HTML and Throwing it out there somewhere.

Speaker 2: I mean I was posting something on the socials yesterday about how I'm, you know, are reinvigorated by RSS. Carlton gave me a nice reader and you know it's like increasingly disgusted by uh mainstream everything and then wanting to focus. So yeah, it's right because Django obvious j I think again, ma most people don't know. Django has its own built-in way to generate feeds, and I'm sure there's a way Do to do that nostatic site thing as well. And then and then you're there, right? That's all you need. So you got your feed, you got your pages hosted on something simply and good to go.

Speaker 3: Yeah, I don't know how if distill does that. I assume it does. Um I know in Coltrain I I automatically generate um RSS feeds because it is so easy to do in Django, you basically It's all built in. So um yeah, that worked out really well.

Speaker 1: Having flashbacks too, because when I started, I started with a a web server and a folder and you put you uploaded HTML and you didn't get a backend thing until you wanted to use a form. And it was only when you used a form that you need some way to handle the form input, so you had a CGI script for that. But This is why I don't use white noise, because why on earth would I have my Python process serve my static files? Because that's what the web server's job is. But Anyway, that's a that's a side, but like we've come so far, it seems, that like now we start with the dynamic process to do the easy thing of serving template views which never change. And you don't want to run a whole process to keep serving the same thing time and time again. And Infinite. Anyway.

Speaker 2: I wanted to quickly ask you, Adam, so current hotness is out there, so UV, rough, types, do you have any hot takes you want to share on either of those areas? Fine if you don't, but

Speaker 3: I mean I don't think it's a hot take at this point, although Carlton might disagree with me, but I think um UV has sort of won the the Python packaging. war? I don't know. I wouldn't call it a war. Um it seems to have taken a lot of the the mind share and um You know, I I've moved basically I was a I was a big fan of poetry uh for a long time and I've moved everything from poetry to UV. Um I've you I've moved everything from black to rough, and I'm in the process of moving everything from my pie to Ty T Y, which is the Astro

Speaker 2: Nastral one. Yeah.

Speaker 3: And um I'm not saying that they're perfect or that there aren't like I have my own concerns about the longevity of those tools and how they're gonna play out long term. But for right now it seems to be fine. They're open source. It seems like uh they're being good stewards of those open source tooling and so If I need to move back to pip at some point, like that's fine. It's all code. I can I can change in the future if I need to, but for right now, I I got some benefits from moving to those tools. And Um, I think that uh has been great.

Speaker 2: The lock-in is low, which I think is important to remember because I think we all have various concerns, but You can just switch back.

Speaker 3: Yeah, I wrote an article at some point before UV was uh was released and it looked at um pip ev hatch PDM poetry, I think. Um so I did a oh and Rye. Rye was like a package manager that was floating around for like six months. Um actually they they moved a lot of that into UV, but Um basically I was just trying to figure out like, you know, what where is the future of Python packaging going? And I wanted to try all these things out. And uh after UV came out and I tried that one, I basically dropped everything else and I moved to that. And um, you know, I I do want to say that like

Speaker 3: I really appreciate there was a article that came out somewhat recently about making pip faster. And I know that there's a lot of people who are doing a lot of great work improving pip and you know all the underlying uh technologies there. And so this isn't to say like those that those tools are bad or they're not good or that no one's working on them. It's just that um You know, I I just got some benefits and so I moved over.

Speaker 1: Fair enough.

Speaker 2: Can we come to the projects and books phase of the show? Or is is that okay?

Speaker 3: Yeah, sure.

Speaker 2: Well, Adam, as our guest, is there uh All we've done is talk about your projects. Are there is there another project out there you want to draw attention to or that you're you've been looking at recently?

Speaker 3: I brought this up earlier, but I was really impressed with the the Django TAS project and how much effort there was put into that to make it ready to get moved into Django Core. And I think it's really solving a problem that a lot of people have. So I'm really Really happy that that that got pulled in and I just wanted to shout out that project and um all the work there. I think the other one uh that I wanted to mention was But Farhound was on on the podcast, so maybe he doesn't need the shout-out, but basically all of his GitHub projects, I just follow him and I'm like, oh That's really cool. I'm glad someone is doing this. And and I really um am looking forward to seeing what happens next and just following along

Speaker 3: and to see, you know. What what happens?

Speaker 1: There's a d just a good one from that I don't think we talked about when he was on, but um he's been doing all this work on Django Bolt, which is this Rust-based super fast Django wrapper type thing. But out of that came um some work on uh the multi-part parser and using different Python packages for parsing multi-parthers. So there's now a PR to try and make that pluggable on the request object so that if you want to, and if you don't need strict backwards compatibility with Django's multi-podpaster, you can swap in one of the um, you know packages from the Django ecosystem or from the Python ecosystem, so you can just pip install, you know, whatever the the alternative is. And Give it a little wrapper, p use it in your Django requests, and you can get like, you know, I can't remember the figures, but it was something like thirty percent higher throughput on passing large

Speaker 1: you know, um multi-part requests. So, you know, go far hand. He's really out.

Speaker 3: Yeah, the the cool thing is like he's working on these things that are sort of ancillary to core, but I think he's gonna come across all these problems which you can solve in core. So and like it'll be fun to see if you know if we can move some of those things into core.

Speaker 1: Yeah yeah yeah that would be super good that's a good good good shout out will

Speaker 2: Okay. I'm gonna shout out uh La Suite numérique, which is this French existing project of trying to open source and have uh non corporate versions of all the infrastructure your government runs on. They have the users of Django. They contribute to Django. Um I think Lots of countries and places should consider having their own versions of things, and it's not the hardest thing in the world to do. So uh pleased to see that they announce I think publicly they're gonna try to switch over, I think all of it or most of it in the next year or two. Um and I would be very surprised if other countries do not do the same. uh for all the reasons everyone can imagine. So cool to see that and cool to see it's Django and it's using all the modern stuff

Speaker 2: um out there. Carlton, what's yours?

Speaker 1: Very good. Okay, so I'm gonna call out a project from Jamie Matthews who was on the co-founder at Dab Apps. Influential in the early days of Rest Framework. Um but he's published an online guide. It would be a book, but it's it's online, it's free to read, called Django Rapid Architecture. So it's at DjangorapidArchitecture. org. And it's basically how Jamie does web apps. And it's um you know he's very um function function based, about compositionality, keeping things clean. He he's he's anti-type hints. He's like, come on, every Django developer knows that a request takes a response and it gives back a um a a r oh sorry, takes a request and gives back a response. You don't need to type in that. He's, you know, he's got his views. It features the absolutely amazing Django Readers package, which enables you to um sort of compose the exact queries that you that you want um to make from the from the ORM and it it handles the selecting just the fields you want and it handles your prefecture related for nested queries.

Speaker 1: It's Which is beautiful. Um, I use that a lot. It's so go check it out. It's it's a very experienced Django developer. 20 years of out of of experience using Django telling you how they do Django. So, you know, it's worth a read. Django Rapid Architecture.

Speaker 2: Yeah, I should read that again. It came out a little while ago and I remember

Speaker 1: or so ago, maybe he really made it.

Speaker 2: Okay, not that long.

Speaker 1: Django Readers has been out for a couple of years, um two, three years now. Uh it's It's just gold dust, it really is.

Speaker 2: Yeah. I was saying I think it came out like over Christmas or something 'cause I remember seeing it and uh looking at it and be like, oh this is gonna be great. I need to really uh focus and look at this.

Speaker 1: It is it is good. It is good. Um I don't you know there's obviously bits that where it's Jamie's opinion, I don't agree entirely with him. So when we get him on the show we can argue about those little bits again Um, but yeah, w when's when somebody of their experience gives you, you know, this kind of breakdown of how they see it, that's always worth a read, whether you agree with individual points or not.

Speaker 2: And that's a chance to shout out another package you have, Adam, Django-F uh FBV, which is things around function-based views and trying to make them not class-like, but less annoying to use.

Speaker 3: Yeah, that's one of one of the packages I install for every Django app that I use. So I use it.

Speaker 2: Books. I'm gonna I'll go first. Um A River Runs Through It by Norman McLean. This is again my trend of trying to read fiction. Uh if people haven't read it, I think it's one of the great American novels. It's really more of a novella. They made a movie about it. Um, but fathers, sons, kind of Hemingway-esque, just uh if you're in the right mood, amazing. And I think underappreciated for how good it is.

Speaker 1: Add a bug.

Speaker 3: Uh so I watch a lot of movies. Uh that's sort of one of the the things that I that I tend to do as a hobby. Uh and I watched A movie called Nightmare Alley, and it was by Guillermo del Toro. Um it was released in 2021, but it was based on a book written from 1946. or forty yeah, forty-six. And so I recently read the book. Uh it's about um sort of a a scam artist, I guess I would call him, uh, who joins uh a circus and then um kind of his his progression and then he continues to be a scam artist and then sort of gets his comeuppance at the end. But um I don't know. I really I really enjoyed the book.

Speaker 3: Uh it sort of has um what is it? Is like Clockwork Orange where they like make up words, but they don't tell you what the words are. It kinda does that a couple of times where you kinda just have to piece things together based on context of what they're talking about. Um but yeah I I really enjoyed it so It's getting very good.

Speaker 1: And well I've been I haven't been reading a book this week. I've been um mostly just reading the newspaper. Um but uh Is the it's not the particular newspaper. I get a couple of newspapers, I get the London Review of Books, which comes out uh twice a month, and I get the Le Monde Diplomatique, which is once a month. And the key there is that they're slow. But The the articles are in depth, they keep you they keep you up to date, but you're not on the hook for the dopamine hits and the whatnot. And we were talking at the beginning of the episode about being sustainable in, you know, your projects, whether it be running a podcast or an open source project or whatever it is you do.

Speaker 1: Well be sustainable in your news consumption too, because it it ex it extracts a cost upon you. And if you are hooked onto the machine constantly, not only are they driving the narrative, you know, with d what they choose to highlight and what they don't, but You're paying that with your energy and your life force. So the end it's not necessarily, you know, get Le Monde Diplomatique or the London Review of Books, don't do. It's Get something that's more considered and step back and you know, t give you give you take the time to read it, but in a more controlled and sustainable way. That's all

Speaker 2: Yeah. I would say that's that's one of the benefits in my life, Carlton. When you came to visit uh me in the US a number of years ago, you were reading the London Review books on the plane and And chortling away about stuff, which I won't repeat why. And I was like, what what what is this paper? I'd never heard of it. And now I've been reading it for three, four years as well. And I can strongly recommend it.

Speaker 1: I uh my it's my slow quest to convert people to London Review books one reader at a time.

Speaker 2: Yeah, we we got a couple of people, um George Gurton who's old family friend online and yeah, it's a couple people. So

Speaker 1: Get them slowly. Anyway, that was my recommendation is read the newspaper, but not the dailies.

Speaker 2: Um, as we go out, anything, Adam, you wanted to mention or that we failed to ask you about?

Speaker 3: No, I I think we covered a lot of stuff. Uh hopefully hopefully it was interesting.

Speaker 1: Was there was there one Was there one more magic wand thing that you might have had? 'Cause we I know we talked about no but i you know Adam you might have a magic wand then if you could fix one thing in Jack.

Speaker 3: Uh I mean we've talked about so many things that I want to I would like to fix. Um

Speaker 1: there's nothing left then that's fine. But if you if there's one where you think, oh yeah, start.

Speaker 3: I mean, I would I would probably just you know the the one thing that I would say, which is not it's not really code related. It's And it's more meta, maybe, is to make Django sustainable and to figure out how to Um not have a business model, because that makes it sound more like capitalistic, but more like How do we make sure we have sponsors for Django that we're getting as many of those as possible and making uh the Django fellows uh a long term solution because I think a lot of the benefits that I've seen in the past couple of years are because we

Speaker 3: pay the Django fellows and they are dedicated to Django and pushing it forward. And I don't know if we would have had the all the improvements over um the all the improv the recent improvements without dedicated people to the project.

Speaker 1: I mean it's now ten years old, right? The fellowship program, so

Speaker 3: but it's longer than I than I thought it was. But

Speaker 2: Yeah. Agree. Oh uh last thing I'll call out. Um in the Django News newsletter, I've been mostly trying to link to the Django's fellows give a weekly report of what they've been up to. You can find it in the forum, but I've been trying to add a add that as a section so you can see and there they add a little brief paragraph and you can see all the tickets and things that they worked on and and they do a lot.

Speaker 3: Yeah, that's awesome.

Speaker 2: Adam, thank you for taking the time to come on, share all your work. We'll link to everything. People could also just go to your GitHub repo uh page and see it, but we'll link to all the things we mentioned. And DjangoChat. com, I will see everyone next time. Bye-bye.

Speaker 1: You next time