JavaScript for Python Developers by Žan Anderle

Yeah, I think that's a good thing.

Speaker 1: Hope you all had a good lunch. Um, my name is John. 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. Uh I'm a consultant and a full stack web engineer. And if you need some help to make sense of your frontend and back-end needs, or if you need someone to mentor your junior folks, please come say hi. Okay, let's start by taking a short trip to Arendel. 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, you'll know how the story goes.

Speaker 1: 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 is way more powerful than she imagined. One time she even accidentally injures her younger sister. Her parents warn her that she needs 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, 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.

Speaker 1: And she finally learns how to control her powers. It's not with hiding and controlling, it's with acceptance and love. And then later her uncle Bang 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 Jengauts, are a lot like Elsa. And JavaScript is a lot like the powers that she has. Here are some amazing and incredible things that we can do with JavaScript. Uh but it there are some amazing and incredible things that we can do with JavaScript. JavaScript. But if we're not careful about which tooling we use, how we include it, how use

Speaker 1: 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 Vinish Vishna called wait you can do that with JavaScript. Um it showcases some um awesome things that you can do with JavaScript. You know, the like you can do front-end, backend, 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 of what you can do in JavaScript. Hopefully this will work. Now, all of this is implemented in

Speaker 1: in JavaScript and it uses a neural network To in order to predict or like or to continue the melody that you just played. So if we play something like um I think that's so cool. Okay. But of course all of this comes with at a 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 have

Speaker 1: before I can write a single line of code? Now a lot of that is hype 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. 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

Speaker 1: because everything is installed in the local node modules folder. So you can use NPM or Yarnt for installing any development tools or any packages that you are using within your JavaScript project. Then we have this thing called Babbel. This is useful when you want to write your code in the latest version of JavaScript, but also want to support the older browsers. So it's kind of like if you 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, 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

Speaker 1: And Internet Explorer. Given the demands for the applications on the web, there are usually a couple of things to be done if we want it to be production ready so that it's fast, small in size, and supported in all browsers. We we might want to minify and ugly the code to uh To get the smaller sizes. If we're using something like a CSS extension language like SUS, we need to compile those files into CSS. 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

Speaker 1: build process. The tools usually used for this are either grunt or gulp. And if we're using modules, uh like we also want to uh bundle our code into a single file from separate files, uh we can use webpack, which is very powerful and sometimes difficult to understand. understand. Then there are a ton of different testing tools. Um 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 popularity of the modern JavaScript, different front-end frameworks. Similarly, as with testing tools, going through them would take a whole new talk.

Speaker 1: So let's just look at four of these and like what's the general idea behind them? them. So as the web applications are becoming more and more dynamic and interactive, we have to provide a a In order to provide a richer experience, we're getting um more and more JavaScript code. 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 by default. Some custom components and then you can use that and make it make them nice reusable code

Speaker 1: Um 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. React and View are more like the V part of the MVC. They can still be used as full frig uh full featured framework as well, but the nice things about those two is that you can use it You can use them in your existing applications without like changing everything about it. So when it comes to JavaScript and Django, there are a few different ways that they can be combined. Possibly one of the best way, especially for larger projects with lots of and lots of interactivity, is to have the whole front end as a separate project

Speaker 1: So in this case, you could use one of the frameworks I mentioned 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 um if you wanted to do some additional processing of your JavaScript code, like bundling, uglifying, or whatever 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, the very least you should do is put your JavaScript in separate files.

Speaker 1: 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 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. And then when they kiss for the first time, we find out that the beast was a handsome prince all along, spoiler alert, uh, but was turned into a beast by some awful curse.

Speaker 1: Again, why are we talking about some fairy tale at a JavaScript talk? Well, it turns out JavaScript is a lot like the beast. 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 kidnap uh kidnaps us and takes us hostage? 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 um JavaScript is the only programming language that people don't bother to learn before using.

Speaker 1: 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. It's it gives you a sense of oh it's such an easy language just because it's um it tries to be lenient. And yeah, that gives you a false sense. And it's actually not that easy. If like it's easy to get started and to do some basic stuff, but if you actually want to design the whole systems around it and build something, that takes time and effort. So why don't we do that right now?

Speaker 1: 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 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 don't worry if you don't get it 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, but unfortunately we'll not 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.

Speaker 1: Implementation, sorry. Throughout the years, new versions of ECMAScript have been released. 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, ECMAScript 6 or ES6 or ECMAScript 2015 was released. And the release was quite big. It was kind of like Python 3 of the JavaScript world world, but without the breaking changes. It added a lot of new syntax to help uh write complex applications and fill in the missing gaps. It added added things like classes, modules, iterators, generators, arrow functions.

Speaker 1: 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 not nearly as big as uh ECMAScript 2015. So, okay, let's do this. Uh the examples I'll show are using ECMAScripts 2016, but most of them would work with ECMAScript 2015, which I just met. Since this is JavaScript for Python developers, I will go uh very quickly over the parts that are similar and spend more time

Speaker 1: on the parts that aren't, which I think are the interesting things. Bits. Um and this will be a handful, but nothing that we can't handle. Okay, let's get right to it. The syntax somewhat resembles Java, um, but shouldn't be too foreign to Python users It's similar to Python 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. But because it's a weekly type language, unlike Python, it also means you can do stuff like this, which doesn't always make sense. So

Speaker 1: when you define a variable in JavaScript, you have to use var, let, or const. Var is function scoped, 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, uh it works as you would expect. expected and variable b is not defined outside of the function. But unlike Python, JavaScript also knows uh knows of a thing called block scope. This is also used in other languages. Block is defined by a set of curly braces.

Speaker 1: So that means for and while loops, 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. Usually we want to use let and const because that's um m other developers might expect that as well. So okay, function versus function versus block scope is easy to work around, but there's a way bigger problem with JavaScript scope, and that that's its global scope. So every JavaScript code that runs on your website can define things in the global scope.

Speaker 1: 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 side of the program grows. 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 know you can you should minimize the global footprints and make things a lot saner. So by the way, if you ever define a fun uh variable without using var, let, or const the variable will automatically be the be assigned to global scope, which can be a real problem. Okay, and since we're talking about var, let, and const, um

Speaker 1: yeah, like I said, generally speaking you should avoid var That's because variables defined with var are are also hoisted. 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 why hoisting can be problematic. So here we have a variable uh x that's assigned a value 10, then we define a function func uh that's Prints out the X, then there's a lot of code, then it defines a variable X, and then again it prints the prints out the variable X.

Speaker 1: Now it's not a complicated, but imagine that there's a lot of code in between, or that the X on line 5 is added later by another developer. So what happens here is um like you get undefined first and then you get five because of hoisting. So with all that knowledge, here's a riddle for you. Here we have a code, um, we have a list of factors, two, four, six, eight. We have an empty list of multipliers and then we we iterate through the list of uh factors And add an anonymous function which will take an argument and multiply it by the factor.

Speaker 1: So if we look at the um like Uh if we look at the output of the last line, what do you think it should be? Any guesses? If you let's actually let's if you think that's this is just JavaScript, let's trade translate this example to Python. This should be easier, right? This is a this is a Django conference. What's the output going going to be here? Four? It's actually sixteen. 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

Speaker 1: evaluate factor when the function is called, not when it's defined. So by the time we call multipliers, the for loop has run and the factor equals eight. However, this would be fixed if we used blocked scope instead. So like what happens if we change um if we change let if we change var to let? We get what we expect what we would we would expect for. Okay, enough about that. Um that stuff you just have to try out and get a sense of it Um let's talk about data types in JavaScript. So JavaScript has has five different uh simple types and everything else is an object.

Speaker 1: Objects in JavaScript are key collections that are mutable. So the simple types are Boolean, null, undefined, string, and number. These types types are immutable and are object-like in the sense that they have methods. Objects, on the other hand, are mutable. Arrays, functions, and of course objects are all objects. This means they can have 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 uh functions first class, which gives JavaScript the superpowers to be used as a functional language.

Speaker 1: Let's talk at uh 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. If it seems confusing, it's because it's it is because it is. JavaScript has only one way to encode strings, and that's 16-bit Unicode. And there is only one way to uh one type for numbers, which uses floating point for everything meaning there is no separate integer or decimal type, which can also be problematic. Now when 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.

Speaker 1: So the syntax should be familiar, except in JavaScript, you can also define methods on an object. And because the objects in JavaScript are immutable, you have to be careful about changing the state. This is similar to um to Python. The logical operators look similar to Python, except they're more verbose. Uh 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 the triple equal sign, so the strict equality Because it will give you the result you would most likely expect.

Speaker 1: The abstract version will only compare the value, but not the type. Let's look at what happens if if you're using the abstract version instead. 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, 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

Speaker 1: Using of uh 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. This is an example of a function as a method on an object. So uh with arguments, it's quite similar to Python. You can give the function arguments, uh, and you can give those arguments default values. When the function is called, it can be called, that's different. It can be called with any number of parameters, regardless of how many were in the function definition. If it so if you call a function with fewer arguments that um the rest will just be filled with undefined.

Speaker 1: And if you call a function with extra arguments, those will simply be ignored. 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 this is also one of a uh uh one of the bigger like points of confusion when it comes to JavaScript. 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 let's first look at this example. So it's like An object

Speaker 1: called pets, it has like two attributes, names and owner, and then it has a uh a method which will return like a description of the object. Now to understand what's going on, um let's let's explain this a bit more. So in JavaScript, this is passed 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 we if a method will have some anonymous function, we have to be careful

Speaker 1: as this might not be in the object we want. It was not defined as a method. So for example, what do you think that Um the description method will output here. Any guesses? So it should return like this owner, so that's Walt knows an awesome cat named uh pet and it should do this for for um For every name in the list. So like it should be a list of these descriptions. The first one being well it knows an awesome path named Simba. Now is that what we get? No, we get undefined and because of the reason I explained. This in this example

Speaker 1: is um bound to to the global object. So it doesn't know of a uh an attribute called owner. So, like if if instead we used an arrow function, we might get something different. And the the reason for that is that arrow functions are special in the sense that they don't um that they don't bind their um their this. So this will just be inherited from their scope. In this example, that's exactly what we need. So here we get Walt Nosen like like we would expect. Um in order to avoid this problem, it used to be a lot more verbose before ES6. Usually developers would do like

Speaker 1: that equals this, and then in the inner function they would use that because it's the this that they would uh want. And yes, it's as confusing as it sounds. Um JavaScript is prototypal in nature, which is in fact a lot more fr flexible than the object-oriented inheritance model. Um but it can also support the classes that we're familiar with from Python and other languages. Um it used to be a a lot more verbose to implement this behavior that you're seeing here But since ES six it's very easy and straightforward. And we have then we have modules. Um they're quite easy to use in JavaScript in one sense, not the other. They do require some kind of module loader.

Speaker 1: So they won't work on their own. You have to use like a webpack, 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. The difference is that we also have to use export uh keywords uh specifically to you know which part we want to export. So we all love the new F strings, right? Well, JavaScript of also offers the similar Bactic template literal. And they were actually implemented one year before Python got F-strings. And they work a lot like F-strings. Um so if you know F-strings, you should be familiar with this. They can even be multi-line.

Speaker 1: Uh in my opinion, JavaScript needed this way more than Python did, because the alternative here looked like this. And this is just insane, like no one no one wants to write code like that. Then we c come to a really big part um 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. So what you do with it is um you give it a function that it should call when 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.

Speaker 1: So, you know, in browsers, um JavaScript is single-threaded. So that means if like we make a request synchronously, it will it'll 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, um, we use promises which is kind of like an A sensible way to do these things. We also uh 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

Speaker 1: which calls get page and getPage is a promise. So we do then, which does what we would expect it to. So when get page uh will have the value that we want sometime in the future. the then will be called and that's this function. So uh we do something with the result um and we also do the catch. Method which will handle the error if anything went wrong while trying to uh get page. And like so this is a really common thing to see in m most of JavaScript applications. Now, as I've said, it's not like JavaScript is without its flaws.

Speaker 1: 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, but JavaScript gets the blame for them. Um but if you think about it, you can do weird stuff with our 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. Like there's nothing stopping you from doing this and it's it's a valid code. But you wouldn't do that. Like even worse, you wouldn't do you wouldn't do that because you're messing up with the iteration. And but there's nothing stopping you from doing it. You just learn how to, you know, not do it.

Speaker 1: And since we're at a Django conference, I've seen that in like in one pull request one time. You wouldn't do that. But there's nothing stopping you from doing it. Like 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 little cute little creature c creature called Mogwai. 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? Chaos and destruction.

Speaker 1: 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 a book this is actually a really good book. Both of them are. It's a bit outdated, but still very, very useful. I also hear he's working on a new one. Uh the book focuses on the good parts of JavaScript and also talks about parts that were just not a good idea. Um it talks about a source of a lot of confusion and unexpected behavior. However, I think the ES6 and above are doing a great job at addressing these problems.

Speaker 1: 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, Saran, Yure, and Andrash who helped me bring this talk to its final form. Thank you.

Speaker 2: I had a question. Uh so what was the most difficult part of um kind of organizing this talk? Because it is such um it you know, expansive task to compare two languages in the way that you did and and have them side by side.

Speaker 1: It was a jerk Like this is the third iteration of the talk. I first gave this talk at EuroPython this year, uh and then at a local Python meetup. Like what you saw right now is a completely different thing. Um 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. Um Um so it's hard to get it right. I don't know if the if it's there yet, but it's getting there. Yeah. So the question was uh how would a promise be different than a callback? 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 um you would have a callback within a callback within a callback within a callback

Speaker 1: which is commonly referred to as the callback hell And you want to avoid that at any cost because it's completely unmaintainable, very re very difficult to read. So the problem with it is that um 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 um 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 how exactly it works. Um, but that's the nice part about it. Like you put like a general catch-all on how to handle if something goes wrong.

Speaker 1: And then you you can chain them, which is a lot lot easier to read and maintain. So a then will always will return a a then method will always return a promise. So you can then chain them. You do then something and then on that you put then something and basically you 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 to wrap your head around it. But then again promises are something that is 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.

Speaker 1: You know, why didn't you get it before? Then you j then it just feels like okay, I I've always known about this. First question is, is JavaScript becoming more like Python or is Python becoming more like JavaScript in my opinion? Well they they get something from each other. So um but I think JavaScript is because 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 uh Python in the latest version. So like you have spread, uh spread operator, which Which when you do like arcs and quarks and um like the asterisk thing in Python, JavaScript borrowed that. Um I think yeah, it's that way around.

Speaker 1: But then if you ask uh what was your second question

Speaker 3: to the extent one langu one of the languages

Speaker 1: I think both of them I mean like um one of the things I liked that um 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, or it can become important just due to popularity. And like you could argue that Python is uh 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 just just because of how uh how widely it's used. So like I think we're stuck with both.

Speaker 4: Thank you again for a great talk. Um besides JavaScript the good parts, what other resources would you recommend and this talk obviously. Uh what other resources would you recommend for someone that is a Python developer that wants to learn JavaScript or at least be proficient with it.

Speaker 1: quite outdated because it doesn't talk about the newest versions, but just the the way it talks about it and explains a few things I found very useful and I personally got a like a much deeper understanding of JavaScript because of it. Um the definitive guide is also uh I heard I've heard is a good book, but it's you know we saw much bigger. So How I see it is it's good to get some sense of the language, like with that book, with the the good parts. Um that's one thing. But then the other thing, as with any language, so on one hand you have the syntax and how 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?

Speaker 1: That's the same in any language. And that part is all is just as scary, if not more scary, in JavaScript, just because of how many packages you have, how it's so difficult to decide, you have no idea where to start. And with that, I uh the thing I found very useful was to start with uh with one of those frameworks, like for example, uh Angular and Ember. Those two I really liked just because they're um they set things up 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 and you don't have to deal with any of the like complicated webpack stuff and stuff like that.

Speaker 1: 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 um like learn about all the d other components and parts. And I found I personally found that very useful. Because I can be like, okay, I'm dealing with Angular now, I'm learning this, and then be like, hey, I actually need 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 where you can touch something or do something only when you need it, not at the very beginning.

Speaker 5: Hey, uh I was just wondering, assuming that there could be a Xena JavaScript, what would be like an example of an element in that?

Speaker 1: I think it would be a um a lot of it would be similar to because Xenop Python is very general. It can be applied to a lot of things, not just Python. So I think you could use a lot of it uh from Python. Um but otherwise I'll I I have to think about it. I'm not able to give you that the answer right away. It's a good question though. You can find me later and I'll think about it.

Speaker 6: Do you think Angular has a a long future or is it a winner take all game with React and View and all those?

Speaker 1: I think the four um 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 uh those I think well it's I mean this is just speculation, right? But I feel like those are mature enough and like have the support and everything and like backed by companies. So I think that they should be staying around. Uh but I know that like Angular did a really poor job of um of how they did Angular 1 to Angular 2 transition. So Angular 2. Sorry? But yeah, I think Angular it's uh it's quite widely used and like I said, it's you know it's backed by Google. Um so I think those are

Speaker 1: It's a common concern just like with the sea of frameworks, but I feel like those are so big right now that um they should be around for a while. But then again you don't know like if some new JavaScript uh features will come out or like we'll end up doing things way differently in five years and those will become obsolete but you know that stuff plagues any framework. Django as well you know.

Speaker 2: All right, thank you so much for the talk, and here are some cookies.