Hey, folks, welcome back to another episode of JavaScript Jabber.
This week, on our panel, we have.
Dan Spear Hello from Tel Aviv, and.
I'm Charles Maxwo from top Endevs. This week, we're gonna be talking about what's new in JavaScript. It's a new year. There's a bunch of stuff that came out last year or so, and so Dan was pointing them out to me, and that's what we're gonna talk about today. So, Dan, I know you have a list. I don't have the list in front of me, so I.
Will let you just.
Yeah, I'll let you steer the ship and I'll.
Provide the color commentary.
Yeah. So it's been a while since we've spoken about what's new in JavaScript. You know, everybody's talking about what's new in frameworks, what's new in CSS, what's new in HDMO. But the JavaScript, you know, there was this period of time where things are coming out, you know, fast and furious, and then it seemed like everything kind of settled down. But turns out that you know, new features are being introduced. So I thought it would be worthwhile to talk about it.
We actually spoke about it a year and a half ago in episode of five ninety and it's interesting to contrast what has moved forward and what hasn't. So, first of all, for our listeners, for anybody who may not know, there's this thing which is the JavaScript standard but is not actually called JavaScript. It's called ekmascript instead, which Brendan Iike, the creator of JavaScript, has likened to a skin disease.
It's really easy to remember too. I mean, EKMA script just rolled.
Roll yeah, rolls off the tongue. EKMA is actually the EKMA International is a standards organization. It was originally the europe In Computer Manufacturers Association, but then they just decided that it's EKMA and you know, not the credentials anymore. But so why is this standard called ekmascript rather than JavaScript? I mean, the fact that it happens to be handled by the ATMA organization should not have changed the name of the language, or at least the standard of the language.
And the reason is that they don't have the copyright to the JavaScript name.
That called trademark technically, but yes.
Yeah, it's a trademark and it's being held by Oracle exactly. The name escaped me all of a sudden, and it's a funny story. Because in case you know listeners don't know, they probably don't. JavaScript was created in by Brendan Ike in Ten Days of Glory back in nineteen ninety five
while he was working at Netscape. They were working in corporation with Sun, which was this the creators of Java, and they they had this kind of corporation where JavaScript was supposed to be the scripting language in the browser and Java was supposed to be the actual heavy duty programming language in the browser. That didn't happen. But what did happen was that Son ended up with the JavaScript trademark, and then.
Because they owned the trademark to Java.
To be honest, I'm not sure either because of that or because that was part of the deal of their corporation with the Netscape. Either way, they ended up with a trademark, and then they were bought by Oracle. So now Oracle holds that trademark and they've literally done nothing with it. So there's this new movement now to actually free that trademark from Oracle. They've actually reached out to Oracle, They've reached out to the governmental body that's responsible for trademarks.
There's an online petition that everybody can sign at JavaScript dot tm fitting url. I signed it, and I encourage our listeners to sign it, and hopefully eventually it will be released. This is actually being led by Ryan Dahl from Dino, who we've interviewed a few months back. So he wrote an interesting blog post about it. We can link to it. He gives the entire history and everything. I hope it's released and we can finally call it JavaScript rather than ekmascript. But be that as it may.
That's the name of the standard and it's being handled by a committee within EKMA called TC thirty nine.
And TC I was gonna say, if you're wondering what the cryptic name, TC thirty nine is literally technical committee or something like.
That, exactly, it's Technical Committee thirty nine. Their whole bunch of technical committees within EKMA, and that's the number they got and they have this whole process of how to introduce features into the JavaScript language. Originally this process had forced five stages sorry, zero through four, because well, you know, everything should be zero based. But now they've actually added an intrim stage two point seven, so now they have
six stages and to run through them really quickly. Stage zero is basically it's a new proposal, it's not even really considered. Basically, you've had an idea and you've written down a note about it and sent it to the committee. That's more or less what stage zero means. It's hardly anything, really, but it's the starting point for all proposals in that are process by the committee. When the Committee decides to actually look at a particular proposal, it moves to stage one.
That means that that proposal is under consideration. The committee expects to devote time examining and identifying the need for that proposal, what it's supposed to address or improve or fix, and basically compare it to other alternative solutions that might exist, and decide whether it's worthwhile to pursue. They need to identify somebody to champion that proposal. They expect an outline to be written and so and discuss algorithms and abstractions
and semantics and so forth, all the good stuff. So that's stage one. Stage two is when the committee has chosen a preferred solution or maybe a few solutions in a in a particular solution space, but the design is very much still a draft and may change significantly before it's actually introduced into the language. The committee actually expects something to be developed and eventually introduced into the language. They're just not absolutely sure what it is yet and
how exactly it's going to look. And at that point they expect, obviously the thing to be much better documented and you know, for people to start experimenting with it and actually have something real to examine. Now, they've introduced a new stage called two point seven because they didn't want to move stage two or stage three, and they wanted to put something in between. So stage two point seven means that the proposal is approved in principle and
is currently undergoing validation. That means that maybe a browser manufacturer has put it behind a feature flag, or maybe there's a Babel plug in or something like. Somebody is playing with it, experimenting it and with it, and you can start seeing how it actually works and whether it actually feels like a good idea. Stage three is when the proposal has been recommended for implementation and no changes
to the proposal are expected. In other words, they feel pretty confident that this is how it's going to be, but it's not yet part of the standard, and therefore backward compatibility is not yet required, which means that if somebody comes up with a better idea, or they they start suddenly discover a problem with it, they can battrack so they can even you know, move it back to a stage two or even to or two point seven
something like that. And finally you've got stage four, which means that the proposal is feature complete and is ready to be included in the standard. Essentially, it means that it's effectively part of the standard. It's just that a new standard document has not yet been released. One is released once a year, So the proposals that are complete weight at stage four until they are included in the
next release standard. And usually by the time they're in stage four, you actually find them implemented in browsers and you can actually start using them. So far, so good.
M Yeah, it's funny too, because you're talking about this process and two things are going through my head, and one is it sounds complicated, but yeah, I mean, if you really think about the progression, it all makes sense.
Right.
The other thing that's going through my head is we're currently heading into a legislative session in the state of Utah, and so I've been going through the process that bills go through the past and they're going, I'm going, Wow, this is in some way simpler and in some ways more complicated than the political process.
In certain ways, it has to be, because unlike the political process, these kind of standards are really set in stone. When something is added into JavaScript, it can never really be removed. Yeah, which means that we had better be really certain about adding it into the standard. And you've got, like I said, you've got the browser manufacturers on this committee, and they've got to really approve it and say, you know,
this is something that we can actually implement. You know, somebody might have this great idea, but implementing it would turn JavaScript on its head. Then obviously the browser manufacturers will push back and won't approve it.
Yep.
So let's put it this way. The attitude is better safe than sorry, and that's a good attitude to have in the context of language standard, especially a languagelike JavaScript. Where As I said, once something is added, it can never be removed.
I really wish that our legislators would do better safe than sorry. Let's think a little more deeply about this before we pass it or not? Right?
Yeah, but yeah, I completely agree, and I think it's good context that JavaScript has always gone way out of its way to be backward compatible. I'm sure there's sometimes where there was just something that they had to kind of roll back, but.
Actually, the one time that I can think of where effectively things were rolled back was they introduced strict mode. And even then they introduce they roll them back by introducing strict mode, So if you're running outside strict mode,
they're still there. They wanted to roll back, for example, the with keyword, and I won't get into the details of why it turned out to be a bad idea in the context of the JavaScript programming language, but they couldn't remove it, and so instead they kind of rolled it back by making strict mode more and more the common way in which JavaScript work and in strict mode with does not exist. Right.
Yeah, And if you're wondering, if you're if you're newer to javascripts and you're saying, what what what is strict mode, don't worry about it.
You're using strict mode.
Yeah, just so you know, you know, we mentioned it, so we might as well provide details. You can explicitly enter strict mode by having the use strict string at the top of a scope or the top of a file. You can't actually ever exit strict mode. You only enter strict mode. And you enter strict mode by default in ekmascript modules. So if you implement a module, it's strict
mode by definition. In HTML, that's if you have a script tagged with the type equals module, it's strict mode by default, and then you can do module things like imports and stuff like that. You also strict mode by default in classes, because again, classes are kind of a new type of a scope, and it makes sense to be strict by default inside classes.
Yeah.
I think most people working within the context of JavaScript, though, they're working under some system that puts them in strict mode without them.
Yeah, because they're building hopefully they're building ekmascript modules these.
Days, yeah, or React projects or you know, whatever other framework or library you're using, generally use modules, and so you're generally put into this box anyway.
And I really can't think of any other occurrence where something was effectively removed out of JavaScript, so you know, it's interesting. Yeah, anyway, So let's talk about a couple of these enhancements and proposals. But before we dive into them, it's really worthwhile to highlight the fact that none of them really significantly or maybe even at all, change the
JavaScript syntax or semantics. So you've got nothing new like the arrow functions syntax or let or cons or stuff like that which really changed the way that JavaScript kind of worked. Well, there is one towards the end, but it's still at stage three, and we'll see if we make it all the way to that one. But all the rest can are better described as being part of
a quote unquote JavaScript standard library. They've added new object types and new methods or functions that are built in that you can use instead of let's say, importing some NPM module that would implement them. So we've got more standard functionality being provided out of the box by the JavaScript runtime environment itself, be it the browser or vi it node or whatever.
Yeah, so what I'm hearing is is that if you're using these feature, you may be already be using these features.
They're just now official standard kind of stuff.
Yeah, you might have there's a good chance that you might have imported such functionality before. Now it's built in and you do need to import it anymore. Kind of like the browsers started providing fetch as a built in function, and you didn't need something like an axios anymore. Ye. So the first one I would like to mention is
something that's actually five years old. It's from ES twenty twenty, and it's called promise dot all settled, and as its name implies, it waits for all this provided promises to be settled. Now, you know, it's very common when working with promises to need to wait on a couple of promises simultaneously, effectively in parallel. And when most developers need to do that, I see most of them reaching out for promise dot all and just using promise dot all.
But what they might have not considered is the fact that promised dot all short circuits on a rejected promise. So promise dot all receives an area of promises and it waits in parallel on all of them. It returns a promise that resolves when all the provided promises resolve. But if even one of those promises reject, then the return promise immediately rejects. And that may not be what you're looking for. It may be, but it may not be.
Sometimes you actually want to wait on all the promises provided until they are all of them either resolved or rejected. In other words, all of them are settled, and hence the name of the method, all settled.
Right, So let me see if I can restate this in a different way. So, if you promised dot all, Yeah, if one of them rejects, you get rejected.
I media doesn't.
Yeah, but it doesn't tell you that they've all finished waiting for whatever it is that they're waiting for, And so effectively the all settles it does more or less the same thing. But if you have one of them that's still waiting for whatever, you know, whether it's going to reject or fulfill or anything else.
So think about the simple scenario. Let's say you have two promises, sorry, let's say even three promises, and you pass the area of the three promises into promise all. Let's say the first one resolves, that's great, and then the second, then the other two are still pending, and then the second one rejects. Then it will immediately return with a reject. It won't wait on the third one to either resolve or reject, and it won't also tell you that the first one resolved. It will just tell
you that, hey, this thing rejected, okay. Whereas with promise all settled, what you get back is an area of objects. First of all, it waits on all three, so even if the second one rejected, it will still continue to wait until the third one completes, and then it will return an array of objects, and each object has a field that indicates whether or not it resolved or rejected. So I wanted to have this open, and I forgot. I just posted a link to Yeah, MDN is always there. Yeah,
MDN is always the best. So it basically returns an array of objects, one per each promise it had. Each element of those rays is an object where and it has a property called status, and that status could be either fulfilled or rejected. It has it. If it's fulfilled, then it will have a field called value with the resolved value, and if it if it was rejected, it would have a field called reason with the appropriate rejection reasons.
So this way you can look at all the promises and see whether they resolved or rejected and what they actually returned. And as I said, in a lot of cases, that's actually what you want rather than just promised dot all. But a lot of people are not familiar with it and use promise dot all when they should have actually used promise all settled.
So MDN makes it look like because it calls promise dot all settled, you pass in the array and then it calls dot then so does it operate as a promise as well?
Yeah, yeah, it returns a promise that resolves to that array of objects.
Right, Yeah, I just wanted to, you know, clarify because you said it returns that, but it does. It's a promise that resolves to that array of so it has to wait for everything to finish exactly.
That's cool.
So I'm going to ask another question that's not about all settled. But you said this is from five years ago. So when you say that we're talking about new things in JavaScript, are these things that are now generally implemented or are these just things that, hey, these have passed in the last however long and people ought to know about them, or what's your criteria for making the list?
Well, first of all, this is the oldest one. Everything else that I'm going to be talking about is newer than that, And I guess my criteria was relatively new things that our listeners might thought known about. Now I think that things that are actually already part of the standard are generally much more interesting that things that are not yet part of the standard. I mean, you know, things that are not part of the standard might be
really cool. Usually they often push the envelope a lot more, which is one of the reasons that the committee is kind of hesitant about adding them actually into the language. But I think that when you've got a functionality that can actually be used and provides real value, that's more pertinent, let's say, than some pie in the sky that might never actually arrive.
Right, So these are probably just hidden gems that you may not have known got added to the language.
Exactly over the last five years, I guess. The next one is from ES twenty twenty two, so it's almost three years old, and it's the dot at method on arrays, strings and type rays, and you basically give it an index and you get back the item. So it's really like using the square brackets in a lot of ways. And you might ask yourself, well, why do I need it, Why don't I just use the square brackets, And the reason is that you can also provide it with negative
numbers and then you're indexing from the end. So if you do dot at on an array and pass in minus one, you're looking at the last element in the array.
Interesting.
Now, that's actually how various other program earring languages actually work. So in other programming languages you might have been able to have the minus indexes in the square brackets themselves, but you can't do that in JavaScript because that's not how named properties work in JavaScript. And in JavaScript you could legally legally have a minus one property. Uh, so
you couldn't use that. And the funny thing is that this negative index has actually worked with the dot slice method for a long time, but then it would always return an array, right, And with dot at you get that actual element from the array, which is just nice.
Yeah, I've used other languages that do this with their array, so but they do it with the square brackets. And yeah, you're you're explaining why you couldn't do that and maintain backward compatibility with JavaScript.
But yeah, this is this is really cool. I like that.
Another one that's more of a you should use and probably don't is object dot has owned. Are you familiar with the has owned property? A method that so in JavaScript you can use there's the inoperator which tells you whether or not a property exists in an object. Objects in javas kind of work like property bags, and you can check to see whether a particular string is the name of a property in an object using the inoperator, But the inoperator also looks up the prototype chain, so it doesn't.
Always say this, this is cool. I just looked it up and I am yeah. Anyway, go ahead.
Now has owned property has existed forever as a way to check whether a property name exists in an object without going up the property chain. The problem with has owned property is that not all objects necessarily have it, because you need to have the object prototype in your prototype chain to actually have it, and it's not there by definition, so you might try to use his own property only to have it break because you're not actually
your object doesn't actually derive from object prototype. So the safer way is to do object dot has own as this kind of a global method static method, and the first parameter is the object you want to test, and the second parameter is the name of the property you want to check. So it's just a safer way. So the preferred way to check whether or not a specific object has a particular property is not using his own property, which is what most of us do, but rather using
object dot has owned. Yet I've don't recall ever seeing code actually work like that.
So right, So if you've this for example, could tell you if you've over ridden a property.
Right, you've written your own function For.
A lot of people, Yeah, a lot of people use JavaScript object objects as dictionaries. You know. Ideally I think they should be using the map object type, but a lot of people still like using simple objects because you know, it's easy to confer to from Jason and so forth. And you want to check whether, let's say, a certain property exists in a Jason object or not, so you might use check using has own property. You should actually check whether or not it exists using hazone.
Gotcha.
So those are two things that were added almost three years ago in EES twenty twenty two. Dot at an object has owned relatively new. I guess mostly not so much you used, but they're there and they're useful, and I guess people should be using them more. Moving on, Yes twenty twenty three. Here's a nice one that a lot of people I think might like, and this is find last on arrays. Sometimes you want to find the
last element matching a particular thing rather than the first. Now, obviously you can do reverse and then find, but why reverse the entire array when you can just do fine last.
Nice. It's funny because I'm I'm looking at the.
Oh, it does have fine last in here, but it also had fine last index, of which I guess is related but not the same.
Yeah, find and find last, return the actual value, find index off, and find less index off. Return the index of the found element.
Right, and this this finds a matching element, right, So you can pass it a function and you can say if this returns true on the element, then Yeah.
Let's say you want you have an area of numbers and you want to find the first one bigger than forty two. So you can pass in a function that compares the x. You know, you would do x errow x forty two, Yeah, exactly, and would find regular find you would find the first element greater than forty two, would find lass. You simply find the last item greater than forty two. Yeah, And like I said, usually what people would do is that they would reverse the array.
And it's kind of silly to need to reverse just to find the last one, right. Speaking about reverse, the next things that I wanted to mention that came out in twenty twenty three are the change array by copy again talking about things that were in JavaScript that are a bit unfortunate but cannot be fixed because backward compatibility. We have certain methods that modify arrays in place. So for example, if you do dot reverse on an array,
it reverses the array in place. Likewise, if you do dot sort, it sorts the array in place, and that's not how we want to work in a more quote unquote functional world. I guess they did it back in ninety five because for efficiency's sake, to avoid the extra locations. But you really, you know, it's you really want to avoid methods that modify objects in place if you can, if you can avoid it. So what they did is they introduced an alternatives, well not an alternatives, alternatives to
these methods that create a copy. So instead of reverse, there's this new dot too reversed, and to reverse does not modify the original array. Instead it returns a new array which is reversed. Likewise, you've got the dot two sorted, which again sorts an array, but rather than sorting in place, returns a new sorted copy. And you should be using these.
There's absolutely no reason. What I used to see are people copying the array by doing a dot slice and then doing a reverse on the copied array, And now they can just do too reversed or too sorted. There's also there's also a too spliced reminder splice. Unlike slice, it can be used to replace, to delete parts of an array and replace parts of an array. Too spliced does that, but instead of modifying the original array again returns a modified copy.
Yeah, there's also a two sorted.
Yeah, I mentioned already the two sorts and is Yeah. Yeah. The dot with is confusing because it's kind of not to something, So where did this come from? Dot with is like dot at, but it modifies the copy, so it modifies a particular item. You know. With dot at you could change the value of a particular item. With dot with, you give an index and a new value, and it replaced, and it creates a copy where that particular element you know, with that index has the new value.
So you might have an array let's say with one two three, you do dot with one comma forty two, so it will become one forty two three.
Yeah, and that I agree with you on this should be your default way to move through arrays. I mean, we we run into these problems all the time where you inadvertently change something that you didn't intend to, and so by doing things in this way, you'll avoid those issues unless you explicitly want to be changing that for a real good reason.
Exactly, and especially because in JavaScript, when you pass arrays into functions or methods, you're passing the reference to the array, right, so you're actually passing the reference to the original array. And if that method then or function then calls dot reverse on the array that was provided to it because it needs a reverse copy for some reason. But use reverse instead of two reversed. It not only modifies the array for itself but also for whomever called it, which
is totally unexpected behavior in most cases. Yep. So yeah, for sure going forward, always used two reversed instead of reverse, two sorted instead of sorts too, spliced instead of splice, and dot with whenever that makes sense. Continuing to move up the calendar, where you know we are now in twenty twenty five, let's look one year back twenty twenty four. We also got a couple of things. We got top level away and by top level. It means top level
of a module. So if you're creating an ECMAScript module, you can have a weight outside of a function body. In the past, you could only use a weights inside a sink functions. Now you can actually use a weights outside but at the global scope as it were, but only inside modules. You might use it to maybe import some sort of a dynamic mode, do some sort of dynamic module import, or maybe get some configuration file or
something like that. So you might want to do a fetch in order to get some configuration or something like that. But you really need to be careful with top level of weights because they block the module load. So if you've got one module weight importing a submodule and that submodule does a global a weight, then it blocks the module that imports it until that promise resolves. Is that clear?
Mm hmm.
Yeah.
There's there's a really good example on the proposal itself, and I posted a link to that the TC thirty nine proposal, where essentially what they're doing is they're running the A weight within a function. That's kind of the So you create a function and then you call the function is effectively what you're doing with the A weight in it that's an acin function, and they've done it with an immediately invoked acin function as well as just a named function that they call that's an acing function.
But yeah, yeah, I can see where this could be a foot gun or you can shoot yourself in the foot doing this, for sure, But I can also see the utility in it. Right.
It's like, in order for this module to do anything useful, I have to have this other thing.
Yeah. Without this data, I can't do anything. Yeah, so I really need to wait on that data before I can actually even finish loading. Right, But again, you should definitely be really careful about using top level of weight inside your actual code.
Yeah, I definitely have a reason to be doing this.
The next ones I want to mention, and they're really useful functions and have been available in a lot of other languages and are provided by libraries like low dash is object to dot group by and map dot group BI. Let's start with object group by. With object dot group by, you provide an array of stuff and the function that you invoke it sorry on on a collection of items, and you also provide a callback function which returns strings that describe each item in the sequence, and then it
groups the items based on the string value. It's kind of difficult to explain, but very often we want to take a collection of stuff and group those things according to what they are. So, for example, I've got I might have like different types of different objects in an array, and they also all of them have let's say a
different type which is a string. So I can group them according to that the value of their type property and have some return to one array of all the objects of one type, another area of all the objects of another type. It's instead of having to filter again and again and again, I can do it in one go.
Yeah, this is something that I use pretty frequently in other languages as well. But and there's a really good example on the MDM doc that I just posted. But yeah, I mean they give a list asparagus, bananas, goat, cherries, and fish. They all have a type property of vegetable, fruit or meat, and then it tells it to a group by type essentially. And I'm not going to read the syntax for you. You'll have to go look at
it because it's hard to just read out. But yeah, then it gives back an object that has properties of vegetables, fruit, and meat.
And it's shoved those objects up underneath that.
So it makes it really easy to, like you said, not have to iterate over at a zillion times if you're just sorting things or handling things based on on their type exactly.
Now, the only difference really between object dot group by and map dot group by is whether or not the result is an object with the various fields or a map with the various entries. Some people would prefer to work with a map, some people would prefer to work with an object, so they can use either object dot group by or map dot group by, but the algorithm is essentially exactly the same.
Yeah, it's interesting too because the so the on MDM for map dot group by, it hands it an array for the things that it's and it has the same list of things actually is object dot group by, but it hands it in an array for the thing that it's sorting, and yeah, it just gives back a map instead.
So kind of interesting there.
Now. The final one that I want to mention is one that's going to make a lot of our listeners kind of grown because a lot of people have really wanted something like that and have written a lot of boilerplate code to effectively implement this functionality, and so it's kind of nice to have it now built in out of the box. But on the other hand, I'm kind of worried that people will abuse it or misuse it.
It's promise dot with resolvers. When we create a promise, only the promise can kind of resolve or reject itself. So you do new promise, you pass in a function to the constructor with the resolve and reject, and that function and the promised constructor invokes that function, and only that code has access to the resolve or reject. You can't resolve or reject a function a promise sorry from
the outside. Now, what people do when they do want to be able to resolve reject a method of promise from the outside is then they actually copy resolve and reject into global variables outside the promised scope. And it kind of kind of feels wonky. Are you following what I'm trying to describe?
Uh, not entirely.
Let's say I have a promise, but I want to have some sort of an external event resolve it. So I do a new promise and I pass in the function that gets the resolve, but I can't resolve it from inside the promise. I want to have just an access to that resolve to resolve it somewhere else. So I copy the reference to the resolve and hand it over to somebody else, and then that somebody else can resolve me.
Okay, sounds complicated, but I think I understand. Let me see how I can restate it, just so that I get it. So I have a promise for whatever reason, I'm not going to use the default you know dot then to resolve or you know dot what are the other ones like that?
Or no, you're not, it's not exactly correct. Let's say you've got you do a new promise and you pass in a function with the resolve and that gets resolve and reject, and then you take the resolve and put it in window dot resolve, and you take the reject and you put it in window dot reject. Now you can call window dot resolve to resolve that promise. Uh huh.
So you're copying that resolve method out of the promise into somewhere else, and that in the case I just gave it to an into a glow effective into a global but you can also copy it into a local variable in a in a scope, but you're just helping it out of the promise. And I've seen a lot of instances where people needed to do that for some reason. They want to be they have a promise, but they want to be able to just resolve it from somewhere else.
Mm hm, I'm trying to think of why you would need to do.
This, but there's there are good examples in the end in the m d N, but I've seen a lot of examples of such things. I've even seen example of something like that within reacts on code when they implement UH, when they they kind of throw promises to UH to do too in order to implement suspense. So it's implemented by throwing promises, and you need to be able to resolve those promises from the outside, so they also kind of hold on to the resolve and reject of the
promises on the outside of the promise itself. Okay, So with resolvers actually does that for you in a kind of built in way. Instead of returning a promise, it returns an object that has three properties. A property called promise which is the promise, a property called resolve which is the resolver function, and a property called reject, which is the rejector function. Okay, So and you can destruct the return value and basically get the promise, get the resolver, and get the rejector.
Right.
So in cases where you need this kind of functionality, and as I said, I've seen this pattern used a whole bunch of times. It's now much easier and clean to do it because it's built into the language itself.
Okay, so from what I'm because I'm looking at the proposal as well. Now, so essentially what you do is you, yeah, you pat.
You do promise with resolvers, and it deconstructs the promise so that you just have references to the promise resolve and reject as as functions or objects.
And then and then you can yeah, and then you.
Can promise as an object and resolve and reject right.
And so so then what I can do is I can I can basically reference those wherever I need. So if I have something else that needs to resolve or reject the promise, it just.
It just called it can just called resolve or reject right directly.
Yeah, it can just do it without having to write, without having to do work some magic on the promise object to you know, get it the internals or something.
Like that exactly. So it's a it's a convenience method. You can definitely write the code yourself, but it was just really ugly boilerplate code. I've seen it done lots of code bases that that I've looked at, and it's nice to have a cleaner alternative, but you should have a good reason to use it rather than use it regular function promise semantics.
Yeah, it's funny because you were talking about people having implemented it, and on the TC thirty nine proposal, it's like existing implementations and it shows where reacted it and view did it, and Axios did.
It, and Typescript did it.
Exactly exactly, and so now it's built in and there's no reason for any of them to actually do it themselves.
Yeah, makes sense.
Okay, now we're kind of done with things that have already actually in the language. Let's look at things that are not yet officially part of any standard.
But are they are Stage four.
Which means that they are effectively part of the standard, just that the standard, the relevant standard has not been released yet. Now, funnily enough.
Hang on, so what does that mean?
It means that the they've adopted the proposal, but they haven't rewritten the ACMASCRIPT standard to include them yet.
Exactly. They release the standard once a year, so they'll release yes, twenty twenty five, sometimes later this year. But these things are kind of waiting for that document to be released.
I gotcha.
So people might be furiously working away at them now because they know now.
They're actually all of them. Are actually the ones that I'm going to mention are actually implemented in browsers. Oh okay, but but they're not because from the browsers manufacturer's perspective, they've they've arrived, right, So why wait for the document if we know that they are going to be part of the document?
Makes sense extra to the browsers.
Yes. Indeed, the funny thing is that I've actually mentioned them in that episode five ninety a year and a half ago. Only then they were stage three, so it took them a year and a half to progress the stage four.
Yeah, so again I like that they're being deliberate about it, So.
Yeah, for sure. So the first one are set methods. Do you know the set object type in JavaScript? Have you used it? No? Set is kind of like the set. In math, it's basically a collection type. Oh yes, where something can either be part of the set or not part of the set.
I thought you were talking about like a method on object or something called set object type.
But no, the set, yeah, I've.
Yeah, you do new set exactly, new set. You pass in an area of stuff to the constructor, and then those things are in the set. You can check whether something is in the set or not. You can add more stuff to the set or remove it from the set, but it's basically just to check if something is a part of a collection or not, and they and the thing is. As I alluded, set is really similar to
set in math. And there are a whole bunch of operators that you can apply on sets in math, and it makes sense to have them on sets in JavaScript as well. So you've got, for example, union, which can take two sets and return a new set, which is then union of those two sets, so that it contains all the items that are in each one of them. Now it's an union rather than a concatenation because everything
is in a set either either zero or one time. Right, So if it's a set of one two and another set of two three, and you do a union, you get a set with one two free right. Likewise, you've got dot intersection which can create an intersection of two sets, or dot difference which returns the difference between two sets. And uh, and these whole bunch of methods that have been introduced to sets and just makes working with sets,
like working with mathematical sets, much cleaner and easier. I assume that they were there was probably more than one package package on NPM that implemented all this functionality. It's pretty straightforward to implement, but now it's built in, so you don't need those NPM packages anymore.
Yeah.
Yeah, And it makes a lot of sense because typically when you're using because because other collection types, you know, dictionaries or arrays, you're you're.
Usually using those to hold all your data.
And like you said, I like the way you put it where it's a mathema like the mathematical set. So this is you typical use sets for certain types of operations, and so if you need a friendly and easy way to do those kinds of operations, you can use sets exactly.
That's what sets are for. So it's really nice to have those methods now built into the jobscript programming language. It's not like this big revolution. It's not like errow functions or like letter cons but it just makes JavaScript a nicer language out of the box.
Yeah, so sets are a new edition.
They didn't well, sets have been here for a long time. Sets were introduced with maps, I think way back in ES what's called ES six or EES twenty fifteen, so they've been here for like a decade. But it's nice to have these operations on sets now part of the standard. Okay, as I said, previously, you had sets, but if you wanted to do these an operation like union, you would have kind of needed to implement it yourself, and it
wasn't difficult. You could spread the set into an array, then cancat into the two arrays and create a new set out of them, and you would get the union, but a whole bunch of copying going on. So now you've got a cleaner, more efficient implementation and certainly an alternative to bringing in yet another NPM package. Right. The other thing that was Stage three and now is released and it's a bit more difficult to explain are sync
iterator helpers. So we've had episodes in the past, way back in twenty twenty one where I actually gave I talked for two whole episodes about iterators and why I think they're great, and I think I might have been able to convince AJ for the duration of the episode, and then he immediately chan is mine once then episode was over. Those were episodes for six eight and four six nine. For those who are interested in the details of what iterators are and how they work, I won't
go into too much detail. Basically, it means that we now have methods like dot map, map or dot filter or dot reduce on iterators like we have them on let's say arrays, And the easiest way to explain how to use them is think of let's say I have an array of stuff, and I would do array dot let's say map, and then dot filter and then dot reduce or something like that. Now I can wrap the array itself in something that in something it's iterator dot from.
So I do iterator with a capital I dot from on the array, and then on the return value from that, I do the dot map, dot filter, dot reduced, et cetera. Now you might ask yourself why would I do that and what's the difference. So, first of all, if it turns an iterator rather than an array. So if I then want to actually get an array in results as a result, I need to actually spread it into the result into an array. So you say, hey, this is
actually even more work. I needed to do add an iterator from on the original array and then spread the result into an array. And you know what's the upside of all this? Why would I want to do all this stuff? There are a couple of reasons. First of all, iterator dot from is not just for arrays. It's for anything that's iterable. So it means that if I now have a new collection type. So for example, maps or sets.
In JavaScript, there are collections they actually implement the four each, but they don't implement the filter, they don't implement a find, they don't implement a reduce, they don't implement filter. So how do I How do I invoke those methods on those types of collections. What I would usually see people doing is either avoid using these collections if they needed these methods, or alternatively copy them into arrays. And if you're going to copy them into arrays, then you might
as well have just used arrays. So now I can apply iterator from to anything that supports iterators, any collection type that supports iterators, and then I can use all these methods on that collection. So that's advantage number one. I don't need to implement those methods directly on each and every collection type. I just need to implement iterators in the collection, and then I can use these methods on any collection type, be it a built in collection
or one that I implement myself. Okay, so that's advantage number one. Okay. The second advantage is that it avoids all the intermediate arrays. When you do a dot map on an array, you get as a result or an array of the of the map. So when you do dot map, dot filter, dot whatever, you're getting a whole bunch of intermediate arrays that you're copying stuff from one to the next, to the next to the next and so forth. With iterators, they don't create those intermediate arrays.
They work by doing lazy evaluation. You just get the results that you need, only the computations that are required without all the intermediate arrays. So they're actually they can actually be a lot more efficient in cases where you don't need all the values, right, And I'm really happy that they're here because iterators have been kind of a dud feature in JavaScript because they lacked all these helper functions. Hopefully, now maybe they'll they'll get some more love from the
JavaScript developing the developer community. Time will tell. Maybe it's too late. I don't know, we'll see.
Yeah, So these are the aerator helpers, right, No.
These are the sync iterator helpers, the serator. The sync iterator helpers are here. They exist in browsers. You can already do iterator from inside Chrome, inside the Safari, inside Firefox. But what we don't have yet are a sync iterator helpers. They're stuck in stage two.
I think yes they are. This one says, so.
Yeah, the sync ones are stage four. The async ones are stuck in stage two. They've been stuck there for a whole while. That's really unfortunate. Again, what's the difference between? Yeah? And If our listeners are interested in the difference between sync inperators and a sync iterators, they should listen to episode four sixty nine where I explained the difference in detail.
The other thing that I wanted to mention, which is kind of here are JSON modules you can now import not only JavaScript, you can import json.
I'm sorry say that again.
You know the JavaScript import command well, you can now import not only JavaScript modules, you can import JSON files and the result of the import is the Jason object.
Oh cool.
You just need to tell the import that you're importing a Jason it you you basically tell it, you assert that this is the type of what you're importing. Is that is that kind of clear?
Yep? I'm just trying to find an example on the internet, but that makes sense.
You do you do import json from something dot json and then at the end of that instruction you add with open curly brackets type colon json close curly brackets. Okay, Theoretically in the future we might have other types I don't know, maybe will import CSS or text files or I don't know what. But for now, we've got it for json. Now why is this useful? Because I mean, you could just do a fetch and then do a JSON parts. Why do we need to import? To be honest,
it's more of a convenience than a necessity. But the convenience is that in a lot of cases we use JSON as configuration, and it's really useful to be able to directly import such configurations into the code. Yeah, think about I don't know, a wet back configuration or something
like that. So you're creating some sort of node based utility, and that utility uses some sort of Jason configuration and now you can just import that configuration at the top of your file and then just use that configuration because if that configuration is missing, there's really nothing that you can do. And it also works with dynamic imports by the way.
Oh nice.
So yeah, it's it's again, it's not earth shaking, but it's really useful, I think, and it's nice to have it built into the language.
Yeah.
Well it's stage four, so that means that it's here.
Yeah.
The way I think about it is you import all the things that are required to run your application, and yeah, typically that's going to be other JavaScript files. But yeah, it makes sense right that you may have some set up data or whatever that you need in order for it to work, and so it's another requirement.
It's just not code exactly. It's a declarative way to load your configuration data into your code basically, and you can be certain that if that configuration fails to load, then your code fails to load. And if it's successfully loads, than your code then gets to run with that configuration. It kind of blocks on that configuration. It doesn't proceed
until that configuration is loaded. So it's not like I'm loading some configuration asynchronously I need to wait for it or write code that waits for it or something like that. I can just import it and use and rely on the fact that if I load it successfully, it means that I have this configuration data.
Yep. Also for the iterator conversation, I did post episode for sixty nine just so that people can go reference that if they want.
Yeah, basically they probably want to listen to both for sixty eight and for sixty nine together. To be honest, since we're running short on time, I want to mention just one Stage three standout. It's being stage streets means it's not yet here, so don't go try to use it. But there are various existing ways for you to actually test implementation, either NPM modules that implement it, or you know, Babel plug ins or some suff something like that. It's
the temporal object or temporal namespace. Actually it's a more accurate way to put it. We all know that the JavaScript date object is pretty bad, uh it it has it has a lot of uh problems and limitations with it.
I've done hand to hand combat with it before and I have lost some of those battles.
Yeah, there are problems around working with the time zones with it. It only really supports your own your own time zone and doing all sorts of daylight saving time computation is really challenging and it and it's mutable with which makes it really problematics. It was created back in nineteen ninety five based on the Java the then Java date object. Java actually fixed their date object, but in JavaScript you couldn't for backward compatibility reasons, so we are stuck with it.
So Temporal aims to fix these problems by providing an alternative to date, so date will still be there because obviously you can't take something away, but now instead you can use temporal. And by using Temporal you'll avoid the need for stuff like moment jas and other NPM modules which aim to fix a lot of the time problems that we face when we need to deal with date and time in JavaScript. Other things, it supports non Gregorian calendars for people who care about these things, for example
the Hebrew calendar. You've got a more date format, parsing of options, so on and so forth. Just as a whole bunch of functionality for dealing with date and time in JavaScript. Now, as I said, unfortunately it's still stuck in stage three. I guess it's really complicated to get everything right in such a complex, complex domain. So they're taking their time. Hopefully we'll get it eventually.
Yeah, I was gonna say, I as fraught as time and time zone and all of that stuff gets.
And it's not just JavaScript.
I know that that we have some listeners that are kind of polyglot folks, so they work on the back end and Ruby or Rust or go or something right, and so you folks know that, hey, some of this stuff is maybe easier in that language, but it's still hard sometimes. And then the folks that only do JavaScript like this is it's a hard problem. And so yeah,
I understand why. Yeah, they may be working through some of the finer details to make sure that they get it right, because, yeah, if they put in an implementation that really does kind of just shine. I mean, that's a big area of pain that a lot of people have to deal with. Now, you said at stage three, so is it implemented or somewhat implemented or partially implemented in browsers.
No, it's not really implemented in browsers as far as I can tell.
Okay, they do have some polyphills that are listed in the proposal.
Oh yeah, for sure. It's it's an object in JavaScript, it's a name space in JavaScript, so you can definitely poly fill it. But you know some of these polyfils. First of all, I haven't checked how complete these polyfields are. And uh.
Yeah, the REA says so it was updated. Oh that's helpful. It says it was updated last year, very very helpful.
It does list other changes two months and four months ago, so it might be longer ago than that.
But the two that it lists are at.
JASS temporal slash polyphil, which I'm assuming is an NPM package, and that says that the alpha release is available. And then temporal dash polyphil, which is a full calendar implementation is it says the beta release is available.
So.
It might be worth looking at.
But yeah, it doesn't look like any of these are entirely stable.
Now we've effectively run out of time. I was going to talk about two more. One is the explicit resource management with the using keyword. It's this one actually does modify JavaScript semantics. I did actually discuss it way back in episode five and ninety a year and a half ago. It was then it's still stage three now, so uh. The one interesting thing is that Typescript actually added it in version five point two about a year and a half ago, So it seems that typescip kind of jumped
the gun on that one. They saw it in stage three, they assumed it was going to be released soon, and so they added support for it, and but it's not here yet. So it exists in typescript but not in JavaScript, which is amusing.
Yeah, I just episode as well.
Yeah, and the other one is something with this really cool name called Shadow Realm. I guess we'll need to find a different episode to talk about that one. It's that one is currently in stage two point seven, which means it's not even stage three, but it sounds good. Yeah. You know, one of the things that I've been thinking about, and maybe if we get requests from our audience to do it, is to do another episode about JavaScript features
stuck in Purgatory. There are a whole bunch of really yeah, there are a whole bunch of really interesting JavaScript features that have been staged two for like what feels like forever. I wonder if it's worthwhile to actually even talk about them, because on the one hand, some of them are really cool and really interesting and they add a lot of really interesting twists to the JavaScript language. But on the other hand, it seems like they're just they're just stuck there.
So the committee is not really doing away with them, but they're also not progressing them. They're so they're kind of stuck. I wonder if it's worthwhile to even talk about them. What do you think?
I think that would definitely be interesting. It's also interesting sometimes the how do I put it, There are things that kind of float.
Out there for a while.
I'll go back to the legislative example, right because I mentioned, you know, laws passing and bills passing and stuff. There are things that get proposed like every year that just
never quite get enough traction. And sometimes what's needed is somebody just points it out and then all of a sudden, some energy comes up behind it and things move, And so I'm imagining that, you know, I don't know that we have that bit that kind of influence necessarily, but it could start the process so that other folks start
talking about it too. And we get some exposure as far as oh, this really is a good idea, and we ought to just go and finish it, right, whether that's maybe we modify it to solve some of the concerns, or you know, there's a little bit more work put into just you know, putting the polish on it or whatever, and then we get another cool thing in JavaScript.
Yeah, and I would imagine that AJ would be really happy that they're not here yet, not to hear maybe forever.
Yeah, well cool, Well, yeah, I mean all of this stuff's really really fascinating and I'm looking forward to hopefully seeing more and more people use some of these features.
Yeah, all the features that we spoke about today are effectively in the language, so there's absolutely no reason not to use them. And in fact, as I explained, in some cases it's preferably preferable to use them rather than the alternatives. So as an example, again, instead of dot reverse, use two reversed. That's like a prime example of something
that we should use. Or another one, if you're doing all sorts of mathematical operations with unions, then maybe instead of using some NPM package, you just use what's now built into the JavaScript language itself.
Yeah, so I did a search on Shadow Realm, and it looks like.
There's a Twilight something Twilight I think it's D and D book that's called Shadow Realm.
And then there were.
Like eighteen of the front page links were you gi oh okay card game?
So in other way, it must be a cool Java's good feature if it's called shadow Realm. I mean, right, the name is really cool.
Yeah, So anyway, but yeah, I'd love to dive into some of these features. Yeah, some of the ones that are in limbo or purgatory or whatever you want to call it. And yeah, but it's also good to just see some of this stuff come along. And like you said, none of these are huge changes, but some of these sure seem like they'd make my coding either more stable or easier to do, and so.
I'm all about that. So all right, well, let's go ahead and do our picks. Do you want to do picks first or do you want me to go first?
I can go first. So first of all, people are listening my I've noticed that I've got a bit of a head cold and the stuff he knows, hopefully that goes away. So my first pick would be for my head cault to go away. Yeah, it's not really such a huge bother, just annoying, So that would be my first pick. My second pick is, we actually had a fun day to day at work. We are the team that I'm mostly working with. We went out together to do to play laser Tag, which was a whole was
a lot of fun. So my second pick would be to have fun days as team building exercises. And the third pick would be to do it a laser tag game because it's just fun. And those would be my picks for today. Short and sweet.
Yeah, laser Tag is fun. I'm gonna pick it's it's a second version of a board game I've picked in the past, so I've picked Machi Koro in the past, and essentially, just to give you an overview of Machi Korro, essentially, your building a town.
You buy buildings, and then you roll dice and you get money based on whether it's somebody else's team or your team, and whether you have a card with that number on it, and then you buy landmarks and once you've built all four landmarks, you win. That's Machi Korro. Machi Koro two is a little bit different, so instead of building four landmarks, you only have to build three. But the other thing is is that in Machi Koro you put out all the different types of buildings you
can build in your town. In Machi Koro two, what you do is you have decks of cards that have numbers one through six, decks of cards that have numbers seven through twelve, and then you have landmarks.
And so you flip cards over until you.
Have basically five unique buildings in each row, and then you win when you build three landmarks. And so you play the rest of the game plays the same. You roll the dice, if you have the building, you get paid the landmarks in Machi Korro, the original have fixed pricing for each landmark.
In Machi Korro too. Your first landmark has a cost, your second landmark has a cost, and your third landmark has a cost, and those costs are on the card.
I mean, those are the only differences. The rest of the game plays the same. It does give you a little bit more variety, and it makes the strategy just slightly a little bit more. You really have to think about it a little extra in order to get what you want, because the cards do give you different abilities, but it's not such a wide breadth of abilities that you're going, oh.
Man, I don't know how to figure this game out. So we played it with some friends of ours. We got it for Christmas, my family did.
And it's board game geek has a weight of one point four to eight, so it's still a pretty simple game. I think Machi Koro's like one point three. So yeah, very very approachable. Simple game. Says age ten plus can play it.
My daughter's nine.
I think she'd be fine playing this game. It says playtimes forty five minutes. I'm not sure if I remember how long it took us. Probably about that long.
So anyway, it's a fun game if you're looking for just something short, not terribly complicated that you can play and kind of chat over the table while you play it.
Chuck, I'm kind of curious, since you are such a board game geek slash expert, if you had to name your like top board game, or at least one of your top board games, just out of curiosity, what would that be? One in the top three or top five? Please?
So that's a little bit tricky, just because there's so many kinds of board games.
Yeah, but there must be something you really like.
So the ones that I've been playing a bunch lately and I can, I can give you a couple of them.
I've already picked them on the show.
I'm just curious which one you like the most.
I'd really have to think about that.
Like I said, the ones that we've been playing lately that we're really liking our Mysterium. We got expansion for that. It doesn't change the gameplay at all. It's just more cards. We got two expansions.
The other one that we've been playing lately is Betrayal at House on the Hill. I should put links to these in here. And that one's a fun one.
It's it's relatively fast too, but it's more of a role play game almost. The idea is you have you're a group of people that come into a haunted house, and you explore the house, and eventually a haunting happens, and then you're trying to complete goals. One of you frequently becomes the trader, almost always, not always, but almost always, one of you becomes the trader, and then everybody's playing
against that other player. And the thing that's fun about it is that the scenario you wind up playing changes from game to game, and so it's and the as you explore a room, you place tiles for the rooms, and so your map changes every game too, and so there's a lot to like about that. Honestly, sometimes I really really like the kind of the thinker games. I'm not so some of the big big ones that people tend to like that I'm not a fan of, or like Seven Wonders, or there are some.
Of them where you're almost playing your own game and then at the end you see who played it the best.
But you do interact with each other as far as did I do better at you with this than that? But then you've got other games.
I'm trying to think.
We've been playing Risk Legacy, which I like but I don't love. With my friends, we played Heat, and I.
Think with Risk is that play properly it can take such a long time.
Yeah, And we're getting to the stage with Risk Legacy. So Risk Legacy modifies the board every time and has special rules for how you win, and so it doesn't take as long.
But the last time we played it, it's starting to get to the point where you really almost have to do world domination to win the round.
And so it does take quite a bit longer. Yeah, I tend to like Settlers of Catan.
That was one of the games that I kind of got into gaming board gaming on. But anymore, it's like there are so many games that just have better mechanisms in them.
And so, yeah, if if somebody likes Catan and wants a better alternative, what would you recommend? Uh, well, you need to think about.
It, Yeah I do. Uh let me let me. I'll I'll come next time with my top two or three.
Games that your homework for next time.
Yeah, but I will tell you that.
Yeah, for the social games, we're really liking Mysterium. If you want a lighter social game, things like Sushi Go Party are fun if you're if you're looking at like maps and things like that. I mean, there are games out there. I kind of have this nostalgic feel for Access and Allies. But that's another one.
That takes like three or four hours to play.
Yeah, there are a bunch of good ones out there. Let me think about that and I'll come back to it.
But to be honest, I don't see myself playing a board game for six hours.
Yeah. The ones that I like, they take you about an hour and a half, and.
You have some idea about where you're at as far as like am I winning or not, but you don't entirely know because there's always some twist that you know, and so somebody could be building towards something and you don't really see it until they resolve it and then you go oh wow, right, but then you turn around and you resolve your thing on the next turn, and
then everybody goes, oh, now he's you know. So those are the kinds that I like, and the ones where I have enough room to get creative on the strategy right, where there's not just kind of a tried and true if you do this every time you're going to win, they go yeah, go is a good example of that with fairly simple rules. So anyway, other picks, My wife and I started watching prison Break, which is an older TV show.
On Oh yeah, that's on the nineties.
I think I think it's early two thousand's but still. Yeah, I've been liking that. I'm still watching. I have the last season of what's it called Reacher, No, not Reacher Jack Ryan. I've been watching that.
Yeah, I tried to watch it. I couldn't really get into it. I actually read some of the what's his name Clancy I think, Uh, yeah, I read some of the books. Yeah, I read some of the Tom Clancy books. I could never actually get into either the movies or the TV shows. I don't know.
Yeah, there are older movies to hunt for. Red October is a terrific book.
Yeah, that's his best one, I think.
Yeah, I've read a few others of his books. But the TV show is not based on any.
Of the books. Oh yeah, they just pulled some of the characters out and they basically have a new threat every season. That said, it's not the best ever kind of action spy TV show that I've ever seen, but I'm enjoying it.
If you've got Peacock, I would I actually picked it a while back, but it might be nice for you to watch. If you've got Peacock. I don't know who has Peacock, but I do. Then it's a Day of the Jackal.
Yeah, you recommended that a few weeks ago, and that's kind of on my list. But yeah, anyway, so I've been watching that. I'm in the middle right now, and I'm gonna pick these books again. I'm on book like nine or ten of the sort of truth books, and they they are so good. I've gotten so I read them in high school and then I hadn't really touched them again, and so he put out more books. The author had passed away a few years ago, but he wrote like very good.
Yeah, I recall reading some of his stuff. I'm trying to remember what.
Yeah, those were his big series, but yeah, I.
Yeah, see he died five years ago.
But anyway, he's I've just been really really enjoying these books, and so yeah, I'll pick those as well. I don't know, I'm kind of rambling at this point because you derailed me with the question about board games.
But yeah, and then I'm.
Just working on getting JavaScript Geniuses and the AI boot camp roll it out. So yeah, anyway, I guess we'll wrap it up because I am not going to keep rambling about this stuff.
But yeah, until next time, pokes Max out