 Man, I wish JavaScript had real objects like class-based instead of those prototype things. Really? You're the genie? Hey, uh, provisioning genie was busy, I had to fill in. What's your good news then? Well, I got good news and bad news. ECMAScript 6, or newer, does support classes, and here's an example. So you can see I have a person class and there's a couple of private fields, so you can actually hide things inside of here without having to hand code the revealing module pattern. That's done with that hash tag on the beginning of the variable name, right? That's right. Sometimes a hash, some languages, a hashtag means a comment, but in this case it means a private field because we don't want to confuse anyone, right? No, of course not. And then there's a constructor, which in this case is just going to squirrel away the first and last names, and then I've got a get name method on this. But then to show inheritance, of course, geeks are people who have favorite development languages and favorite sci-fi movies. So in this case, geek extends person, that's how you do inheritance. So I'm still going to have the other members and method, but I'm also going to have now a favorite developer language and a favorite sci-fi movie. And you can see in the constructor, this is how you would call the base class. And of course, the base class, just to make sure that nobody gets confused, is called super. Right. Like, what's with that? Like some languages, the parent is below you, like a base, and in this language, the parent is up above you, like superman or superwoman or something. So anyway, there's that, and then the get message now returns all this other information. So then I'll set up a couple, and everybody can kind of get to know us a little bit better. We'll set up a couple of objects, Bob and Julie, with our favorite programming languages, and notice that neither of them is JavaScript. But that's okay. We didn't choose our... We're using the revealing module pattern to show people why maybe it's not. Really, I guess. Anyway, there's that. And then if we look at the result, you'll see that it actually worked. In the arrow functions video, which if you haven't seen it, go check that out. We talked about the difference between arrow functions and traditional functions in an object class. And this example, the second example shows that, and they're fancy names for them. So the traditional function is now called a prototype method, meaning that there's one method for all the objects of that class. It's literally a shared code for that method. And it uses the classic this syntax, meaning that this is, in fact, put a little cheat sheet up here on exactly what this means. Probably handy for all of us. Yeah, I actually refer to this in my own code just when I forget some of the details. Anyway, maybe we'll do a video on that someday. But in any case, the arrow function, because of the fact that arrow functions in JavaScript behave more like using kind of closure rules for, so the scope of any symbol inside the arrow function is based on where it appears in the code rather than on how it's called. So in the second example, it's going to, it's going to, well, let's see the result, right? You'll see that the first example, it says my name for both, which is correct. The second example, your name should be on both. Let's see why that happened, right? I came down here and I made a me object with my information, and that worked as I would expect. And I created a you object, but I defined the, I defined the functions, the methods as coming from the me object, which is something you'd probably never do in real code, but it illustrates the fact that me.getName2 actually copied the closure, so that this was from the me object, the you object, if that makes sense. It does, it does, but it's confusing. This is why this is confusing. This is why this is confusing. Yeah, exactly. So anyway, I find it's nice to use arrow functions inside of my classes because even though they don't behave as you would expect for the reason that you would expect, they at least behave a little bit more like you would expect. So Julie, you've been developing for years and in all these languages, what's your take on it? Do you like the addition of classes to JavaScript and do you use them? How do they compare? I do use them, you know, I had been doing, I have been doing for less, several years there's a lot of react development and so and I use components for my react development. I haven't switched to hooks. So from my perspective, all of my react components are classes and thereby I've gotten very used to this sort of programming method. I have recently started exploring web components and I'm finding I'm also using that same pattern for web components and finding I like it. One of the things that I'm struggling with just like everybody else is when you switch up what you're doing on a day-to-day basis, you have to re-understand how this works and by this, I mean this in that new pattern, in that new pattern that you're adopting. And so I do a lot of arrow functions because of that and because the context of the this in the class is how I expect it to behave and that works for me based on the patterns and my patterns of thinking about how to develop things. So I think, yes, I like them and I use them extensively, almost exclusively I would actually have to say. Yeah. Yeah, I use them too and I like them but I kind of still miss, I'm going to be elitist here or something. Maybe and just say real objects whereas I realized that prototypal objects is perfectly legitimate model. It's just not the one that I'm used to and I guess it feels like it's a bit of a slippery slope when you try to make it seem like you're providing something familiar when it's really at its core, not really a thing. Yeah. Yeah. One of the other things about this is that the instance methods take more resource, they take more memory, right, because the prototype method, it's really the prototype for the function that is represented by the constructor of this class because it's still just a function underneath and still just a JavaScript function and prototype underneath. So but the nice thing is if I had 1000 instances of this object class, I would only have one copy of getName1 whereas getName2 is actually tacked on to each instance of the object. Right. Which is important because otherwise the closure trick wouldn't work. Exactly. Yeah. But on the flip side, if I had 1000 of them or 10,000 of them, I would be chewing up a lot of memory for all that extra loading closures. So I think architecturally it's a really important thing to keep in your head like, hey, is this class something that I'm going to be creating many, many instances of and thereby I want to be pretty careful about how I'm defining my functions, whether I'm using the arrow functions or I'm using traditional functions and why and how I'm going to handle that versus if you're creating like a service as a class as a service where you're going to maybe have a singleton and maybe have callback functions or whatever it might be, then that closure pattern is probably just fine. And so then it doesn't matter as much. So I think it's architecturally something that you need to think about when you're making these design choices or your coding choices. I agree. So if you're watching this and you like it, please give us a like, love it if you subscribe to the channel so you can get notified of future videos. And also if there was anything in here that you'd like more detail on, like maybe we threw around the word closures a bunch, you wanted a video on closures, would you like us to do a video on all about this or maybe that? I don't know or some other preposition or the other. Anyway, thanks for watching and we'll see you next time on Browser Native.