Modern JavaScript for Django Developers

Speaker 1: Yeah, so so my name is Corey Zhu , and today I want to talk about uh modern JavaScript. And super quick about me. So I kind of had two stages to my career. The first one for about the first 10 years, I was the CTO of a company called Demogi. We make what I believe is the largest open source Django application in existence. I'd be happy to be proven wrong about that. But our our project has over 150,000 commits over the last uh 12 years or so, including about 11,000 from me. And then in the last four years or so, I've I've been doing uh kind of like side project entrepreneurship, I would say. So so building little web applications mostly in Django, um

Speaker 1: like doing everything myself, uh building marketing and and then trying to to sell stuff online. And yeah. And so my goals for this talk today are uh are two The first is I I want to convince you that modern JavaScript is just like it's important, it's useful, and maybe most importantly that it's not too scary. And then I'm hoping to provide you with a roadmap to start using it in your Django projects if you're not already. And the talk is usually loosely based on a series of articles that I wrote last year, which is available at that URL. And so if you don't follow something I'm doing or you want to go deep dive into anything I cover here You can go to that URL and there's a much longer write up

Speaker 1: with a lot more details. So yeah, so why talk about JavaScript? And this slide is like almost too too obvious to even put in here, but um when I was making this talk, I was I was just looking at my browser tabs and you know I've got Gmail and Google Docs and WhatsApp and and Slack and Trello and and all of these applications are are using, I'm sure, tons and tons of JavaScript. And to provide uh a web-based UI that that sort of is in line with with what people expect on the web these days, uh, you're almost gonna always gonna be using at least a splash of JavaScript and more likely maybe even a lot. It's not going away. This is uh these are the results from the Stack Overflow developer survey last year.

Speaker 1: Um JavaScript is the most used language among developers. It's been in that position for the last eight years and probably not going to be unseated anytime soon. And it's it's better than many people think. And so these are now the most loved frameworks from that same survey. And if you look at this list, like four out of the top five frameworks are JavaScript frameworks. And they're all above Django. Django's down here at number seven, which I found kind of surprising. But I think in the in the Python Django world, it's often I often find myself joking that JavaScript is not great and people don't like working with it, but people do love working with JavaScript. Uh and and that's one of the goals I have is to convince you that that you might you might love it also.

Speaker 1: Um it's hard. And and when I first started doing web development way back in 2008. JavaScript was hard because it was just like kind of this like goofy, quirky language. And you had to worry about browser compatibility for everything you did. And you know, if you use two equals instead of three equals, you might introduce bugs in your code. And it was You know, it was just kind of like this, uh, it was a quirky language. Um, and these days uh it still has its quirks, but but the reason JavaScript is hard today, I think, is because it's so complicated. And there's just there's so many different pieces of the ecosystem. There's frameworks, there's tools, there's like syntaxes, and If you're a Django developer, if you're trying to get started and then you're like, okay, I want to use some JavaScript, and then you're faced with this

Speaker 1: incredible complexity of of uh choices of of what to do, then you can kind of just get overwhelmed and you say, well, I don't want to like worry about any of that stuff. That that seems really complicated. I'll just I'll just do something much simpler. And so yeah, again, I think one of my goals is to convince you that that uh it's it's not as bad, or maybe to pick out some of some of the bits of this that that are useful. And the last thing I'll say about motivation is just JavaScript isn't that standardized in the Django ecosystem. And so If you Google Django JavaScript, at least when I do it, the very first result is it's this is the Django contributor guide to like if you want to add JavaScript code to the Django admin site.

Speaker 1: This is the style guide for how to do that. And I was really surprised by that because I have to imagine that the number of people who have contributed JavaScript to the Django core. is is not that many, but Google still thinks it's the most relevant page to return about Django and JavaScript. You can also see these questions like can I use JavaScript in Django, which which I found funny, or how do I connect JavaScript to Django? And yesterday I was looking at the conference schedule, and like I think I counted at least six talks, uh, not including this one, just with people with different ways of using Django with JavaScript. Um there's also At least two talks that uh are are kind of like here's how to use Django without JavaScript entirely. Um and so yeah, so there's just there's not standards to this.

Speaker 1: Um I'm gonna propose another Another way, yet another way. But hopefully what I'm talking about will be more of like a fundamentals and less of uh of a specifics. And so yeah, so this talk is kind of broken up into three parts. The first is about uh front-end organization. Uh so just kind of like how how your front-end code interacts with with your Django projects. The second will be on integrating a React application into a Django project. And that's not because I think React is the best framework or anything else, but I think a lot of the things that come up will come up with. uh any any modern JavaScript framework and um and it's a good uh way to to explain a lot of these concepts.

Speaker 1: And then in the last bit, I'll just touch on some of the benefits and features of this modern complex JavaScript ecosystem. So let's talk about organizing front-end code. And I'll start with what I consider to be the default architecture for a Django project, which is like you build out your site. Using your web, your your views and your templates and your forms, you realize at some point that you need something dynamic to happen on the page. So you throw in some Inline JavaScript to your template, maybe a library or two, and then repeat. Right. And so these projects are often using jQuery, at least uh five or ten years ago these days, they might be using something. uh different like alpine um but but basically uh yeah

Speaker 1: like this approach it it's actually kind of great right and and i i do love it uh especially for small Projects, it's super simple. Like we all recognize it. We all know how to work in this environment. One nice side effect is your pages are usually self-contained. You've got you know you've got your template stuff here, and then you've got your JavaScript stuff down here. uh so you can really easily see how everything interacts. You don't have to go chasing uh files around and stuff. Um but there are some problems with this um and and most of the problems arise over time as your front end code base grows as your project grows. And so things like code sharing across templates, sort of figuring out where in your template inheritance you want to include your JavaScript libraries, how you're going to manage that. Mixing Django and JavaScript together.

Speaker 1: And what I found is these can often lead to these kind of home thrown homegrown front-end organizational systems. And this example is from that big open source Django project I mentioned. And the way that we were managing dependencies, even to this date, although we're migrating way far from it, is in our views, we we annotate like the request with which JavaScript libraries we're going to need for that page. And so in this particular example, you could see like this if this request needs NVD3, the graphing library, then you know include these four. uh files that that mvd3 depends on in the base template. And this is kind of problematic for a lot of reasons. Like your logic is spread out in a bunch of places. This annotation happens in the view. This

Speaker 1: library import is happening in a base template somewhere. The actual code that calls the JavaScript is probably living somewhere else in another template or in a different JavaScript file somewhere. And so like this often leads to front-end code that feels a little bit spaghetti-like. And another side effect, which I'll touch on later, is that you're also not leveraging a lot of what modern JavaScript can do and can do to mitigate this problem. So is there a better way to do this? And uh and a few other talks have have mentioned this already, but this is this is kind of if you Google how to use uh React and Django together, you'll end up with an architecture that looks something like this, where you have a standalone front end on one side and then a completely standalone back end on the other side.

Speaker 1: These two projects are usually completely separate uh in terms of code. They might even be in different repositories. And they only will typically talk to each other through APIs. And this can be great too. It will let you go all in with a JavaScript framework. And so if you love React and you just like want to do everything in React, then you can do that. And And you can have a server, a Django on the back end to do all the good stuff that Django can do. You also get this nice separation of your backend and your front end, which arguably could lead to sort of better modular API design. It also helps your team. Like if you have people who uh exclusively work on the front end, they can do that. They can point out a staging site and

Speaker 1: they don't have to Worry about databases and Python and any of these things. So this can be this can also be a really nice uh way to structure projects. But there are problems and and and I don't like it for my own projects primarily because I feel like everything every time I try to get anything done in this architecture, it takes like four times as long as I think it should. And so instead of being able to just quickly drop in a Django form on something, you have to create an API, you have to like do a UI library front-end thingy, you have to potentially do routing on the front end. And it's just, I find it really slows down velocity of development. And it also makes deployment harder. You might have to run like a node process on one side and a Python process on the other.

Speaker 1: You might start dealing with cross-origin stuff if these two front-end and back end are running on different subdomains. And and you're losing a ton. And so looking at the sort of list that gets included into the intro to Django on the Django talks. Like you're throwing away Django's URLs and view systems, you're throwing away templates, you're throwing away forms. And then like you you are using obviously the ORM and you're using the auth system. You're getting a lot of Django security, but You're in a world where you're wrapping those things with libraries. And so you're not in sort of core Django land anymore. You're in like Django Plus and a lot of the stuff has to get re-implemented in in your front-end codebase.

Speaker 1: And so Django has this philosophy, batteries included, which is one of the reasons I love it, one of the reasons why I expect a lot of us love it. And in this world, it's kind of like, nah, like bring your own batteries. Like, um, and so so I call this like the Energizer bunny. I I wanted to give it a picture. So uh he's carrying his own batteries along instead of uh instead of using ones that that may be already living inside Django. And so are these our options? Like do we do we need to choose between this Nice simple familiar thing that doesn't necessarily scale all that well that gets kind of unwieldy, or this this uh you know, beautiful decoupled uh modern thing that that you know, slows us down and and makes us throw throw away a lot of what's in Django. And thankfully, like, like

Speaker 1: the answer is is no. And what I wanted to do and what I think is is a good way to structure a lot of projects is getting the best of both worlds where you can have uh you can default to Django, URLs, views, templates, everything, everything we know and love. And then when you need to like drop in a splash of modern JavaScript when it makes sense and combine those two things. And so I'm I'm the rest of the talk I'm gonna I'm gonna deep dive into into one way that you can set this up. Um but just to like quickly summarize how How uh I think about these three choices. The first one is kind of like it can work really well for super small projects, but but kind of never like if you're gonna do anything on the front end, you might as well. uh go through the effort of of getting into sort of like a hybrid world.

Speaker 1: The client server one I think is great if you love JavaScript frameworks or if you have this this team structure where your front and back end developers are separated. And the third one I find is really nice for people like me who love Django, want to use Django, but then also want to do like complex stuff on the front end sometimes. And I think it works really well for solo developers as well. where you move from the front end to the back end and you're kind of owning the whole stack. So so yeah, let's let's dive into that. And I'm gonna do it again in the context of of integrating a React uh application into a Django project. And so what what we want to do is is basically this. So we we want to have our normal Django thing with our views and our templates and our static files. And then like somewhere in that static world.

Speaker 1: We want this magical React thing. And so how do we how do we get this blue box? And if if you go to the React uh The React tutorial, you'll see like a whole a whole robe that looks like this. It's like, oh, okay, you just import React and then you call this. And and When I was looking at this, and if if you if you haven't sort of spent a lot of time in modern JavaScript world, like you might be thinking like import react, like how what does that mean? like don't don't i have to like add a add a script tag and point it at a cdn or something like that and then you might see this h1 thing and you're like well that doesn't look like valid javascript syntax like that's not a string what is that and because it's not And if you drop this into a Django template or if you drop this into a web page, like your browser will just say, I don't know what to do with this thing, I don't know how to import this, I don't know how to read this H1 thing.

Speaker 1: And And that's because you need a toolchain in order to do development like this. I put a little asterisk there because you don't technically need a toolchain to use React, but but you do need it to sort of use React in a way that I recommend using it. And so what yeah, so why do we have tool chains? And and basically it's it's so that we can do modern stuff on on legacy browsers. And so JavaScript, unlike Python, when you're building a web application, you can't really control the JavaScript environment that. uh that is is is being used. So your your users might be on the latest version of Chrome and then and then you can you know support that. But if you're not, if you know if they're using some ancient version of IE or something like that, then then the browser still needs to ideally work on on that.

Speaker 1: The JavaScript should work on that browser. And so what what toolchains do is they they have let the JavaScript world continue to advance, to continue to add good stuff. You know, they added modules so you can do imports just like you can do Python stuff. They added new syntaxes that make Building UIs easier and a toolchain will let you write your code this way and then turn it into something that actually still works on any browser. And so once you learn that, it's like, okay, what toolchain should I use? And the React docs for integrating with an existing code base send you over to this more flexible toolchain section. And then you're like, oh, okay. And Like looking at this, there's just it's like the fact that there's four options, the fact that like

Speaker 1: combining the power of Webpack with the simplicity of presets, like if you're not in the JavaScript world, if you don't like know what a lot of these words mean. This is just, again, you just sort of reach this point where you're like, what am I reading? Like, why is this so complicated? And then again, it's like, it's easy to just give up and just ah stupid JavaScript. And And move on. But it's really not that complicated. And so I want to try to explain to you what a toolchain is from its primitives. And a toolchain basically just has three things. There's a package manager, a compiler, and a bumbler. And so the package manager's job is the easiest way to think about it is it's pip. So you're gonna use it to install your libraries, it'll pin the versions for you. And yeah, it's it 'll do everything that Pip

Speaker 1: does. And NPM and Yarn are the most popular package managers. You can just use NPM. uh you you can also use our own but but these recommendations I'll give they're they're just it's not because I have you know I have strong opinions and I've I've deeply researched all this stuff it's just But like I want to use JavaScript. Like I just want to use the boring stuff. And so all the recommendations I give here are just the most popular thing that will be the most supported. We'll have like the best documentation, etc. So that's the package manager. The next thing is the compiler. And the compiler is the thing that's going to take that modern syntax stuff and then turn it into stuff that your browser understands. And so you can see here that example with these H1s, which this is called JSX, which I'll touch on later. It'll take this and turn it into just a normal JavaScript function call, which can then

Speaker 1: uh which can then be uh dropped into a browser and used. And so Babel is is the most popular compiler. It's what I use. It's what I recommend. And then the last thing is the bundler. And the bundler, it does a lot, but its main job is to is to take uh JavaScript code that spans files and libraries and whatever else and smash it together into a single file, which is called a bundle. And so you can write your code, you can have your code spread around wherever you want, you can uh import libraries and call library functions and your bundler will Take all that, it'll figure out your dependencies, it'll take everything you need for that project and then bundle it together so that you can then just drop that bundle file onto your web page.

Speaker 1: And so you don't have to do any of this. crazy stuff uh with dependency management across multiple places that that that all that all just live natively in your JavaScript code. Your job JavaScript code declares its own dependencies, your bundler takes care of making sure they're available for you and in that page So putting it together, we have uh NPM, which we'll use to like install stuff, manage our libraries, our imports, Babbel. Uh we'll take our source code and compile it down into browser-friendly stuff. Webpack the bundler will take all that together, create the files that we need, and then we can just drop those files directly into our browser, and finally we have something that works. And so going way back to this picture,

Speaker 1: we can just shove that whole thing in front of Django. So you can have all of this on the left side and it just spits out a bundle file that you can then drop into your Django static files, use just like any other Django static file that you would. And and then you're using React or whatever modern JavaScript inside your directly inside your Django views and your Django templates. So what does that look like just in terms of file system? So this is how I structure my projects. So you have your normal Django, MandaShot Pi, your site, your app, and then you can basically just like add a folder anywhere. I call it assets, where you have essentially your front-end code base.

Speaker 1: And then that will go through this pipeline and then again just gets dropped into your normal static folder. So hopefully that's pretty straightforward. And then just to close the loop on this example, so uh this is back to our Hello World React application. Um and you can see Like we write this on the left, it goes through the pipeline, and then we just include it as a normal static file as we would include any other static file in a Django template. And then the only other bit of communication happening here is in the Django template, we define this div with an ID root. And uh React will grab that ID and use it to render itself. And so this example is obviously very simple. It'll just do a hello world, but but the React application in here could be arbitrarily complex. So this could be a single

Speaker 1: page app with a bunch of. different routes and whatever else. And you can serve it at any Django endpoint that you want. And if you do that with Django, then you're also, you know, you can continue to use Django for session management. You can use the auth system if you want, you can drop in uh you know normal Django template variables and and convert them to JSON, have that have that work with your React app. So I find this is a really nice way to sort of get the best of both worlds with uh with using React and and sort of keeping most of what's in Django Django. And um yeah, there's a there's a much more comprehensive example where I walk through all of this, including uh how to you know work with the database, work with APIs, do create, update, delete. cycles, uh URL routing and all that. If you go to that link.

Speaker 1: And yeah, so I didn't have time to go through through all of that and talk, but it but it's all there on the side. Cool. And so yeah, so what's the payoff? Like in some ways, all I've done so far is just add like a hundred new tools and a lot more complexity to your already probably complicated Django project. And so why would you why would you do this? And there's a lot of things that you get. You get to use the latest JavaScript frameworks, which will mostly assume that you have some version of a pipeline or a toolchain in place. And I'll say from experience that despite being skeptical for a long time, building complicated UIs in these frameworks is

Speaker 1: it is just like a really nice experience. and really increases your velocity once you get over the hump of of uh wrapping your heads around them and and setting up the tool chain and everything else. You get dependency management, you get new features and syntaxes, language extensions, and and I I didn't even have time to touch on this, but you also get other front end good stuff, uh like SAS, which is which is kind of a nicer way to use CSS , and and other things like that. But If I could summarize the payoff in one sentence, it's just like you get to treat your front-end codase like a real codebase. And so it's not this, it's not this, you know. spaghetti thing that's scattered across your templates

Speaker 1: and you know your libraries are being imported ad hoc in in various places and and like who knows where you find the right JavaScript function. Like your front end code base is organized into modules. It you know it has like It it manages its own libraries, the versions, and and all of this. You have nice IDE support with uh being able to do development, how how you would expect to do development, um, and how you're already doing development in in Python and in Django. A few specific stuff that uh has happened in in the JavaScript world. So this this is kind of old news at this point. ES6 was was the the last really big update to javascript which i think is came out in 2015 um but but a lot of people are still not using it or don't don't know all about it um

Speaker 1: One of the big things it added was modules. So we've seen that already, but you can define functions wherever you want and then import them from other places. So this allows you to organize your code. in in uh a structured and insane way instead of uh instead of uh just ad hoc um It added classes as as first class citizens to JavaScript. So those of us who were doing web development maybe 10 or 15 years ago remember that there were just all these different patterns around doing classes in JavaScript, but now there's there's sort of a defined way to do it. It added arrow functions, which are basically lambdas. And these get really useful when you're doing uh when you're building UIs in in frameworks and you you want to do sort of a lot of inline functions that that update a a variable or

Speaker 1: or change a UIL and that type of stuff. It has template strings which uh which are just like f strings uh and are nice are nice to to work with default argument values and and there's there's a ton more stuff in here. This was just like the the five or six that I picked. And yeah, other stuff. So JSX, this is how React recommends that you build your user interfaces. It's kind of like if JavaScript and HTML had a baby. It's also kind of like the Django template system. And basically it allows you to write what looks almost like HTML. It's not quite HTML. It's actually more XML-e. But in it, you can inject these brackets and then write arbitrary JavaScript code.

Speaker 1: But this this allows you to build your UIs in JavaScript just as nice a way as you would in a Django template system. Um and I'll I'll say like React also has nice state management capabilities that make doing this type of stuff also uh a lot more pleasant. So you just you define this UA element once and then it will sort of uh read the state of your your latest object and update your UI accordingly so you don't have to worry as much about um sort of like trigger-based events systems updating your UIs. Vue has has a different take, which which is to uh create standalone components that are sort of modular, like like a single file.

Speaker 1: And so a view file is broken into three sections with the template at the top, which is similar to a Django template again. A script section in the middle where you define your business logic and where you can map uh map the data in your template to uh to JavaScript logic and then kind of built-in styles as well. These styles can be scoped, which is nice. So you can have a view component define its own styles, and then you don't have to worry that those styles would bleed out into the rest of your page. And then TypeScript is another nice thing that's been added. It's very, very similar to Python 3's type hints, but this will allow you to uh define types for for class properties or for function arguments or or pretty much everything.

Speaker 1: And then you'll get nice compile time errors and IDE support and other things when when uh any data is not the type that you expect. And like the Python type hints, these can be incrementally added to your code base. So any any valid JavaScript is up is already valid TypeScript. And then you can just drop them inside. That 's uh sort of as you go. Um and uh a lot more. Um And I'll say like I definitely I don't consider myself to be any sort of JavaScript expert or guru or anything like that. I still consider myself a Python developer, a Django developer. And so I really only like myself have touched the tip of the iceberg and and then the stock

Speaker 1: touched the tip of the iceberg. But um but yeah like the JavaScript world, the JavaScript ecosystem these days It's it's a lot better than I think I thought it was uh you know a few years ago before I started uh before I started really getting into it. And um I find these days that I enjoy, you know, building applications in JavaScript, writing JavaScript code, um, almost as much as I enjoy it in Python. Not not quite as much, but maybe 80% as as much. And because it's the language of the browser, investing in that really increases what you can do as a full stack developer. And so I encourage you, if you're not already, to um

Speaker 1: to try and and and and do some modern JavaScript stuff, uh get over the hump of of the fear of of this ecosystem, uh, because on the other side, it's it's a nice place to be. Yeah, so thanks. And for a yeah, for the comprehensive examples of all this, you can go to saspegasis. com and click guides. Saspegasis is is one of my my internet side hustles that I mentioned. And I am Czu and Twitter and CoryZoo. com is my website. talk about development and uh and about sort of trying to to make a living online. And I think that's it.

Speaker 2: Thank you uh Cory. Please um if anybody has any questions to to Cory, please uh follow the face-to-face link

Speaker 3: below. And it's called chairbones that suggest challenges in your project. You can go ahead, John. Yes, I must say something was

Speaker 1: Hello. Sorry that took me a little while to find find the right links Anybody have any questions? Yeah.

Speaker 2: Yeah, hi, thanks, Corey.

Speaker 4: Um That was good. Uh you mentioned um still using Django templates. Um and I didn't see an example of that. I more saw that you've got an example of where you put your code, but Uh you were talking more about using templating on the on the front end, so combine that

Speaker 1: Yeah, maybe maybe I didn't uh maybe I didn't articulate that clearly. So the the example I I kind of powered through was uh how you would you would mostly ditch Django templates for React. But that that would just be one page. And so any other page you want, you could not use React at all. And you can just use Django itself. Like be because you're doing all of that in the normal Django way, you know, serving your React app inside a Django view. Like any any other view can just directly use a Django template. Um it's mixing and matching Django templates and uh and React apps. Like what I typically do is I

Speaker 1: I'll have a base template with just my UI scaffolding, like you know, navigation and sidebar and stuff, and then let React take over in sort of the main content pane. Um and I find that that usually works pretty well. Um and and when I'm when I'm building an app, like probably 90% of my pages will be normal Django templates. And then like there'll be one or two pages that are are really complicated React apps because they have a lot of interactivity.

Speaker 4: Okay. Uh consistent?

Speaker 1: A bit. It's easier if you're using frameworks, like CSS frameworks, because then you can just add the same classes to on the React side to the Django side. I yeah, I haven't I haven't actually had a ton of issues with that. Um but I but I could like it is true that uh the styling doesn't quite perfectly translate from from the Django world into the React world. You can use if you use exclusively CSS classes. It it mostly does. A lot of people when they're in a modern like JavaScript world, they like doing uh more explicit style imports and other things like that.

Speaker 1: Um and I haven't found a good way to make all that work together.

Speaker 4: Thank you.

Speaker 1: Yeah, no problem. Thanks for the question.

Speaker 5: Right, I have also a question. Um when you use like the Like React uh React page, how do you communicate then do you use classical REST API? Like the single page application approach or do you try to try uh do you try to inject like two templates on some data f for the React app

Speaker 1: Yeah, it it kind of depends for me. Um and uh but I'll I'll usually do one of those two things. If it's uh it's kind of like if If you know the size of what's gonna be needed, um one of the nice things about doing the hybrid thing is like for example, if you just have some config like a single object that you want to be available to React, then you You can just serialize that object directly to the Django template, and then you don't have to worry about API calls or whatever. You just assign it to a variable and your React code has access to that variable. If you're doing like a list view and there might be five things or there might be 500 things and you want to have pagination and all that, then you get more into API territory.

Speaker 1: And you can mix and match those two things. So I have like in the example I mentioned, there's a list of employees, which is, you know. handled by an API and then there's some static data like choice lists uh which which can just get passed directly to the template as JSON

Speaker 5: thank you thank you

Speaker 6: Can I ask something?

Speaker 1: Yeah?

Speaker 6: Okay, good. Um I was wondering maybe I missed it in your talk, but uh I was wondering if you have actu any experience with uh combining this using CDNs like uh S3 or something like that. Where the statics are let's say uh yeah uploaded somewhere else.

Speaker 1: Yeah. Uh that that works fine. Uh so as long as As long as you're using like once you build the bundle file, which which I usually do as part of my like CICD pipeline. Then that bundle file is available just like any other static file. So it can be, you know, you can you can deploy it to a CDN or you can drop it to S3 or whatever else. It's at that point it's just the same as as a regular image or or anything else that you have.

Speaker 6: And and and maybe I missed that as well, but um because normally in in in yeah compiling let's say the bundle files you have like dev mode and a production mode that at least in React it works like that. And they can be quite different in that sense. How how do you deal that using uh let's say development? Because you want to have that live reloading Uh like uh dot yeah.

Speaker 1: Yeah, so in in dev I uh I just I build the bundles directly into my static folder. And so Django, Django just serves them just like it would everything else from the dev server. And then those are git ignored. And then in prod. I run the same thing to build them first before I run collect static. And then collect static uh will handle everything else once they're there. Does that make sense?

Speaker 6: Yeah, thanks. Yeah, yeah, that makes sense. Yeah. Thank you.

Speaker 7: Uh I have another question which is you just mentioned that you usually have a bunch of um just regular Django. uh endpoints and then a few bits of your websites are react or whatever it is. Um do you ha run into a problem with uh with basically resource duplication where you are loading the same stuff in different parts of the application and how do you go around that?

Speaker 1: Yeah.

Speaker 7: I think is a common pitfall.

Speaker 1: Yeah, yeah, yeah. Definitely. And it it it's kind of I use two options for that. And there might be smarter ways to do this, but like If you want, if you have a small number of you know pretty different applicate like single-page apps, then you can just have a single bundle for each of those. And in that bundle Um that bundle will include like all its dependencies also. Um and so like the upside of that is that each page is uh you know, is only loading one JavaScript file essentially. The downside of that is that when you click from one page to the other, it has to like download all of the dependencies and everything else on that second page. And so the other way you can set it up is to

Speaker 1: kind of declare the dependencies a little more explicitly and have like a dependencies file and then have the sort of just the the the the stuff that's unique to that page sitting on top of that. And yeah, like if I had If I had you know a bunch of different pages, uh I would probably do it that way. Um but I I I've never actually had enough where it was a big problem. And you know, once you load the page once, like the browser will catch it until uh until the next time. So I never I never

Speaker 7: tried to deal with that. Yeah, exactly. Okay. Thank you.

Speaker 8: Yeah, can I ask you?

Speaker 1: Yeah, please.

Speaker 8: Yeah. Okay. Um yeah, um we did so uh see um uh the the inclusion of uh the javascript framework into uh the jungle project I myself have a feeling that uh when um When you really dive into the JavaScript framework, it does pose a very big challenge for uh for sharing that uh with Django uh developers amongst each other Um but um yeah the the the problem of sharing model information which is sort of like one of the the instigators of trying to get it inside of project anyway I also felt that pain um but um I I solved that by trying of not by trying by actually using the options

Speaker 8: call uh that is usually um uh exposed by um the rest framework. Are you aware with uh what what the the options call is exposing about the the rest framework and if so did you ever try that route

Speaker 1: I'm aware that it it exists uh but but no I don't I don't know uh I don't know a lot about that or how

Speaker 8: the good thing is that the the options call on the rest framework sort of does an introspection of the model that it is serving along with all uh choice fields and possible values that you can have for choice fields And so you can actually make a dynamic form on your uh javascript library uh that interprets what the option call is offering and on the fly generate a form for using on your models on on the back end. And um for me that paid off more than trying to include the the uh the dynamic generation of JavaScript inside the the the jungle project because um yeah you can s have a cleaner separation there. I was very

Speaker 8: fighting the the the coat on the one end and including something here But um okay, but yeah, then

Speaker 1: yeah

Speaker 8: look into it because you'll be surprised what you can achieve with it. It's really awesome.

Speaker 1: Yeah, yeah, that's that's cool. I think I think there's kind of three options for keeping those objects in sync. One is like ad hoc manual. Um One is this like introspecting the the API metadata as as you're saying and then and the third like I think uh I I haven't actually done this myself, but I have some friends who I respect a lot who who say that GraphQL plus tooling just like solves this for you. I don't exactly know where the where the model lives, but it lives in one place and it generates your JavaScript models and your Django models. So that's that's another route that I've I've been interested in in exploring.

Speaker 8: Okay, thanks.

Speaker 7: I'll try and go next. See that's okay. Um I'm very much a GIS developer myself, so it's always good to see some JSP flow around there. I wanted to ask about your your point about Django being batteries included and there not being much batteries for JavaScript. Do you see that as a good thing that Django doesn't have much opinions or would you think that on the contrary, Django

Speaker 6: should try and have more built-in

Speaker 8: support for more modern approaches?

Speaker 1: Oh, that's a hard question. Uh I think Django should should do what it's good at. I think um there's uh You know, there's danger in trying to do too much. And also with the front-end uh ecosystem being what it is and moving as quickly as it is, there's also sort of like you could imagine a substantial either maintenance burden or or getting stuck on um on some you know tool or or library or something that that ends up sort of losing favor. So I guess it's good. I think it'd be nice if Django said like here's like three or four ways of doing this that that we recommend. And maybe that was like a documentation thing. But I I don't think Django should like ship with React or anything like that.

Speaker 1: There's plenty of open source projects that will give you architectures like that. Thanks.

Speaker 4: I've got a a another another question which is um I mean I this was really This this these kind of questions are the really the the reason I came to the conference and also to hear about um hot wire and HTMX.

Speaker 1: Yeah, we said a five minutes also.

Speaker 4: I've been uh thinking those sort of things uh for a few months. myself and excited to see that other people have those things because I've been working with Vu uh and Django uh for the last six to eight months um previously being Django and a plane developer. And and and I find that uh yeah it Roos well architected and it's got everything there, but it's shifting all your tech tech onto the front end and uh all your tooling and all your all your knowledge onto onto front end stuff and Django becomes a headless API server as as as as you mentioned. Um but then what you then find is that there's a few

Speaker 4: complaints that maybe VU isn't fast enough and you need to do server-side rendering and you end up with a node running on the server. And Yeah, I I don't know, you you didn't mention server-side rendering and all of that. And yeah, that I think that's why there's a bit of distaste. One of the the uh one of the reasons is a bit of distaste in uh, you know, frameworks. Communities like Django.

Speaker 1: Yeah, yeah, for sure.

Speaker 4: Sorry, I wasn't really a question, but yeah, yeah. No, uh did you did you did server-side rendering? Um

Speaker 1: Yeah. You know, uh uh it never has for me, and I think um I guess because And correct me if I'm if I'm wrong about this, but my sense of server-side rendering is is really good and important for um pages that Like you want Google to index well and you know a lot of people are gonna hit and um and I I find that those pages are usually uh relatively static and so um for those I I just like I make them Django pages and then and then you then Django 's handling the server side rendering for you. But yeah, no, if I had like if I had a really complex UI that I wanted to be server-side rendered, I don't know what I would do.

Speaker 1: I would be sad. Okay.

Speaker 4: Yeah, that's fair. Okay, but you haven't had hit performance issues with that?

Speaker 1: I haven't personally. I mean m most of the applications I've built, the the complex UIs are happening uh sort of post-login. Um and so at that point uh I I feel like the penalty for you know the first time you log in, it's a little slow, but like Google's not into indexing that page anyway. Like there's the upside is is maybe like less important. Um

Speaker 4: Okay. Cool.

Speaker 1: I wouldn't build my landing page in like client-side rendered React necessarily.

Speaker 4: Yeah, cool. Well thank you. I uh you really helped clarify uh quite a few things. Um great.

Speaker 1: Glad to hear.

Speaker 4: But uh yeah, that looks forward to hearing your questions on the hot wire and HTMX.

Speaker 1: I don't know much about them, so I'm I'm looking forward to learning about it as well. Cool. Anybody else All right. Thanks everybody.

Speaker 4: I think we're done.

Speaker 1: See ya. Cheers.