WEBVTT 1 00:00:05.320 --> 00:00:09.320 Hey, folks, welcome back to another episode of JavaScript Jabber. 2 00:00:09.679 --> 00:00:11.359 This week, on our panel, we have. 3 00:00:11.359 --> 00:00:15.000 Dan Spear Hello from Tel Aviv, and. 4 00:00:14.919 --> 00:00:19.239 I'm Charles Maxwo from top Endevs. This week, we're gonna 5 00:00:19.239 --> 00:00:21.920 be talking about what's new in JavaScript. It's a new year. 6 00:00:22.160 --> 00:00:25.320 There's a bunch of stuff that came out last year 7 00:00:25.440 --> 00:00:28.960 or so, and so Dan was pointing them out to me, 8 00:00:29.480 --> 00:00:32.119 and that's what we're gonna talk about today. So, Dan, 9 00:00:32.320 --> 00:00:34.759 I know you have a list. I don't have the 10 00:00:34.799 --> 00:00:35.799 list in front of me, so I. 11 00:00:35.759 --> 00:00:36.640 Will let you just. 12 00:00:38.240 --> 00:00:44.159 Yeah, I'll let you steer the ship and I'll. 13 00:00:42.759 --> 00:00:44.000 Provide the color commentary. 14 00:00:45.079 --> 00:00:48.119 Yeah. So it's been a while since we've spoken about 15 00:00:48.119 --> 00:00:51.079 what's new in JavaScript. You know, everybody's talking about what's 16 00:00:51.119 --> 00:00:55.320 new in frameworks, what's new in CSS, what's new in HDMO. 17 00:00:56.039 --> 00:00:59.840 But the JavaScript, you know, there was this period of 18 00:01:00.079 --> 00:01:03.159 time where things are coming out, you know, fast and furious, 19 00:01:03.679 --> 00:01:06.000 and then it seemed like everything kind of settled down. 20 00:01:06.760 --> 00:01:10.280 But turns out that you know, new features are being introduced. 21 00:01:10.799 --> 00:01:12.879 So I thought it would be worthwhile to talk about it. 22 00:01:13.359 --> 00:01:16.519 We actually spoke about it a year and a half 23 00:01:16.599 --> 00:01:19.799 ago in episode of five ninety and it's interesting to 24 00:01:19.920 --> 00:01:27.280 contrast what has moved forward and what hasn't. So, first 25 00:01:27.280 --> 00:01:30.439 of all, for our listeners, for anybody who may not know, 26 00:01:31.159 --> 00:01:35.120 there's this thing which is the JavaScript standard but is 27 00:01:35.159 --> 00:01:41.120 not actually called JavaScript. It's called ekmascript instead, which Brendan Iike, 28 00:01:41.159 --> 00:01:44.200 the creator of JavaScript, has likened to a skin disease. 29 00:01:47.439 --> 00:01:50.000 It's really easy to remember too. I mean, EKMA script 30 00:01:50.079 --> 00:01:50.799 just rolled. 31 00:01:51.359 --> 00:01:55.079 Roll yeah, rolls off the tongue. EKMA is actually the 32 00:01:55.200 --> 00:01:59.560 EKMA International is a standards organization. It was originally the 33 00:01:59.599 --> 00:02:04.239 europe In Computer Manufacturers Association, but then they just decided 34 00:02:04.280 --> 00:02:07.799 that it's EKMA and you know, not the credentials anymore. 35 00:02:09.719 --> 00:02:15.560 But so why is this standard called ekmascript rather than JavaScript? 36 00:02:15.639 --> 00:02:18.240 I mean, the fact that it happens to be handled 37 00:02:18.240 --> 00:02:21.639 by the ATMA organization should not have changed the name 38 00:02:21.680 --> 00:02:24.080 of the language, or at least the standard of the language. 39 00:02:24.560 --> 00:02:29.319 And the reason is that they don't have the copyright 40 00:02:29.560 --> 00:02:31.080 to the JavaScript name. 41 00:02:32.319 --> 00:02:34.879 That called trademark technically, but yes. 42 00:02:35.039 --> 00:02:42.599 Yeah, it's a trademark and it's being held by Oracle exactly. 43 00:02:43.159 --> 00:02:45.840 The name escaped me all of a sudden, and it's 44 00:02:45.879 --> 00:02:49.759 a funny story. Because in case you know listeners don't know, 45 00:02:49.840 --> 00:02:54.199 they probably don't. JavaScript was created in by Brendan Ike 46 00:02:54.280 --> 00:02:57.240 in Ten Days of Glory back in nineteen ninety five 47 00:02:57.520 --> 00:03:01.000 while he was working at Netscape. They were working in 48 00:03:01.120 --> 00:03:07.319 corporation with Sun, which was this the creators of Java, 49 00:03:08.639 --> 00:03:12.680 and they they had this kind of corporation where JavaScript 50 00:03:12.719 --> 00:03:15.080 was supposed to be the scripting language in the browser 51 00:03:15.599 --> 00:03:18.879 and Java was supposed to be the actual heavy duty 52 00:03:18.919 --> 00:03:22.879 programming language in the browser. That didn't happen. But what 53 00:03:23.080 --> 00:03:27.680 did happen was that Son ended up with the JavaScript trademark, 54 00:03:28.639 --> 00:03:29.479 and then. 55 00:03:29.360 --> 00:03:31.039 Because they owned the trademark to Java. 56 00:03:32.000 --> 00:03:34.360 To be honest, I'm not sure either because of that 57 00:03:34.639 --> 00:03:36.879 or because that was part of the deal of their 58 00:03:36.960 --> 00:03:41.560 corporation with the Netscape. Either way, they ended up with 59 00:03:41.639 --> 00:03:45.039 a trademark, and then they were bought by Oracle. So 60 00:03:45.120 --> 00:03:48.400 now Oracle holds that trademark and they've literally done nothing 61 00:03:48.479 --> 00:03:52.520 with it. So there's this new movement now to actually 62 00:03:52.919 --> 00:03:57.039 free that trademark from Oracle. They've actually reached out to Oracle, 63 00:03:57.199 --> 00:04:02.080 They've reached out to the governmental body that's responsible for trademarks. 64 00:04:02.120 --> 00:04:06.800 There's an online petition that everybody can sign at JavaScript 65 00:04:06.879 --> 00:04:11.800 dot tm fitting url. I signed it, and I encourage 66 00:04:11.800 --> 00:04:16.399 our listeners to sign it, and hopefully eventually it will 67 00:04:16.399 --> 00:04:21.519 be released. This is actually being led by Ryan Dahl 68 00:04:21.639 --> 00:04:25.240 from Dino, who we've interviewed a few months back. So 69 00:04:25.319 --> 00:04:28.279 he wrote an interesting blog post about it. We can 70 00:04:28.319 --> 00:04:30.839 link to it. He gives the entire history and everything. 71 00:04:31.720 --> 00:04:35.000 I hope it's released and we can finally call it 72 00:04:35.360 --> 00:04:39.519 JavaScript rather than ekmascript. But be that as it may. 73 00:04:39.800 --> 00:04:43.519 That's the name of the standard and it's being handled 74 00:04:43.800 --> 00:04:47.600 by a committee within EKMA called TC thirty nine. 75 00:04:49.319 --> 00:04:52.560 And TC I was gonna say, if you're wondering what 76 00:04:52.680 --> 00:04:56.480 the cryptic name, TC thirty nine is literally technical committee 77 00:04:56.519 --> 00:04:57.079 or something like. 78 00:04:57.040 --> 00:05:01.079 That, exactly, it's Technical Committee thirty nine. Their whole bunch 79 00:05:01.120 --> 00:05:03.879 of technical committees within EKMA, and that's the number they 80 00:05:03.879 --> 00:05:08.800 got and they have this whole process of how to 81 00:05:08.920 --> 00:05:16.040 introduce features into the JavaScript language. Originally this process had 82 00:05:16.439 --> 00:05:21.519 forced five stages sorry, zero through four, because well, you know, 83 00:05:21.600 --> 00:05:27.040 everything should be zero based. But now they've actually added 84 00:05:27.199 --> 00:05:31.439 an intrim stage two point seven, so now they have 85 00:05:31.959 --> 00:05:36.759 six stages and to run through them really quickly. Stage 86 00:05:36.959 --> 00:05:40.800 zero is basically it's a new proposal, it's not even 87 00:05:40.879 --> 00:05:45.160 really considered. Basically, you've had an idea and you've written 88 00:05:45.240 --> 00:05:48.079 down a note about it and sent it to the committee. 89 00:05:48.199 --> 00:05:52.199 That's more or less what stage zero means. It's hardly anything, really, 90 00:05:52.680 --> 00:05:59.040 but it's the starting point for all proposals in that 91 00:05:59.240 --> 00:06:03.759 are process by the committee. When the Committee decides to 92 00:06:03.839 --> 00:06:08.279 actually look at a particular proposal, it moves to stage one. 93 00:06:09.199 --> 00:06:13.480 That means that that proposal is under consideration. The committee 94 00:06:13.480 --> 00:06:17.680 expects to devote time examining and identifying the need for 95 00:06:17.759 --> 00:06:21.959 that proposal, what it's supposed to address or improve or fix, 96 00:06:23.439 --> 00:06:28.600 and basically compare it to other alternative solutions that might exist, 97 00:06:29.399 --> 00:06:33.480 and decide whether it's worthwhile to pursue. They need to 98 00:06:33.519 --> 00:06:39.759 identify somebody to champion that proposal. They expect an outline 99 00:06:39.839 --> 00:06:45.160 to be written and so and discuss algorithms and abstractions 100 00:06:45.240 --> 00:06:48.639 and semantics and so forth, all the good stuff. So 101 00:06:48.720 --> 00:06:54.000 that's stage one. Stage two is when the committee has 102 00:06:54.079 --> 00:06:59.839 chosen a preferred solution or maybe a few solutions in 103 00:06:59.879 --> 00:07:04.079 a in a particular solution space, but the design is 104 00:07:04.240 --> 00:07:08.560 very much still a draft and may change significantly before 105 00:07:08.600 --> 00:07:14.480 it's actually introduced into the language. The committee actually expects 106 00:07:15.160 --> 00:07:18.519 something to be developed and eventually introduced into the language. 107 00:07:18.519 --> 00:07:22.720 They're just not absolutely sure what it is yet and 108 00:07:22.879 --> 00:07:27.079 how exactly it's going to look. And at that point 109 00:07:27.120 --> 00:07:30.480 they expect, obviously the thing to be much better documented 110 00:07:32.040 --> 00:07:35.680 and you know, for people to start experimenting with it 111 00:07:35.720 --> 00:07:42.759 and actually have something real to examine. Now, they've introduced 112 00:07:42.759 --> 00:07:46.920 a new stage called two point seven because they didn't 113 00:07:46.920 --> 00:07:49.439 want to move stage two or stage three, and they 114 00:07:49.519 --> 00:07:53.000 wanted to put something in between. So stage two point 115 00:07:53.040 --> 00:07:56.839 seven means that the proposal is approved in principle and 116 00:07:57.000 --> 00:08:03.000 is currently undergoing validation. That means that maybe a browser 117 00:08:03.040 --> 00:08:07.160 manufacturer has put it behind a feature flag, or maybe 118 00:08:07.240 --> 00:08:11.319 there's a Babel plug in or something like. Somebody is 119 00:08:11.360 --> 00:08:15.800 playing with it, experimenting it and with it, and you 120 00:08:15.839 --> 00:08:19.199 can start seeing how it actually works and whether it 121 00:08:19.240 --> 00:08:25.439 actually feels like a good idea. Stage three is when 122 00:08:25.639 --> 00:08:30.279 the proposal has been recommended for implementation and no changes 123 00:08:30.319 --> 00:08:33.600 to the proposal are expected. In other words, they feel 124 00:08:33.639 --> 00:08:36.679 pretty confident that this is how it's going to be, 125 00:08:37.279 --> 00:08:41.279 but it's not yet part of the standard, and therefore 126 00:08:41.799 --> 00:08:45.639 backward compatibility is not yet required, which means that if 127 00:08:45.960 --> 00:08:49.200 somebody comes up with a better idea, or they they 128 00:08:49.200 --> 00:08:52.639 start suddenly discover a problem with it, they can battrack 129 00:08:52.919 --> 00:08:55.600 so they can even you know, move it back to 130 00:08:56.159 --> 00:08:58.639 a stage two or even to or two point seven 131 00:08:58.799 --> 00:09:04.200 something like that. And finally you've got stage four, which 132 00:09:04.240 --> 00:09:08.159 means that the proposal is feature complete and is ready 133 00:09:08.159 --> 00:09:10.759 to be included in the standard. Essentially, it means that 134 00:09:10.840 --> 00:09:13.519 it's effectively part of the standard. It's just that a 135 00:09:13.600 --> 00:09:16.799 new standard document has not yet been released. One is 136 00:09:16.879 --> 00:09:22.200 released once a year, So the proposals that are complete 137 00:09:22.320 --> 00:09:25.799 weight at stage four until they are included in the 138 00:09:25.799 --> 00:09:30.240 next release standard. And usually by the time they're in 139 00:09:30.360 --> 00:09:36.159 stage four, you actually find them implemented in browsers and 140 00:09:36.200 --> 00:09:41.399 you can actually start using them. So far, so good. 141 00:09:41.639 --> 00:09:44.600 M Yeah, it's funny too, because you're talking about this 142 00:09:44.720 --> 00:09:47.440 process and two things are going through my head, and 143 00:09:47.480 --> 00:09:52.799 one is it sounds complicated, but yeah, I mean, if 144 00:09:52.799 --> 00:09:55.960 you really think about the progression, it all makes sense. 145 00:09:56.279 --> 00:09:56.559 Right. 146 00:09:58.879 --> 00:10:02.720 The other thing that's going through my head is we're 147 00:10:02.759 --> 00:10:06.399 currently heading into a legislative session in the state of Utah, 148 00:10:06.759 --> 00:10:09.919 and so I've been going through the process that bills 149 00:10:09.960 --> 00:10:13.279 go through the past and they're going, I'm going, Wow, 150 00:10:13.440 --> 00:10:16.799 this is in some way simpler and in some ways 151 00:10:17.759 --> 00:10:20.919 more complicated than the political process. 152 00:10:21.600 --> 00:10:24.480 In certain ways, it has to be, because unlike the 153 00:10:24.519 --> 00:10:29.440 political process, these kind of standards are really set in stone. 154 00:10:29.480 --> 00:10:33.399 When something is added into JavaScript, it can never really 155 00:10:33.480 --> 00:10:37.000 be removed. Yeah, which means that we had better be 156 00:10:37.240 --> 00:10:42.440 really certain about adding it into the standard. And you've got, 157 00:10:42.919 --> 00:10:48.000 like I said, you've got the browser manufacturers on this committee, 158 00:10:48.000 --> 00:10:50.720 and they've got to really approve it and say, you know, 159 00:10:51.240 --> 00:10:53.720 this is something that we can actually implement. You know, 160 00:10:53.840 --> 00:10:58.159 somebody might have this great idea, but implementing it would 161 00:10:58.200 --> 00:11:03.120 turn JavaScript on its head. Then obviously the browser manufacturers 162 00:11:03.159 --> 00:11:05.240 will push back and won't approve it. 163 00:11:06.720 --> 00:11:06.960 Yep. 164 00:11:09.159 --> 00:11:12.840 So let's put it this way. The attitude is better 165 00:11:12.879 --> 00:11:16.480 safe than sorry, and that's a good attitude to have 166 00:11:16.600 --> 00:11:20.679 in the context of language standard, especially a languagelike JavaScript. 167 00:11:20.919 --> 00:11:24.240 Where As I said, once something is added, it can 168 00:11:24.240 --> 00:11:25.519 never be removed. 169 00:11:26.759 --> 00:11:30.200 I really wish that our legislators would do better safe 170 00:11:30.240 --> 00:11:33.960 than sorry. Let's think a little more deeply about this 171 00:11:34.000 --> 00:11:35.960 before we pass it or not? Right? 172 00:11:36.080 --> 00:11:40.080 Yeah, but yeah, I completely agree, and I think it's 173 00:11:40.159 --> 00:11:44.279 good context that JavaScript has always gone way out of 174 00:11:44.320 --> 00:11:48.559 its way to be backward compatible. I'm sure there's sometimes 175 00:11:48.559 --> 00:11:50.600 where there was just something that they had to kind 176 00:11:50.600 --> 00:11:52.600 of roll back, but. 177 00:11:53.480 --> 00:11:57.440 Actually, the one time that I can think of where 178 00:11:57.480 --> 00:12:01.960 effectively things were rolled back was they introduced strict mode. 179 00:12:02.120 --> 00:12:05.440 And even then they introduce they roll them back by 180 00:12:05.600 --> 00:12:10.639 introducing strict mode, So if you're running outside strict mode, 181 00:12:10.639 --> 00:12:13.600 they're still there. They wanted to roll back, for example, 182 00:12:13.639 --> 00:12:16.440 the with keyword, and I won't get into the details 183 00:12:16.440 --> 00:12:19.519 of why it turned out to be a bad idea 184 00:12:19.600 --> 00:12:23.799 in the context of the JavaScript programming language, but they 185 00:12:23.799 --> 00:12:29.360 couldn't remove it, and so instead they kind of rolled 186 00:12:29.399 --> 00:12:33.639 it back by making strict mode more and more the 187 00:12:33.759 --> 00:12:37.799 common way in which JavaScript work and in strict mode 188 00:12:38.080 --> 00:12:40.320 with does not exist. Right. 189 00:12:42.279 --> 00:12:44.840 Yeah, And if you're wondering, if you're if you're newer 190 00:12:44.879 --> 00:12:47.480 to javascripts and you're saying, what what what is strict mode, 191 00:12:47.799 --> 00:12:48.759 don't worry about it. 192 00:12:49.120 --> 00:12:50.320 You're using strict mode. 193 00:12:51.279 --> 00:12:55.279 Yeah, just so you know, you know, we mentioned it, 194 00:12:55.320 --> 00:12:58.960 so we might as well provide details. You can explicitly 195 00:12:59.159 --> 00:13:04.159 enter strict mode by having the use strict string at 196 00:13:04.240 --> 00:13:06.320 the top of a scope or the top of a file. 197 00:13:07.039 --> 00:13:10.120 You can't actually ever exit strict mode. You only enter 198 00:13:10.159 --> 00:13:15.080 strict mode. And you enter strict mode by default in 199 00:13:15.799 --> 00:13:20.480 ekmascript modules. So if you implement a module, it's strict 200 00:13:20.559 --> 00:13:24.679 mode by definition. In HTML, that's if you have a 201 00:13:24.879 --> 00:13:30.080 script tagged with the type equals module, it's strict mode 202 00:13:30.080 --> 00:13:32.200 by default, and then you can do module things like 203 00:13:32.279 --> 00:13:35.639 imports and stuff like that. You also strict mode by 204 00:13:35.679 --> 00:13:39.679 default in classes, because again, classes are kind of a 205 00:13:39.720 --> 00:13:42.039 new type of a scope, and it makes sense to 206 00:13:42.080 --> 00:13:44.080 be strict by default inside classes. 207 00:13:45.080 --> 00:13:45.360 Yeah. 208 00:13:45.440 --> 00:13:49.200 I think most people working within the context of JavaScript, though, 209 00:13:49.679 --> 00:13:52.080 they're working under some system that puts them in strict 210 00:13:52.080 --> 00:13:53.200 mode without them. 211 00:13:53.399 --> 00:13:58.200 Yeah, because they're building hopefully they're building ekmascript modules these. 212 00:13:58.159 --> 00:14:03.240 Days, yeah, or React projects or you know, whatever other 213 00:14:03.399 --> 00:14:07.039 framework or library you're using, generally use modules, and so 214 00:14:07.120 --> 00:14:09.200 you're generally put into this box anyway. 215 00:14:10.639 --> 00:14:14.879 And I really can't think of any other occurrence where 216 00:14:15.200 --> 00:14:20.320 something was effectively removed out of JavaScript, so you know, 217 00:14:20.600 --> 00:14:26.120 it's interesting. Yeah, anyway, So let's talk about a couple 218 00:14:26.159 --> 00:14:29.919 of these enhancements and proposals. But before we dive into them, 219 00:14:30.200 --> 00:14:33.480 it's really worthwhile to highlight the fact that none of 220 00:14:33.480 --> 00:14:38.480 them really significantly or maybe even at all, change the 221 00:14:38.559 --> 00:14:42.840 JavaScript syntax or semantics. So you've got nothing new like 222 00:14:43.440 --> 00:14:49.000 the arrow functions syntax or let or cons or stuff 223 00:14:49.039 --> 00:14:52.279 like that which really changed the way that JavaScript kind 224 00:14:52.320 --> 00:14:56.679 of worked. Well, there is one towards the end, but 225 00:14:56.840 --> 00:15:01.120 it's still at stage three, and we'll see if we 226 00:15:01.600 --> 00:15:04.559 make it all the way to that one. But all 227 00:15:04.600 --> 00:15:07.919 the rest can are better described as being part of 228 00:15:07.960 --> 00:15:12.919 a quote unquote JavaScript standard library. They've added new object 229 00:15:12.960 --> 00:15:21.519 types and new methods or functions that are built in 230 00:15:21.960 --> 00:15:25.519 that you can use instead of let's say, importing some 231 00:15:25.720 --> 00:15:31.919 NPM module that would implement them. So we've got more 232 00:15:32.000 --> 00:15:36.559 standard functionality being provided out of the box by the 233 00:15:36.639 --> 00:15:40.039 JavaScript runtime environment itself, be it the browser or vi 234 00:15:40.080 --> 00:15:41.279 it node or whatever. 235 00:15:42.639 --> 00:15:45.600 Yeah, so what I'm hearing is is that if you're 236 00:15:45.720 --> 00:15:48.399 using these feature, you may be already be using these features. 237 00:15:48.440 --> 00:15:52.360 They're just now official standard kind of stuff. 238 00:15:53.200 --> 00:15:55.600 Yeah, you might have there's a good chance that you 239 00:15:55.720 --> 00:15:59.639 might have imported such functionality before. Now it's built in 240 00:15:59.679 --> 00:16:01.919 and you do need to import it anymore. Kind of 241 00:16:02.039 --> 00:16:07.559 like the browsers started providing fetch as a built in function, 242 00:16:07.840 --> 00:16:12.320 and you didn't need something like an axios anymore. Ye. 243 00:16:14.600 --> 00:16:17.480 So the first one I would like to mention is 244 00:16:17.639 --> 00:16:22.000 something that's actually five years old. It's from ES twenty twenty, 245 00:16:22.879 --> 00:16:30.159 and it's called promise dot all settled, and as its 246 00:16:30.279 --> 00:16:35.799 name implies, it waits for all this provided promises to 247 00:16:35.879 --> 00:16:40.279 be settled. Now, you know, it's very common when working 248 00:16:40.320 --> 00:16:43.799 with promises to need to wait on a couple of 249 00:16:43.840 --> 00:16:50.960 promises simultaneously, effectively in parallel. And when most developers need 250 00:16:51.000 --> 00:16:54.000 to do that, I see most of them reaching out 251 00:16:54.120 --> 00:16:57.039 for promise dot all and just using promise dot all. 252 00:16:58.519 --> 00:17:02.840 But what they might have not considered is the fact 253 00:17:02.919 --> 00:17:07.440 that promised dot all short circuits on a rejected promise. 254 00:17:07.720 --> 00:17:12.200 So promise dot all receives an area of promises and 255 00:17:12.240 --> 00:17:15.200 it waits in parallel on all of them. It returns 256 00:17:15.200 --> 00:17:19.279 a promise that resolves when all the provided promises resolve. 257 00:17:19.960 --> 00:17:24.319 But if even one of those promises reject, then the 258 00:17:24.400 --> 00:17:31.559 return promise immediately rejects. And that may not be what 259 00:17:31.599 --> 00:17:35.519 you're looking for. It may be, but it may not be. 260 00:17:36.279 --> 00:17:41.200 Sometimes you actually want to wait on all the promises 261 00:17:41.240 --> 00:17:47.279 provided until they are all of them either resolved or rejected. 262 00:17:47.319 --> 00:17:50.039 In other words, all of them are settled, and hence 263 00:17:50.119 --> 00:17:52.200 the name of the method, all settled. 264 00:17:53.119 --> 00:17:56.400 Right, So let me see if I can restate this 265 00:17:56.640 --> 00:18:00.000 in a different way. So, if you promised dot all, Yeah, 266 00:18:00.720 --> 00:18:02.599 if one of them rejects, you get rejected. 267 00:18:03.319 --> 00:18:04.160 I media doesn't. 268 00:18:04.440 --> 00:18:07.720 Yeah, but it doesn't tell you that they've all finished 269 00:18:08.559 --> 00:18:11.079 waiting for whatever it is that they're waiting for, And 270 00:18:11.119 --> 00:18:16.400 so effectively the all settles it does more or less 271 00:18:16.400 --> 00:18:19.119 the same thing. But if you have one of them 272 00:18:19.160 --> 00:18:23.359 that's still waiting for whatever, you know, whether it's going 273 00:18:23.400 --> 00:18:25.400 to reject or fulfill or anything else. 274 00:18:27.119 --> 00:18:29.799 So think about the simple scenario. Let's say you have 275 00:18:29.920 --> 00:18:36.400 two promises, sorry, let's say even three promises, and you 276 00:18:36.519 --> 00:18:39.359 pass the area of the three promises into promise all. 277 00:18:39.880 --> 00:18:44.400 Let's say the first one resolves, that's great, and then 278 00:18:45.279 --> 00:18:48.240 the second, then the other two are still pending, and 279 00:18:48.319 --> 00:18:52.880 then the second one rejects. Then it will immediately return 280 00:18:53.000 --> 00:18:56.000 with a reject. It won't wait on the third one 281 00:18:56.200 --> 00:18:59.119 to either resolve or reject, and it won't also tell 282 00:18:59.160 --> 00:19:03.079 you that the first one resolved. It will just tell 283 00:19:03.119 --> 00:19:09.279 you that, hey, this thing rejected, okay. Whereas with promise 284 00:19:09.400 --> 00:19:13.279 all settled, what you get back is an area of objects. 285 00:19:13.519 --> 00:19:15.759 First of all, it waits on all three, so even 286 00:19:15.799 --> 00:19:19.000 if the second one rejected, it will still continue to 287 00:19:19.000 --> 00:19:22.599 wait until the third one completes, and then it will 288 00:19:22.640 --> 00:19:29.880 return an array of objects, and each object has a 289 00:19:29.960 --> 00:19:35.039 field that indicates whether or not it resolved or rejected. 290 00:19:36.440 --> 00:19:42.200 So I wanted to have this open, and I forgot. 291 00:19:43.559 --> 00:19:47.839 I just posted a link to Yeah, MDN is always there. Yeah, 292 00:19:48.000 --> 00:19:51.359 MDN is always the best. So it basically returns an 293 00:19:51.480 --> 00:19:56.359 array of objects, one per each promise it had. Each 294 00:19:56.720 --> 00:19:59.519 element of those rays is an object where and it 295 00:19:59.599 --> 00:20:02.960 has a property called status, and that status could be 296 00:20:03.079 --> 00:20:08.440 either fulfilled or rejected. It has it. If it's fulfilled, 297 00:20:08.519 --> 00:20:10.880 then it will have a field called value with the 298 00:20:10.960 --> 00:20:14.759 resolved value, and if it if it was rejected, it 299 00:20:14.799 --> 00:20:21.119 would have a field called reason with the appropriate rejection reasons. 300 00:20:22.920 --> 00:20:25.359 So this way you can look at all the promises 301 00:20:25.880 --> 00:20:29.000 and see whether they resolved or rejected and what they 302 00:20:29.039 --> 00:20:32.799 actually returned. And as I said, in a lot of cases, 303 00:20:33.119 --> 00:20:36.640 that's actually what you want rather than just promised dot all. 304 00:20:37.160 --> 00:20:39.240 But a lot of people are not familiar with it 305 00:20:39.359 --> 00:20:41.759 and use promise dot all when they should have actually 306 00:20:41.880 --> 00:20:43.240 used promise all settled. 307 00:20:44.079 --> 00:20:47.400 So MDN makes it look like because it calls promise 308 00:20:47.480 --> 00:20:50.240 dot all settled, you pass in the array and then 309 00:20:50.279 --> 00:20:53.279 it calls dot then so does it operate as a 310 00:20:53.319 --> 00:20:54.160 promise as well? 311 00:20:54.559 --> 00:20:58.559 Yeah, yeah, it returns a promise that resolves to that 312 00:20:58.839 --> 00:20:59.759 array of objects. 313 00:20:59.839 --> 00:21:03.799 Right, Yeah, I just wanted to, you know, clarify because 314 00:21:04.839 --> 00:21:08.400 you said it returns that, but it does. It's a 315 00:21:08.480 --> 00:21:13.000 promise that resolves to that array of so it has 316 00:21:13.039 --> 00:21:15.640 to wait for everything to finish exactly. 317 00:21:18.240 --> 00:21:18.799 That's cool. 318 00:21:19.359 --> 00:21:22.359 So I'm going to ask another question that's not about 319 00:21:22.640 --> 00:21:26.240 all settled. But you said this is from five years ago. 320 00:21:26.400 --> 00:21:29.960 So when you say that we're talking about new things 321 00:21:29.960 --> 00:21:34.759 in JavaScript, are these things that are now generally implemented 322 00:21:35.240 --> 00:21:38.000 or are these just things that, hey, these have passed 323 00:21:38.000 --> 00:21:40.799 in the last however long and people ought to know 324 00:21:40.839 --> 00:21:44.960 about them, or what's your criteria for making the list? 325 00:21:45.400 --> 00:21:48.720 Well, first of all, this is the oldest one. Everything 326 00:21:48.759 --> 00:21:50.759 else that I'm going to be talking about is newer 327 00:21:50.759 --> 00:21:57.279 than that, And I guess my criteria was relatively new 328 00:21:57.359 --> 00:22:02.440 things that our listeners might thought known about. Now I 329 00:22:02.480 --> 00:22:04.960 think that things that are actually already part of the 330 00:22:05.000 --> 00:22:10.200 standard are generally much more interesting that things that are 331 00:22:10.440 --> 00:22:12.279 not yet part of the standard. I mean, you know, 332 00:22:12.440 --> 00:22:15.319 things that are not part of the standard might be 333 00:22:15.440 --> 00:22:19.960 really cool. Usually they often push the envelope a lot more, 334 00:22:20.039 --> 00:22:22.400 which is one of the reasons that the committee is 335 00:22:22.440 --> 00:22:26.200 kind of hesitant about adding them actually into the language. 336 00:22:26.480 --> 00:22:29.079 But I think that when you've got a functionality that 337 00:22:29.240 --> 00:22:35.400 can actually be used and provides real value, that's more pertinent, 338 00:22:35.640 --> 00:22:38.559 let's say, than some pie in the sky that might 339 00:22:38.680 --> 00:22:39.680 never actually arrive. 340 00:22:40.519 --> 00:22:45.400 Right, So these are probably just hidden gems that you 341 00:22:45.480 --> 00:22:48.119 may not have known got added to the language. 342 00:22:48.079 --> 00:22:53.759 Exactly over the last five years, I guess. The next 343 00:22:53.759 --> 00:22:59.160 one is from ES twenty twenty two, so it's almost 344 00:22:59.240 --> 00:23:05.039 three years old, and it's the dot at method on arrays, 345 00:23:05.240 --> 00:23:09.440 strings and type rays, and you basically give it an 346 00:23:09.480 --> 00:23:13.079 index and you get back the item. So it's really 347 00:23:13.160 --> 00:23:15.680 like using the square brackets in a lot of ways. 348 00:23:15.799 --> 00:23:18.319 And you might ask yourself, well, why do I need it, 349 00:23:18.359 --> 00:23:21.279 Why don't I just use the square brackets, And the 350 00:23:21.480 --> 00:23:24.359 reason is that you can also provide it with negative 351 00:23:24.480 --> 00:23:29.880 numbers and then you're indexing from the end. So if 352 00:23:29.920 --> 00:23:32.839 you do dot at on an array and pass in 353 00:23:32.920 --> 00:23:36.920 minus one, you're looking at the last element in the array. 354 00:23:40.720 --> 00:23:41.279 Interesting. 355 00:23:42.440 --> 00:23:47.119 Now, that's actually how various other program earring languages actually work. 356 00:23:47.240 --> 00:23:50.240 So in other programming languages you might have been able 357 00:23:50.279 --> 00:23:55.400 to have the minus indexes in the square brackets themselves, 358 00:23:56.200 --> 00:24:00.400 but you can't do that in JavaScript because that's not 359 00:24:00.559 --> 00:24:04.519 how named properties work in JavaScript. And in JavaScript you 360 00:24:04.599 --> 00:24:09.640 could legally legally have a minus one property. Uh, so 361 00:24:09.680 --> 00:24:13.920 you couldn't use that. And the funny thing is that 362 00:24:14.079 --> 00:24:18.799 this negative index has actually worked with the dot slice 363 00:24:18.839 --> 00:24:22.440 method for a long time, but then it would always 364 00:24:22.440 --> 00:24:26.160 return an array, right, And with dot at you get 365 00:24:26.279 --> 00:24:30.160 that actual element from the array, which is just nice. 366 00:24:31.200 --> 00:24:34.240 Yeah, I've used other languages that do this with their array, 367 00:24:34.400 --> 00:24:38.480 so but they do it with the square brackets. And yeah, 368 00:24:38.720 --> 00:24:41.720 you're you're explaining why you couldn't do that and maintain 369 00:24:41.759 --> 00:24:43.920 backward compatibility with JavaScript. 370 00:24:44.519 --> 00:24:46.759 But yeah, this is this is really cool. I like that. 371 00:24:48.920 --> 00:24:52.720 Another one that's more of a you should use and 372 00:24:52.960 --> 00:24:58.319 probably don't is object dot has owned. Are you familiar 373 00:24:58.359 --> 00:25:02.960 with the has owned property? A method that so in 374 00:25:03.079 --> 00:25:08.319 JavaScript you can use there's the inoperator which tells you 375 00:25:08.400 --> 00:25:11.440 whether or not a property exists in an object. Objects 376 00:25:11.440 --> 00:25:15.240 in javas kind of work like property bags, and you 377 00:25:15.319 --> 00:25:19.759 can check to see whether a particular string is the 378 00:25:19.839 --> 00:25:23.000 name of a property in an object using the inoperator, 379 00:25:23.640 --> 00:25:27.759 But the inoperator also looks up the prototype chain, so 380 00:25:27.839 --> 00:25:28.559 it doesn't. 381 00:25:28.200 --> 00:25:30.799 Always say this, this is cool. I just looked it 382 00:25:30.880 --> 00:25:33.319 up and I am yeah. Anyway, go ahead. 383 00:25:34.440 --> 00:25:38.160 Now has owned property has existed forever as a way 384 00:25:38.200 --> 00:25:43.599 to check whether a property name exists in an object 385 00:25:43.640 --> 00:25:47.920 without going up the property chain. The problem with has 386 00:25:47.960 --> 00:25:52.720 owned property is that not all objects necessarily have it, 387 00:25:53.359 --> 00:25:58.319 because you need to have the object prototype in your 388 00:25:58.359 --> 00:26:02.359 prototype chain to actually have it, and it's not there 389 00:26:02.359 --> 00:26:05.559 by definition, so you might try to use his own 390 00:26:05.599 --> 00:26:09.880 property only to have it break because you're not actually 391 00:26:09.880 --> 00:26:16.319 your object doesn't actually derive from object prototype. So the 392 00:26:16.440 --> 00:26:20.960 safer way is to do object dot has own as 393 00:26:21.039 --> 00:26:24.559 this kind of a global method static method, and the 394 00:26:24.559 --> 00:26:27.440 first parameter is the object you want to test, and 395 00:26:27.519 --> 00:26:29.920 the second parameter is the name of the property you 396 00:26:29.960 --> 00:26:34.839 want to check. So it's just a safer way. So 397 00:26:34.880 --> 00:26:38.400 the preferred way to check whether or not a specific 398 00:26:38.519 --> 00:26:43.480 object has a particular property is not using his own property, 399 00:26:43.519 --> 00:26:47.319 which is what most of us do, but rather using 400 00:26:47.400 --> 00:26:51.599 object dot has owned. Yet I've don't recall ever seeing 401 00:26:51.640 --> 00:26:53.920