 I would like to take the opportunity to introduce our next speaker, Cori Zhu. He will be talking about modern JavaScript for Python developers. Cori is a web developer and entrepreneur. After being the CTO of Tomachi from 2006 to 2017, Cori's moved on to his own side project and he has an impressive list of them. Cori got into Python in the early days of Django and hasn't looked back. Without further ado, I would like to present Cori. Take it away. Awesome. Thank you. I'm going to try to do the screen share again. This works. We see you. Cool. Thanks, everybody. Welcome. Today I want to talk to you about JavaScript. My wife made me at the slide. I was going to jump in. David introduced me. I don't need to say too much here. I was the CTO of a company called Tomachi from 2006 to 2017. I remain the top contributor to our main repository, which is a source of pride for me. I'm sure I'll get past soon. Since 2017, I have become a serial side project maker and entrepreneur. I make internet experiments and try to sell things online. Why are we talking about JavaScript at Python? Your first reaction is JavaScript. Your second reaction might be something like this, which I won't read aloud. JavaScript maybe gets a little bit of a bad rap in the programming world. This is another one that you kind of see tossed around. There aren't many good parts of JavaScript. When I was googling for memes, I found this one, which I don't really understand it, but I love how happy the Python guy looks. I thought I would throw it in here. I think JavaScript can be stigmatized, especially by those in the Python world who think that Python is the greatest thing in the world, which I kind of believe and probably a lot of us do. But if you're a web developer in 2020, then you probably need to use JavaScript. It's everywhere, it's sort of unavoidable at this point. Also, I will say that JavaScript is not so bad. It's come a long way in the last 10 or 15 years since I first started my career in web development. I'll show you a few of the things that you may or may not know that JavaScript does these days and can do these days. But once you wrap your head around it, the modern JavaScript ecosystem and developer experience is actually pretty decent. In 2008, when I first started doing a lot of web development, JavaScript was pretty straightforward. It was this thing that you put on your website when you wanted to add some dynamic functionality, maybe a little modal or an auto completion widget or something like that. You threw it on, maybe use jQuery. That was around back then. But by and large, it was this relatively simple and for anybody who's tried to sort of get into JavaScript in 2020, it looks a lot more like this. You may or may not recognize some of these logos, all of these logos. But essentially, JavaScript today is, there's a ton going on. There's package managers, there's frameworks. There are entirely new versions of the language, like TypeScript, and it's quite a lot. It's quite intimidating. And especially as someone who identifies as a Python developer, just kind of wanting to use JavaScript to serve my sort of web development needs, it was really difficult to sort of break into this world and figure out what all was going on here. And so my goal is to teach you, I guess sort of what I've learned, hopefully what you need to know in order to use modern JavaScript in your web apps in 2020. And I'm assuming you, like me, are Python developers. My background is primarily in Django. I've built a few class gaps. So a lot of the examples in this talk will be based on Django. And I'll say at the top that this talk is based on a series of articles that I wrote. And I'll link to those in the discourse and in the slides. So there's a lot more detail in there. So hopefully if I go too fast or I cover things that you don't land, you can always go back and refer to these articles where there's sort of a lot more detail, a lot more depth to everything I'm going to talk about. So I want to kind of start by sort of describing how most front-end code bases that I've worked on have evolved. And so we would start out where, you know, for me it's usually Django, but building out a site using your normal sort of Django or Flask tools, your views on your templates, you realize you need something dynamic to happen on the page. And so you go to Stack Overflow, you find a little snippet of JavaScript that does the thing that you need. You maybe add a script tag to include some library from a CDN, or maybe you copy and paste it into your app. And then you go to one. And this, you know, this isn't necessarily a bad thing. And for small projects, this works totally fine. If your project is not sort of too front-end heavy or too large, this isn't too much of a problem, you can go pretty far. But as your project gets bigger, this can create a lot of problems. Here's an example from one of our repositories at Demagi. And this is our base template in Django. So this is sort of the template that a lot of our other Django views, our other Django templates sort of inherit from. And you can see here, I don't know if you can see where my mouse is, but we have this pattern where we annotate the request object in Python to say which libraries we're using. So we say, like, are we using NDD3, which is a graphing library on this page? And if so, then include these four dependencies that NDD3 needs. Or are we using data tables, which is a library that sort of does sorting and search for data tables? Okay, well, then we need these three libraries. Or are we using type ahead? And so, you know, there are a couple of immediate problems with something like this. You know, first of all, you're loading a lot of scripts on your page, which is bad. Your dependencies are also sort of very far away from each other. Like this logic lives in some base template. The thing that sets the use NDD property on the request is probably in some Python view code somewhere. And then the logic that's actually using NDD3 is probably in a different JavaScript place altogether. And so, this is quite a common thing to happen to mature or more mature Python apps as they sort of take this ad hoc approach to to sort of JavaScript and JavaScript dependencies as they end up with a lot of this stuff sort of scattered around in different places. It's pretty hard to reason with. And so, I call this pattern server first. And it, you know, it's kind of you start with the web framework, with the sort of the Django world, with the Flask world. It's the most common one that Python developers choose. And I put choose in quotes because you kind of, you don't really choose this architecture. You sort of stumble into it over the course of months or years of slowly adding frontend stuff to your app. And in this world, as you saw, usually the JavaScript is included ad hoc at the page level. Sometimes that's baked into your template hierarchy. Sometimes it's not. And yeah, like I said, it sort of gets more and more unwieldy over time. And another thing which we'll see later is you're not really taking advantage of what JavaScript can do today. So I kind of lovingly gave this the mascot of the spaghetti monster because, you know, not that your whole code is spaghetti, but your frontend code base kind of gets spread around all different places. And so it becomes a little bit spaghetti-like. So, right. So is there a better way to do this? And if you sort of start from, you know, 2020, I want to build my most modern, my best web application that I can, you'll probably end up finding something that recommends you do something like this. And so in this world, you basically, you create two separate, entirely separate projects. You have your sort of frontend project, and that might be its own entirely distinct code base. And then you have your backend project. And the only way they know about each other and the only way they talk to each other is through APIs. So these are often run by different processes. One might be running in Node, and one might be running in Python. They might be running on two different subdomains. And this is nice. Like, this has a lot of upside. It plainly separates your backend and your frontend. And that can be really good, especially if you have a team and you have a team of JavaScript people and a team of Python people, and nobody wants to sort of cross the chasm, then you get this really nice separation. Some of the downsides of this towards the bottom, like your backend basically becomes an API factory. And so, like in the Django world, you know, you're throwing away Django views by and large. You're throwing away all of the templating system. Similarly in the Flask, in the Flask world, you're not really using JINJA. Flask is just serving APIs. And for us, as Python developers, when you're doing development on the frontend, you lose that sort of familiarity of, oh, this is how I've been making websites for the last 10 years, and now you're asking me to do this entirely new, totally different thing, and I'm only allowed to write APIs. And so, the result of that makes simple stuff more difficult. It makes your deployment architecture a bit more complicated. And so, this isn't always ideal either. Certainly, for me, as like a single person doing my own sort of like full stack projects, this, I didn't want to sort of like take on all this weight when I thought, you know, why can't we just use these two things together? So this one, yeah, I didn't have as good a mask out for this one, so I call it the Energizer Buddy, and the analogy is that you're bringing your own batteries. Like you're throwing out the batteries that are provided by the Python framework, and you sort of have to bring all your own stuff to the table. You have to re-implement everything in this sort of like new API pattern. So this, I'm not going to read through all of this, but this is taken from the guide and sort of talks about the differences between these two. And yeah, I mean, basically, one is kind of usually started by server developers, one's usually started by JavaScript developers. They have sort of different properties around whether they use frameworks, how they manage the JavaScript tooling and all that. And they both have pros and cons, but I have found that neither has been sort of ideal for me. And so the architecture that I like, and the one that I use for most apps these days and that I recommend the most, is what I call a hybrid application. And in a hybrid application, you basically mix and match these two things. And so rather than saying, you know, my front end and my back end need to be completely decoupled or not taking any sort of structured approach to organizing your front end code, you sort of mix and match these two things at the page level. And what this allows you to do is take the power of modern JavaScript and there is good stuff in there. Combine it with the familiarity that you're used to with your Python web frameworks and develop applications that sort of meet both sides. A big downside of this is that you kind of have to dip your toes into JavaScript build tooling. And that is not always the most fun process. And so, yeah, so I want to tell just like a short story of my own experience adding React to a Django project. And so this would have been sort of like, right when I stepped down to Moggy, I'm like building my first side project. I hear that this thing React is like all the cool kids are using it. I should be using it. And so I'm like, okay, I'm going to like use React in this project. It's going to be great. And so I go to the React, you know, the tutorial and they have this sort of hello world code. And, you know, for those of you who know modern JavaScript, like this doesn't look too crazy. For those of you who don't know what it looks like, what is that import? Like how does that import work? And where does that like, can I even do that? And then you go down and you see this, you know, this H1, but it's, you think it should be a string, but it's not escaped by strings. And you're like, what am I looking at? And if you put this code into a browser or into a JavaScript file and you try to run it, like it's not going to work. Like this isn't valid JavaScript code. And yet it's sort of front and center in the React hello world and like my head is like kind of exploding. But what I figured out pretty quickly is, oh, I need a tool chain. And so, yeah, so why tool chains and the short answer is so that we can do new good stuff with JavaScript and also support legacy browsers. And, you know, like, I imagine a lot of us have gone through, you know, the Python two to three migration and we all know how painful that can be. In the JavaScript world, you don't really have that option. Like your code needs to run on, you know, it needs to run on ideally, you know, seven or eight different browsers, you know, all these mobile phones and you have very little control of what particular version of JavaScript is going to run on any particular device that your code is running on. And so you have to be very defensive about it. And so the way that the JavaScript community has gotten around that is they have introduced tool chains that essentially allow you to write newer, better, easier to reason with JavaScript code and then they turn that code into something that browsers can actually deal with. So that's what the tool chain does. That's why you need it. It's so that you can do stuff like this and not have it crash on browsers when you open them. So, okay, so I need a tool chain. What tool chain should I use? And so the React documentation has some advice on this and, you know, my first reaction was kind of like, okay, this looks like a lot of options. But okay, I'm integrating with an existing code base. So I'll go check out this more flexible tool chain section. And so I go over there and I'm reading this and I'm thinking like, okay, neutrino combines the power of webpack with the simplicity of priest. And mix is a toolkit for full stack. And like, I don't know what, like, maybe this makes sense to you all or to somebody, but when I read this, I'm just like, what is all this stuff? And what are even these words and like, why do they all sound so funny? And yeah, it's funny. Like my first experience like getting into this this sort of like JavaScript world that I had never been a part of was like, it was very humbling and sort of like, it caused me to like have some kind of like, you know, am I like not like, I thought I was like a professional web developer. I thought I sort of like understood what was going on. And then I'm reading all these words that barely make sense to me. But it's not this complicated. And you don't really need to care about all these different options. If your only goal is to use modern JavaScript. I'm sure the JavaScript people have have very strong opinions about these various tools, but you don't need to if you're just sort of trying to get something done. And so, yeah, so these are the basic elements of a tool chain. And most of the tool chains will look something like this with possible replacements of these different specific tools. But essentially you have a compiler. You have a bundler and you have a package manager. And I'll quickly talk about each of those individually. So the package manager is the easiest one. And the one line answer is it's it's pit for JavaScript. So this is the thing that will where you'll put your request in into a file. It, you know, you'll give it versions. It manages your dependencies for you. It does your installations for you. So it's almost one to one with PIP. NPM does, you know, they both do other stuff, but you don't really need to worry about that. In the JavaScript world, there's two main packages managed package managers and people will argue about which ones to use. But NPM is sort of the most popular one. And it's the one that I recommend. And I'll say like, when I recommend these tools, it's not from the perspective of like, I know everything about JavaScript, and these are definitely the tools you should use, but these are the most popular ones. And you can't really go wrong if you use them. If you do want to sort of get really into this stuff, you can you can go read, you know, 100 articles about NPM and yarn and decide which one you want to use. But that wasn't something that I felt the need to do. Yeah, so that's the package manager. The next thing is the compiler and the compiler is the thing that lets you write that code like the H1 thing that we saw in the React example. So it'll take sort of new stuff that's been added both to JavaScript and extensions that, you know, other people have come up with like TypeScript or JSX, which I'll talk about in a little bit, and turn them into browser-friendly JavaScript. So that's the thing that's doing the work of translating the modern stuff into the stuff that your browsers can deal with. And Babel or Babel, I'm not sure how to pronounce it, is the most popular compiler out there and it's the one I sort of recommend using. And then the last thing is the bundler and the bundler does, it kind of does two things. One thing it does is it bundles your code, so it's pretty well named. And one thing that it does is it manages dependencies for you and that's part of the bundling process. So if you remember this example I showed where we had this sort of, you know, all these different libraries were being included based on this property that was manually set. If you just use those import statements in your JavaScript code, then your bundler will figure out that you need those libraries, it'll get them for you, it'll get the dependencies of those libraries, but it won't grab everything that's installed and it'll sort of figure out what it needs and then create a single bundle file. And so the other thing it does is, you know, you see on this page there's, you know, 20-some odd different files that might get included and this isn't even sort of a complete example, but it'll take all that stuff and just put it into one file. And so if you have it all in one file, that's fewer requests that your page has to make, which will make your site more performance. And again, there's a lot of bundlers out there, but Webpack is sort of the gold standard and the most popular one. So, yeah, so that was a lot of information quickly, but to put it all together, NPM is going to be our PIP, it's going to deal with all the libraries that we want to use. Babel will take our modern JavaScripts and turn it into browser-friendly JavaScripts and Webpack will sort of take all those things, bundle them together, create this one nice JavaScript file, and we can finally have a Hello World. So, yeah, so that's a lot of effort, but it is worth it and it's a one-time sort of exercise that you have to go through and in the guides, I have sort of very detailed instructions on how you can do all the stuff set it up in a Django project. In terms of putting it into a project, this is a Django example and so you have the whole pipeline there on the left-hand side and then all you really need is that bundle file. So then you just treat the bundle file as any other static file as you would an image or a CSS file and then you do your normal thing with views and templates and then you can use any of this modern JavaScript directly in a Django app or in a Flask app by only just sort of referencing this file and having this thing in place on the left to create it. Yeah, so in practice, this is one way you could structure that and so you'd have your sort of your modern JavaScript source files in a project folder. I called it assets, you can call it whatever you want and then you have some build tooling that takes those and outputs them into your normal static files directory and then everything works sort of the same way and this assets folder, it's never referenced or used by Django but it's used to build your front-end source and you could keep it outside of the project but I find that having it inside the project is nice because then you can sort of do everything at once and really they are sort of dependent on each other. And yeah, so this is what a single page React app then becomes in this sort of hybrid architecture that I mentioned so you have your modern React thing over here it goes through your pipeline and then it gets included in your Django template just as a bundle like this and you can see this like div ID root is in your template and then the React thing knows to go render itself in your root template. So yeah, hopefully that makes sense. I realized I sort of went very quickly through that but there is a much more comprehensive example of this in the guide but that's the basic things of it and then the rest is sort of how do you deal with auth and how do you deal with APIs and all of that good stuff. So why bother with all of this? At the beginning I kind of said it would be worth it and it is you do end up in a much better world in terms of your front-end code base and so what's the payoff? Some things, so you can use the latest JavaScript frameworks and they are quite nice. It's one of those things where it can be a steeper learning curve to start working with them but once you wrap your head around them and once you get comfortable in them and they increase your velocity the experience of building UIs in some of these frameworks is quite a bit nicer than sort of your standard document.getElementById.addEventListener or the jQuery version of that. You get the dependency management so you don't have to do any of that stuff yourself. All of your JavaScript dependencies can be managed in sort of this import-export fashion that I showed in the React example. You get new features and convenient syntaxes which I'll show a few and you get there's a ton of sort of customization that is not in just JavaScript but people who have their own opinions about how to make JavaScript better and you can leverage any of that stuff depending on what you want to use. Hopefully it kind of gets rid of your front-end spaghetti. One of the big things you get is ES6 which is just like the sixth version of ECMA script or something like that but anyway it's later versions of JavaScript and it's hilarious. Basically they just added a bunch of features to make JavaScript more like Python but they are useful. One of the things you get is arrow functions which are basically lambdas and while this looks kind of trivial in the same way that lambdas look kind of trivial like you just change the syntax of this function thing when you write a lot of single-line functions then these become really useful and I'll show you on the next slide why you end up writing a lot more single-line functions. That's a novel concept but yeah so ES6 adds classes to JavaScript the constructor is basically you're a knit function and these work how you would expect. They have something called template strings which are basically F strings so the syntax is similar to F strings except they add a little dollar sign here but you can essentially you can escape this name, variable and brackets and it'll render appropriately and like F strings you can put arbitrary JavaScript code in here like one line JavaScript code so you can do a lot of much more powerful string formatting than the traditional string thing that that we've been doing for so long and default argument values so also just sort of like something that's been in Python forever but yeah so you can have optional arguments and instead of being undefined which they would be in JavaScript they will get assigned whatever the default value is and there's a bunch more stuff as well these were just some of the highlights that I pulled out another thing so this is kind of a react thing so this is that H1 thing that I showed you a while back but essentially it's a language called JSX and it's kind of like string templating for HTML and it's funny at first and it takes some getting used to but it is really nice in that it provides a really easy way to sort of write code that looks like HTML but add business logic inside of it that can do complicated functions and so this would obviously render hello what is it, Harper Perez on your page and this is one place where where those arrow functions are useful if you want to do complicated bindings and other stuff in these templates then you end up using a lot of sort of one line functions View which is another popular JavaScript framework has a different take on this sort of a lot of these frameworks what they're trying to do is they're trying to make it easier to combine HTML with your styles and with your business logic and so View defines this format where the View file is broken into three parts there's a template which is kind of the HTML there's the script area which defines the business logic in here of what's actually going to happen with your data and then there's styles that get applied and one nice thing about this View example is these styles can be scoped which means that the style will only get applied to the Ps in this file so it's a nice way to avoid having clobbering your global styles for a particular component so again this is it becomes a nice way to build UIs in sort of a way that the whole UIs contain together rather than sort of being out in a bunch of different places and yeah and that's honestly that's really the tip of the iceberg I feel like I know maybe you know this top part of the iceberg as well but there's a ton going on in the JavaScript world these days modern JavaScript is actually not so bad and I encourage you to use it and bring it into your Python projects yeah thanks and so yeah like I said if you want to see sort of code samples and anything else you can go to saspegasus.com which is one of my side projects and then just click guides and you'll find like a super long write up on all of this stuff and if you want to find me and I'm CZU on pretty much everywhere but especially Twitter and the zatec Slack cool thank you very much Corey that has made oh that's quite a lot that's enough that's made JavaScript to an absolute novice like me at least recognizable and I see we have a bunch of questions and we have some time for questions I have one question which is any reason for not looking at angular uh no I think if I was going to put if I was going to put a third framework in that in that diagram it would have been angular I have the sense and this might be sort of the JavaScript influence on me but I have the sense that angular is sort of a little bit on the decline these days and react and view are sort of still on the rise but I'm aware that angular for a long time was the default especially project integration I know view was created by one of the lead developers of angular2 and so when the angular2 angular3 fork happened a lot of the people who didn't like where Google was taking angular3 hung around angular2 for a while and then jump shipped a view which which people say is sort of like like a better version of angular2 but but yeah that's that's my short answer I have used angular and I don't have anything too bad to say about it cool, next question any ideas for server side rendering of the dynamic JS code in addition to the Django template code yeah that's something that I don't know enough about actually so I'm going to admit my ignorance there I have the sense that if you get into that world you need to to be back in the Node.js world but I'm not I'm not too sure we've kind of reached the limits of my knowledge on server side rendering cool next question is there a better way of integrating with Django admin run server other than run this npm command in a separate shell yeah um yes and no there are libraries that attempts to solve that problem for you so I think there's something called like Django view loader for example that tries to dynamically sort of compile and put a view like a view pipeline into like directly into a Django template I found that the npm flow has been totally fine and as a personal preference I like using the bare metal tools because I find that often these libraries that have been written specifically for Django like they work really well as long as you don't have a use case that they haven't thought of and then the moment you sort of break out of that it they can be really hard to configure and you end up wishing that you had sort of just started with the bare bones tools that's my experience but I haven't tried a ton of other I've never felt the need to find a better way to do that it's good to know where things are dangerous I should say that it's easy to have you know the equivalent of like how run server auto reloads like it's easy to have that set up in your npm so you can watch for changes in your JavaScript files the experience is quite the same you're just running two processes instead of one but you don't have to re-run the npm command every time you change a JavaScript file yeah cool next question have you ever used or do you know about Dash if so do you have an opinion I have heard of it I have never used it and so I do not have an opinion cool another question hard one test of view components every time I touch it I miss pie test yeah you know my experience with view is somewhat limited I have the sense that that there is sort of a canonical answer to this and if you go into the view docs they have opinions about that but I don't off the top of my head know what the answer is front-end testing is another one of those things that is a big initial investments and I haven't finished to get over the hump on all of my projects but once you get it all set up then the experience of running front-end test is not so bad cool then is ES6 still full of foot guns if you pass more arguments to a function then it accepts I like the expression foot gun it's great yeah I know that they have sort of strict mode and I believe it is intended to catch a lot of those things also sort of like a lot of the common gotchas of JavaScript scoping variables properly and things like that so I think you can run your build pipeline in strict mode and it will catch a lot of those things for you I don't know specifically about that one and whether that's something you can sort of set a rule for cool and one last one I think which is Redux have used it and is it worth using I have dabbled in it not on my own projects but for other projects I think it can be worth using for a big complicated react project my sense is it's just a giant global state dictionary and so for people who know react one of the annoying things is you kind of have to pass state around and push it up and down between parents and child components and I think Redux sort of says no this application has this global state and everything can access to it and so if your workflow so if that sounds like it would be useful for your workflow then I imagine it's worth looking into for small applications I haven't had the need for it cool I think we've some people typing I don't know if there are any more questions oh yeah no thank you very much Cori it's been very enlightening yes I believe we now have a short break before the lightning talks which will be in room 1 so Cori thanks again thank you everyone for listening see you all at the lightning talks thanks everybody