 So yeah, Pythonic JavaScript for web developers or how to get modern JavaScript into your already existing Python projects would be the almost more aptly name. So good hello, my name is Ville, aka Uninen and like Python I like DJing and both are my passions in life and past year I have been working with JavaScript but I've been working on web since 1995 and with Django over 11 years so I already feel a bit old here. I code for fun and sometimes for work but I don't really consider myself as a programmer per se. I work mostly with small teams and as a project manager and tech lead. And like I said last year I worked, spent with a small finish startup, bootstrapping a five person team, development team with agile methods and writing JavaScript and this was my first contact with real JavaScript if you will. And I learned a lot and I think I learned stuff that maybe some other persons would like to know also and that's why I wanted to give this talk to you. So let's start with you. How many of you have heard at least one of these terms? Okay so almost all of you. How many of you actually know what they mean? Okay a little bit less. So the idea of this talk is to give a really basic introduction to modern JavaScript and related things. The call of this talk is to get you an idea what's going on with modern JavaScript and to get you enough knowledge to get started with writing good stuff and also to learn where to learn more. So according to Wikipedia 95% of the top 10 million most popular web pages use JavaScript. That means that you actually need to know it even if you work in the back end. And unfortunately we are at the Euro-Python, we are Pythonists. So why or why does JavaScript need to look and feel a little bit like this. I.e. not very friendly or beautiful. So to get a little bit perspective let's take a look at the history. I think I skipped a few. So JavaScript was developed basically in 10 days in 1995 when web looked like this. And to compare Python was at the moment in version 1.2 and Netscape Navigator was just released 2.0. And fast forward a few years in 1999 web looked like this and our JavaScript was forwarded to version 4 which was on par with Python 1.5. And based on the news article I found there everything else were worse except the presidential problems. We have been using basically the same JavaScript since then even now when our web looks totally different. And this is why the definitive book of JavaScript is really huge and the good parts of the JavaScript is not so huge. This by the way is a good book and worth a read if you want to learn the good parts of JavaScript. It talks about functions and loose typing and dynamic objects and stuff like that. But there's more. So recently there was yet another version of JavaScript called ES6 or ES2015. ES stands for ECMAScript which is the standard for JavaScript. And these new features are basically moving the language in really, really good direction from the programmers point of view. We are getting latent const variables which mean that you can actually now have not global variables and you can have constants. You have real classes, object literals, better object literals. You have modules, iterators, generators, map and sets and promises, template strings, destructuring and as a way under weight. So it pretty much already starts to look more like Python and more like a proper programming language. And if we then go back to the way that we have used, at least I've used to develop JavaScript, which I call here the old school way. It's basically just adding jQuery to the site and then some script tags and that's about it. And this is the whole life that I've been working on the web. This has mostly been the state of JavaScript on the web and on the projects I've been working. And fortunately we now do have a better way as Raymond Hedinger would want to shout at this point. So the modern version is way more complex for obvious reasons. We now live in 2017 and our web apps and web pages are constructed in more complex ways and the JavaScript part adds to it itself. We start with NPM, which is a package manager for JavaScript and it's the world's largest software registry, which is open source but the registry holder itself is a incorporation. So that's a kind of interesting thing right there. Anyways, NPM gives you a file called Package Chasen, which is basically requirements TXT for your PIP in Python. And NPM has dependency tracking and stuff like that, so you can actually know what versions you are shipping with your product. Then we move to transpilers, Babel is the one usually used. This transpiles your new code when you move things to production to old code that most browsers can understand back to the ES5 or even ES4 and we need to use that because browsers and IEE and stuff like that. But Babel is with our JavaScript stack. Then linters, if you want to get really busy with JavaScript and be good at it, you need to lin to your code. In my opinion, it makes your coding experience but also reading the code and doing code review and stuff like that. Way more pleasurable as you know that you can maintain standards. ESLint is a JavaScript linting package, which is in my opinion way better than Flake 8 for example. There are at the moment no official guidelines like PEP8 but there is a project called JavaScript standard style, which is a NPM module you can install and it has standard recommendations also. For the moment I think the most used standard style or most used coding guidelines are Airbnb coding guidelines. By the way, I have links to everything I'm mentioning here and I'll give you a link at the end of the talk. Then we have lots of different JavaScript modules and packages and we need to ship them out. Webpack is at the moment one of the most prominent tools for that. Webpack also does lots more. We've also already had a talk here at the Europe by talking about Webpack. It's a really powerful tool but it's also quite complex and still not very stable, at least in my opinion in like documentation terms and stuff like that. So when you bundle your assets, you need to invest a little bit time to get this one going on. Also at this point you probably want to collect and bundle all your other static day assets like CSS and SAS and stuff you want to pre-process and Webpack can do that for you too. Also Webpack includes some kind of pretty amazing stuff like tree shaking, which automatically can eliminate some dead code from your JavaScript that's not included in the production bundle if you just configure it right. Then after all these like build tools, you of course want to use some framework. This is the same kind of deal that usually when you start a Python project, you probably don't want to start from scratch. You select your favorite framework and start working. So the top three contenders in my book are Angular, React and View. If in your company one of these are already in use, use it just use that or if you know one already just use that, it doesn't really matter. But in case that you are not familiar with any framework so far, I would warmly recommend View, which is a... I've been working with View a lot and I've also been working with Django a lot. I think View is a little bit like a child of Django and Flask. Only it changed its gender to JavaScript. So it's really easy to get started. It has good documentation, which is unheard of in JavaScript world. It's lean and fast, but still robust enough to get you going with the really big project if you need to. And it has View X, which is kind of React, Redux kind of a data model too if you need one. So these new shiny things require new tools and they require new configuration, which is obviously kind of a pain in the butt. And whenever I usually have needed to delve into JavaScript configuration, I end up to the wrong page in Google and it makes me shame of myself and the world. So to help with that I have created an example project that uses Django and this stack I mentioned. And I just pushed it on the GitLab project, but it's not quite there yet, but we might have time to look at the code really quickly. The idea here is that you can get an idea what you need to get started with this kind of stack if you don't know what's going on. Examples from the JavaScript world with using the kind of frameworks like Django are really, really rare or they are non-existent and definitely no documentation exists anywhere. So I think this will help you to start away if you want to. So what about the actual topic of the talk? What is Pythonic JavaScript? This is by the way a real sign from Norway. I was very pleased when I saw that. Obviously this is a quite opinionated list. This is my opinion and your mileage may vary. But for me, Pythonic code is something you feel rather than measure. I think this comes down to the talk we had about beautiful code and I think Pythonic is a little bit same. But from JavaScript perspective, I think bundling your code into packages and into modules is the first thing you need to do. Namespaces are a honking great idea and stuff like that. So just use NPM. How many of you have worked with code like this in HTML when you have loads of script tags importing something and then in the HTML itself a script tag which has the actual code I have. Yeah, so most of us. The better way of doing is to put everything in one file with ES6 plus syntax and start with using strict mode. It prevents you from writing bad code and disables some bad features of the language and then you start importing the libraries. This first import is a require function which is a Node.js function. This is not native JavaScript. Some of the older libraries and some, well, some libraries still need this require and won't work well with the native imports. But some do, and then I added just to point out that it still might be hairy that sometimes you need to explicitly set something to window because some libraries just don't work, but this is what it is. And then you have the native module imports. Native imports in JavaScript look quite familiar for Pythonists and this is actually I really enjoy when I see this kind of JavaScript code. And the last one, we put everything, our code itself in ify, which is immediately invoked function expression, akafe. So everything puts in to here, won't leak outside. And now that I, after I wrote this, I figured out that when we are actually writing new JavaScript, it doesn't matter so much, but this is the way the old schoolers like to do it. And then at the end, it gets, the program gets run. So all you need to do on your HTML is add the one minified and ugly-fied and stuff JavaScript file that was bundled with Webpack. So that's the first thing. You bundled your files and instead of doing multiple imports and stuff like that, you collect MPN packages and you handle them in one place. That's kind of a way of working that we have been used to in like proper programming languages and now we can do it in JavaScript too. So that's kind of nice. Coding guidelines and the linking stuff is really important in my opinion. JavaScript obviously doesn't work like Python, which in Python, you can read other people's code quite easily. In JavaScript, you can't unless you have really good guidelines on how to write your code. So if you write, for example, for your company and you have several developers in your team, it really helps a lot if everybody writes consistent code and after you check the code in to the repository and it's been peer reviewed, no one should be able to tell who wrote the code. And when you link the code, it's quite easy to do and a strict code review, of course, helps. It's amazing how much better looking and better feel you get to a JavaScript file without doing anything else, but just like arranging it differently via the coding guidelines. It's amazing. And then the maybe obvious, maybe not thing, but semicolons are optional in JavaScript. So in my opinion, why use them? We are transpiling our code, so the transpiler adds them where it needs to automatically. Even if we do use them or don't use them, the transpiler doesn't care, so why should we? So like those list parenthesis, these might be elegant weapons like your father's parenthesis, but we don't need them, so let's not use them. So to recap, Python JavaScript in my opinion is modular. It consists of packages just like your Python project. It has a package JSON. You can import stuff there. You can keep separate projects in separate repos if you want to. It's testable and it's tested. You can actually test the code when you write it this way and it's easy to test. This is a big, big thing. Even if you have that one small JavaScript file in your project, if you write it this way, you can actually test it and then you know that when you change your Django model or whatever, when you run your front-end JavaScript tests, if they don't break, you are losing less sleep when you are pushing things to production. And when you link the code, it actually looks good and it looks similar to everybody else's code. And extra bonus, it's semicolon free. So I'm not really sure how much time we have left. 20 minutes. We can do at this point, I think, a short demo of the code I pushed. If I find my cursor from somewhere. Is it in? Nope. Here we go. Oops. Yes. Now we are sharing the same screen. So let's do this. Can you see this? All right. Let's start with the project. So this is the demo project. It's not quite finished yet, but it's just a basic Django skeleton with one app. And it has some static files. It has SAS file and a JavaScript file. The SAS file, how many of you know SAS? Okay, almost all. So SAS is a CSS kind of thingy that you can preprocess to CSS. We use this to render the CSS for the demo page, which looks like this. Just a really, really simple HTML page. And the whole JavaScript here is here. So if we go from top to bottom, we are in strict mode, and this hot module thing is a webpack helper. That is actually quite awesome thing. When you develop with webpack development server and you change your JavaScript code, the code gets updated in the browser automatically, and it doesn't mean the Django run server kind of refresh the whole page. It just refreshes the JavaScript, and it keeps the state. So imagine developing a huge JavaScript one page app that has loads of states, and it just changes one little thing. You don't need to refresh the page. Everything stays the same, and webpack just reloads it for you. Then we are using Vue and jQuery, and we are using the cookies module because we want to use this Ajax post method from jQuery with Django's CSR token. In the requires, this is pretty weird thing about webpack that I personally don't quite understand nor like, but if you can require anything that webpack can read. If you have a plugin for SAS, you can require SAS, but it just eats it for you. So if you want to do CSS or SAS with webpack, you need to require the files. And then the actual code is really simple Vue instance. So you attach the Vue instance to any HTML element, and this one has data element, so it's just like object variables here. This is totally not finished or even thought out yet, but I put something to get started. Computive methods are, think of them as Python properties, so this total sum acts like a property that automatically updates when you're variable updates, and then you have methods that are methods. We also have in Vue these special methods like created, which, as you might guess, gets run when the instance is created. At the moment this doesn't do quite nothing yet. It gets hooked into this main container, and then I think we have here, we have this V dash model, which is, where's my hard to see this one here. When we change V model in the form itself, it automatically updates in the Vue instance, and this would be really better if I could show you the actual page, but I think I'm not going to get it running at this point before we run out of time, but the idea here is that to get Vue going, you only need this really, really small instance of clean and easy to read and understand JavaScript, and other point here I wanted to explicitly made is that you can use it with your existing jQuery thingies. You can have your page full of jQuery thingies, but you can just add the Vue thing right next to it and it just works, or you can start with the clean slate like we did here and just do it. There's one more special thing here. This is something I wrote for myself as a helper for the webpack and production pushes, because we might next want to see the webpack config, so here we have webpack config, which is a JavaScript module that actually just requires another module based on the end variable we give it from the command line, and if we have dev end, we require some webpack things first and some plugins, and then we get git hash, explain it in a minute, and then webpack wants entries that it reads, and I've imported them from here, so you might have, we only have here just one JavaScript file, but for example in a typical Django project, you'd have one or two JavaScript files for every Django app you have, for example, and you can grow this list as large as you want, and webpack just, with this notation, you get one file for each entry, and you can bundle those entries too, and it gets really complicated, this is really, really simple stuff here, and for caching and for ease of production pushes, we use git hash in the bundle name, so automatically when you push your code and then build the static assets with webpack, the assets get named with the git hash, and then there are some dev server things and rules how to use JavaScript, what to do with JavaScript files, use them with Babel, and then there are test for view files, which we didn't get to see yet, and then there are SAS files and a list of plugins, and if I show you really quickly the template tag, I wrote the idea here is that in the template tag we do the same thing, we get the git hash and then the template tag outputs the script name for us, so in development we can use this demo file or in development we can have it on local server and in production wherever we want, and it just works automatically. So this is something you'll find from the git repo, I uploaded, and now if we can quickly back into the presentation to recap, semicolons in JavaScript are totally unnecessary when you use transpilers, note when you don't use transpilers, it's not 100% but it's 99% sure, but if you use transpilers, if you build this tag, it's pointless to use semicolons. There are tons of good tools and packages for JavaScript, so don't write stuff yourself, don't reinvent the wheel, the NPM is full of good stuff, also unfortunately bad stuff, there are easy to use frameworks and there are hard to use frameworks just like there are in Python, and turn on linting to every project, and it kind of is lipstick on a peak, but hey, that's JavaScript, but with good tools, you can actually have quite fun with JavaScript too. So yeah, when you do it like this, you can automate everything, you can have it in your production, QI builds just like every other language, so investing to this is a good thing, that's about it, thank you. Do we have time for any questions? Yes, we have time for questions, so any questions? No questions, there must be some. Yes, it's only a little question. When to use a require and when to use import? That's a good question. Use require when the import doesn't work basically. JavaScript packages are really, really poorly documented, but if the package is good, it works with import, if the package is older, it probably doesn't work with import, but if it uses like right spec, it just works with import, but you need to look at the documentation and basically almost every time you need to look at the source, because there is no documentation, so yeah, that's JavaScript for you, but that's a really good question. When you build your own stuff and when you try to evaluate what packages you want to use, select those that are like you can use with native imports and modules, because they are obviously better written and maintained. Hello, thank you for the talk. So there are certain actual Python, Python but then into web compiles. Okay, have you ever considered that for actual production use or just for sheds and giggles? I got to eat lots of those frameworks and I didn't even know that they existed. There are interesting takes on the topic and I think that if that's your thing, you want to write, for example, if you like TypeScript and that kind of stuff, then it might be for you and why not use it in production if it works. So I myself haven't wanted to go down to that route because I think the tools that are built with JavaScript, when you have the stack working, it works really well and all the tools and all the IDEs and stuff like that and debug tools and stuff like that already work, so I don't quite need to feel the need to keep in Python in that low level, but if it works for you, great. I would like to know if some big project actually uses that kind of transpider. Any other questions? No, thank you. Okay, thanks again.