Hasty Treat - Seven Interesting JavaScript Proposals - Async Do, JSON Modules, Immutable Array Methods, and More!

key.

Welcome to Syntax, and this is the 300 and 65th episode.

And we are gonna be talking about 7 interesting JavaScript proposals.

These are gonna be things that are at various levels. They call them stages. There are various levels. Some of them may see the light of the day, and some of them just maybe just relinquished to a GitHub issue at some point for the rest of their lives.

Hey, everybody. Hey.

I did talk about same proposals. I love talking about stuff that could possibly come to JavaScript.

It's like when you were a kid and you're looking at the LEGOs catalog, and you're like, oh, man. I could get that Lego system or this one.

Landon does it all the time. He, like, goes to sleep with his Lego Catalogs in his bed so that he can, like, look at them and be like, oh, what is Legos?

My kids have been doing that with the flyers. So we get this, like, Newspaper thrown on our porch, like, once every week or 2.

And we've tried to get them to stop, but they won't. So our kids are now excited when it comes because they get to look at all the Fliers Nice. For all the grocery stores and Oh, yeah. And stuff like that. It's hilarious.

Oh, that's very funny. CSF. This episode is sponsored by 2 amazing companies, one of which is DQ, and the other one is LogRocket.

Now LogRocket is the perfect Place for you to see all of your errors and exceptions happen, and I mean actually see them in a video scribble replay with your network Quest, your Air Log, all that and more.

And it works with all the systems you know and love, whether you're working with, let's say, you know, or React and Redux setup. You can even check Got your Redux store inside of this. That's a a killer feature. But it works with any platforms, not just React and Redux, but just about anything that you could Think about it. It's gonna trigger a warning. It's gonna show up in your dashboard. You're gonna get to see a scrubbable video replay along with the error as it happens. So if the user clicks a button, and it turns your website into, a Sharkosaurus, which is one of Landon's favorite animals.

It's not a real animal. If it turns your website into a shark asaurus, you'll get to see how they did that somehow by Log Rocket. So head on over to logrocketdot s forward slash syntax where you will get 14 days for free. So check it out at logrecord.comforward/

syntax. We're also sponsored by DQ. They are the trusted leaders in web accessibility.

You've probably used their axe dev tools.

If you haven't, their axe dev tools are a little thing you install in your browser, and you run it on your website. And it tells you about all kinds of little accessibility issues that may be Creeping into your website. Well, I'm here to tell you about DQ's Axe DevTools Pro, which contains all kinds of stuff including automated and intelligent guided testing.

It can perform all kinds of advanced accessibility testing. You can test part of the website.

You save time, get it right the 1st time. You wanna check out axe dev tools, and definitely take the 14 day free trial at d q. That's deque.com Forward slash syntax.

Alright. Let's jump on into it. We got 7 proposals here that may or may not come to JavaScript.

I like to look at all the proposals myself. Oh, yeah. If you just go to GitHub.comforward/gc39, that's the committee that regulates ECMAScript, which is what JavaScript is. I I don't even know if we necessarily have a good explanation for Why is it called ECMAScript and then the language is called JavaScript? Right? Because I think, when Flash ActionScript was a thing, I think ECMAScript Flash was also based on ECMAScript standard. Is that true? That is very true. Is there other languages that are based on ECMAScript now?

So I think so.

I'm I'm waiting for Wikipedia to load, but I think so. But I don't know so.

Oh, here we go. Major implementations of ECMAScript.

JavaScript, SpiderMonkey.

SpiderMonkey is the engine written by, Brendan Eich, v eight, ActionScript, JScript, which is Microsoft's implementation, QTscript, Inscript, And Google Apps Script. Oh, it's interesting actually because, yeah, Google Apps has its own, like, scripting language, which is not full blown JavaScript. So I guess that is 1. And, also, Cloudflare has their own implementation of JavaScript, which is not Node. Js. We should talk about that on a show at one point. I did not know that. Because I guess, because, like, if you think about it, there's the browser has implemented JavaScript, all of the browsers. Node has implemented JavaScript With, I guess, with v eight, Deno has. And then, like, it's a bit weird that Cloudflare has its own version of JavaScript and then Google Apps Script, I guess. I've never

Never dove too much into that, but I'm sure there's some some folks in that. Anyways So I wasn't too off. I said v eight. I wasn't yeah. I wasn't too far off. Okay. Neat.

So ECMAS e t c 39 is the ECMAS or committee. They are the ones that decide what features will come to JavaScript, and they have a forward slash proposals GitHub.

That gives you a list of stage 1 or stage 0, stage 1, stage 2, and stage 3. And once it reaches Stage 3, then it will be added to the language. So anything in stage 3 is kinda like, alright, this thing is solidified.

Stuff in stage 0 is just pie in the sky ideas, and we're gonna go through a whole bunch of different ones. So Oh, and we should say that things can go backwards too. It's not often that that happens. And I I don't know if they can go all the like, how far they can go backwards, but decorators famously went backwards in a stage. Oh, yeah. Decorator is now in stage 2. I think there's, like, a new decorator's proposal.

Interesting.

It's good. It's it's really frustrating sometimes, but people are just making sure that they get the stuff right. Otherwise, we're gonna we have to live with it for the rest of our lives. Yeah. You bet. You wanna grab the first one there? Yeah. Let's get started on the first one. The first one is proposal

JSON modules. Now this is a really cool one Because, typically, if you've ever imported maybe something that is not a JS file in JavaScript, you might not know this, but many times that's Just your bundler who's deciding what to do with that file. So to give you a little bit of an insight in the importing of different types of files, If you have, let's say, a a setup and you were using, let's say, Vite, and you wanted to import a GraphQL file, What that actually does is the bundler sees that GraphQL file. It goes to a plug in that knows how to resolve a dot GraphQL file. It transforms it into a literal jace JavaScript file and then returns that from the import. So what you're not doing is you're not importing a GraphQL file. You are importing a JS file that's been transpiled from a a GraphQL file, and that's pretty much the same for most of these things. So With this, this is not that, and that's why this is so exciting. This allows you to assert a different type of File that you're importing, and this particular one is JSON.

There might be others in the future, but basically, the way the syntax works is the same as your normal JavaScript import For e s m, so you do import thing from, file path dot JSON. Right? Like a normal JSON. Only this time, you get to add an extra keyword at the end Assert.

And then you say assert and then brackets, type colon, JSON inside of a string.

And that tells JavaScript that, hey. This thing is a JSON file. And guess what? Because it's a JSON file, you can now use that data As if it were just data, and that does not require any additional transpilation on that import.

Or parsing either. Like, It parses it for you. Right? Yeah. So

that's very good. And I think this is actually going to be a trend in which we'll see other things being Importable as well. Maybe CSS and stuff like that as well. Yeah. Important things to note here is that it is just a single default import,

Meaning that you cannot import, like, a sub property of that object. So that's that's good to know. There's only one thing.

And the difference between JavaScript and JSON is that it's not executed, and this is to avoid security issues. So if you were importing Some data from a third party URL, it will not execute any JavaScript that was sneakily put in there. Even though you think you're importing JSON, it's it's actually importing JavaScript, so you don't have to worry about that. And then the last thing, I just looked this up. And If you're using e s m, e s modules in Node. Js, you currently cannot import JSON that way. There is a flag In node called experimental JSON modules, because, like, with common JS, you can just import JSON, and it just works.

But because that is not part of the ECMAScript spec, there's no way to do it in Node currently. They have a flag for it, which doesn't look like The same thing as what we're talking about here, but I think that it also says in the docs, this is experimental.

And We are waiting for the JSON module specification to be finished, which is will be ideal. Yeah. And this is part of the import assertions, which is

used to be Part of the same proposal, and now it's been broken off into a separate proposal called import assertions.

So something really need to keep an eye on there.

Next one we have here is proposal array find from last, And this one is very, very simple. This will simple.

This will add dot find last and dot find last index methods to any array.

So if you are trying to find something in an array, you can look from the end first. And that's really helpful because, Currently, if you want to reverse an array, that's a a mutation method, meaning that the original array will be reversed. So there's not Really a great way to start looking from, like let's say you have a list of a 100 tweets and you wanna find the last instance of somebody tweeting about syntax f m. In that case, you would have to copy the array, then reverse it because that's a mutation array, and then you would have to find it. And with these methods, it would just Take the original array. You don't have to duplicate it or make a copy or reverse it or anything. Just start looking from the back forward.

Have you ever used Python? I just wanna maybe say that out of the bat.

Years ago has Been a been a while, but I did do 1 project where I had to write a couple lines.

I remember there being some, like, really awesome array stuff in Python that we don't have using, like, dot dots where you could quickly and easily grab a specific range of items and stuff from, an array. I wish I I wish I had some syntax in front of me. It's been a while since I've written Python, But I remember really liking that, and I did see at some point a proposal for something like that. If you know what that is, maybe tweet it out of this. I can't find it right now, but I thought that was pretty pretty neat. Could be interesting stuff. I I you know, we we work with arrays so much. It's really nice that So many of these things have to do with arrays, so to say.

So next 1 is going to be the async do, which, you know, that sounds like Some morning dew that just arrived. Yeah. Sounds like a sick Mountain Dew, like, limited version. Yeah. And so what an Think do is basically, you could think of it as just a block of asynchronous code where you can await things. Now typically, what you have to do right now, If you want a a block of code that you can await things on is you typically would have to either put it in a function and call that function. That an async function or, you could do an async IFFE, which is a self invoking function, which this intact For that, you could just Google self invoking f. A function that you define and then call instantly without a like an anonymous function that you define and call instantly, or there's the top level await, Which is going to allow you to await things at the top level. But if this this is specifically not for top level await usage, but this is Something like you would think of any block of code where you're all of a sudden, like, you know what? I'd really need to await something right here, but I don't need to make this entire function Synchronous or or this entire block asynchronous or whatever. I just have this bit of code, a block of code. You could use an async do. And the way this works is you just do async, Do and then brackets. The curly brackets. Yeah. It's almost like a function without being a function. It's almost like a self calling function without there being a self calling function. Yeah. And and that makes sense. I think the the one downside I see to this right away is that if you need to

get access to the values of that asynchronous code outside side of the block because you most people are using, let or cons. Those are block scoped. Mhmm. The async do would be a block, then you would be You would have to create, like, a variable outside of the block and then just update that variable inside of it. But it's just one of those things where, like, I I wouldn't use that all the time, but I can definitely see myself

finding it useful in little situations. You got a little example here with Promise dot all. Yeah. I put some code a code snippet in because I thought this was kind of neat where they wrapped a couple of async do statements inside of a promise all array That would allow you to essentially use those various what are the different ones? Promise all? All settled

dot What are the other ones? We did an entire episode on them. I know. I have a course on them. Yeah. Either way, it allows you to use any of those other promise resolving, you know, sequences that you can have. So that's kinda cool. Yeah. Yeah. I think so as as well. I'm be very curious to see if we will be getting this type of thing.

I'm just looking at that promise example. Like, yeah, you couldn't do that. You would have to define the functions outside of the promise and then pass them in and call them, Unless, I guess, you use an iffy. So cool. Cool. Next one we have here is proposal change array by copy. So this is A massive proposal currently in stage 1, so very early days, where it's proposing every single array method That currently is, a a mutation method, meaning that, like, some of our methods like dotmap and dot filter. Split Those just return I'm sorry. You're you're you were doing the what's it called ones, and I was doing the the mutated ones. I was doing the immutable ones. Yeah. So those those ones return a new array and don't modify the original array. But some of them, like reverse.

Split. They and and split and splice and and sort, those all modified the original array, and you kinda have to, like, Keep this running tally in your head that half of them are gonna mess with the original data, and the other half of them won't. So this is a proposal to add And in general, in in, like, functional programming, people just take a copy of the array before they mess with it just so that you have the original data if you need it. And then you don't get these weird side effects or you you pass in an array to a function. You accidentally mess with the original data. So that's really nice, and this is a proposal to add, basically, immutable versions of all of these methods

to Arrays. Yeah. And I do wanna say that my my split comment doesn't even apply in either regard. So you can just strike that from the record that I even said the word Split at all because that that does not apply here. Split is not a method. Yeah. I was I was thinking of splice, but what's neat about this is the naming of them where you have the e d to the word that's typically been used. So for instance, You would have splice becomes spliced, and sort becomes sorted.

Shift becomes shifted. Opt and pushed. To me, I understand that language because it's saying, hey. Give me the shifted array, not shift this array.

That's that's the way I'm thinking about it. Yeah. I like the I like the naming at first. Does that make sense? Yeah. 1st, I was like, I don't know about this, but now I like it. I like it a lot. Yeah. I think that this would be a good idea. And, like, there's no

I don't think there's any harm in adding these. It would only simplify the fact that You can go all in on being immutable, and then you don't have to do that weird thing where you

copy the array. Or And it makes your code more readable.

Because the moment you start throwing in spread operators and stuff on arrays and whatever, it's not that that that code is unreadable. I like that code. But if You don't have to have it. It'll be, you know, that much more readable. Oh, and it says under motivation,

tupoldot prototype. So there's a proposal for Adding tuples to JavaScript. We've done a an entire episode on records and tuples. You can go and listen to what that means. But it says it introduces these functions as a way to deal with the immutable aspect of a tuple. So I guess we are getting all of these

In tuples, so why not have them in arrays as well? For sure. And you know what's really lovely? And, I I mean, if I had to put on my top ten list of, Scott, stop down list of JavaScript proposals he most wants to see. You know, records and tuples are very high up there for me. And so is this next one actually, which is the, Temporal proposal, which we did a whole show on episode at number 295.

Wow. 295. I can't believe. Wow. 365 already, and that's 295.

We did a hasty treat on the new temporal date objects in JavaScript. I'll have a link to that in the show notes. That was a really great episode. We broke down what's going on with this thing, but, basically, There's just their chance to make the dates date object and and dates in in JavaScript better because they you know, everybody reaches for a date library, whether it's DataFNS or a moment or anything like that. For working with dates, JavaScript's never been a ton of fun, and it's probably one of the biggest weak points of the language overall. So The, temporal proposal looks very, very good. If you wanna learn more about this one, just pop on over to the link in the show notes or just, search for it in your podcast player. Next one we have here is the proposal

as pattern. This one took a couple of reads to actually understand Why would you even need this? And Scott has a comment here in our notes. Scott don't get it.

Yes.

I read it 2 or 3 times, and I was like, oh, I don't. I mean, I don't I don't I mean yeah. I don't get it. If you think you know, like, sometimes you look at all this destructuring and

variable renaming, and you you look at all these The functions and and whatnot, you know, like, hokey doodle. Well, this will make it even more, complicated, but I actually figured out What the the benefit of it is. So, the idea is is when you are destructuring either an object or a parameter into a function, You are able to capture both the high level value of a destructuring as well as the lower level Structured variable. So meaning that if you have a variable called person, and then inside of the person, you have Names and then inside of the names you have first. If you wanted to destructure that first, which is 3 levels deep into a variable, You can do that with the curly brackets, but the problem is is then you you sort of give up the ability to destructure the entire person variable. And what this will allow you to do is Is do both. You can get the low level destructured variable as, like, first name, but then you can also say as person. And you can just structure the entire thing into a person variable, which seems to be pretty handy.

Not sure if this one will be added. I can think of A handful of times where I've actually run into that issue, but then I just say to myself, well, if I need the whole thing, then why don't I grab the whole thing and then and then just Access the property nested or pop a destructure on the next line to get the values that I want. It's very funny. I,

that that makes me get it. And and, honestly, I have had those moments where I'm like, oh, this would be nice to have. So that was a good explanation. What do you think? I get it. Yeah. And I also think that if we do make syntax merch, we need something that says hokey doodle on it because that's a really great catchphrase.

Hokey doodle. Hokey doodle.

Hokey doodle. That's a lot.

Next one is going to be, the proposal for pattern matching. Now Those of you who've ever given Rust a try will know exactly kind of what this is doing. And in fact, when I was doing my little Rust bit when I was really experimenting with it quite a bit, I learned that match is, like, primarily how you write things like This in Rust. I mean, this is, like, the way to do it. So what is it? Well, it's kind of like a fancy switch statement, and I would imagine that, CSF. Rust's popularity is one of the reasons why this is even existing. I I I mean, I could be speaking completely out of my butt there. But, you know, I think people seem to like this. And and so it is like a pattern matching switch statement, where, basically, a switch statement. You have a value. You check to see what that value is. And, well, if it's that, then you you you do the thing. But with this, it's a little bit more you can match a whole bunch of things. Yeah. Like a programmatic

switch statement?

Yeah. And so, you can check for multiple parameters inside of an object.

So the whole the whole thing is basically it's a match. Here's the thing you're checking, and those are wrapped inside of brackets, then you have a win statement.

And the win statement has parentheses, and inside of that win statement is sort of like What you typically are looking at.

So you'd be able to do things like regex match matching, but also just, basically, you could think of it as like a Turbocharged switch statement that allows you to, do a whole lot more than just checking a single value.

So I found this neat little snippet, because some of the examples are kinda hard to parse, but this one definitely feels like it's not hard to parse because what it is, it's basically a An inline switch that you could use inside of JSX.

So let's say you had a React component and you were checking a prop. Maybe you could think of it as, like, you have a React query or Apollo's coming back with several different things, and you have a props object. So you could say match props When loading, then show the loading screen. When error, show the error screen. When data, show the error. But that's actually looking at the properties themselves that are inside of props, not like a string value. Man, talking about code like this, especially complex code on a podcast, tough sometimes, but We'll have a link to this in the show notes. You can check it out. It basically would be pretty nice for something like that. All you need to know was that it's a supercharged

switch statement at the end of the day. So this also works with the last thing that we talked about, which is the as. And you can use regex To do multiple matches, and then you can destructure the matches into their own variables.

So you can say when it matches these things, then the 1st match thing is going to be property 1, and 2nd match thing will be property 2.

Wow. This is a big one. It's a big one. And like I said, in in Rust, this was like the way you do just about any kind of thing like this. It felt like you were using a match instead of the if statements for many things. So this complex if statements or anything like that, switch statements, this looks like pretty pretty wild. I'm into it. There's some really interesting stuff in here. This one says specifically,

draws features from Rust, Python, f Sharp, HerbScala, Elixir, Erlang, and c plus plus,

which is like JavaScript's growing up. Smart folks use those languages, and Yeah. Yeah. Definitely.

I believe that is it. Those are the 7 proposals that we may or may not be coming to JavaScript. We'll be sure to update them as those things change, but it's always fun to take a look into the language of JavaScript itself and how it can evolve and how it does evolve over the years. Yeah. At least we know we're getting the temporal.

At least we're getting that one for sure. Definitely. Yes. That I'm really excited about that one. And that one That one hasn't been, like, totally solidified, but it has a fully featured polyfill. Yeah. So if you were okay with Throwing the dice on that one as to if the API would be stable, then you could start using it already today. Okay. And I'll find the link for that polyfill and toss it into the show notes because, gotta have it. Gotta have it. Gotta have it. Alright. Thank you so much for tuning in, and we will At you on Wednesday. Peace. Peace.

Head on over to syntax.fm for a Full archive of all of our shows. And don't forget to subscribe in your podcast player or drop a review if you like this show.