Transcript: PyCharm's Year of Django - Paul Everitt

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

Hi, Carlton.

And we're joined again by Paul Everett, who's a Python advocate at JetBrains.

Welcome back, Paul.

Hi, Carlton.

Thank you for coming on.

Maybe I'll give that to you.

You were just telling us before we started recording, there's some exciting stuff happening related to Django.

On the other hand, JetBrains is so cool.

I joke that I should be paying them, not them paying me, but don't tell them I said that.

Um we are uh we've been around a while as Python IDE, Django IDE.

In fact, I believe the original tagline for PyCharm 15 decades ago was Python and Django IDE.

So we're pretty good at at analyzing the magic strings and Django and the magic structure and all of that and putting it into machinery the IDE can use.

We are starting a year's worth of a lot of things going for Django.

Um, we've been doing a lot of things in different directions over the past few years, past API and things like that.

We're getting back to Django and a lot of cool stuff coming down the pike in the product itself, but also things that we want to talk about and show and teach and patterns and this whole idea of what does professional development look like for Django?

I mean, that's partly why we have this podcast, is because unless you're doing the hallway track or or work at a company with people you know doing interesting things with it, there's no easy way to keep up with it all besides the different forums and mailing lists.

Just follow Carlton on Mastodon.

I mean, that dude just can't stop typing.

So I I wanted to hit you up, Paul, because this week I've um look like over the summer I've been using VS Code um for whatever reasons.

And literally lot this week I switched back to PyCharm and I pulled it out, and I've been having um any number of squiggly lines all over the place.

Um and that was going on with VS Code, and I switched over to PyCharm and I had the exact same squiggly lines.

It's all about the typing.

It's like the you know, because the static analysis doesn't you know pick up that you've overrid the manager or yeah, something like that.

And then I went into the PyCharm settings and I hit the Django integration box, and it just all those wiggly lines went away, and it picked up the reverse managers and you know, just everything.

And it's that depth of understanding of Django, which I think is PyCharm's real strength.

No, that was in that's in the professional edition.

And this is a normal kind of software relationship.

Um, Python Professional has Django integration, you got it exactly right.

When you say this is a Django project, then lots of things start to surface for assistance.

Well so what I'm curious just internally, so what besides you advocating for it, like how do the powers that be decide that this is the year of Django?

Like what what's the forces that come together to make that?

Is it just every year is a different major framework?

Are there particular you know, we were talking again offline about changes in terms of uh JavaScript and server-side rendering?

Like how how does that all come together?

Where you can publicly say, like, this is our fo this is the focus for the next year or so.

Um in the past number of years, we with PySharma, we got such a big scope.

The surface area is huge.

Surface area of Python is now huge.

Python isn't a market anymore, Python is a collection of markets, and um products can get into uh a mode of I'm gonna do a little bit of everything, and then they go through a mode of I'm gonna do a lot of something.

And so we're just kind of decided that Django is a really good affinity for us in a number of ways.

Um we have a long and great relationship with Django, and that's probably the best part of the the prime part of it is that there is a relationship here.

Uh second, Django is uh for professionals and professionals who have a tendency to do larger projects where an IDE helps you, um in teams where an IDE helps you, people who have a psychographic profile where they value tooling, like testing, where IDEs help you.

And I'm saying IDE intentionally because the emergence of VS Code and PyCharm in the Python world over the last five years, Python a little bit behind JavaScript, but similarly, is starting to value tooling.

Uh type hinting as an example.

Who raise your hand if you would have expected JavaScript to be the one to get to really adopt casual typing?

No, it's crazy.

Yeah, that's true.

I mean, that's and it you know, Carlton's often talked about being a fellow and less so on the board, but just balancing that tension of like the people when you're in it, you're working with are have the more complicated, advanced use cases, but you still want to try to maintain uh friendliness to newcomers.

And I'm sure you know with PyCharm as well, right?

Like you can't, you don't want it to necessarily turn into AWS, like you want it to still be usable.

And in your point, if you extrapolate it past something like JavaScript into the web and web browsers, there's a lot of different agendas at that level as well.

Um, so for us and our kind of year of Django that we're doing, um, some really innovative product stuff that we're working on that we intend to roll out in the coming releases, content that we're working on, teaching, and relationships with folks like you.

I mean, it is it five, six years, the the annual partnership with um the Django Software Foundation and PyCharm.

I mean, and that's um you know, that's a sizable portion of the Django budget.

Django really uh relies on that.

It's a third to a quarter of the yeah.

Okay.

Like there's nothing hidden, like there's spreadsheets forever and on the board.

But yeah, I mean, you know, the PSF puts out an annual report, but again, they have uh a lot more staff than you know, Pete and the people running stuff.

And they were shocked, and I was like, wow, it really is hitting home.

Like, how could they know, right?

They're not at the time, you know, Jacob's now on the board, but he wasn't on the board, so yeah, there's value in letting people know all that.

Anyways, yes, Carlton, you had a question.

I don't know if it's gonna be on, it's on as we record.

I don't know if it's still gonna be open when this episode goes out, but if it is still open, folks, go and fill in the survey because we need those.

It's people's it's people's one chance to give us some feedback, right?

I mean, I give the classic example is we asked um what people were doing for caching, and they're and like 90% were like, oh, we use Redis.

And so we were like, should we have a Redis backending core rather than a third-party package?

And so the Redis backending core is directly came out of the the survey from 2021 or 2022.

I think so.

2021.

And so the first one was just a Google sheet that I put together.

Um, and then from there, we've um JetBrains has really helped both standardize it and now they do the translations um because they're already already doing it with the Python Software Foundation.

So I'm very um I feel like a grandparent.

I'm like, I feel happy that that's you know, I saw it come out this year and I didn't have to like do it all myself.

Uh yes, Carlton.

Because so JetBrains are not only helpers put it together, but then they format it and they do this nice infographic at the end.

But there's some nice little they look for correlations in the data.

I think there's one that was something, it wasn't exactly this, but something along the lines of older developers are more likely to use ver VMs and younger developers will use containers or something like that.

I can't remember the exact thing, but it was like, yeah, that's brilliant.

Uh let us know.

Because it's just one person's like, ah, I've got to put the survey together.

We need to we need

a way of it.

I think we asked Adam Johnson and maybe a couple other people, but it was just like, well, and then from there it's you know gotten hopefully revised and gotten better each time.

But yeah.

It's a big bit of work.

Um we went through kind of a systematic effort at hiring a Python advocate at JetBrains on my team for Django, focused on Django, the Django community, um for her own benefit.

I will not say the name yet until she joins, but we are so wildly happy to have her uh November 1st time frame, and we will pick up the pace of things like the Django survey.

Oh, that's super.

Because you're all busy with the you know the pie cons and

I think I I think I emailed you when I found out separately just saying here's my two thumbs up.

Excellent.

Uh she's wonderful.

Well, so what so what will you know what will be new now that they'll be a full-time person?

Will that be the the point person for Django things?

I know there's like what's yeah, what is what's what's what's the in a year you look back and say this is what we wanted that role to achieve?

What's the mixture of stuff?

Right.

Um the art is in what you want to what instead of what you will do.

Uh I believe in storytelling over a period of time and knowing what effect you want to accomplish at the end.

And so if if uh she already has a strong narrative of what she's about and what she wants to accomplish, and then we can support making that happen in the community, and then we'll get you know, the company will get its benefit along the way, but for the most part, to support and stay out of the way, equally, someone really close to the product, a lot closer to the product than I am, who can to Django

, who can then inform the product, PyCharm, about its Django support.

I was just before we started, I was like, Carlton, what do you think about because he knows a lot more about Django than I do?

Um, and can inform the steering of the product, especially something we were talking about, this kind of junior professionals that are starting their career journey.

And that psychographic profile is really important to me.

And the contrast is, well, I've got my text editor and I've got my my my terminal shell and you know I I know all the you know, I know everything.

And like as a as a a veteran, it's hard to, it's not hard.

The tooling's lovely and the tooling's nice and smooth.

It makes it, but it's like, oh, I could I could live without that, no problem.

But if you're a junior or an advanced beginner and you're just sort of stepping up to that next level, to have the tooling to guide you and to put the rails down and to show you the way, it's like the good example.

I'm I'm constantly using a git GUI because you know I can use the git command line.

But I tell you what, a GUI doesn't often make life much easier.

But it's it's that same thing, you know.

If I've got a tech, you know, if I've got the text, the test runner showing all my tests, I can see which ones failed, I can click through, I can, you know, jump straight to the source code, that kind of thing.

That tooling, it really helps me do my job more effectively, you know, regardless of whether it's PyCharm or you know, some other option.

And I'll I I'll use the same framing you finished with, regardless of what tool it is.

That level of tooling is a way of development that in the world of Python, we don't promote enough.

Python is really simple.

You can just engage Python is you don't need a compiler like Java or.NET or whatever.

So there's a temptation, I can just use them.

Yeah, yeah.

And some people could use the Rails that you described.

It's it's a different world, right?

And and I was like, oh, okay, like that makes more sense because it's just powerful.

Like it would just, I think it would start up this I don't want to it was doing some stuff that I wasn't familiar with using a like a text editor as opposed to an IDE.

Um which leads me into a question of so you have there's a big um educational licenses, I believe, are free, is that right with PyCharm?

Like I s I would imagine that leap is a big one, right?

Because you don't want to lose them, but all of a sudden they're like, wait, I have to pay for it.

Though of course they just paid a lot of money for college.

But like what is that, what is that like how do you how do you view the that funnel?

That's what you're describing.

Uh what justifies paying for this?

Is that kind of where you're going?

But I'm an old, I'm an old crusty hat.

I mean, I don't know what junior you know, do juniors turn up, here's your laptop, here's your thing.

Is it is it typically like a uh for these advanced beg beginners or junior developers, is it a company account where they they buy a bunch of PyCharm licenses and give them to their employees, or do they let like these days employees make decisions and charge it back to the company?

Or is it just all over the place?

All right.

Not that

Okay.

And so they probably have a couple of options for what their internal IT department supports.

Uh, for something like us, we feel pretty traditional for them for other kinds of software companies.

There's an internal license server that you can use once you reach a certain number of licenses, and there's a pool and you can administer the purchasing and make it available to people and stuff like that.

And that's an area that we have been going more into supporting with some of our uh tools like toolbox um to helping companies administer tooling.

Now, back to your other question or kind of meta question about the value of tooling.

I've got opinions on this.

So for a lot of these shops, developers are pretty important, wouldn't you say?

Software is kind of important these days, right?

If you look at like the median salary of a developer, the cost of like PyCharm is their first minute and 20 seconds of their work day.

So all we gotta do is make them more productive than a

Yes, right?

Because part of is part of the challenge, right, is that people don't know what they're missing.

They don't know what they're missing, right?

Unless and you get locked into a pattern.

Um and that's I don't know, I find like for tooling, like the only way I besides just chatting with people is like when I see people doing, you know, occasionally things on YouTube, and you're like, oh, that's sort of interesting, like, and I either like or dislike what they do.

But it's I feel like for beginners, there's a huge leap to like if I showed how I was doing something or any of us, like we would have Git aliases, we have all these things that, you know, the speed at which we go is different.

No one's gonna catch up with that per se.

And it takes a lot of work to be like to make a course out of here's how I got to that level of productivity, without um, you know, I can speak from percent experience, it's a lot of work to put those together.

Um so I just, yeah, just wondering how you, you know, I know you do a lot of YouTube tutorials um as well, like how to like guide someone up that ramp, because it's I would imagine sometimes it's hard to get across how much more effective you can be with these tools than just doing it your old way.

Like, how do you tell someone they're being slow, basically?

It's called Badass, uh Making Users Awesome, I think, by Kathy Sierra.

And in there she talks about the suck zone.

And she also talks about um like in with photography, people want to Mac master taking photos, not master the camera.

So make them good at photography.

Don't make them good at cameras.

And we we as advocates tend to get really jacked up about our IDE and let me show you what the IDE can do.

And we need to be better at showing you how you can be better at Django.

So we really got to think about that and keep our eye on the ball when it comes to what you just described.

Someone that's just trying to get their job done.

Carlton, you want to add to that?

And it's like, oh, what did he do there?

Or what did she do there?

That was kind of cool.

They just did it.

Yeah, yeah, yeah.

Exactly.

Um, in fact, the perfect, perfect demo is one where you never say pie charm, but somebody pulls their hair out.

What tool are they using?

Show me how to be like that.

Um, and so that that's an area that we got to get better at.

Um I was just curious, what's the the latest story and path?

Um, I mean, not that there's a silver bullet for it, but I imagine you you all have thoughts on that.

Sure.

We actually have a pretty good angle here because uh we're independent of all the cloud providers, right?

Yeah, yeah, yeah.

We we we are not some cost center that is trying to it it seems like every startup.

I'm sure you're gonna laugh as soon as I say this.

It's like every startup that gets some VC funding when they talk about the monetization strategy.

Well, we're gonna have a cloud.

We're gonna, you know, we're gonna have an edge service that we're we're gonna charge for using our open source tooling.

Like, okay.

Um we try to take a direction that is somewhat independent.

We are the lens that people look at through their, look at their code through, and we and people trust us for that.

We got to maintain that trust so that people don't feel like we're going to steer them to like our deployment strategy or something like that.

Now that's also a tough one because there's a lot of deployment strategies.

And so keeping up with all of them is a challenge.

But I but I would I would think on the you know, from from where you sit, Paul, like uh I agree with that.

On the other hand, I know that when if you're using VS Code, they can bundle and say, here's some credits on Azure.

Like when I was at startups with funding, like, yeah, it's like, oh, all they would compete to offer you, you know, X amount of dollars worth of credits for stuff, which isn't the same as real money, but um that's can sound enticing in a way that like with experience choosing what you want to use and having control, you kind of have to get burned a bit to value that.

I mean, if you if you look at the tool, like what actually do people pay for?

They pay for deployment, they will pay for some sort of performance security, like look at Sentry.

And you know, there's a lot of other areas, it's just like you're not gonna get blood out of that rock.

Um so but maybe so Carlton, I interrupted you before though, you had a point.

That's like in a lightweight.

I I quite enjoy playing with that.

And one thing I've just wondered is if if say I had PyCharm installed, if it could somehow hook into the Django integration in PyGram charm so it could be because it hasn't got that.

And I was just wondering if there's any possibility of that ever.

That's just an ask you about the status of Fleet.

Uh so just to explain, Fleet is like JetBrain's next generation IDE.

It has a different UI, different UI stack.

It's intended to be polyglot from the start.

Its big feature is it's distributed from the start.

Uh, the front end and the back end are separated and can be in different processes, even in different locations, even in multiple locations, multiple back ends.

And you can kind of

It indeed indeed, a remote container.

Um the back ends contain the brains of our current IDEs.

So we're not starting over from scratch.

Mostly.

There's still some wiring up, as you discovered with the Django integration, still some wiring up uh to kind of close the loop on it.

But when that arrives, it will be a different IDE experience that will be a great fit for mobile users, distributed users, uh IT companies that want to provision a back-end, make it available.

It's always warm, it's always indexed, all those kinds of things.

Interesting.

So, were we gonna talk about testing a bit a bit?

Uh the kind of the biggest one is stuff that we already have available and we want to polish and do a better job of telling the story about.

First of all, we mentioned before about the the Django survey.

Yes, I remember the first time I saw PyTest overtake the Django test runner, and I was shocked that it's do you do you trust those results?

Um, I mean, I you know, I'm an old stick in the mud, so I'm still using uh, you know, the t the Django test runner and still very happy with it.

But you know, quite often when I'm working with client projects, it will be like, you know, PyTest, PyTest, PyTest, and no problem.

But yes, I think it I think it's same.

Um, I still kind of old-fashioned that way, but uh everyone else that I hear just immediately goes to PyTest.

Second question.

Stick my fellow sticks in the mud.

Class-based views or function-based views?

No, so I I use class-based views almost um almost universally.

It's for me, it's um my views always get gnarly, they always get whatever, and I I like the namespace that a class gives you to to break them up.

Um, but I tend not to use too what I don't do is with Django's generic class-based views, is get into massive overriding of the mix-ins and all the rest.

Because I think in the Django community there's this constant debate, and it's often um conflates class-based views as a general thing with the specific implementation of class-based views, of generic class-based views that come with Django.

And no question, those are super complicated, and the inheritance structure is uh, you know, it's too complex.

It's there's too many mix-ins, too much superclassing.

Um maybe.

Um putting

Like, so I write when I write a class-based view, it's like class and then the get handler, and it reads like a function-based view, but it's indented one level and you've got the namespace to break up, you know, the various bits.

And that's that's it.

Whereas if you if you and the class, but the generic class-based views are great if you don't need to override specific methods or work out what the call order was, but otherwise you're digging into clo classy class-based views, and it's like, ah, what's the method and where is it?

Yeah, and it's just no.

So I understand all the people who love function-based views, but the answer to your question is I use class-based views every single time.

What stick do you have in which mud?

I would say I try to I I go down, so I start with generic class-based views.

I I don't mind overriding one or two methods, but at some point you just need to go, as he said, just define your get method and use use the namespace.

Um, I don't, you know, honestly, in my day-to-day, I'm always trying to find the simple, elegant way to do it.

So I really I probably over-emphasize using generic class-based views, definitely class-based views, just from a teaching standpoint that's a lot simpler.

Um, there are a handful of occasions where you need a function-based view.

Um, but I've, you know, as like there's a reason why class-based views were inv invent, you know, are used.

There's a reason why the code base is in that.

Like I'm not gonna it's a religious debate in a way, but if someone asks me, it's like I'll take generic class-based view, class-based view, function-based view in that order of preference.

Yep.

I mean, one of the things I'm adding to the 5.0 edition of my beginner's book is I'm adding more function-based view things because I think it's I think it's probably an easier way to uh think about how the request response cycle in a way that if I just jump to like template view, list view, detail view, people are gonna miss that.

So I'm adding a lot more of showing both.

I always I I didn't want to for a long time because I was like, this is gonna totally overwhelm people, and I think it will a little bit, but yeah, I think it's from a teaching perspective, it's helpful.

I can't remember exactly the type, but it's a polemic.

And he says at the beginning, look, this is a polemic, don't take it, you know, too seriously.

But he he me he you know he means it.

But um, the sort of big um challenge he puts to class-based views is well, where's the view gone?

And a view is a function which takes a request and it turns it into a response, right?

That's the web problem.

Take requests and turn them into responses.

And a function-based view wears that on its sleeve, whereas the class-based views, when you just see, you know, list view, model is this, and it's like, well, where's the view?

Where's it gone?

Um, and so I think you know, to if from a teaching perspective, to teach people that is dead right, yeah, because you show them the that the request goes in there and the response comes out there.

And then when you switch, when you move to class-based views, I think it's really important to show them the actual handler.

Look, there's the handler on the class-based view, and it takes the request.

You don't write that bit yourself, and you just declare these forms and you know, these fields and magic is done.

Well, I was always I was always a purist, Carlton.

Don't worry about that.

But like, you know, most engineering books are are bottom up, right?

It's like, well, I don't want to just give you the answer.

I want you to like work hard to get there so you understand the answer.

But, you know, when you're trying to build a website, sometimes you just want to build a website and then backfill a little bit.

And so certainly the early, earlier versions of the book were more show than tell.

Um, and I just keep adding in tell, but I think I just need to make clear to people like this is tell, but you don't have to know this right now.

I'm just putting it there for like I want to have both.

I'm trying to have my cake and eat it too.

Because I value the the telling more and more as I get into it and as I deal with people.

But I also understand they need to just like get a hello world working, deploy a site.

Like they don't want to 400 pages to put up a site when I can just show it to them in three pages and then be like, hey, let me explain how that actually worked.

Like you did, but I agree with you 100% for the beginners.

You just get get them to the success point quickly without all the backstory.

But then somebody who's gonna, perhaps in your professionals book, I don't know, but somebody who's gonna go off and build web applications, there's gonna be the point where they're like, Do you know what the generic stuff just doesn't do what I want, and I need to I need to just turn a request into a response and understand being 100% clear on that request response cycle on the web problem.

Yeah.

You know, that's that's equipping them for a career.

Well, this, I mean, Paul, you know, you educate people like this is the challenge.

When you sit down with someone, you can tailor it.

But when you're doing a video or a book or an article, you have to kind of guess and pick a layer of like what are they gonna what are they gonna ask next?

So that's that uh yeah.

One, the IDE can give you more assistance on that, and second, um well, I'll I'll go off on a little bit of a detour of an anti-pattern.

In the world of Python web frameworks for a period, and oh my god, for damn sure in JavaScript frameworks, there's this race of well, my hello world is only five lines, and so it's way better than your framework's seven lines, and everyone rushes to adopt the five-line web framework.

It's okay to write a little bit of code, you know.

We've got smart tools, we've got PS Code, we got PyCharm, they'll generate a lot of this for you.

And just because you have a great first five minutes in a miserable next five years, make better decisions, people.

So, um, okay, that's interesting.

Well, that's that's um, I was just last week talking with someone.

Carlton has a talk on this, you know, Django can be a micro framework, and there's a repo.

I just we'll put a link in from four years ago, which makes me feel old, showing how quickly you can get to hello world with Django.

Um and it's like 10 lines, maybe.

Yeah, yeah.

Um, and you know, even Flask, if we're just gonna the obvious comparison, like they show Hello World, but that's not how you build Hello World with Flask.

Um, so I think they've indeed solved that marketing problem better than we have.

And uh Pyramid came out.

I'm I'm one of the Pyramid guys, I was Zope before that.

And Pyramid suffer greatly when like six months later, Flask comes out with its five-line hello world, and everybody thinks it's just the magic.

Um, whereas Pyramid, oh my gosh, the conveniences it gives you over the next five years are amazing, but people just don't see that during the first five minutes.

So back to class-based views and testing.

Um, I like this pattern of being able to instantiate the thing that's about to be rendered and then test that thing that was instantiated.

And to move some of the stuff out to make it easier to test, like properties on the class that's the class-based view or something like that.

Um, and I just find that to be on the way towards my theory of testing, which is testing ain't about eating your vegetables, it's about joy.

And what is the more joyful way to develop?

What isn't joyful for me is I've got my editor, I've got my terminal where my test runner runs or my dev server runs, I've got my Chrome browser over here, and I'm always going back and forth between all these different things, context switch, context switch, etc.

And wouldn't it be great if I had like one environment I could sit in it and I could run my tests, execute that view under the freaking debugger.

And whenever I have a question, I just set a breakpoint, run my test, I stop right there.

I can poke around, I can see the entire universe at that point of execution.

I don't have to do print statements or in JavaScript console logs and all this other crap.

I don't have to go over to 50 different tools to find out the universe.

I'm right in my editor.

Right where I'm typing is where I'm executing and is where I'm digging.

No, I mean a debugger is an amazing thing.

It ain't just for bugs.

As well.

Like, oh, here's my favorite um trick, trick.

It's the favorite cheat.

Is um well, I'll go halfway through a test.

I'm like, what's the assert?

I don't know what the assert is, but I can put a break point in the test and then I can vibe out.

Oh my god, if you ever try to answer the question of where did Sphinx get that pixel from, good luck.

You can't know the answer unless you set a breakpoint.

You'll never find the answer by looking around on disk.

And so what you just said is exactly right.

You just set a break point, run your test.

Life is so good.

Why don't people want this?

Will, what's wrong with these people?

I mean, you know, if people Google Django testing tutorial, I think I'm near the top of results.

I think the problem, the problem is at what point do people say, you know, read the manual, I just want the docs.

Um and that happens at some point.

Um, but you know, docs are I I like to say now, docs are designed for if you already know what you're doing and you just need like, oh, what's that thing called?

Whereas the tutorial teaches you.

So the docs are not going to teach you how to do a thing.

Well, the thing is, I think maybe Django docs are pretty good at the why, but they don't give you the context.

I mean, compared to other docs.

So no, the Django docs are great.

But like there's a so to take this exact example, there's a um section in the advanced testing tutorial, which is testing class-based views.

But it's it fits on like one screen.

It's two cognitive examples.

And if you like it shows you how to instantiate an instance of a class-based view, and then you can call individual methods on it, right?

But that could be like two chapters in a book, you know, really showing you how you leverage that and how you know how that enables you to test the methods in isolation and how you build up, you know, to a really good testing short.

But the Django docs haven't got that.

They've got these two examples, which kind of if if you just need a reminder, they're perfect.

But if you're learning that for the first time, you need you need somebody alongside you to say, hey, look at this, and this is how we could use this, and this is the patterns it unlocks.

I mean, there's also at the higher end, there's like Adam Johnson has his speed up your Django test book, which is amazing resource.

And that's probably smarter because that's like, okay, you value tests, but let me show you how to make them better.

Um But how do you, yeah, how do you lead a fish to water?

How do you tell them what life is like without tests if they don't know?

I mean, one way, in a way, a unless you work with other people, like like working on another project reinforces that for beginners.

So if you airdrop into a project and you write some code, you're like, well, that worked.

Why is things breaking?

It's like, oh, because there's other, you know.

Whereas I think there's a sense that you can have everything in your head a little bit when you are doing everything.

So that would be pedagogically, that'd be interesting to like airdrop you into a project and be like, just do this simple thing, oh, and run the test suite, and then just a million things break because you don't know what's going on.

And I hope that I get to march in your army as you help convince people with your book about this.

Um, and I I think there are things that can be done, like have AI write your test based on your last test.

So really lower the friction, lower the barrier, get tests to be closer to the code, like a companion to the code.

But there's also something, I don't know.

Have either of you heard about in the world of JavaScript something called Storybook?

Storybook is the thing, storybook is Portuguese.

Portuguese is the language, if I think I know what it is, but I don't, it's Portuguese.

Storybook is the thing that I think I know what that is, but not really.

And you write a story, which is kind of like the setup for the variations of that component, and then you go over and run this tool, and in the browser you see a listing of all your components, and click on it, and you see that component rendered, and it re-renders as you type, and it renders all the variations of your component based on inputs and the paths and all of that, and that's the story that you write.

It's like a catalog of your project.

But guess what?

You can feed those stories to your tests so you don't think you're writing tests.

Maybe there's a way we can trick people into doing things that can be tested because those are the things they want to do, they want to see the rendering of their snippet, like

Um, but maybe just in a large sense, there's a way to get something like testing into the workflow they want instead of eat your vegetables.

Um so testdriven.io, Michael has some, um obey the testing goat.

I think those are their website.

Which one?

Um But I think that that's off-putting to beginners.

I think I'm not against well, I don't do test driven.

I think most people don't do test driven.

I think it's I think the problem is if you hit someone with testing is test driven, they just go like, well, I don't even know how to build this, let alone test it.

So I think that's part of the part of the problem with testing is that it's not done that way.

There is this way of development where you just sit, you stay in the flow, stay close to your editor, everything is brought to you, and you can set this debug break point.

I will also say when it comes to testing and debugging and running of code, boy, is JavaScript kicking Python's butt.

Yeah.

Oh, it doesn't exist.

Like it's not really solved, is it?

Um you had there were some toots, tweets about things recently.

Do you care to share that story?

Uh I think all three of us are, but particularly Carlton since he's put a lot of work into this.

We're big fans of HTMX.

Yes.

That's the way the web's supposed to be.

Um, and HTMX lets you get some of the benefits people have moved to SPAS for.

You can keep your existing stack, you can keep your non-JavaScript programming language, you can stay with Python and get some of these benefits.

Carlton, would you agree with this?

Like, so you know, I've been working on an application for the last six months, and like it's we're six months in, it's going really well, and I've got four endpoints.

I use JSON response four times.

So it's not just a it, it's no longer API first, it's API maybe.

Like maybe there's a rich component that needs some JSON.

So I, you know, there's four related to one bundle of views.

There's four uses of JSON response, and that's it.

The rest is just HTML.

Thank you very much.

And it's it's lovely.

It's not, you know, this week's framework or you know, some new tech that's uh experimental and won't be around in six months.

It's the oldest stuff in the book.

And it's like I was writing stuff like this in 2005, and I'm writing it again in 2023, and it is wonderful, just wonderful.

Half of what Carlton is saying is I already know Django, and Django can render HTML.

I don't have to send it to the browser to render uh JavaScript to HTML.

So it isn't just Django rendering the HTML that we already know and love.

It's HTML render by the browser that we already know and love.

The web has a platform.

It is super good at this.

We don't need to put the HTML and the CSS into JavaScript.

Carlton?

Well, just

So I've got a detailed view, and that has a nested um or a bit a section of data which is quite computationally expensive and it's a bit slow to render.

And so to make it fast, I just literally um load that separately.

So I just have a little hxget on load, you know, a thing.

And it pulls it in in afterwards.

So it loads the main page and the page is instantly responsive, instantly rendered, and then the little bit of um of the little bit in the section, the table of data, which is a little bit expensive to generate, that comes in maybe a second later.

But it's not the page isn't stuck there waiting for it, you know.

And it's just like, how joyful is that?

And the the you know, the the people looking at it, they're like, oh, this is great.

This is really, and it's just like, but it's the oldest rope in the box, you know.

It's really we just need

Be like, we got your full stack right here.

Um it it's it it enables me to build an application single-handed in a way that I literally wouldn't have been able to build for the last decade, like

There are other business reasons.

What about blind people?

A lot of these these spa front ends could care less about that.

What about a 3G low-powered phone in a remote part of the world?

A lot of them have a really bad story on time to first content paint, which then impacts their SEO score.

You'll get a bad SEO score.

Google might index your spa once a month, and they may give you a bad core web vitals score on it.

So all these are making people rethink the spa front end, React front identification of everything.

But a large part of it, Carl, it is what you said, Carlton.

It's exactly right.

I can't do all of that.

Can I use a technology that just works?

Can we go back to that and make it better?

And so um, Carson, the creator of HTMX, put out a post talking about the loss of view source and what Google's uh search page looked like in 2003 versus the indecipherable optimized mess it looks like now.

And one of the things we might have lost is being able to look at the web.

And so I made a counterpoint to that, and strangely enough, the creator of JavaScript replied to my tweet saying that if we want to get back into that game, there was a time when HTML wasn't abandoned, where we didn't have to do everything in JavaScript.

It was the time of HTML5 with the what working group, where people in the community came together kind of in opposition to the browser vendors and won instead of a world of XHTML2, we have the world of HTML5.

And so he was encouraging us to stop complaining and say, hey, HTML is good enough, let's make it better.

Let's not make it.

He was responding to me saying that the web shouldn't be a big JavaScript runtime.

Okay, it uses JavaScript to do that, but it's in a very controlled and small way, you know.

Like, why is it that every element isn't clickable or can't send events?

Why is it, you know.

So do you think do you think we can get browser vendors to implement this stuff?

I mean

Five years ago, would you have predicted that CSS would have a renaissance?

No.

CSS in the last two years, even Safari.

I used to be.

I think it has no idea.

It's this is also like this is a philosophical thing.

Like, why do we have to like opt into like security and all our stuff, like instead of the opposite?

Like we're you know, the onus is on us to say, no, don't sell all my data.

and Google Chrome uh recently getting pretty shifty.

Yeah about

I mean, but all this uh all this is um again, it's the needs of solo developers or small developers and also big corporations, in that if you go online and look at how is like every every week, if not almost every day, I get someone saying, Should it shouldn't I use like you know, view or react and all this stuff for my solo project that I'm building like on the side?

I'm like, no, no, no, no, no.

But everything that they read online is here's how to do full stack because you know who's writing it, who's employed, people at larger companies.

And it is true that if you work at a company over 10, 20 developers, there's probably a dedicated front end and back end, you know, and you're probably only writing a you know, so how do you, you know, it's part of it is I try to tell people like that's just how it is out there, it's not n nefarious.

Totally right.

There are important voices pushing back on the people use React because people use React.

It has become that way.

That's the reason people use React.

Yeah, we just gotta talk about it more.

I don't, you know, so um 5.0 has just done the feature free.

So now, okay, 5.1.

Need to make some changes to the template Django template parser, which I've kind of just done horrible things in Django template partials as a proof of concept.

So we get an official API there that can use.

And then whether or not Django Partials template partials itself becomes part of Django, I don't know.

But improving the template language there, there's there's uh renewed discussion about like a kind of um capturing tag.

So, you know, say you've got a pagination um thing, and you would want to render that twice on the page, once at the top, once at the bottom.

It's quite a heavyweight component.

So you want to render it, capture the HTML into the context, and then just output that same HTML again when you render it later, rather than render it twice because it's expensive.

That was there was a ticket for that number 6,000 and something closed 10 years ago.

And it's like, okay, as a oh, where do we need this?

Who knows?

Somebody maybe I don't know.

But you know, it's discussion to reopen that.

There's this, you know, there's things like um template tags, rediscovering those and how to use them and what the patterns around those are, and that's super powerful.

But you know, I got um I want to pass a model object into a template, but I need some, I don't really want to pass the whole model object.

I want to do some transforms on it and you know, fet some related properties and what so what we what I really want to pass is what's called a view model.

It's like a a it's like a special object which gives the template exactly what it needs and no more, just simple attributes.

So I can calculate that in my view and pass that in.

But you can use template tags to kind of do that view model type thing.

And then that's all in Python and it's all testable.

And then you've got a really simple bit of HTML, which is a template, and the two just go together in a beautiful way.

And you're what you're not doing is got these gnarly templates with ifs and loops and you know function calls in and all the rest of it, which is totally unmaintainable and not really editable because you'd like

And in fact, um, for 3.13, Jim Baker of Jython Fame and Guido are working on tagged template strings, tag strings, a pep, already have an implementation.

Um, I'm helping write the pep on it.

And it's a way to do basically, at strings that can run through a function.

And then Jim has an HTML templating language built around that, which is just so interesting.

Yeah, absolutely.

That's not the way people develop anymore.

People think in terms of components.

You can come over, I'll show it to you.

You you're you're bullish on um HTMX pool.

You know, you're

I think it represents a set of ideas that I would like to be actually foundational.

Whatever it is I wind up doing, and hopefully this Django work that you're talking about, maybe they'll actually converge.

Who knows?

It would be great if it was reimagined in the context of partials, components, small pieces, um, not rendering the entire thing.

Just at the most fundamental level, you don't even have to think about it.

It's baked in which is the direction I think you want to go.

You've been working on.

And then I guess that would feed into the UI work as well that you

Uh Sphinx is what I call it.

And so I have a view layer for Sphinx, and I um have kind of reimagined the templating, it doesn't use ginja.

And the idea is an ecosystem of reusable components.

I could write a component, it would work in Sphinx or Pyramid or Django, because it is insulated from its outside world, and it's able to it it's able to get stuff from the outside world, it's able to be given stuff.

And you see this a good bit in the world of JavaScript.

Indeed, exactly.

Even though, you know, 10 years ago there's a lot big push to like, well, Django, you know, why didn't they do more?

Why don't they bundle more in?

And it now it provides the flexibility to be open to these um new technologies and the where the pendulum swings in a way.

I forget which of our guests made that point.

Like, and I really like that that Django is batteries less magic.

Because magic is like maybe more like Rails, where it's just like boom, zero to sixty.

But then what if I want something different?

What if the ecosystem changes?

Sure.

Yeah, you're stuck with it.

Whereas batteries, a little more work to put them together, but they're there for you if you need them or don't use them.

That is wisdom.

Uh God merchants

or opinions.

But yeah, no, I mean, again, just thinking of what you're talking about, the Django template language there, and like the the the way it makes you write these template tags to encapsulate your logic rather than letting you put logic in the template.

You know, I grew up writing PHP, and you know, I've always liked the Dango Django template language for that.

But coming back to it after all these years of doing JSON endpoints left, right, and center, it's like, oh yeah, actually, this is a really powerful pattern, and it it's it's dead right.

And it enables you to do the transformation logic in Python, and then if you know, if it's rendered as a list or a table or a thing, that's just a little HTML change.

And then it that even that can be a parameter, and it's it's really flexible, it's just lovely.

He's like red team, you know, he's like, where are the weaknesses?

Well, we should have a post-fellowship program, right?

I when I put that together, put it together in like you know, an afternoon sort of thing, the first sort of you know, take of it.

I I looked up when I first thought of that, and the note I first thought of it was eight years ago.

It's like that's been on my background for eight years.

I could have done that eight years ago, but

I wasn't sat there building a fresh project, having to the prospect of writing all these crowd views and writing a list view and a crowd uh to get no, I'm just I'm writing the class I always wanted to write because I'm not doing that 58 times for this whole life of this project.

That's how CrowdView came about.

Is there anything else as we wrap up that you wanted to mention or that we didn't cover?

Um, it's time to have fun with Python and web frameworks.

It's time to have fun with Django and new ideas, um, new patterns in testing, new patterns in HTMX.

And uh I'm I'm in the joy business these days, and we should all remember how awesome it is that we have it.

We should help the next generation of people take over, get them in place.

Let's have the new heroes replace the old heroes.

And um let's spark some innovation.

Let's have Python not ship its eight its UI layer to JavaScript.

Yep.

Boom.

Well, I'm sure we'll we'll need to have you on again shortly, especially with this this year of Django and hearing about all the work that will happen.

So look forward to that.

Links to everything in the show notes.

Um Carlton, will you take us out?

Thanks so much for coming on, Paul.

Um, really enjoyed the chat.

Um, so we're Django Chats, we're Django Chat on Mastodon.

You've got to be in podcast number 5000 territory.

Uh, the community is lucky to have the two of you.

Will, I look forward to marching in your army on uh getting people to work better.

Um, and hopefully I come back on in a year and we we look back on this and reflect on what's all transpired since then.

Amen.

Everyone, we will see you next time.

Bye bye.

Bye bye.