Transcript: Django Unicorn - Adam Hill

I'm Carlton Gibson, joined us over by Will Vincent.

Hello, Will.

Hello, Will.

Hello, Adam.

Thank you for coming on the show.

I've been listening for a long time.

So uh normally it's at like two times the speed, so this is a little bit different, but um I'm excited to talk to you guys.

I really appreciate you uh

That's good.

We always ask about the backstory, and you've been around for a long, long time.

So perhaps you could tell us how you got into programming, how you found Django, you know, what's your origin story?

Um and in my day job at the Molly Fool, um we use C sharp and a lot of the Microsoft stack.

Um and so Can

I want to ask you.

So the s the I'm always fascinated by the Microsoft stack and the C sharp stack.

When you're working when you're working on Django, what are the sort of bits that you miss?

What's what's the what are the really nice bits of working in that in that um ecosystem?

So um I mean, I started working in Django because I wanted to get away from the Microsoft stack.

Uh but the nice thing about it, I guess, is that it's sort of all integrated uh with each other.

If you're on Windows, you use SQL Server, use um, you know, um just the whole the whole stack together, whereas Django, you kind of have a little more flexibility, and with that comes a little more choice.

So you have to choose Postgres or MySQL, and you have to choose Gunicorn or you know what what your serving uh platform is.

So it it it becomes uh, you know, there's there's just more choices there.

Okay.

I wish I had

I'm sure some of you

don't do.

Okay, so anyway, you're at Monty Fool, programming C sharp, you think?

Um But my friend uh introduces me to someone who wants to start a startup which uh is for house auctions.

So it's the idea is about as dumb as it sounds.

Um it's like we're gonna start uh you know a house auction at a dollar and let people bid and then they get a house at the end.

Um so I was like

Ahead of your time, I think, right?

That's like open door and stuff too, sorta.

And so I was reading about Rails and I was reading about other frameworks, um, and I came across this Django thing.

And uh it was mostly, I think, the ORM, and at the time it was South, uh, which you could do migrations, and I was like mind-blown.

Like I don't have to manually write uh stored procedures, uh, like sign me up.

So uh I tried uh working with this startup uh for a while, and I used Django at the time, I think it was one 1.2.

Um, and I really loved Django and I found all these things that I really loved about it, and I found out that this startup was um was not gonna work out for all sorts of reasons.

Um but that was fine.

And so uh that was my that was my first introduction uh to Django.

Uh and then around 20 uh 2011, our CTO at the time kind of looked at a couple of us techies and said, if there was any tech stack um that you would use, what what would we use?

If we were starting from from scratch.

Um and so I advocated for Django at the time, some other people advocated for Rails and some other things.

So it was uh um I don't remember.

It was so long ago.

Um it was mostly a conversation.

It was like uh, let's try this and let's try that.

Uh and I maybe I just convinced a lot of people um that we should we should try it out.

But um so

Uh we have some back end services that are still in C sharp because um you don't want to have to rewrite everything and they still work and it's perfect.

Um and we have some WordPress sites as well.

Uh so it's a couple of different technologies, but most of what you see when you hit the site is all served from Django.

Okay, super.

Had you used Python before Django or because that's also uh you know a big part of the Django experience as opposed to the Microsoft stack.

Uh I think when I looked at uh when I was evaluating other frameworks, Python was a big uh point in there.

It was like, oh, I really like the way that this looks.

It was aesthetic, um, and and sort of the ecosystem around Django and Python.

Even at that time, it was still like, oh, there's all these packages that I can use and pull in, and um I don't have to rewrite all this stuff.

That was really appealing to me.

Rails was way more popular, but I thought Python looked better to me than Ruby, and also even then had more applications.

Um and so I'm always interested to hear what you know.

But you know, because a lot of people they come into their first framework with no knowledge of web frameworks, and so they kinda blame the framework for the learning curve of that.

But if you already kind of know how websites work, you you skip that blame, right?

It's only kind of like your second or third.

You're like, oh, maybe it wasn't Rails or Django that was so hard, it's just the web is a little bit trickier than I gave it credit for.

I'm like, Yeah, what do you well?

If it was easy, you know, because they're like, Will you can build Instagram in a weekend?

I'm like, yeah, for like ten people.

But like you know, a billion, there's a reason.

It gets a lot harder.

Yeah, yeah, for sure.

Uh sort of the name one.

Now, um, which way around do you want to take it?

Do you want to do unicorn first or last?

Sure.

Yeah, that sounds good.

Uh first.

First is fine.

For people who don't know it, can you tell us what it is and then we can discuss you know various aspects around it?

So uh this short pitch is basically it's a reactive component framework on top of Django.

So uh it basically lets you have a Python class and a template, um, and they kind of are tied together, they're bound, and you can render that uh Python template inside of a regular you know Django template, and then you can have attributes on the HTML.

So you could like click a button and it will call something in the Python class and then re-render on the front end, and things have changed.

So it's um that's the easiest way to explain it.

And you can actually target even if you wanted smaller uh pieces to like reduce the payload.

Um but basically, you know, when I was looking around at things, um, I don't know if you've seen like uh Elixir's uh uh live view.

Yes.

Uh so basically they use WebSockets in the back end and they do this sort of reactive uh functionality.

And I looked at it and I was like, you don't have to write any JavaScript to have interactivity on your website?

That's like crazy, right?

Um and I kind of wanted that for Django.

So I actually built a prototype using Django channels, which Carlton I know you you work on.

Um and I found it more cumbersome than I wanted it to be.

So I didn't want to run Redis, I didn't want to run a separate process.

Um, and so uh I was looking around a little bit more, and in uh PHPs, Laravel, they have live wire, and instead of WebSockets to uh you know make that interactivity, they use regular old Ajax requests.

Um so it sounds a little when you first think about it, you're like, I mean, you're gonna make an Ajax request for every update, and then you're gonna pass back HTML from the server side.

Some people are like, that doesn't make a lot of sense.

Like it's uh not gonna be performance, and you know, why would you do it when you can just use these WebSockets?

Um but the the upside is that it makes deployment really simple because you're just it's just Ajax.

It's um it's already what the server is dealing with.

And if you look at sort of GitHub or um there's other examples, but GitHub is the canonical one.

If you watch the network inspector, uh they're passing back snippets of HTML.

It's not JSON with some SPA on top that's re-rendering it.

Uh so it's a it's a pattern that that lots of big sites use.

Um and Unicorn basically uh it gives you an easy way to do that without wiring up all the bits uh by yourself.

Um because I know in Django right now uh HTMX is really hot and people love it, and I love it too.

I've used it on some of my side projects.

Um it's really great, and Carson is uh you know an awesome developer and a great advocate for this style of uh web programming, I guess.

Um but you still have to create your URLs, uh create new routes, you have to make sure your templates are set up in a certain way, and so uh the one thing that Unicorn does is it kind of handles it all.

I call it its magic, um, but you know, um it basically it gives you a pattern for doing that sort of thing.

So that was the question I was gonna ask.

So this this this this HTML over the wire thing.

So the the the Rails they use the the hot wire, right?

Which is their version, and then um HDMX has been is blown up, it's very big.

And I was gonna ask you, so you're in exactly the same sort of um place, the same uh strategy.

What you know can you just go over again what uh what is the selling point of Django Unicorn versus HDMX for all the folks that have seen HDMX explode and big on that?

What do I get extra when I come and check out um Django Unicorn?

What would be the selling there?

It also integrates, it's it's basically Django aware, right?

It tries to play nicely in the ecosystem.

Um you can use Django messages inside of your Python class, and things just work sort of as you expect.

Um validation works the same way.

You can use forms.

Um, it basically knows about Django, and so it can be a little bit smarter about what it's doing.

Um, there's support for Django models and query sets.

Uh you know, I try to just sort of integrate it into the whole, you know, ecosystem.

So it feels like it's part of a Django project, as opposed to um something that you kind of add on and then have to fiddle with.

Like, because it's exactly that question, right?

I'm sure I saw like I've researching this episode on Reddit and other places, everyone asks you, well, why not HTMX?

And you know, I feel like those the two you have certainly show it, and then the plans for more, um kind of eager.

I hope you get a chance to do those as well.

They're so bad.

So yeah, I mean it's it's just like a conference talk, honestly.

It's but it's three minutes as opposed to, you know, uh 45 or whatever.

Uh but uh between trying to write out a script and make code that makes sense that I can show and then finding a quiet space in my house that I can record it, it's like uh I'd rather write some code and just like put some new features out there as opposed to making a screencast.

So uh, you know, that's my own fault.

It's like you you build this thing and then the demands are like nine out of ten, the selling of it rather than the doing of it.

You're you're at like step zero basically at that point, and then um a lot of the you know the um where unicorn sort of like caught on a little bit was more on the marketing side.

So like I built a whole site that has little you know small demos that people can play with and see.

And um, you know, I went on Reddit and I tried to advertise it a little bit.

And so, you know, there's uh there's that whole other part of writing code when you're in the open source ecosystem that like people don't really think about or or maybe don't want to to work on because it's it's the less fun part.

Is that built with Unicorn?

Um basically I have side projects so that I can dog food my own side projects.

Um so it's sort of like turtles all the way down.

Um the hairy the hairiest yak in the world, one way or the other.

Um and basically I just wanted to make something uh to store all my GitHub stars.

I mean, that's basically what the the genesis of that project was.

Um because you know I wanted to have a better interface that I could see all those stars and I could sort of attach notes to them.

Um now they have lists in GitHub, which is kind of nice, you can organize.

Um but yeah, I wanted someplace where I could you grab all that stuff, and I was like, well, if I'm getting GitHub stars, there's probably other things that I could also pull in and uh bookmark uh for later.

Um so there's like hacker news favorites, and um there's all sorts of other sites that I sort of integrate with, but that that was the plan.

And that's free to s sign up for.

Do you have plans to go on, Gary?

Go ahead, go.

Yeah, it's free.

Um you can sign in with uh GitHub.

Uh and yeah, there's there's plans to monetize it.

If you want to pay me five dollars a month, uh feel free.

You can.

It's most of my things are to scratch my own itch.

Um, so I don't I don't think I'm ever gonna make a whole lot of money off of these things.

I have a day job, and that's fine.

That's how I that's how I survive.

So it's all good.

I've got a key key command.

I see that, see that, but it's kind of like an append-only list in that they go onto the list and it might be like five, ten links a day.

And it saves me having to read them there and then, but the reality is I very rarely go back and sort of process like this.

So is that I mean, I think that's normal.

I've spoken to a lot of people that have the same phenomenon.

Is it have you got any thoughts in how we we might use something to you know surface this?

And I think a bunch of people are like, yeah, I'd like that.

Yeah.

But if you figure out something, I would love to hear about it.

I'm hoping somebody's gonna come up with something that will just say, oh, you you know, you've bookmarked a site on this of three years ago.

Like I don't show you.

Like I start today and it's just empty because I don't even pretend, I don't want that burden of like I should do this.

So I used to have this problem where I'd have like 4,000 tabs open and I could never find any any, and I just keep them open at all.

And so what I decided was that if I just bookmark every single site that I see, um the idea that strikes me interesting.

I thought every site that I would leave open in a tab, I bookmark it and close the tab.

And it's amazing because now I have like one, two tabs, and you know, if it's really hectic end of the day, there might be ten tabs say, but I never have fifty.

And it's like a closed loop.

Because if you've got an open tab, you it's constantly sort of in your decision cycle, going, Do I need to read this now?

Do I need to read this now?

Yeah, it's an endless loop.

You need you I do I use a search history.

So, like, yeah, very often I'm like, oh yeah, what was that thing?

I wish I hadn't closed it.

And then I just go into my search history and and there it is.

It's a tension between be you know endlessly curious, which I think many good developers are, and then you know, not getting bogged down with trying to learn everything.

Right.

I think especially for people I I get this email pretty often from readers who like, I just don't even know where to go.

Like there's so many things to read.

And you know, I think with time you're kinda like, well, if I needed to turn over that stone, I could, but there's sort of a context, you don't need to like master everything and you know, like react stuff.

It's like, yeah, it's gonna change every couple of months.

Like but you can kind of let go of that anxiety around not knowing anything, I think.

But the first couple years, you you feel like you have to keep up with that.

Whereas I mean, there's you know, so many things I don't know.

I don't know, go around telling everyone it, but like I don't pretend otherwise.

It's just like, well if I needed to, like for me that's a coping mechanism.

I think after the first couple

Um but that that first couple years that's the tricky part is like where do I even start here?

Like there's there's so much.

Well uh did this come out?

Yeah, this will come out.

So not so DjangoCon US is coming up.

Carlton just got back from DjangoCon Europe, and my talk is a 45-minute talk on uh aligning the Django puzzle pieces, where I'm gonna try to present the tapestry of Django as a whole as a roadmap for people, because I f I feel like many people learn it, you know, it's like puzzle pieces, but they're all flipped upside down.

You have no idea where you're going and somehow they fit together.

So to at least say, here's the map of Django, and it will take a long time to cover it, but here's kind of the context I wish I had those first couple years.

So, you know, modes, you models, URLs, templates, views, admin, but also like what are signals, middleware, like ORM, query sets, you know.

So dig deep dig deeper into things, the the geo stuff.

Just give a sense of here's like the entirety of Django.

Um, and you know, so here's the fundamentals, and then here's all this cool goodies, deployment.

Like there's a huge I mean deployment is such a big topic.

Um, but in Carlton, actually, I was thinking of you because uh you still like multiple settings files, right, for your deployments as opposed to one setting file and environment variable.

Um I see people jumping through a lot of hoops trying to fit everything into the um environment variables only um pattern.

And I think it's time for the pendulum to start swinging back another way where it's like, do you know what?

If you're fighting with your environment settings or environment variables, trying to put everything into an environment variable so that you can just you know change your M file or change your folder in order to change your deployment settings.

Maybe you want to just you know stick that in a separate settings file where it's easy to read and you don't have this massive amount of machinery generate um enabled that's needed to be put in place in the switch environment.

Maybe it's time for the dependent to switch back another way.

And then of course we'll end up with multiple settings files and everybody hard coding secrets in the wrong places and everything that and we'll swing back to environment variables or you know something because apparently we're not allowed to use environment variables anymore because they can be I don't know what

one, a little bit of the other.

Um so that might be even more m you know, messier than than both those approaches, but

But you know, sometimes there's various bits and bobs that you need to customize per environment.

It's much more suited to have a separate settings file for than trying to push all of that into environment variables.

Yeah, you don't want to hard code secrets in the in the file itself.

Yes, that's when we when the community decided to emphasize not doing that, that was a good step forward that everyone should follow.

But you know, like all these things, we end up sort of gravy changing, gravy changing.

And and now I'm sure GitLab and is the same, you know, they they don't let you just uh search for that stuff, but you could just you know get anything.

So I think there's a little more guardrails, but um

Plus, all the platforms as a service require environment variables anyways.

So if you're using well, what used to be Heroku, um then uh but yeah, I agree.

It's not it's not a canonical thing.

My pitch for Django is that um you know we that there is a canonical way to solve for this.

I think that would be nice and it would um kind of get around some of this conundrum of what you're supposed to do.

And so people just know that like this is the way to do this thing.

Uh because it is a thing that that pops up all the time.

It's the same with um, you know, should I deploy my React app with my um DRF app?

You know, the I see the same sort of questions on Reddit over and over and over again of like, how do I do this thing?

And um I think the more that Django can provide, it doesn't have to be super opinionated, but if it can provide some guidance and like, and this is how you want to do this thing that 80% of the people want to do, I think that would be beneficial.

It's but um this summer I was take very much focusing on async tickets.

I've got one more pair of um things to try and get into 4.2 for on the async front, and then we want to swing around to a proposal to modernize the request object um and maybe add JSON parsing to the request object.

So you just go request.data, and if it's a JSON request, you'll get JSON data, whereas if it was a like a form encoded request, you'd get um like the equivalent of post data now, like the dot post.

Um you get form encoded data, but either way, you're gonna get that back as a nice dictionary.

Um after that, there is a there is a proposal to actually get around to okay, what you know, what can we look at in terms of making a better story here for people?

Um it's difficult because every time it comes up, there's massive differences in opinions, including to the extent that no, actually, environment variables aren't the way to go because you know what you want is a is a file that you put in place that's read at process launch and then deleted, and then it's sold in a single thing, so it's not when the process gets dumped, it's not all leaked in the environment.

You know, this ah it's the trouble is you know, there's so many opinions in so many different ways, but we're gonna sit down, okay.

Can we make this can we make the template that start project template one step up?

Um, and it's not an instant process, and it you know, it takes a while to go through, but there are proposals in in place, and it's it's coming to the point where that's bubbling to the top of the backlog to process.

So we'll see.

We'll see.

I should go uh research a little bit the past efforts more, but I think that's that's a big thing.

I have

I need I need numbers and bar shafts.

Uh just a histogram will do, make it up.

So, Adam, Django Unicorn, very good.

I know Andy Ide, who builds horse reddit.

He I can't stop him talking about.

We're hoping to get him on the show soon.

He can't he just absolutely raves about it.

So um, you know, I think you know people should go and check that out.

I want to talk about some of your other products.

So I can I talk about the one I'm really excited about, which is um Minestroni, which is a um which is a way of selecting DOM elements from um elements from the DOM, right?

It's a HTML sort of search library.

Tell us about that, because that.

I'll tell you why I want to use it, it.

It's for simplifying HTML test cases where you're testing against rendered HTML.

But go on.

It's very lenient and lets you sort of find things in there.

Um there are a couple other libraries that are floating around, but it seems like everyone sort of uses BeautifulSoup.

Uh and I use it in all my projects or a lot of my projects.

Um and I love it.

So there's that.

Um I find personally the document documentation is a little hard to read.

Uh just one big long uh you know list of methods.

Uh and so every time I'm like, well, how do I find just this element?

And so I have to kind of read through stuff.

Um and the API is sort of it's there's a lot, there's a lot if you look at all the um you know attributes and all the classes that are available.

Uh so my basic idea was well, I'm just gonna make a little wrapper library.

It's gonna it uses beautiful soup underneath the hood because there's nothing better.

Uh but maybe I can provide just a nicer API for people to do sort of, I'm always looking for solve the 80% because like the last 20%, that that's the hard stuff, and I'm maybe not smart enough to figure that stuff out, but like the 80% I can definitely get.

Uh so I have uh nice methods to basically um get elements, loop over all of them, uh look at your attributes, get the classes.

Um and I tried to do, you know, I tried to make the API as nice as I possibly could.

Uh that was another thing that I was really trying to sort of get out of this exercise.

And this is this is just like Unicorn, where it's like, you know, I'm I'm just looking around and I'm like, uh I feel like this could be better.

Like it doesn't have to be this hard.

Like maybe I can make something and provide it and um you know make things a little bit easier for people to use the documentation and use the API.

So that was that was the basic thought about it.

And um and you like you said, the basic API is just

Um so it's you can search uh using it's basically looks like um like CSS selectors.

Yeah, so

Yeah, yeah, yeah.

That's that's the point I wanted to get is that you just use a CSS selector, which you're totally happy with, rather than X what's the X path expressions or whatever which is just all that stuff at all with that so like in my entire career I've never had success with X path sub expressions.

I just couldn't they just wouldn't go into my brain in the right way.

So every time I needed to construct one, I had to go and look up the syn or look up the query query path syntax.

Whereas CSS selectors, because you're using them all day every day, you know them and you can, you know.

Yeah, just fine.

But what I want is um when you've got HTML, um HTML and you would you want to uh a cert equal on the contents, right?

You so you you render the template, you want to make sure that the the template, you know, you're writing your template tag, did is it functioning how you want it to?

So you want to get the the HTML and you normally you want to pull it out of a hot uh out of a bigger a bigger page, you know.

What did did the page render with the HTML I expected?

So if you can query that down to a small HTML element and just match against that rather than is this string appearing anywhere in this in this HTML?

And no, well it didn't appear, and then it prints the entire page of HTML, and it's like no no no no no.

Whereas if you've if you've extracted the the one element, you can just have the HTML that for that element appear and it's like, oh well, I see, I I missed an attribute or something.

Um you can use beautiful soup if you want, too.

But this might be a little bit easier.

So yeah,

yeah, yeah.

What what other projects are you?

I mean you have so many.

But I mean this is like sort of like a static site via Django, which Yeah.

I don't know.

That's just basically yeah.

And um it sort of made me start thinking because all the the answers are are great, you know, like um it's uh Pelican or uh Lecter or there's all these Python ones, right?

And there's Hugo and there's Jekyll, and there's there's so many.

Um but I it sort of just like triggered a thought for me of Django does 90% of what all these other things have rebuilt and done.

Uh and maybe Django could do something like these other uh projects.

And so it was it was just a prototype, and I was like, huh, I wonder if I can do this.

Um so I started by just um I use actually Carlton, I think you had a talk at DjangoCon US at some point with a single file, and then Will, I think you have the repo.

So this encompasses both of you, which is fine.

Oh, so I can use this little single file thing, and I can make um I can make sort of I can reduce the complexity, right, of what you need when you have a Django uh project.

And so I I use both those ideas in this.

Uh and basically it's a Django app and it looks in a particular folder for markdown files, everything it sees in there, it renders them to HTML and then outputs them to a different folder, sort of just like every other static site generator.

Um the other fun thing that I did was um there's no databases, right, in Django, in um in a static site.

So uh in I think it's Hugo and in Lecter, there's a couple of um options for this, but basically it uses JSON.

So you could have sort of sort of a database where you have uh data inside of JSON, and you can pull that out and then shove it into a Django template, and it will get rendered as part of your uh static site generation.

Is that

Okay.

So when you're working and you're like you know typing up markdown and stuff, it'll automatically reload the contents.

Um so that's a nice little dev experience.

And basically, I took Django and I tried to make it as simple as possible for an end user to start up a project.

Um and now it's it doesn't do everything, right?

It's just static content.

Uh but it's sort of it's again that 8020 rule of just like if you just need a blog uh system, like this is a pretty simple way to just start that up.

And um, but it still provides all the power of Django behind the scenes, so you can use Django libraries, uh you have Django templates, so you have template tags that you can do things in.

Um most of the other Python static site uh generators use Jinja, so like it's just a different, you know, it's a different approach, right?

Uh but it was really fun to work on, and so I really like it.

So if you I mean I think that that point about being simple, so it's literally just a folder of markdown is the important thing, right?

Because if there are there's a whole you can you can start there, then if you need a full Django site, there are things if you and but you still need it static, you could use there's a Django bakery project, right?

Which takes so then what that does is it sort of reads your URL conf and then crawls the URL conf for every to enumerate the URLs and that and then writes a stack stack site to stakes it.

And then I think there's a Wagtail bakery project if you've got a Wagtail site, but that's like a lot more machinery on top, and then but then you're still able to just host a the output of um a folder of static HTML files rather than oh I've got to spin up a Django process and have that running all the time and everything that's entailed on that.

And so it's it's all a static site.

So uh I use render.com because Heroku is going away, sadly.

But um render will host your static sites for free.

So uh I push to uh I push uh change of markdown to GitHub.

Render will pick that up.

It runs a uh it's basically a Django management command in the background and then outputs the static uh HTML and then it's on the site so it's a nice flow.

That's cool, trade.

I was gonna say all Django.com so I thought that was your home page.

That's like your sort of personal that's you know we're all just

I feel like our our question this fall needs to guess needs to be like what platform hosting service do you like and why?

Because there's there's quite a few and I've I've been deep diving on this.

It sounds like is render the one that currently you like Adam for

Heroku was my was my you know standard forever.

And so when I was looking around it seemed like render was was really the replacement for that but

I'm contracted with them to write the the Django uh nice docs.

Um so supposed to do that this week actually um so um because they are lack they don't have a dedicated Django docs and so I've been talking to them and that's uh they're gonna have something both you know an existing site and a um migrating from Heroku but rent you know render ha render has great stuff too I'm not making a judgment on platforms but that is a a whole fly has and it will be filled shortly.

Maybe it doesn't really work out because you know just different different approaches by different you know communities which is totally fine and I love Django.

I'm not gonna move away from it so um but

And they they make they make basically all their money they make millions of dollars a year on hosting and then also they have a starter project that like an official starter project.

And then from that he's able to do all this all the you know give away all this stuff and do new things.

So it is appealing you know that it's one less layer of complexity.

On the other hand it's completely dependent on one person.

But like it would be great if Django had Django start project gave you a site you know kind of like there's starter projects like I have Django X there's a whole bunch of them if there was also an option for like a deployable start a deployable project and then click a button it was up to the vendors but you could deploy on render fly you know take your pick um that would be friendlier.

I think it's something very very important that Django has the kind of structure the community owned project the community project that it is and I would I would defend that against some these the kind of costs that I think if we were to if we were to make it into if we were to make it into an entity that had a revenue a proper revenue stream of its own then there would be a real danger that the revenue stream gets hijacked.

So you know the the example we're not saying this is necessarily right but in the Apple world which you know part of them follow that ever all the really long standing people there are decrying the fact that its revenue stream is now services because it's taking away everything that made Apple the company that they loved over the last 30 years.

And I feel the same thing would happen to Django or an analogous thing would happen to Django if Django became a money making enterprise so I'll just put that as a sort of something that we can discuss a DjangoCon sometime over a few bevies but um Eric Mathis Django simple deploy project it looks like it's just hitting the the absolute button here on um uh you know being able to just go um all like automate all deploy pick your plat

form and okay he started with Heroku and is now like right I've got to get the other platforms on but I think he's got platforms.shell going they were sponsors at Django

as a pull request or as a as a plug-in um and so it may be there with the with the to work we were talking previously about improving the start project that even though we get there a bit slower we might be able to get there you know anyway without needing to um sell the project into a or like convert or sell the project but converting the project into a commercial enterprise so you know I I hear everybody say now I just think maybe it's not as bad as all that.

deal with it I don't want to understand the inheritance hierarchy and everything.

But I I did this presentation and so I had to sort of dig into it more than I normally can just uh avoid.

And there there are some nice things about CBVs.

And so but I I kind of wanted to make a library that provided some of the niceties of class based views but still stay in the function based view world because to me it's more simple to understand a request comes in here and there's a response out here and I don't have to look into any mix-ins and figure out you know what is happening inside of here um with a class-based view

So uh for the longest time there's a library called uh Django Annoying uh which is not the best library name um but I I would use it all the time and it has it has a bunch of uh decorators and other you know uh model fields and stuff but uh two of the decorators that I would use there's uh I think it was render2 and then there was an Ajax one and it basically is just a decorator that you put on top of a function based view and uh you can return a

dictionary from it instead of render to response or you know http response or whatever and it will take that dictionary throw it in the context um oh and you specify the template uh name in the inside the decorator uh function call and it sort of cleans up your your function based view which I kind of I like um and the code there's not a lot of code so I was like okay this this is all fine and then for the Ajax one uh it would do something very similar just uh render uh JSON res

ponse and it would take that dictionary and and pass it back.

Um so I used that library for a long time.

Uh and uh I saw those two functions, and then I started thinking of some other things that I tend to do with class-based views, like uh a redirect view from your Urals, or just like a you know template view from your Urals, just sort of like some little nice um shortcuts, basically.

Yes.

It's just I have to write some code to do it.

So I took that code and I made it into this library.

Um and it sort of it tries to encapsulate some of those patterns, but stay in the function-based view world.

Uh and so

So you get your um template view, as view, and then you pass in some init keyword what arcs.

So you don't have to get those per request, right?

Is that that's yeah.

So kind of I like looking

Like it's not the worst thing in the world.

In one thing.

And so but Sure.

And one of them is about locality of behavior.

And one of the advantages of these um kind of HTML over the wire type things is it keeps it keeps the behavior in the same place.

You're not writing CSS in your JavaScript file, or you're not writing your business logic over here, and you're the you it's kind of like I'm writing this template and I just add a few little tags on, and all of a sudden it works.

You spend a lot more time working in the same file, and you don't have to have five files open to read them.

And so a lot of these practices that you know about mixing behaviors that you end up with, you know, a forms file that's got one form in it, and then a serializers file that's got one serializer in it, and a filters file that's got one filter in it, and a view file that's got one view in it, and it's like, but hang on, I could just put all of those in one file and they'd fit on one screen, or maybe I have to scroll down a teeny bit, and it would all be in one place, and I wouldn't have to have four files open and four tabs where I can't see the stuff.

Why can't I just put it in one file?

And I've been sort of advocating that to clients um for years, and they'd be like, Oh, they'd sort of look at me as if it was unprofessional, and I didn't have the the tech, the sort of the jargon to give an argument as to why it wasn't, it was in fact the opposite of unprofessional.

It was a lesson I'd learned hard over you know a decade and more of experience.

And then Carlson wrote that essay, and I was like, that's that's the locality of behavior is uh anyway.

Sorry, I just got excited about that.

I had a blog post on an about page, a Django about page six ways, and basically showing, because I think like we all are pretty fluent in Django, right?

But like a lot of people don't understand know how to import.

It's like, wait, if I have a you know, this file, a forms file, how do I bring it in?

You know, so just being like, okay, like let's do you know, an about page six different ways, like let's jam it all into one file and you know, let's break it out is a really great teaching method, I think.

No one ever read that post, but I was like really proud of it when I wrote it.

And I keep thinking, like, I think there's a lot more here to this.

I mean, your talk, Carlton, I mean, part of why I was so excited about your talk was getting at this idea of just yeah, it has guardrails, but like you can do whatever you want in Django.

Um, but you kind of need to understand the enough of it to feel comfortable doing that, right?

Where it's like, yeah, we could do it that way, we could do it this way, versus a beginner is just like, what?

Like one file?

Like that breaks all the laws I've just been taught and you know memorize but don't understand.

Like you've got it.

But sometimes it's easier, literally, you you know, it's only a hundred lines total.

Just have the hundred lines next to each other.

And you know, so

That's that's crossing.

Or did you summed up the

So you but you I didn't let you finish because I

Like uh there's one that uh serves a favicon.

I think I stole that from Adam Johnson's post uh at some point.

Okay.

Uh where you can serve like an emoji as your favicon instead of setting up an actual image.

Um what else do I have?

Oh, I have a middleware.

So the other thing that people seem to like uh with class-based views is uh like uh having a method explicitly for git and for post.

So you're kind of splitting up those two uh pieces.

Um and so the way that I tend to do that now is I have this middleware and it's really simple.

It just uh looks at the method and then adds a property onto the request object, which is isPost, is get, is head, is you know, all the different uh HT verbs.

Uh and then so in my function-based view, I can just do if request.isget do my get stuff, or isPost and do my post stuff, instead of um request.method equal, equal, you know, get uh, which looks a little messy and feels not super dry when you see that over and over and over again.

So it's just little helper things that I that I added that um seem like they're useful.

I'll write a function-based view from time to time, but more or less I use a class-based view.

And I normally start it class, my my view inherits from view, and then def get um, you know, self request args, keyword args, whatever.

And um at that point I look at it as I've got exactly the same as a function base view, um, which is the request comes in here and I return it from there.

But I've got what I've got is a namespace to break it down at.

And of course it's indented, and there's a bit of boilerplate, and there's a self-argument which gets in the way.

But the the sort of advantage is when you get to if get if it request is get or if request is post, it's sort of outdented because you've got separate handlers for those.

And it's it's what's nice about that sort of circle of um examples there is to show that it's entirely equivalent.

It doesn't matter which way you you do it or which way you like or what you use, because one day's one way is more indented in one type and the other way is more indented in the other, and it's all the same, right?

So, what are we arguing about?

We're arguing about um, well, I like blue.

No, I like red.

Which blue says someone else?

Which red says someone else?

We bike changed.

But I like I like that example.

Um anyway, function functional base.

Did we mention Luke's um piece?

Um it's it's pretty brilliant.

It's uh it sort of lays out a case for function-based views.

Um and I actually um you know borrowed some code from that as well for the redirect uh view.

And uh it basically, you know, you were talking about Carson's essay about uh cardinality.

It's like when I read uh Luke's uh Django View the Right Way, it was like this is what I've been thinking all along, and I just cannot like put it into words, but like this is so you know, like my thought process uh when I was reading it.

So highly recommended.

Super, super.

I would say of the top five questions I get from my books, you know, function-based versus class-based is one of them, and and people now cite Luke's piece to me.

And I'm like, well, I agree, but um you know, I'm still gonna I I think I yeah.

Um, but if you just take sim simple class-based views, you know, where you're literally declaring them by hand, and then you build and you use the namespace to break your logic up if you need help and methods, which is what I like, versus I find functional composition um to be um quite a complicated subject um for even advanced programmers, and it can be difficult to get your head round and difficult to think in the right ways.

And this is just a literary question.

Do you think for beginners, which particularly you know you target more will recommending for um function-based views and decorated approaches and things, which are I think, well, are they hard to grok?

And is it not easier to teach a class with a namespace with separate bits?

I don't know.

That's a question.

I mean that's my sort of feeling.

Yeah, you're the special guest.

Is it clear what I'm saying?

Because I didn't really announce it.

I think a lot of my you know bias is that I already knew how HTTP worked.

And so to me, I'm like, I want a request and I want a response.

And I understand that what what to do with those things where it's not so abstract.

Um and a lot of my what I've realized over the years is that um I have a I have a reaction because of where I came from with C sharp, where everything is a class, it has to be everything is OO to the nth degree, and you have interfaces and you have you know class hierarchies and things.

And so for a long time I was like, I I don't want that.

I understand these functions and you can compose them, and I you know it was a visceral reaction uh to those things.

Um that doesn't mean that they're wrong or they're right.

It's just you know, I think everyone goes through uh their own learning experience and um what makes the most sense to them.

And I I sort of love, hate that Django has these two ways to render um responses because they different people like uh each of them.

And uh I just think it makes it harder when you're starting, but uh at the end of the day, like you said, they're they're equivalent.

So you know, pick your poison as far as I'm concerned.

I think to just come back to me, the gang of four pattern um for is a method object where you've got uh a complicated function and you convert it to a class in order to break the function into separate steps, which are then called from a sort of from the get handler from the main request handler.

So is it it's a it's a method or pattern for um decomposing your logic in anyway.

That was Will.

So it's I the earlier versions of my books I've mentioned function-based views and shown like a hello world with it, but said I want to get you up and going, and we're gonna backfill.

And so I haven't gone more into it.

I get a lot of emails about it.

I have been convinced I want to build at least CRUD with function-based views and do both.

But then I want to show like build something out that's like a 20-line function-based view, and then be like, this is why generic class-based views exist.

And you know, yeah, you gotta do some research, but like changing one line versus having this custom code that repeats a lot.

I think you know, I I I go if I can use a generic class-based view, I do, but as you're learning, I think you need to learn both.

And so I'm I'm gonna add both in more than I currently do.

But I still think it's it's sort of like if you're teaching in college class, be like, yeah, let's talk about HTTP and let's do it all fundamental principles.

But if someone's like, I want to build a website, it's it's a question of when do you introduce it for me?

Like, that's the tension I have is like I don't want to just overwhelm everyone.

So I think that I will for the 4.2 versions have function-based views crud and show a sprinkling of how messy function-based views can get, because you know, if Luke writes them, or you know, they they can be really nice, they can be awful, awful, awful, awful.

Whereas, you know, manipulating one or two lines of an existing generic class-based view, I prefer doing.

And one he sort of opens the book with a chapter on Python.

He's like, look, fundamentally, Django is just Python.

And so you need to learn about this of like decorators and properties and descriptors and yeah, like all the these advanced Python bits.

He's like, but if you know these, then you'll understand how um Django works.

And if you know that Python, then you'll understand that you know that these different ways, you know, are just are options.

I find myself, you know, I wrote my books because I didn't like those kind of books, but now that I have more experience, I understand them more, and I find myself rewriting my books to be like those books.

So I have to.

My god.

Yes.

I know you have a Python utils site which is built with Unicorn, which is kind of cool.

Uh um, we're gonna link to it in the show notes.

I don't know if you have a quick snippet you need to say or

Anything you'd like to say.

I don't tweet very much, but occasionally I do.

Um and if you want to keep up to date with, I sort of post um updates to what I'm working on and um try to be somewhat witty on Twitter.

I mean, you have these other screencasts and things if you get more community support.

Is that still the case?

It's been awesome.

I never thought that anyone would uh sponsor it, so that's been great.

And um it is sort of, you know.

When you're building something like this, it's like you need some intrinsic motivation, obviously, because it's like it's a slog.

I've been working on this for two years, so like you don't just you know, it's not it's not uh overnight or whatever.

Um but uh the the extrinsic uh motivation is also kind of nice of just like yeah, people love this and they're using it and uh they want to support uh open source, and I really appreciate that.

Really interesting.

Thanks for all the the work you do in the project.

You're just prolific and super, and it's really great to chat to you.

Bye bye.

Bye bye.