JavaScript for Python Developers
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 50 | |
| Author | ||
| Contributors | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/44065 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
DjangoCon US 201821 / 50
2
5
7
8
13
18
20
21
22
35
41
44
45
47
00:00
Software developerInternet service providerVideoconferencingInformation technology consultingForcing (mathematics)Online helpFamilyWeb 2.0Front and back endsComputer animation
00:45
Power (physics)Random matrixPlotterProcess (computing)Inheritance (object-oriented programming)State of matterSubsetMultiplication signGame controllerDependent and independent variablesComputer animation
01:52
Power (physics)SubsetScripting languageProcess (computing)Projective planeComputer animation
02:48
Scripting languageComputer fileTemplate (C++)BootingScripting languageWeightCoefficient of determinationSingle-precision floating-point formatWeb applicationSoftware developerCartesian coordinate systemProjective planeSoftware frameworkCodeLine (geometry)Template (C++)Connectivity (graph theory)Complete metric spaceDifferent (Kate Ryan album)1 (number)Module (mathematics)Local ringRouter (computing)Data managementVirtual realityFlow separationMereologyRevision controlWeb browserComputer fileSoftware testingVirtual machineCombinational logicNeuroinformatikVariable (mathematics)Front and back endsGoodness of fitArtificial neural networkKeyboard shortcutSet (mathematics)Order (biology)Mobile WebProcess (computing)InternetworkingDefault (computer science)Perspective (visual)Web 2.0Product (business)Chaos (cosmogony)Fiber bundleComplex (psychology)Content (media)BootingInteractive televisionPower (physics)Web pageCASE <Informatik>Endliche ModelltheorieJava appletComputer animation
09:48
Power (physics)Remote procedure call2 (number)Transport Layer SecurityMultiplication signPRINCE2CASE <Informatik>Computer animation
10:32
Transport Layer SecuritySource codeFormal languageMereologyProcess (computing)Scripting languageComputer animation
11:15
Formal languageComputer programmingUser interfaceEmailVideo game consoleFunction (mathematics)String (computer science)Lambda calculusVariable (mathematics)LogarithmCodeComputer fileDecision theoryFunctional (mathematics)Scripting languageMereologyComputer programmingFormal languagePhysical systemStatement (computer science)ImplementationBlock (periodic table)Complex (psychology)Online helpBit rateAlgebraic closureStandard deviationCartesian coordinate systemVariable (mathematics)2 (number)MathematicsScaling (geometry)Slide ruleJava appletRight angleVarianceWeb browserSign (mathematics)Revision controlWebsiteECosSocial classLetterpress printingProgramming languageType theoryMultiplication signObject (grammar)Electric generatorWordSoftware developerModule (mathematics)FamilyCodeError messageDifferent (Kate Ryan album)1 (number)InternetworkingProgrammschleifeSet (mathematics)Arrow of timeBitSinc functionComputer animation
18:22
FaktorenanalyseBinary multiplierDivisorString (computer science)Type theoryBoolean algebraFunction (mathematics)Array data structureCodeOperator (mathematics)Video game consoleElectronic mailing listFunctional (mathematics)DivisorScripting languageDoubling the cubeCodeEqualiser (mathematics)Equals signSoftware developerPoint (geometry)Arithmetic meanFunctional programmingFactory (trading post)Flow separationInstance (computer science)Object (grammar)NumberBitCausalityResultantData typeDifferent (Kate Ryan album)Block (periodic table)DecimalRevision controlMathematicsIntegerBinary multiplierParameter (computer programming)Multiplication signElectronic mailing listSocial classProcess (computing)Order (biology)Descriptive statisticsDefault (computer science)AbstractionState of matterCodierung <Programmierung>Pairwise comparisonFunction (mathematics)String (computer science)Line (geometry)WordType theoryArrow of timeOperator (mathematics)Java appletKey (cryptography)VarianceLogicLoop (music)Expected valueBoolean algebraComputer animation
25:29
Letterpress printingSocial classVideo game consoleModul <Datentyp>Template (C++)Structural loadElement (mathematics)Error messageMenu (computing)CodeRange (statistics)Object (grammar)Descriptive statisticsFunction (mathematics)Structural loadFunctional (mathematics)Natural numberElectronic mailing listSocial classFormal languageProcess (computing)MereologyObject (grammar)Scripting languageComputer-assisted translationWeb pagePrototypeJava appletExterior algebraMultiplication signElement (mathematics)Module (mathematics)System callBuildingError messageDifferent (Kate Ryan album)Inheritance (object-oriented programming)Computer clusterThread (computing)Software developerWave packetHardy spaceArrow of timeCodeBootingCartesian coordinate systemBitAttribute grammarWordOrder (biology)String (computer science)Similarity (geometry)Endliche ModelltheorieBlock (periodic table)Object-oriented programmingWeb 2.0WritingKeyboard shortcutTemplate (C++)Computer animation
32:36
Rule of inferenceMultiplication signChaos (cosmogony)MereologyJava appletScripting languageComputer animation
33:13
Codierung <Programmierung>Revision controlScripting languageSystem callMereologyException handlingFormal languageCausalityECosRight angleTask (computing)Physical systemSoftware frameworkProcess (computing)Form (programming)Goodness of fitError messageIterationPoint (geometry)Different (Kate Ryan album)Operator (mathematics)Order (biology)Web pageJava appletForcing (mathematics)Group actionGoogolCodeWave packetConnectivity (graph theory)Source codeRandom matrixBit rateElectronic program guideSoftware developerElement (mathematics)Disk read-and-write headWeb 2.0Arc (geometry)QuarkLocal ringGame theoryMeeting/Interview
42:33
HTTP cookieProcess (computing)Software frameworkDescriptive statisticsDifferent (Kate Ryan album)Lecture/Conference
43:06
Coma BerenicesInternet service providerData typeXMLComputer animation
Transcript: English(auto-generated)
00:17
You all had a good lunch. My name is John.
00:20
That's me. I'm here. I'm hiking with my family near my hometown. I'm coming here all the way from Slovenia. And no, that's not Pennsylvania. That's Slovenia. I get that a lot. I'm a consultant and a full stack web engineer. And if you need some help to make sense of your front end and back end needs, or if you need someone
00:42
to mentor your junior folks, please come say hi. Yeah. OK, let's start by taking a short trip to Arendelle. Yes, I mean the kingdom from the animated movie Frozen. Specifically, let's talk about the queen of Arendelle, Elsa. Now, if you've seen the movie,
01:00
you'll know how the story goes. Elsa is born with some magical powers, which as a kid she uses to play around and do cool stuff. Soon, she realizes that she's way more powerful than she imagined. One time, she even accidentally injures her younger sister. Her parents warn her that she needs
01:21
to learn how to control her powers. Otherwise, she'll be a threat to herself and others. They try to do the best job they can to help her with that, but unfortunately, they pass away in a horrible accident. So now, teenage Elsa is left to figure out how to control her amazing powers all on her own. Fast forward a few years.
01:41
Her powers get out of control, and she puts the whole kingdom in a state of eternal winter. Again, fast forward a bunch of challenges she has to face and a few plot twists, and she finally learns how to control her powers. It's not with hiding and controlling. It's with acceptance and love.
02:01
And then later, her Uncle Ben came to her and told her that with great power comes great responsibility. Sorry, wrong movie. Okay, so why on earth are we talking about Elsa in this JavaScript talk? Well, we, my fellow Jenga-nauts, are a lot like Elsa,
02:22
and JavaScript is a lot like the powers that she has. Here are some amazing and incredible things that we can do with JavaScript. But there are some amazing and incredible things that we can do with JavaScript. But if we're not careful about which tooling we use, how we include it,
02:41
how we use it within our Django project, it can easily blow up. So let's go over that stuff real quick. JavaScript's ecosystem is kind of astonishing in both good and bad sense. There's a great talk by Ofer Vishna called Wait, You Can Do That With JavaScript.
03:04
It showcases some awesome things that you can do with JavaScript. You know, you can do front-end, back-end, we all know that, but he also talks about how you can do mobile development, stuff like VR and AR. And let me just show you my favorite example
03:21
of what you can do in JavaScript. Hopefully this will work. Now, all of this is implemented in JavaScript, and it uses a neural network in order to predict or to continue the melody that you just played. So if we play something like,
03:41
I think that's so cool.
04:02
But of course, all of this comes at a great cost. It can be really hard to navigate so many packages. It's hard to decide what to use, when to use, and it can also feel like, why are there so many tools that I have to learn before I can write a single line of code? Now, a lot of that is hype,
04:21
and a lot of the problems also come from feeling that you have to use and learn everything at once. You don't. If you know about these few ones that I'll mention, you'll have all the basics covered, really, and you don't need to use them all at once. Use them when you need them. So first of all, let's look at the package management.
04:42
In Python, we have pip and more recently, pipenv. In JavaScript, there is npm, node package manager, and the competing yarn. They're very similar from the user's perspective, but are different under the hood. The way you use them is quite similar to pip, and there's no need for a virtual environment
05:01
because everything is installed in the local node modules folder. So you can use npm or yarn for installing any development tools or any packages that you are using within your JavaScript project. Then we have this thing called Babel. This is useful when you want to write your code
05:22
in the latest version of JavaScript, but also want to support the older browsers. So it's kind of like if you wrote all your code in Python 3, and there was a tool that transpiled that into Python 2 so that it could be used on machines that don't support Python 3. Now, I know it's not a perfect analogy,
05:40
but that's the gist of it. That stuff's really important when it comes to JavaScript because you have countless different combinations of browsers and computers that your code has to work on, and Internet Explorer. Given the demands for the applications on the web, there are usually a couple of things to be done
06:02
if we want it to be production-ready so that it's fast, small in size, and supported in all browsers. We might want to minify and uglify the code to get the smaller sizes. If we're using something like a CSS extension language like SaaS, we need to compile those files into CSS,
06:23
and many other things. To add to the complexity, there are usually different set of requirements for local development and production-ready applications. All of this makes it very useful and important to be able to automate the build process. The tools usually used for this are either Grunt or Gulp,
06:44
and if we're using modules, like we also want to bundle our code into a single file from separate files, we can use Webpack, which is very powerful and sometimes difficult to understand.
07:00
Then there are a ton of different testing tools. Just going through that would be a talk in itself, so I'm not gonna do that at all. Then we come to arguably one of the reasons for popularity of the modern JavaScript, different front-end frameworks.
07:20
Similarly, as with testing tools, going through them would take a whole new talk, so let's just look at four of these, and what's the general idea behind them. As the web applications are becoming more and more dynamic and interactive, in order to provide a richer experience, we're getting more and more JavaScript code,
07:42
and the underlying HTML is simply not enough. So in order to make some sense out of that chaos, we can use the front-end frameworks. All of these frameworks make it really easy to bind some variables to the HTML. They make it really easy for you to define your own components that HTML doesn't have by default,
08:03
some custom components, and then you can use that and make nice reusable code. Angular and Ember are both full-featured MVC frameworks, complete with routers and everything. This means you can use them to create single-page applications.
08:22
React and Vue are more like the V part of the MVC. They can still be used as full-featured framework as well but the nice thing about those two is that you can use them in your existing applications without changing everything about it. So when it comes to JavaScript and Django,
08:42
there are a few different ways that they can be combined. Possibly one of the best way, especially for larger projects with lots of interactivity, is to have the whole front-end as a separate project. So in this case, you could use one of the frameworks I mentioned
09:00
and use Django just for the supporting API. I have a lot of good experiences with this model, as do other people. Another way is to have JavaScript within your project. With that, if you wanted to do some additional processing of your JavaScript code, like bundling, uglifying, or whatever,
09:20
you can either make use of all the JavaScript tooling that I talked about or you can use Django loaders, pipelines, and such that will hide the JS tooling from you. Personally, I prefer the former. And then finally, if you just want some minimal JavaScript in your project without any additional stuff,
09:41
the very least you should do is put your JavaScript in separate files. It doesn't belong in your templates. Cool. You're now on a great way to start controlling your powers. Congratulations. Okay, so let's talk for a second about the story of Beauty and the Beast. Now, we've all heard the story.
10:02
There is this scary beast living in a remote castle, and Belle somehow ends up trapped there, and the Beast won't let her go. As time goes by, Belle learns more and more about the creature and gets to know it. She realizes the Beast ain't that bad. After a while, she even falls in love with him.
10:23
And then when they kiss for the first time, we find out that the Beast was a handsome prince all along, spoiler alert, but was turned into a beast by some awful curse. Again, why are we talking about some fairy tale at a JavaScript talk? Well, it turns out JavaScript is a lot like the Beast.
10:41
It seems scary, irrational, but if you just get to know it, you realize there's actually something great inside, a powerful, expressive language. It's hidden somewhere in there. Now, is JavaScript the Beast without its flaws? Absolutely not. Is it justifiable that it kidnaps us and takes us hostage?
11:03
Of course not. But then again, the fault is not entirely its own. Douglas Crockford, the guy who wrote the book JavaScript, the Good Parts, once said, JavaScript is the only programming language that people don't bother to learn before using.
11:23
And I find that very true. Think about it. Have you heard of Zen of Python before? Have you heard of this thing called the Pythonic way of doing things? Of course you have, because you put effort into actually learning the language before using it. But with JavaScript, it's very often very different.
11:44
It gives you a sense of, oh, it's such an easy language just because it tries to be lenient. And yeah, that gives you a false sense. And it's actually not that easy. It's easy to get started and to do some basic stuff, but if you actually want to design
12:01
the whole systems around it and build something, that takes time and effort. So why don't we do that right now? Why don't we take the next 15 minutes and go over the basics of the language? We won't be able to cover everything, but it should give us a good idea of how things work. This might go fast, so feel free
12:21
to go over my slides later and try some of this stuff in your browser's console. That's the best way to learn about this stuff. And don't worry if you don't get everything right now. Before that, let's have a quick word about different JavaScript versions. The whole history of JavaScript is really interesting and fascinating,
12:40
but unfortunately we don't have time for that. What you need to know about is that JavaScript is a language standardized by the ECMAScript standard, ES for short. And JavaScript is its most known application, implementation, sorry. Throughout the years, new versions of ECMAScript have been released.
13:01
The version that is supported even by the older browsers, like Internet Explorer and stuff, is ES5. If you've never tried any of the newer versions or have no idea what I'm talking about right now, that's the one you're familiar with. In 2015, ES6 or ECMAScript 2015 was released.
13:23
And the release was quite big. It was kind of like Python 3 of the JavaScript world, but without the breaking changes. It added a lot of new syntax to help write complex applications and fill in the missing gaps. It added things like classes, modules, iterators,
13:41
generators, arrow functions, promises, and a bunch of other things. This is also the release where a lot of us stopped keeping up. The version is well supported by modern browsers, but not by older ones. After that, there was one release per year with more new features, but not nearly as big as ECMAScript 2015.
14:05
So okay, let's do this. The examples I'll show are using ECMAScript's 2016, but most of them would work with ECMAScript 2015, which I just mentioned. And some would work with the classic ES5. Since this is JavaScript for Python developers,
14:22
I will go very quickly over the parts that are similar and spend more time on the parts that aren't, which I think are the interesting bits. And this will be a handful, but nothing that we can handle. Okay, let's get right to it. The syntax somewhat resembles Java,
14:41
but shouldn't be too foreign to Python users. It's similar to Python. It just uses curly braces, semicolons, and a lot more parentheses. So JavaScript is a dynamic and weakly typed language. This means that just like in Python, you can do the following,
15:00
but because it's a weakly typed language, unlike Python, it also means you can do stuff like this, which doesn't always make sense. So when you define a variable in JavaScript, you have to use var, let, or const. Var is function scoped,
15:20
while let and const are block scoped. Additionally, const variable, as the name implies, is constant, so trying to change it will result in an error. And let's talk more about scope, because we don't really think about that in Python. So Python and JavaScript are similar when it comes to function scoped variables. So if you look at the first example,
15:42
it works as you would expect it, and variable b is not defined outside of the function. But unlike Python, JavaScript also knows of a thing called block scope. And this is also used in other languages. Block is defined by a set of curly braces. So that means for and while loops,
16:02
if statements, and so on, that's all blocks. If you're using let or const, those variables will be defined only within that block, but not outside of it. And this is different from how Python does it. If, however, you used var to define the variable, it would behave the same as Python.
16:22
Usually we want to use let and const, because that's, other developers might expect that as well. So, okay, function versus block scope is easy to work around, but there's a way bigger problem with JavaScript scope, and that's its global scope.
16:43
So every JavaScript code that runs on your website can define thing in the global scope. Even if it's two separate files, they will share the global scope. This can be useful in small programs and not really that big of a deal, but it's very dangerous and error prone as the site of the program grows.
17:03
So it's important to package your code into modules, classes, objects, enclosures. You do not want to pollute the global scope. That way, you should minimize the global footprints and make things a lot saner. So, by the way, if you ever define a variable
17:23
without using var, let, or const, the variable will automatically be assigned to global scope, which can be a real problem. Okay, and since we're talking about var, let, and const, yeah, like I said, generally speaking, you should avoid var. That's because variables defined with var are also hoisted.
17:44
So use let or const instead. Hoisting, which is something we're not familiar in Python, is it means that the two examples here are interpreted in the same way. And this can lead to some unexpected behavior if you're not careful. So this is a simple example showing
18:01
why hoisting can be problematic. So here we have a variable x that's assigned a value 10. Then we define a function func that prints out the x. Then there's a lot of code. Then it defines a variable x. And then, again, it prints out the variable x.
18:23
Now, it's not complicated, but imagine that there's a lot of code in between, or that the x on line five is added later by another developer. So what happens here is you get undefined first, and then you get five because of hoisting.
18:44
So with all that knowledge, here's a riddle for you. Here we have a code. We have a list of factors, two, four, six, eight. We have an empty list of multipliers. And then we iterate through the list of factors
19:01
and add an anonymous function which will take an argument and multiply it by the factor. So if we look at the output of the last line, what do you think it should be? Any guesses?
19:24
Actually, if you think this is just JavaScript, let's translate this example to Python. This should be easier, right? This is a Django conference. What's the output going to be here? Four? It's actually 16.
19:42
Now, the reason for that, and the same thing happens in JavaScript. This is because the variable factor is function scoped, and the anonymous function will evaluate factor when the function is called, not when it's defined. So by the time we call multipliers,
20:02
the for loop has ran, and the factor equals eight. However, this would be fixed if we used block scope instead. So what happens if we change var to let? We get what we expect, what we would expect for.
20:23
Okay, enough about that. That's stuff you just have to try out and get a sense of it. Let's talk about data types in JavaScript. So JavaScript has five different simple types, and everything else is an object. Objects in JavaScript are key collections that are mutable.
20:44
So the simple types are boolean, null, undefined, string, and number. These types are immutable, and they're object-like in the sense that they have methods. Objects, on the other hand, are mutable. Arrays, functions, and of course,
21:00
objects are all objects. This means that they can have attributes, methods, and can be passed around as parameters, and can be returned by functions. This is very cool, because that is what makes functions first class, which gives JavaScript the superpowers to be used as a functional language.
21:25
Let's look at the simple types. So boolean is what you would expect, and is similar to Python. Null is the JavaScript version of none. Then there is undefined, which represents something that hasn't been defined, versus the empty value, which is null.
21:41
If it seems confusing, it's because it is. JavaScript has only one way to encode strings, and that's 16-bit Unicode. And there is only one type for numbers, which uses floating point for everything, meaning there is no separate integer or decimal type,
22:00
which can also be problematic. Now when it comes to objects, there are different ways to declare them, just like in Python. Usually we use the object literal to declare them, which is similar to how you usually declare a dictionary in Python. So the syntax should be familiar, except in JavaScript, you can also define methods on an object.
22:24
And because the objects in JavaScript are mutable, you have to be careful about changing the state. This is similar to Python. The logical operators look similar to Python, except they're more verbose.
22:40
There's one big catch, though. When doing comparisons, you have two options. There is abstract equality, the double equal sign, or strict equality, the triple equal sign. You should almost always use the triple equal sign, so the strict equality, because it will give you the result you would most likely expect.
23:02
The abstract version will only compare the value, but not the type. Let's look at what happens if you're using the abstract version instead.
23:23
So simply use the triple equal sign most of the time, and you should be fine. There are two main ways you can define a function in JavaScript. You can use a function keyword, or using a fat arrow function. You can define a function globally,
23:40
inside another function, as a method on an object, as a method on a class. For that matter, you can define a function anywhere as an anonymous function. Using anonymous functions is very common in JavaScript. So common, in fact, that it's one of the reasons that JavaScript has arrow functions, which are quicker to write.
24:05
This is an example of a function as a method on an object. So with arguments, it's quite similar to Python. You can give the function arguments, and you can give those arguments default values. When the function is called, it can be called,
24:20
that's different, it can be called with any number of parameters, regardless of how many were in the function definition. So if you call a function with fewer arguments, the rest will just be filled with undefined. And if you call a function with extra arguments, those will simply be ignored.
24:42
And a good thing to note is that a function in JavaScript will always return something. If you don't specify what, it will return undefined. So, okay, this is also one of the bigger points of confusion when it comes to JavaScript.
25:01
So in Python, we have self when working with classes and objects. Self will be passed to methods, and it's a reference to the instance of the object. In JavaScript, we have this, but it behaves a bit differently. Let's first look at this example. So it's like an object called pets,
25:21
it has like two attributes, names and owner, and then it has a method which will return like a description of the object. Now, to understand what's going on, let's explain this a bit more.
25:40
So in JavaScript, this is passed to every function, not just method. If we define function as a method, this will store the object, which is what we would expect. However, if a function was not defined as a method, this will reference the global object, which is where the confusion comes. So for example, if a method will have some anonymous
26:03
function, we have to be careful, as this might not be the object we want. It was not defined as a method. So for example, what do you think that the description method will output here? Any guesses?
26:22
So it should return like this owner, so that's Walt, knows an awesome cat named Pat, and it should do this for every name in the list. So like it should be a list of these descriptions, the first one being Walt knows an awesome Pat named Simba.
26:42
Now is that what we get? No, we get undefined because of the reason I explained. This in this example is bound to the global object, so it doesn't know of an attribute called owner. So like if instead we used an arrow function,
27:04
we might get something different, and the reason for that is that arrow functions are special in the sense that they don't bind their this. So this will just be inherited from their scope.
27:20
In this example, that's exactly what we need. So here we get Walt knows, like we would expect. In order to avoid this problem, it used to be a lot more verbose before ES6. Usually developers would do like that equals this, and then in the inner function they would use that
27:41
because it's the this that they would want, and yes, it's as confusing as it sounds. 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.
28:03
It used to be a lot more verbose to implement this behavior that you're seeing here, but since ES6, it's very easy and straightforward, and then we have modules. They're quite easy to use in JavaScript. In one sense, not the other.
28:21
They do require some kind of module loader, so they won't work on their own. You have to use like a web pack, for example, to get this to work, so we're not going to go into that in detail, but the syntax is somewhat familiar to Python.
28:41
The difference is that we also have to use export keywords specifically to which part we want to export, so we all love the new f-strings, right? Well, JavaScript also offers the similar backtick template literal, and they were actually implemented
29:00
one year before Python got f-strings, and they work a lot like f-strings, so if you know f-strings, you should be familiar with this. They can even be multiline. In my opinion, JavaScript needed this way more than Python did, because the alternative here looked like this, and this is just insane. No one wants to write code like that.
29:23
Then we come to a really big part called promises. So a promise is an object that represents a value that is not known at the time of the creation. It will be known sometime in the future, but it's not known when you create it.
29:41
So what you do with it is you give it a function that it should call when the value is known. This is something that is very useful to have, because when building web applications, this is something we need all the time. So in browsers, JavaScript is single-threaded,
30:03
so that means if we make a request synchronously, it will block the whole application. You won't be able to scroll. You won't be able to click. You won't be able to do anything. So we have to do these things asynchronously, and because this is so common, we use promises, which is kind of like
30:22
a sensible way to do these things. We also, in the newer features, there are new other ways to do this, but if you learn about promises, that should get you quite far. And like to just quickly go over this example, so we have load page element,
30:43
which calls get page, and get page is a promise. So we do then, which does what we would expect it to do. So when get page will have the value that we want, sometime in the future,
31:00
the then will be called, and that's this function. So we do something with the result, and we also do the catch method, which will handle the error if anything went wrong while trying to get page. And so this is a really common thing to see
31:21
in most of JavaScript applications. Now, as I've said, it's not like JavaScript is without its flaws. It has many. It was designed in a hurry, had a rough childhood, and is plagued by being used with some awful, dumb APIs. Those aren't a part of JavaScript itself,
31:42
but JavaScript gets the blame for them. But if you think about it, you can do weird stuff with other languages as well, if you want to, but you don't because you learn how to use it, right? So for example, let's look at Python. You can write ugly Python code. There's nothing stopping you from doing this,
32:02
and it's a valid code, but you wouldn't do that. Even worse, you wouldn't do that because you're messing up with the iteration, but there's nothing stopping you from doing it. You just learn how to not do it. And since we're at a Django conference, I've seen that in one pull request one time.
32:24
You wouldn't do that, but there's nothing stopping you from doing it. The language allows you to do that. So let me try to get a visual in your head. Do you remember a movie called Gremlins? For those of you who don't, there's this cute little creature called Mogwai.
32:44
It gets named Gizmo. Now, it's the cutest thing ever, right? But it comes with three rules. Never expose it to direct sunlight, do not let it get wet, and do not feed it after midnight. What happens if you do any of those things?
33:02
Chaos and destruction. And that brings us to JavaScript. Learn about the parts you shouldn't be using in the first place, and you're going to have a great time. I've mentioned this earlier in my talk, but I suggest, this is actually a really good book. Both of them are.
33:21
It's called JavaScript, The Good Parts by Douglas Crockford. It's a bit outdated, but still very, very useful. I also hear he's working on a new one. The book focuses on the good parts of JavaScript and also talks about parts that were just not a good idea. It talks about a source of a lot of confusion
33:40
and unexpected behavior. However, I think the ES6 and above are doing a great job at addressing these problems but the bad parts are still there. So you have to be aware of them and avoid them. A quick shout out to my friends, Ed, Lacey,
34:03
Saron, Yura, and Andraj who helped me bring this talk to its final form. Thank you. I had a question. So what was the most difficult part of kind of organizing this talk? Because it is such
34:23
a expansive task to compare two languages in the way that you did and have them side by side. It was a journey. Like this is the third iteration of the talk. I first gave this talk at EuroPython this year and then at a local Python meetup and like what you saw right now
34:41
is a completely different thing. It's difficult to get right because there's the subject, like there's so much to talk about. There's a lot to explain. So it's hard to get it right. I don't know if it's there yet but it's getting there. Yeah, so the question was how would a promise be different than a callback?
35:02
So before promises in JavaScript we would use callbacks in order to handle the asynchronous code. What would happen then, I don't have this here, but what would happen is you would have a callback within a callback within a callback within a callback which is commonly referred to as the callback hell.
35:22
And you want to avoid that at any cost because it's completely unmaintainable, very difficult to read. So the problem with it is that if an error happens in one of those callbacks it's just like you have to handle errors at every point of the way. Whereas here where you see the,
35:43
where you see get page and then you're doing then and then you have catch, catch will handle any of the errors that happen above. Basically. Like you want to test this stuff out how exactly it works but that's the nice part about it. Like you put a general catch all
36:02
on how to handle if something goes wrong. And then you can chain them which is a lot easier to read and maintain. So you can do a then will always, will return a then method will always return a promise so you can then chain them.
36:20
You do then something and then on that you put then something and basically you're like doing this train of things like okay first this should happen then this should happen then this should happen and it all happens asynchronously. And it's a lot easier to wrap your head around it. But then again promises are something that is,
36:41
it's one of those concepts where it feels really weird if you're not used to it. And then one day it clicks and you don't know why you didn't get it. You know, why you didn't get it before. Then it just feels like okay I've always known about this. First question is, is JavaScript becoming more like Python
37:01
or is Python becoming more like JavaScript in my opinion? Well they get something from each other. So, but I think JavaScript is becoming, I don't like putting it that way that JavaScript is becoming more like Python but it does draw some things, it did draw some things from Python in the latest version
37:22
so like you have spread, spread operator which when you do like arcs and quarks and like the asterisk thing in Python, JavaScript borrowed that. I think yeah it's that way around. But then if you ask, what was your second question?
37:46
I think both, I mean like one of the things I liked that Douglas Crockford was also talking about was that a language can become important for two reasons. Two reasons, it can become important for its, you know, ideas, how it does things.
38:02
Or it can become important just due to popularity. And like you could argue that Python is important because it has great ideas and also is popular but then JavaScript you could argue is important because of its popularity. And it's not like it's going away
38:20
just because of how widely it's used. So like I think we're stuck with both. Thank you again for a great talk. Besides JavaScript, the good parts, what other resources would you recommend, and this talk obviously, what other resources would you recommend for someone that is a Python developer that wants to learn JavaScript
38:41
or at least be proficient with it? Yeah, so I really like the JavaScript, the good parts. I actually read it just for this talk and I was surprised, it's quite outdated because it doesn't talk about the newest versions but just the way it talks about it and explains a few things I found very useful. And I personally got a much deeper understanding of JavaScript because of it.
39:02
The Definitive Guide is also, I've heard is a good book but it's, you know, we saw it much bigger. So how I see it is it's good to get some sense of the language like with that book with the good parts. That's one thing but then the other thing as with any language, so on one hand you have the syntax
39:24
and how the language works, right? But on the other hand you have frameworks, packages, ecosystem, which is just as big as how the language itself works, right? That's the same in any language. And that part is just as scary if not more scary in JavaScript just because of how many packages you have,
39:42
how it's so difficult to decide, you have no idea where to start. And with that the thing I found very useful was to start with one of those frameworks like for example Angular and Ember. Those two I really liked just because they set things up
40:04
for you much like Django does. Like Django will let you just start writing code and not bother you with the details that you don't wanna like deal with right now. But you can if you want to. And Angular and Ember are the same way. Like they set things up for you
40:20
and you don't have to deal with any of the like complicated web pack stuff and stuff like that and you could just start writing code and it's like an MVC framework so you're kind of used to that. And then it lets you iteratively like learn about all the other components and parts. And I personally found that very useful
40:41
because I can be like okay, I'm dealing with Angular now, I'm learning this and then be like hey, I actually needed to do the processing a bit differently. Let me go and check into that. But I didn't need to do that part until after I needed it, you know? And that makes a big difference and I feel like that's a really good learning process
41:00
where you can touch something, do something only when you need it, not at the very beginning. Hey, I was just wondering, assuming that there could be a zen of JavaScript, what would be like an example of an element in that? I think it would be, a lot of it would be similar because zen of Python is very general.
41:20
It can be applied to a lot of things, not just Python. So I think you could use a lot of it from Python. But otherwise, I'd have to think about it. I'm not able to give you the answer right away. It's a good question though. You can find me later and I'll think about it. Do you think Angular has a long future
41:42
or is it a win or take all game with React and Vue and all those? I think the four frameworks that I mentioned, maybe with the exception of Ember, but I don't want to say that because I really like Ember. But those I think, I mean this is just speculation, right?
42:01
But I feel like those are mature enough and have the support and everything backed by companies. So I think that they should be staying around. But I know that Angular did a really poor job of how they did Angular 1 to Angular 2 transition.
42:21
So, sorry? But yeah, I think Angular, it's quite widely used and like I said, it's backed by Google. So I think those are, it's a common concern just like with the sea of frameworks, but I feel like those are so big right now that they should be around for a while.
42:43
But then again, you don't know if some new JavaScript features will come out or will end up doing things way differently in five years and those will become obsolete, but that stuff plagues any framework. Django as well, you know? So. All right, thank you so much for the talk
43:01
and here are some cookies.