 Hello everyone. Let me first ask a few questions to roughly determine JavaScript proficiency in this room and also to see who thought it was a good idea to come to a JavaScript doc at a Python conference. So how many of you here are doing web development either as a day job or on the side? In most of you, cool. So raise your hand if you've heard of JavaScript and know what it is. Okay, keep your hand up if you've ever written a few lines of JavaScript. Almost everyone, good. So keep your hand up if you've ever used jQuery to use that code. Yeah, almost everyone still. Have you ever used any tools like Bauer, NPM, Gulp or Grunt? Okay, a lot of you, but... Hands are going down. So how many of you have used the front end frame or like Angular, React, stuff like that? Okay, about quarter. And so how many of you know what ECMAScript is? Okay, 20%. And finally, how many of you have used ECMAScript 6 or higher? Okay, then this is perfect. This is the doc for you then. So what I've noticed is that a lot of Python developers either have little to no experience in JavaScript or they have some experience with older versions and like jQuery and simply haven't been able to keep track of all the development and a sea of new tools that have emerged in the recent years. This was definitely me two, three years ago. I would often think that what's been happening with JavaScript is just crazy and that it's impossible to, you know, keep up to date with everything and also somewhat unnecessary. Like why can't I just keep using jQuery if it gets the job done, right? Why are there so many tools that I have to learn suddenly to write a few lines of code? These feelings are well summed up in a post from 2016 called How It Feels to Learn JavaScript in 2016. If you haven't read it, I recommend it because it's both funny and way too accurate. It describes a mock conversation between two developers where one asks for advice about how to build a website that dynamically fetches some data from an API and then the other developer starts describing how to use latest and greatest to achieve this simple task and then simply very quickly the example becomes very contrived. And hearing and seeing examples like that in real life makes a lot of people want to stay away from modern JavaScript and simply go with good ol' jQuery. I totally get those concerns and often they're well founded and then you have some people who will want to stay away from JavaScript altogether because of how confusing and unpredictable it can be. And that's also somewhat understandable. But let's face it, JavaScript is useful and so widely used might as well learn more about it, right? And it turns out it doesn't have to be that scary. In most cases, modern JavaScript is easier to grasp than it used to be and it's cleaner than it used to be. Also, there are a lot of tools that can help you nowadays. So let's get started. We'll briefly go over the history of JavaScript just to understand which versions are out there, how that's progressed. Then we'll cover some basics of the language. After that, we'll take a look at the JavaScript's ecosystem like package management, different tools that you can use, different front-end frameworks and finally some advice on how to make sense of it all. And a quick shout-out to my friend, Ed, who generously gave the idea for this talk. So even though the history of JavaScript is actually very interesting, we won't go into it too deeply because we don't have the time. There's a very cool blog post by Auth0 that describes the whole history and it's very interesting to read. But basically, it was created in 1995 by Brendan... Hey, I don't know how to pronounce his last name, Aik. And it was to be used in Netscape browser, which is the predecessor of Firefox. And apart from the similar syntax and the name, JavaScript has very little to do with Java. But it was named that way because the idea was that developers and corporations would use Java to develop their website solutions and then JavaScript would be its counterpart for non-developers. So they wanted it to sound similar and that's why they gave it that name. It was developed in a very short amount of time, which explains some of its misbehavior and its problems. In 1997, it was standardized as the ECMAScript standard. So it's still the standard we use today and JavaScript is simply the most known implementation of ECMAScript. So when you're using JavaScript, you're actually using ECMAScript. As the years went by, the new versions of ECMAScript were released, ES for short. In 2009, ES5 was released, which is the version you would probably be using if you haven't been trying out any of the latest ECMAScripts, any of the latest versions. It's the version supported by most browsers, even the older ones. Then, as a rough timeline, in around 2010, Backbone.js was released, which was one of the first, I think it was the first, popular front-end framework for developing single-page applications. And this would be the first of many frameworks to come. Anyone here who doesn't know what a single-page application is? Okay. And then in 2015, ECMAScript 6, or as it was later named, ECMAScript 2015, was released, and the release was quite big. It's kind of like Python 3 of the JavaScript world without the breaking changes. It added a lot of new syntax to help write complex applications and to help fill in the missing gaps. It added things like classes, modules, iterators, generators, arrow functions, promises, and a bunch of other things. It's also the release where a lot of us stopped keeping up. This version is well-supported by modern browsers, but not by some older ones or, you know, Internet Explorer. I think it depends, because ECMAScript has so many features that some are supported and some aren't. I can't remember. I think Internet Explorer 11 doesn't support everything. I can't remember exactly. It's always a good idea to check what's supported, but we'll get back to this later. So, okay, on to the language basics. Before I go into this, a few notes. The examples here are using the ECMAScript 2016. Most of them would work with ECMAScript 2015, and some would work with the classic ECMAScript 5, which you're used to. If you're worried about browser support, we'll talk about that later. Since this is JavaScript for Python developers, I will go very quickly over the parts that are similar to Python, and we'll spend a bit more time on parts that aren't similar, which are the interesting bits, I think. Don't forget that the slides will be available online, so you can always go back and look at anything that went by too fast. I don't think looking at a lot of syntax in a talk is not... It's not that interesting, so, yeah, with some parts, we're just going to go through quickly, and then you can look at it in your own time. So, if we just quickly look at the syntax, it kind of resembles Java without all the types and everything, but it shouldn't be too foreign to Python users. It's similar to Python. It just uses curly braces, semicolons, and a lot more parentheses. But it has classes, methods, so a lot of it should be familiar. JavaScript is a dynamic and a weekly type language. This means you can do the following, which you can also do in Python, so a variable can first be a number, then it can be a string, and no one will complain. But because it's a weekly type language, it also means you can do stuff like this, which is just confusing. So, when you define a variable in JavaScript, you have to use one of the keywords. You have to use either var, let, or const. Var is function-scoped, while let and const are blocked-scoped. And additionally, const variable, as the name implies, is constant, so trying to change it will result in an error. Then also, when you define a variable with var, it gets hoisted, which means these two examples do roughly the same thing, so whenever a variable will be defined at the top of the scope, which can result in some... If you're not careful, it can result in some unexpected behavior. So, generally speaking, we want to avoid using var and just use let and const instead. Because, for example, like here, it can result in some unexpected behavior. So, you loop through a list, and then you expect to get ABC, but it instead gets CCC because they all point to the same variable. If we use let in this example, you would get the expected ABC. So, JavaScript has five different simple types, and everything else is an object. Objects in JavaScript are key collections that are immutable. The simple types are boolean null undefined string number. These types are immutable and are object-like in the sense that they have methods. Objects, on the other hand, are mutable, like I said. Arrays, functions, and, of course, objects are all objects. This means that they can have attributes. They can have methods. They can be passed around as parameters. They can be returned by functions. This is very cool because this makes functions first-class, which gives JavaScript the superpowers to be a functional language. That along with the anonymous functions, which we'll talk about in a bit. And if we quickly take a look at the simple types, boolean is what you would expect in a similar to Python. Null is the JavaScript version of none. Then there is undefined, which represents something that is not defined yet versus the empty value, which is null. JavaScript has only one way to encode strings, which is 16-bit unicode, and there's only one type for numbers. There's no special type for integer or everything just uses floating points. Okay, when it comes to objects, there are different ways to declare them, just like in Python, but usually we use the object literal, which is similar to how you would define a dictionary in Python. So this syntax should be familiar, except in JavaScript you can also define methods on an object, and you can also give it anonymous functions and so on. And because objects in JavaScript are mutable, you have to be careful when using them, just like with Python. So if you don't think about it, it can be unpredictable. But once you're aware of, okay, this is mutable, then it's easier to get around it. By the way, sorry about the different styling of codes. I had this whole setup ready for using code snippets in my keynote, and then it stopped working, and I just mixed some styles. So there will be more different styles, and I apologize for that. The operators look similar to Python. They're cleaner in Python, I mean I prefer and or, but these behave as you would expect. You have to be careful though not to use bitwise operators instead. So like you see how there are like two of these. If you use just one, then it's a bitwise operator and it doesn't work. It's not a logical operator. However, when it comes to comparison, you have to be careful because in JavaScript you can do both two types of comparison. The first one, the upper one, will coerce the types, so it can result in some very, very strange things, whereas you should almost always basically use the bottom one because it will check the value and also the type. But if you use the upper one, then you can get some really weird stuff. So just use this one, the bottom one, and you should be safe. There are two main ways to define a function in JavaScript. You can use a function keyword or a fat arrow function. You can define a function globally or inside another function or as a method on an object, as a method on a class. Or for that matter, you can basically define a function anywhere as an anonymous function. And using anonymous functions is very common in JavaScript. So common in fact that it's one of the reasons that the recent JavaScript released arrow functions which are quicker to write and easier to read. You can give the function arguments and you can give those arguments default values. This should all be very familiar from Python. But what's different from Python is that when a function is called it can be called with any number of parameters regardless of how many were defined in the function definition. For example, if this was called with fewer arguments, the rest would be filled with undefined. And if it was called with extra arguments, then those would simply be ignored. A function in JavaScript will always return something. If you don't specify what, it will return undefined. But it will always return something. Isn't this for the case that you just called it? Why is it undefined? So this example had return and then this one doesn't have a return. So this one just does some calculations but doesn't give any return. Doesn't return a value. So JavaScript will automatically return undefined instead. Okay. So in Python we have self when working with classes and objects in JavaScript we have this but it behaves a bit differently. So if we defined a function as a method, this will store the object which is what we would expect. However, if a method will have some anonymous function, we have to be careful as this in the anonymous function would not be the object we want. It would be a separate this. So to avoid it, all we have to do usually is to use arrow functions as that will not define its own this and just use the one that we would expect usually. It depends on the use case but generally speaking, so if we just look at this example like on pets we have a method description and inside the description we are using an anonymous function that returns a string and inside this anonymous function we are using this but it will return undefined. So the way we would solve this prior to ECMAScript 2015 is we would like first store the this value into that or some other naming but that is actually very common. Nowadays though, all you need to do is use an arrow function and this works as expected. JavaScript is prototypal in nature which is in fact a lot more flexible than the object-oriented inheritance model but it can also support the classes that we're familiar with from Python and other languages. It used to be a bit more verbose to be able to implement this behavior but since ECMAScript 2015 it's very easy and straightforward. Modules are easy to use in JavaScript but they do require some kind of a module loader so if you just have a bunch of files in your browser and try to export import things won't work. You have to have some kind of a module loader. This is supposed to change in the future but for now this is where we are. So it's very similar to... the syntax is different but otherwise it works as expected. The difference is you have to use the export keyword when you're trying to export something. So we all love the new F-strings in Python, right? Well JavaScript also offers the similar Bactic template literal and they were actually implemented like one year before the F-strings. It works as you can see a lot like F-string. They can even be multi-line and in my opinion JavaScript needed this way more than Python did because in Python you have some alternatives that are okay whereas in JavaScript this example would have to be implemented like this without a template literal and this is a very common thing to see and it's just annoying to do and very error prone. Okay, a very important feature that is very common and useful is a promise. So a promise is an object that represents a value that is not known at the moment of the creation of the promise but will be known sometime in the future. This is a very useful feature to have because when building web applications this is something we need all the time. Like if you look at the, if you think of a common example when you're trying to get some content from an API if we made that request synchronously everything would have to wait like the user wouldn't be able to click or scroll because JavaScript is single threaded whereas when you create a, if you create it asynchronously then you can just wait for this value to be returned and a promise basically gives you a nice syntax around that where you can say, like you have a promise and then you put dot then and then will resolve when the value is returned. So that should cover the basics of the language. So you might not have seen or maybe you have from this short run through but JavaScript is very expressive, flexible and powerful. It's also quite versatile as it can be used as a functional language, it can be used as an object oriented language and it turns out a lot of frustration with JavaScript comes from misusing the language or when trying to make it behave like the same way as some other language. It of course does have a lot of messy parts which we didn't get to in too much detail. I recommend this book, JavaScript the Good Parts. In some ways it's a bit outdated now because there's a lot of the issues were addressed in the recent JavaScript changes but it's still a very good book and it focuses on the good parts and how to have like a nice experience with JavaScript. But yeah, there are a lot of like global variables that are a big issue. These two operators that we saw earlier can also be very problematic and a lot of other things. But it's a good book, I recommend it. Let me also just mention a super set of JavaScript called TypeScript. Who here has heard of TypeScript? Okay, about half of you. So what TypeScript does is add some features on top of JavaScript. The most important being the optional static typing. So this will then, the TypeScript compiler will then compile this to normal JavaScript but it will give you like compile errors if you have some wrong typings. It's a very useful thing to be using in like a big application. It's quite different than the dynamic weekly type JavaScript but that's why it's useful because it's different from that. So as with any language, the language itself is one thing. It's syntax and you learn that. It's manageable. But the surrounding ecosystem, packages, frameworks, this is where we spend most of our time. And JavaScript's ecosystem is alive and booming so let's look at what's out there. So first of all, let's talk package management. In Python, we have pip and most recently pip-env. In JavaScript, there is npm, short for Node package manager and the competing yarn. They're very similar from the user's perspective but different under the hood. The way we use them is quite similar to pip or pip-env so you also do npm install, npm install and stuff like that and in JavaScript, there is no need for a virtual environment since everything is just installed in local Node modules folder. So you will usually use npm or yarn for installing some development tools or when using some kind of module loader, you can also then import these packages in your code. But oftentimes, and this is great and very useful and very powerful, but oftentimes all you want is a simple package manager for your front-end dependencies. So say you're using jQuery or Bootstrap in your website and you want to manage that in a bit saner way than just downloading this minified script and saving it. And Bower is perfect for that because you can then just... You can also do Bower install and it will save it in a file. The dependencies will be saved in a file and you can import them from your HTML. And so, okay, we have different package managers and we know how to install them. We know how to install different packages. So which are some of the tools that we should be using? One thing I promised earlier is we'll talk about browser support when it comes to the latest ECMAScript features. The tool for that is called Babel and it will basically take your ECMAScript code and transpile it into ECMAScript 5 compatible version or any other version for that matter. This is great because you can start using the latest features today and still have the browser support, which no one can... I mean, we can never ignore that. And so, given the demands for the applications on the web, there are usually a couple of things to be done if we want the application to be production-ready, fast, small in size, supported by all browsers. We might want to minify and ugly-file the code. If we're using a CSS extension, like SAS or less, we need to compile those files into CSS files and many other things. To add to the complexity, there are usually different set of requirements for local development and then for production-ready applications. All of this makes it very useful and important to be able to automate the build process. The tools usually used in the front-end world are grunt or gulp. And if we're using modules and if we want to bundle our source code, so, like, say you have your source code in 10 different files and you want to have just one bundle which you can import in your HTML, you can use Webpack, which will take all your source files, look at all the requirements, look at all the imports, everything that you're using, and give you just one single file. Then there are a lot of different testing tools. Just going through them could be a talk in itself, so I'm not gonna dive into it. There's, yeah, just Google JavaScript testing and you'll find a bunch of tools like Jasmine, Karma, but it's a big topic, so we're gonna skip that. I will get to that in a bit because it relates to another thing. But ask me again if I didn't answer your questions a bit later, okay? Then we come to, arguably, one of the reasons popularity of modern JavaScript exploded, different front-end frameworks. Similarly, as with testing tools, going through different frameworks could be a talk in itself. So let's look at what the point of these frameworks is and what are some general ideas behind them. So if we look historically as the web applications were becoming more and more dynamic and interactive in nature and had to provide richer experience, we were getting more and more JavaScript codes and in order to make sense of that chaos, people started using front-end frameworks. All of these frameworks make it really easy to bind some variables in JavaScript to HTML. Then they also let you define your own components which you can then use in HTML so it's very easy to make some reusable components and structure your code like that. This makes it very easy to create rich interactive experiences for the user without having the awful error-prone and unmaintainable code. Angular and Ember are both full-featured model view controller frameworks complete with routers and anything that you might expect with that. This means you can use them to create single-page applications. React and View are more like the v-part in the model view controller model, but they can easily be extended to be used as a full-featured framework as well. The nice thing about React and View, though, is that you can start using them in your existing application without needing to completely change your whole front-end. So how to make sense of it all? There are a couple of suggestions, but a good idea is just to start somewhere. I know for me it was very intimidating. Like I said at the beginning, it's like you want to write something simple and you look online and it seems like you have to learn 10 tools before you can even write a single line of code. It's usually good if you can take a tool that takes away some of the complexity and you can just start coding and then learn the complexity as you're progressing on each level. If we're talking very practically on how to start using... how to basically up your JavaScript game in your projects is to prepare your code base. What that means is don't use inline JavaScripts. Don't use onclick attributes in your HTML. Put it in a separate JavaScript file. Don't use JavaScript in your HTML file like in the script tag, but put it in a separate file because that will make things cleaner and easier to deal with later on. You can also, like I said, instead of downloading jQuery Bootstrap as a minified file and just saving it, use instead maybe a Bower package manager. And that's a good start. Generally speaking, like when we talk about using stuff like Angular, Ember, ReactView, the general guideline is that it's better to have your back end just be an API and let the front-end framework take the whole control of the front-end. It usually gets messy when you try and mix and match those two, but it can be done if you're using Django. You can use tools like Django Pipeline, Django Compressor, which lets you automate some of the build processes. I think Flask has similar tools, but I'm not familiar with those. And that's usually a good idea to get started. What I found also was that these frameworks are really huge, right? But that's also and very popular, and that's good because they're getting more and more friendly to the newcomers. So Angular, Ember, basically all of these four have their own client, like command line tools. And that actually helps a lot because you don't have to know everything when you get started. So, for example, with React, you have the Create React app, which will give you the whole structure, prepare you your web back, everything that you might need and don't want to deal with right now. And it's the same with Angular, Ember. And this is a really good way to get started in my opinion. It's how I got started was basically just start dabbling in one, like I created a project and start trying things out. And it's great because you can focus on one thing and then when you're prepared, so let me backtrack. So you can focus on one thing because the framework already prepared everything for you. You don't have to worry about what will web back do, what will gulp do, how will you run the server. Like usually all you need to do is create a project and then run server. And it all just works. And this is great because you can focus on the code, you can focus on learning the framework, learning JavaScript. And then when you're ready, you're like, oh, but web back isn't doing what I need it to do right now. And then you can dive into it and make some changes and learn it like that. So it's very easy to incrementally learn these things and dive into it because honestly, I mean, no one has learned all these tools at once. So don't expect that you will learn these 20 different tools at once. I think that's it. Yeah, thank you. Thank you very much. Thank you very much for the talk. We have a few minutes time for questions. So if you have questions, please come forward and take the microphone and ask your question. Hi. I'm very starting to get my hands in JavaScript. So you mentioned something about bootstrap and the good practice or have a package package manager. Can you talk a little bit more about that? So, um, yeah, so if you look at Bower, uh, it's a tool that lets you, um, manage your frontend dependencies. So what, what you'll have is bower.json file which works kind of like, um, requirements.text in Python. So you define your requirements there and then you do Bower install and it will install all these requirements. So instead of you downloading manually a version of bootstrap, you let Bower do that instead. So when a new version comes, you can just do, I don't know the, um, the arguments, but basically you do like Bower upgrade and it will get you the new version. And in your code, you're still importing the same, like it will store all these dependencies in like a, I think Bower components folder. So you'd have Bower components folder and then inside that, you'd have bootstrap and then inside bootstrap folder you would have bootstrap minified, for example. And then in your code, you import that and when the version changes, you still have the same import. Uh, and it's just a lot cleaner and saner way of doing it because it's all in one place. It's easier to maintain. Does that answer your question? Yeah. Yeah. Uh, yes. Thank you for the talk. Um, I'm trying since, uh, quite a bit of time to make Python and Node communicate, especially for, for example, configuration. Uh, usually you have webpack on one side. You have maybe a Python server on the other side. Do you have good practice or ideas on how, um, well, there is two things. How to eventually package, uh, JavaScript code within Python packages and how not to duplicate information between your Python code and your JavaScript code. For example, if you have a Django application how to pass some settings dynamically to JavaScript so you can have just one source of truth on this regard. Um, I don't have like any tips that would be useful for, you know, production setting or anything like that. Um, it's a tricky subject. Definitely. Sorry? Definitely. Yeah. It's a tricky subject and I don't have that much experience with it because I was all, so, it's great if you can simply have two, two different projects, right? But you're asking what to do in case when you, when you can't have that, when you want to mix, mix them. Yes. And I don't have that much experience with it because so far I was always lucky to be able to separate them and it made things much easier. Um, when I didn't, when I wasn't able to do that, um, I helped myself with, like I said, Django, I think, pipeline, tools like that. I didn't like the solution at all. Um, so like I said, I don't have any good tips for you. Uh, if you'll develop something, I'd love to hear about it because I think, and I think a lot of people would, okay. Um, I'm not sure if it solves your complete problem, but, um, maybe part of it. Uh, I've written a tool that enables you to package some files as a, uh, PyPI package. And so you can just require it in your Python project and it will pull in that other package. It's called X Static, this project. And it will just drop a bunch of files at some place and you can just use them. It's, it's only a very, very simple tool, but at least the packaging part is maybe solved by that. X static on, on PyPI. Thanks a lot, Zahn. Um, I don't want to use JavaScript and I never plan to write any, but, and also, as you rightly said, you don't want to jump in and learn everything at once, but the only time I need to encounter JavaScript is when I'm trying to debug something else everything opens up in all these different directions and many of them are obscure and you don't know which things are implicit that are a proper developer of JavaScript would know about. Do you have any advice for somebody in that kind of situation? I mean it's, if you have to do it then you just have to learn about it. I mean, think about from the other way around like a front-end developer that would want to debug some Django code would also not know what, what's implicit why does this load this file automatically? So they would also have to learn a bunch of things just to be able to debug. It's a bit trickier with JavaScript, definitely, for sure. I mean, it's hard, you're asking me how to, you know, how to find a shortcut and I'm not sure if there is one. I'm sorry. There's no such things as free lunch only at the conference. Yeah. Okay, yeah, I think we have some questions. Thank you very much.