ES13 and Beyond: The Future of JavaScript with Christina Zhu 
===

[00:00:00] 

Hello and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. You can try it free at logrocket. com. I'm Noel, and with me today is Christina Xu. Christina's a developer advocate, speaker, engineer, and I have Bad joke enthusiast written here in my show notes.

She's here to talk about her Seattle JS talk ES13 and beyond the future of JavaScript. to show, Christina. How's it going?

Great. And yourself?

I'm good. Thank you for joining me. I'm excited to chat today. Before we delve in, can you give listeners a brief overview of, who you are and how you found yourself talking about JavaScript.

And yes.

Yeah so my history with JavaScript actually goes way back, so my first exposure to JavaScript was actually when I was a child, and I was playing a game called Neopets that probably many millennials have heard of [00:01:00] currently. So, in Neopets, you are actually able to customize your pet's profiles with HTML, CSS, and JavaScript.

Similar to MySpace, almost. And that is how I got started coding in JavaScript. I didn't even know it was called JavaScript back then, or that it was even considered coding. But I just really wanted to make sure that my Neopet had the best page, and that my profile page was, super sparkly, the mouse was like a cupcake, stuff like that.

And yeah, that was all JavaScript. So that's how I got started and how I got started coding. 

Nice. What a good origin story. I feel like I've heard someone else give me this, like a very similar kind of spiel is it was Neo pets and it's Oh, of course. Yeah. I feel like there, this is, was a thing. I wonder what percentage of like front end people. can point back at their history and be like, yeah, I can blame little online virtual creatures for my whole life trajectory here.

Yeah. Or even like MySpace, because to a lesser extent, MySpace also allowed you to [00:02:00] customize with a lot of web dev stuff. So I do feel like that's one of the things that we lost as we moved onto like Facebook and Instagram and yeah, Tumblr as well. A lot of my friends also got started doing Tumblr stuff.

Yeah, I know. I feel like this is a thing I could sit here and pontificate, but yeah, like, I feel like weird, quirky, like customizable landing pages in front of us. It's just not the same when we've like WYSIWYG'd it all and made nice GUIs. It was way more fun when half your friends pages were like super janky, nothing ever loaded right.

And like you some ones that was. Well made and well crafted. You're like, Ooh, nice. This person spent some time on this. 

And then forcing your friends to listen to the Linkin Park song that you had autoplaying on your page,

yes. Yeah. You're taking me back. Taking me back. Very good. Cool. Well, let's not stray too far off topic here. So let's let's talk about, let's talk about ES maybe just to help frame people who aren't like super familiar with the space. What is. ECMAScript, yes, and JavaScript.

And I guess, what's the relationship between [00:03:00] those two? I don't know how much most people know what JavaScript is. But what is Yes.

Yeah so ES is short for ECMAScript, and that's like the official name for JavaScript. And JavaScript was made in 1995 in a ten, in ten days, basically. It was originally called Mocha, and then it was renamed to LiveScript. It was basically made because Netscape wanted to have a scripting language to compete with their upcoming competitor, Microsoft.

They were about to release something called Internet Explorer. So crazy. Yeah. And then recently, A hot new programming language had also been released called Java, So when Netscape finally released LiveScript, as it was known back then, they decided to rename it shortly to Javascript which is, completely unrelated to Java but they just wanted to also ride that hype train, right?

So, yeah, that being said, Java and Javascript are about as similar as a car and a carpet, so very yeah, not the same.[00:04:00] 

Yeah. So, why did you choose the title of your talk, ES13 and Beyond, , as the main bit of the title, instead of focusing on JavaScript? What part of kind of the JavaScript life cycle is driven by the ES standard?

Yeah, so, that is a great question. So actually for me personally, I actually did not know we were all the way on es13 until maybe this year and for me, I just thought the last biggest release was es6, which was now, you know back like a couple years ago now So for me, I was like, oh wow, like we actually are like a couple versions later now and If I didn't know, then maybe other people don't know as well, so I just figured it'd be great to talk about, the later versions and teach people about, the latest features and whatnot.

Yeah. So is there I guess to move on from history a little bit, are there any, is there anything major that's changed or how do you like to frame this discussion? What should devs be paying attention to with these version updates, like from [00:05:00] six, all the way up to 13.

Yeah so I can talk a bit about that actually if you want me to go over each year and their major, release, but,

Yeah. Maybe like the high level I don't know what's a big one, big milestones were that are noteworthy. That'd be cool to hear.

yeah, definitely Top Level Await, which was released Very recently is definitely one of the most popular ones that have been released. So that was released last year, but even simpler things such as like optional chaining which handles, nested structures better and rest and spread properties for arrays.

These are just a couple of the features that have been released recently. So I just think personally, it's really awesome that we've moved away from the once in a decade update to a yearly, evolution of the programming language, which is pretty awesome.

Yeah. Yeah. So I do want to dig into the specifics a little more, but I think At this point, some listeners might be sitting there thinking wait, I've been using top level await and like optional chaining forever. And I've always just thought it was fine. It's always worked in my browser. Can you explain a little bit about, like [00:06:00] why that is and then why it matters that we are now bringing them into the yes, standard.

So I do think some browsers like Chrome actually do implement stuff before they are quote unquote like officially integrated into JavaScript. There's a lot of different features that are currently like in, in implementation and being made. But the fact that they are like officially introduced into JavaScript means that they will have like compatibility with all kinds of browsers and be set as the new standard.

So, Yeah you do have libraries that have been helping you implement all of these things in different ways, but having it being, officially supported is great and you won't have to do those workarounds anymore, essentially.

Yeah. Yeah. And like you said, those libraries, the like the transpilers and the poly fills and all that stuff, I don't have to do as much. Heavy lifting for us. It's like the code we're writing can be the same thing that is being deployed in the browser and it makes debugging easier and mapping easier and all that stuff.

Yeah, you got it right.[00:07:00] 

Yeah it's super cool. So, let's talk about some of the new features. Like what are some of the benefits of, let's start with the first one you mentioned top level top level of weight.

So, you might remember trying to use await outside of an async function before, and ESLint or whatever would be complaining about it. So the fact that we do have top level await now, it allows you to use the await operator outside of an async function. So you don't know, you don't have to like, no longer wrap it around an anonymous private function anymore.

So it simplifies your code a lot. There's a lot cleaner syntax and better error handling, and overall it's just way easier to use.

Yeah, exactly. Just like less little superfluous code. It's not really doing anything. Yeah. So , was there any functional problem with what devs would typically do before, like you said, wrap it in an immediately invoked function of some kind? Is there any like functional problem to that or is this just primarily a, like kind of a quality of life improvement?

I would say it's mostly a quality of life improvement But that being said, I [00:08:00] do think that it makes it a lot easier to read the code, which is, what programming is all about. People will be reading your code, you'll be reading other people's code. And I guess, one of the other big differences is that the execution of the parent module will only start when the child module code is finished.

So, overall, just a lot cleaner. And I think handling edge cases better, yeah.

Yeah. Yeah. Let's see the next one you mentioned was optional chaining. That one seems pretty obvious, but maybe just to devs that haven't really thought about it in a while or aren't maybe JavaScript developers day to day. How does that look and how is that helpful?

Alright, so you guys might be... I'm not sure every JavaScript developer has gone through this, but access a value of a property that's located very deep within a chain of connected objects. So, for example, like house. property. owner, name, lastname, firstcharacter so, and basically the optional chaining allows you to double check if that each reference in the chain is valid before continuing on.

[00:09:00] So before you might have To have I don't know, like a 12 if statements on does this exist? If so, continue. Oh, does this exist? Oh, then continue. But now you can just add like a question mark after each one. And it basically checks that for you. So I know a couple of other programming languages has have this implemented, but it's really nice to see this implemented JavaScript allows us to handle nested object structures a lot more gracefully.

Yeah, it's a lot cleaner code, a lot fewer of these if statements going all the way down 19 layers deep to make sure that your properties are actually there and set especially if you're writing like TypeScript or something. And, there's a type checker enforcing, making sure that you're type safe and accessing, not accessing no properties.

Like this is almost a must it's super nice. Let's see, is there anything else cool in the last year or so? I guess maybe just in in the most recent version, ES13, that is, is worth mentioning or might be handy for devs to utilize.

Yeah. So I, another thing that I think is really cool is that we now have private class [00:10:00] methods and fields. So before that they were all global and which means that global and public, which means that fields and methods can be accessed globally and they can be read and modified from outside the class.

So before that, you might have seen code where Developers said, Oh, this is private and they mark it with an underscore in front of the method or the variable. But there's actually nothing preventing the code from accessing that. It doesn't assign any particular meaning to variables or any functions with the underscore.

But now if you mark it with a hashtag or like a pound symbol before the field and method it actually makes it private and it is supported by JavaScript, so it actually cannot be accessed outside of the class beyond the, regular getters and setters. 

Nice. Yeah. Is there any kind of workaround for this? I guess I asked the question cause I'm curious. I feel like there's a lot of Weird kind of on the weird fringes of JavaScript. There's always all this like stuff where people are going in and like shimming things and writing wrappers around properties and attributes to make [00:11:00] other people's JavaScript behave the way that someone wants it to.

And it feels like this is going to be a barrier to that. I think, do you think that's going to, this is going to change how a lot of these front end libraries and utilities kind of work, or do you think that this is primarily just going to be a code health for a given library to just be a little bit cleaner.

I will say that writing in JavaScript these past couple years is a lot, how do I say this, more forgiving and that attitude is also reflected amongst JavaScript developers as well so JavaScript is very forgiving in that, it allows you to do a lot of really wacky stuff without throwing an error at you so I do think like this move towards more strict private methods and fields and stricter class typing, like stricter typing overall, like you can see with the popularity increase in TypeScript that we're moving more towards like other, more strongly typed languages, which are a bit less forgiving.

So I do think that, JavaScript developers will have to [00:12:00] adapt to that and, have to think more strongly typed, 

yeah, no, I think that, I think that is true. It's almost baffling how like fault tolerant and just like, it just keep going and we'll do as best we can, the JavaScript kind of execution environments at large have been so far up to this point. Especially with like how much heavy lifting, how much of the internet is really like running through JavaScript to some extent.

Like it's it's almost baffling. But yeah, I think I agree with the thesis that it's changing for better or worse. We'll see how it plays out in the coming years. How about array, like access methods? There's been a couple of changes there, right? 

Yeah. We can talk a bit about that. So, so far we've been using square brackets to access elements of an array. So in bracket notation syntax, we just need to pass the index of the element which we want to access, and it returns the item of that index. But, to access it backwards, you can also, add in negative numbers and, do a bunch of wacky stuff.

The common [00:13:00] practice was to write, Array. length minus n where n is the nth item from the n, or even n array. slice, negative n. So the first one, hard to read. The second one, performance issues. So, so, in ES13, they've added the at method. So it's better for handling the negative indexes and error handling in general.

And it also works for strings, so you can do arrayed. Dot at zero, and it gives you like the first item in the array, or if you have a string at, zero gives you the first character of the string. So, it is, I feel as equally easy to read, but way better for, handling those random edge cases where you want to go backwards and whatnot.

Yeah. Nice. Is it, are the new, are these new methods mainly about like indexing or are there any other utility methods that I don't know, people might be leaning on. We have map and reduce, but I'm thinking about, I don't know, the more other, more complex methods that like low dash or something people might be using to just do more high level manipulation on arrays.

Or is this largely just quality of life stuff [00:14:00] for easier array

I do feel like there are like a lot of quality of life improvements. So like in ES14, which was released in June this year, actually they added like five new array methods. So for example, like toSorted, so it returns everything in the array, but sorted, reversed, find the last findLast, you pass in the function and it finds you the last item that, returns true for that function.

Just a bunch of like little things that, makes you think. I thought this was, you know, already a thing, but I guess it wasn't, so it's really nice that they've added it, and people that, want to interview in JavaScript no longer have to go to Python to get these basic array functions, so now we can do it in JavaScript if you want to interview in JavaScript.

right, those quality of life things are nice. And I feel like the story with the JavaScript is always like, I can't remember if this is like actually a method or not, but I'd like, I want to do this, then you gotta Google it and then figure out if it's in the library. Yeah, so those are always nice to see.

And let's see, I feel like we're flying through these. Is there anything else, as just these nice [00:15:00] little, easy to understand rock quality of life? Features that devs might care about.

Uh, Yeah, let me, so actually I can talk about some of the features that were most used as described by the state of JavaScript 2022. So top level weight top level weight is definitely coming in at number one where 67% of people that have heard of it have used it. So definitely seems like that was something that people really wanted and great to see that it shows up in my code today even.

Object. hasOwn also coming in around 41% it checks if it has its own property. We have, already have functions similar to it, but we have a specific function for hasOwn now. NumericSeparators also is one that has been introduced that I don't feel like a lot of people know about.

So it allows you to use stuff like underscores to allow you to read big numbers easier, so if you are trying to hard code like one number that's in the trillions, for whatever reason, you can [00:16:00] separate it with underscores now which makes it a lot easier to read.

I didn't know about that one. Yeah. Nice. That's awesome.

Yeah. And then there's also promise.

any which is also coming in at 43%, and one of the ones that are a little less used is array. findblast, so a lot of the newer array functions people don't know about but I figure once they do, they'll probably start using them more.

Nice. So is promise is going back one is promised at any, like essentially just giving you the result of the first promise. Does it like wait for a single promise to finish in an array of supplied promises?

Yeah so promise. any is a promise combinator. It resolves as soon as any one of the promises is fulfilled. So it takes in an iterable set of promises. So very similar to promise. race, it resolves as soon as any of the promises resolve. It disregards all the other rejected promises. But unlike promise.

race, promise. any only rejects when all promises are rejected.

[00:17:00] Ah, I see. That's a subtle, that's a subtle difference. So it'll wait if any of them succeed. It'll then return the succeeding promise, but if all of them reject, it still rejects. Is that right? Got it. Got it. Cool. Yeah. And then Hey man, I'm still, I'm hung up on the number separator one. I didn't know that was a thing.

Is it only underscores with the number separator one or can you use like other symbols as well?

I think in the examples that I've seen so far, it seems like underscores are the most popular one right now. So it's pretty hot, like helpful when you're dealing with large numbers or bit masks, so it does work with bit masks as well.

Nice. Yeah, I can't, I can count, well, I can't even count the number of times that I'm looking at these huge it's usually time or something, it's okay, this is, 600, 000 seconds or something. I'm, like, counting out this number of zeros here and trying to make the math work.

Yeah. Very cool. Are these trends that you're looking at, are these patterns what you expected or were you expecting to see any features higher or lower in that list?

That, that's a great question. I do feel like [00:18:00] recently I have been working in TypeScript a lot more and, the more that I've come to work in it, the more I enjoy it and I was not surprised to see that the industry is also moving towards that trend. But there's a couple other things that I thought were really interesting from the state of JavaScript 2022 which is, top level weight saw a 26, 26% increase in usage by or Vitae.

Is a very hot and growing fast library. It won four awards last year. 

It's fast and it's growing quickly and it's very fast.

Yes. I do believe I saw a statistic that was like, it has a 98% retention rate among users, which was really insane. Am I pronouncing it right, by the way? Is 

is is how everyone I've talked to. Yeah.

Okay, so 

On the, on the team and everything.

Okay. Okay. So I was not correct. Both. Both.

I think like it's probably one of those people love it, but I bet half of people are saying it wrong So I feel like you're in a large cohort there.

So there are also so we're the [00:19:00] biggest innovations are currently in the space are in reactivity and hydration, specifically, so it will be really cool to see you know lots of future improvements coming in. Related to performance, I feel like there's been, like, a big shift towards things like server side rendering the past couple years, so I'm really excited to see those trends continue.

And most interesting is that private fields were actually the most commented new feature, apparently people were having debates about it. About private fields and whatnot, and from what you've described, I can understand why now, but I just thought that was, funny that people were fighting about private fields.

Yeah, cuz I feel like it's not surprise super surprising to me that it is a little bit yeah, there's some contention there because the yeah like I think there are a lot of libraries and tools and stuff. The way that people think about JavaScript I can always go in and do anything I want, even with other people's code that is running on the page, right?

And I think this is a philosophical [00:20:00] departure from that, like a step in the other direction a little bit. Yeah, so it's not it's not super surprising to me. Is this analysis leading you to any predictions on what future versions of ES will look like, or , what'll be in the definition?

You can actually take a look at the current proposals that are in flight so TC39, which is like the group of folks that kind of decide and figure out what goes into the next version of JavaScript, they have a very transparent and open proposal method, so it's very similar to just opening a PR.

You describe the issue that you're having with JavaScript, you code a solution they add comments and tear it to pieces and, go into this internal cycle of improvement until everyone is happy with what they've got. So, you can actually go and take a look at some of the proposals currently and see what stage of the process they're in and they are all there on their website GitHub repository.

But, Personally I do think that we will be seeing, it depends on what do the JavaScript [00:21:00] developers want and what does TC39 think will be, like, a good improvement for the language.

Yeah I'm curious to just from a more like a higher level here. Are there is there a timeline? Do we know when the next major version will be? Because it sounds like there were like, it was, things were slow for a while. Then we've had a bunch of versions in the past couple of years, few years.

What what does that release cadence? Or spec, went in the solidification of the spec. How does that timeline look?

It's funny that you ask that. So, before ES6, which was in 2016 or 2017 now, The last release was like in 2009 or something. So after ES6 the TC39 specifically wanted to move towards a more yearly release schedule. So, ES14 was released in June this year and I'm expecting, ES15 will probably be released in the summer of next year as well.

So, we can probably see it then. But, as is with the Yearly releases, they will be a lot smaller and less groundbreaking than, a once [00:22:00] in decade release. Because I remember, like, when ES6 was released everyone was, like, so hyped about it and it was, like, crazy. Yeah.

Yeah. Again, like like we said before, just, we had to do so much less poly filling and stuff. It's just Oh, we can, yeah, like we can actually be a lot closer to the code that's really running in the browser. And that was super nice. You mentioned before the increase, or we talked about the increase in TypeScript usage and have JavaScript, the ecosystem just feels more.

Regimented and strict. How do you think that, like the increase in the uptick on TS has looped into and influenced like the features that are getting put into the ES specifications

So I guess for folks that don't know, like TypeScript is a superset of JavaScript that allows really strong typing. There are like a couple perks for this, so it allows IDEs to provide better autocomplete navigation, refactoring, and it reduces the number of runtime errors significantly.

Which speeds up, the speed of [00:23:00] development. So the traction that TypeScript has gained in the past couple years is pretty incredible. And several very prominent JavaScript libraries, like Vue, Angular, and Dedo, for example, they recommend it or even use it by default now. So, if you use some of the most popular libraries, it's more than likely you'll be picking up some TypeScript now as well.

yet. Do you think that is again, like influencing what features are getting added to yes, or do you think that's a separate discussion?

I do feel like it does have an influence. And I do think we'll be seeing a shift towards that so another interesting statistic that I saw in the state of JavaScript 2022 is that actually I would estimate around 35% of JavaScript developers code, almost 90% of the time in TypeScript now so actually 100% of the people that code exclusive in TypeScript that accounts for almost 20% of all JavaScript developers.

Yeah. So, Thank you. A lot of people [00:24:00] are either coding 50% of the time in TypeScript or more right now. So I do feel like this kind of shows a demand for the kind of features that TypeScript offers. So it wouldn't surprise me that, we move towards that in the future too.

Yeah, do you think that there's just like application patterns or the way that, the way in which code ends up being written, do you think that is influenced by this shift to TypeScript? 

I do think so, yeah. So you mentioned like Lodash earlier, right? I do think we will also be like seeing an adoption of functional programming concepts too. Just because I do feel like a lot of these things lead to more bug resistant code and for a language like JavaScript, that was originally written in 10 days I feel like that might be something that developers are looking to emulate, especially as, a lot more products are being built in the web and in the browser, right?

So it makes sense that corporations and larger companies would [00:25:00] be trying to build code that is more bug resistant and failure resistant, right? That's more like classical object oriented programming or whatnot.

Yeah, which is, it's interesting then to, to loop back and talk about like private class methods and like Optional chaining and think about these things through that lens of like functional versus object oriented programming, because, private class methods, for the most part, if in a highly functional code base, aren't really going to impact how most of that code is written and running. chaining on the other hand, I feel like, I guess one could argue that is is universally helpful. But I guess maybe these array, like the array methods are a better example. Like you said, like these kind of high level array manipulations where you can just like mutate data on the fly as you go.

Without having to copy it or create objects to hold it. That does feel much more functional. So it seems the ES spec is trying to be as agnostic as it can be in supporting devs. However, they're using JavaScript. But these patterns are emerging [00:26:00] nevertheless, is there.

Do you think that, do you think that's true or do you think that there's like more kind of time being spent thinking about, how to write more functional code?

So the question is whether we'll spend more time writing functional code or

I think more like does the ES. Do the ES updates, do those seem to be mainly focused on, or suggesting or pushing devs towards writing more functional code, or do you think that they're agnostic of, more traditional object oriented versus more functional JavaScript?

That's an interesting question. I think it really so all the proposals right are mostly driven by the users themselves. So I do feel like it is like a reflection on what JavaScript developers as a whole are more interested in right now. And TC39 is really there to facilitate that and keep like high quality for the code that's integrated into the language.

[00:27:00] But I guess we'll see, right? It depends on the state of the JavaScript developers right now.

Yeah, I think so too. It's been interesting to see unfold. This is I don't know the stage I've been paying the most attention to. And I think I just probably have more perspective because this is like what people have been working on since I've been a professional software developer.

And it's cool to see evolving. Are there any kind of big outstanding JavaScript pain points that either you just anecdotally feel are there, or you've seen in the wild or as a result of the state of JavaScript surveys that are, if you think. Need to be addressed sooner.

People should be focusing on.

Yeah so that was actually one of the interesting things that I also read in the State of JavaScript 2022. So the number one pain point right now is code architecture. Clocking in at around 35% and then the other pain points that are mentioned is managing dependencies state management.

date management debugging and finding packages. So these are a couple of the bigger pain points that developers [00:28:00] have mentioned. So you ask what features do you think we'll be moving towards? I think it will be features that will be addressing these pain points. There's another question where they ask what do you feel like is missing from JavaScript?

The number one response was static typing. Next you have standard library. Tying back to date management, better date management immutable data structures and observable JavaScript. So I just think just from this survey alone, you can see what JavaScript developers are having trouble with and what they think should be improved upon.

So I do think we'll be seeing hopefully improvements in JS addressing these pain points in the next couple years.

Yeah. Yeah. I hope so too. Again, like in my numerical separator example before it's always time is like the crux of so many development problems, it's time zones off by one error, it's just managing dates. So it's always tough. Cool. Yeah. Is there anything else that you observed or noted in putting together this talk or just in reading through the survey that you wanted to talk about, or maybe steer?

[00:29:00] Listeners towards.

Yeah, I guess I can talk a bit about, how the popularity of frameworks have been going in the last couple years, which I thought was interesting, personally. So, for example interest in front end frameworks, Svelte hopefully I'm pronouncing that correctly Svelte Has been introduced since 2019 and since then has been gaining a steady increase in adoption While things like Vue and React there's still a pretty large interest in them But it has fallen slightly the past couple years probably because of the introduction of Svelte The biggest fall we've seen actually has been in Angular.

So JavaScript developers apparently are not as interested in Angular anymore I'm guessing probably due to a lot of the newer frameworks that being said adoption is still pretty high just because a lot of the Apps written in the last couple years, you know are in angular and then we have ember which is staying pretty steady at around like 20 percent interest rate And it has not really gone up or gone down.

So [00:30:00] I figure ember will just chill there for a while longer yeah,

Yeah. Have you explored any of these frameworks recently yourself and been impressed by the newer players at all?

I would say that i'm mostly a react developer. I am pretty happy with a lot of the improvements react have made in the past couple of years and, react native is pretty cool. I have not had a chance to really work in Svelte, but seeing how many people are interested in it and how happy those users are, I would be happy to give it a shot.

Yeah. Yeah. If you do, I'd recommend I think the interesting story with Svelte is how early Svelte kit was introduced into the ecosystem and, how much that is influencing . You know, The whole language in the community or it's the framework in the community and how people think about it.

Yeah, so I think a lot of this stuff is worth, a weekend project at least to see for devs to understand what's out there. Cool. Nice. Well, thank you so much for coming on and chatting with me, Christina. It's been a pleasure.

Yeah. I had a lot of fun today and it'll be really great to see, where JavaScript goes the next couple of years. I [00:31:00] think it'll be a very exciting time.

Yeah. Yeah. I agree. I agree. Yeah. There's a lot to pay attention to again. Yeah. Thank you so much.

Great. Thank you.