CHARLES MAX_WOOD: Hey everybody and welcome back to another episode of JavaScript Jabber. This week on our panel, we have Steve Edwards.
STEVE_EDWARDS: Hello from very cold and rainy, typical April, Portland.
CHARLES MAX_WOOD: We also have Dan Shapir.
DAN_SHAPPIR: Hi from a warm and sunny Tel Aviv.
STEVE_EDWARDS: Ah, quit saying that. Makes me nuts.
DAN_SHAPPIR: What can I do? It's always, it's almost always warm and sunny in Tel Aviv.
STEVE_EDWARDS: I know.
CHARLES MAX_WOOD: I'm a Charles Max Wood from Top End Devs. It's also warm and sunny here in.Utah, but by the end of the week, it won't be that anymore. Welcome to Utah weather. We have a special guest this week and that is Thomas Randolph. Thomas, do you want to introduce yourself? Let people know why you're famous.
THOMAS_RANDOLPH: Sure. As you said, my name is Thomas Randolph. I, uh, I'm not famous.
CHARLES MAX_WOOD: Let's start with that. Yeah.
STEVE_EDWARDS: After this podcast, there'll be people clamoring for your autograph.
CHARLES MAX_WOOD: That's right. You'll be infamous.
THOMAS_RANDOLPH: Yeah. I would say my only real presence is kind of on Twitter. I interact casually with folks like Diane and other people. I work at GitLab, so you may have heard of GitLab. I come in from Denver, where it's also kind of warm and sunny, although like Utah, the weather could change at any moment. So,
CHARLES MAX_WOOD: yep,
THOMAS_RANDOLPH: expecting maybe to have snow even this month. So who knows? Yeah, we already had snow this month here.
STEVE_EDWARDS: We just had a snow day here in Portland last week. We just sat down here in Portland, closed all the schools and everything. Here they close if you get an eighth of an inch, but it was a lot of snow for one day.
DAN_SHAPPIR: So yeah, that's another thing about Tel Aviv. It never snows in Tel Aviv. Actually it did snow. I told that it snowed once in the 50s, but you know, since then.
THOMAS_RANDOLPH: Wow. Yeah. 70 years.
CHARLES MAX_WOOD: I remember when I lived in Italy, I was living in Tuscany and it snowed and people just didn't know what to do. So anyway. We're going to be talking about TC39 stuff and upcoming features for ECMA script.
Hey folks, this is Charles Maxwood from Top End Devs. And lately I've been working on actually building out Top End Devs. If you're interested, you can go to topendevs.com slash podcast, and you can actually hear a little bit more about my story about why I'm doing what I'm doing with Top End Devs, why I changed it from devchat.tv to Top End Devs. But what I really want to get into is that I have decided that I'm going to that I always wished I had with devchat.tv and I renamed it to Top End Devs because I want to give you the resources that are gonna help you to build the career that you want. So whether you wanna be an influencer in tech, whether you want to go and just max out your salary and then go live a lifestyle with your family, your friends, or just traveling the world or whatever. I want to give you the resources that are going to help you do that. We're going to have career and leadership resources in there. And we're going to be giving you content on a regular basis to help you level up and max out your career. So go check it out at topendevs.com. If you sign up before my birthday, that's December 14th. If you sign up before my birthday, you can get 50% off the lifetime of your subscription. Once again, that's topendevs.com.
THOMAS_RANDOLPH: So I have a question. I am only academically familiar with async generators. I've written one or two here and there. I can't say that I've used them sort of in a production type scope. One of the things that I really like about observables is that they can be sort of a push type wrapper around lots of different data sources. So for example, an observable could wrap around the click behavior on a button in a page. And now you just have a stream of clicks coming out that you can subscribe to at any time. Is that something that you could also do with an async generator? So respond to like click type events?
DAN_SHAPPIR: So first of all, we have an episode of JavaScript Jabber talking exactly about synchronous iterators, generators. So if you want to learn more about that, you know, we can link to that as well. But so first I can say this, first of all, I actually implemented an observable library that was surprisingly complete using a surprisingly small amount of code because I just use synchronous iterators and generators on the inside. So you could, so they are equivalent in the sense that you can implement one based on the other. Although I might say that the asynchronous iterators and generators are actually lower level to an extent. They do tend to have a more imperative style or approach to them. So it's kind of like if you compare a promise which is as a venable to an await. So you might say that the synchronous iterators and generators are more like a weight, like a sync weight. And the observables are kind of more like promises in that regard, that they espouse a more functional dot notation type of coding. But yes, there is definitely an overlap in terms of the functionality. And you can achieve very similar results using either one or the other.
THOMAS_RANDOLPH: Interesting. So yeah. I mean. to our conversation earlier about like, you know, the standard library is sort of, would underpin so many great improvements. You know, maybe, maybe it's, it would be right to make observable something that you can import and then it would just build on the already existing async generators and you get a couple of extra things. And that's, that's it. I think that, that's a perfectly fine approach to me. And I think that that would unlock a certain architectural approach for some people like myself without having to bloat the language, which I think AJ would love.
DAN_SHAPPIR: I think that that's a great idea, actually, that if and when observables do get added to the language, then it really has to be as part of the standard library rather than as a global, always available object that's just part of the language core, and that's it.
THOMAS_RANDOLPH: Yeah. I mean, all of us might be getting the gist here of kind of the approach. But I think. most things should probably be in the standard library. I think it's, I think the language is pretty good kind of as a core by itself. And there are things that are going to, you know, 10% of JavaScript developers use this and 20% use this. Those are, those are perfect things to put in the standard library because it's, it's going to solve the problem for 10% of people or 20% of people. And it probably should be there.
CHARLES MAX_WOOD: Yep. Well, I agree with everything you guys said on that second point. I, I just wanted to chime in way back when and plus one, the idea that if observables make it into the standard library or the language, that yeah, then we could just, yeah, RxJS would then just be a library of operators, right? And that would just be super cool, so anyway.
THOMAS_RANDOLPH: Or the standard library could even have a bunch of operators too. Like if RxJS is just providing maps and filters and reduces on a data stream, you could have those operators come from a special standard library that's specifically for data streams and-
CHARLES MAX_WOOD: Yep.
THOMAS_RANDOLPH: man, RxJS can just go away, which I think they would like.
DAN_SHAPPIR: And again, you will see an overlap here with another proposal that's later on in your list, which is the emitter proposal, which kind of bridges the gap, it kind of stands right in the middle between observables and asynchronous iterators and generators. You might say that if I had that emitter library, which hopefully we'll get to, and the synchronous iterators and generators, then together I could really easily build an observable, really in a few lines of code. Anyway, but moving to the next one on your list, what would that be?
THOMAS_RANDOLPH: The next one that I really am really excited about, and this is one that might be divisive, but it's partial application. And this is another stage one proposal. So who knows if it's even gonna progress, but the proposal, if you go read it, is extremely thorough. Obviously someone has a lot of experience with this and has covered kind of all of the edge cases. But basically this allows you to fix certain arguments to a function and by doing that it creates a new function that expects the rest of the arguments. So this can kind of be, you can kind of think of this as like, you know, if I'm always passing one parameter to a function, I can just create a new function with that parameter fixed and then expect the rest of them, which is really useful when you are writing strongly functional applications where everything is a function and the result is passed to another function and the results are passed on.
DAN_SHAPPIR: Yeah, for those of coming from functional backgrounds, it's effectively currying, I think. It's a term that's commonly used.
THOMAS_RANDOLPH: It's very similar, yes. Yeah. Yeah. Currying specifically breaks a function down into individual calls that all only take one parameter, which when you only have one or two arguments, that is a...it's pretty easy, right? You say an ad, the typical example is an ad function takes two numbers and then it returns the result. Well, you only want a function that takes one thing. So the first function takes the first number and it returns a function that takes the second number. And then that function adds the two.
DAN_SHAPPIR: Yeah.
THOMAS_RANDOLPH: That's curry.
DAN_SHAPPIR: Yeah, exactly. Because-
THOMAS_RANDOLPH: Partially sort of like, if you have more than two arguments, you want to just like fix one and then take the rest. And that's what partial occupation is. Yeah.
DAN_SHAPPIR: It's interesting because again, if we look at JavaScript, like you said, if we have an add function that takes two parameters and I invoke it with one, I've effectively invoked it with the second parameter being undefined, which is probably not what I want. But if I use a functional programming language, I like, I don't know, let's say Haskell, and I actually call a function with one parameter, what I get is a new function that just takes the other parameter. So I've not actually really invoke the function. I've just, you know, like you said, a function with multiple parameters is like a sequence of functions with a single parameter.
THOMAS_RANDOLPH: Right.
DAN_SHAPPIR: I'm again really hesitant about this one. Well, first of all, you know, obviously people who are listening will say, bind and why do I even need this? And like you said, the proposal is pretty thorough and does explain why it's not like bind because You, you, like you said, you can control which parameters are replaced. It's not necessarily in order. And also you, you can avoid dealing with the whole this thing and so forth. So, so there's certainly value in that regard, but my problem with it is that if you look at the spec, it reads like a whole lot of line noise, like you have the, what's the name of this wave character? It's, uh, I forget in English. It's the tilde and the question mark and it introduces a whole lot of syntax into the language. And at the end of the day, I'm not sure that it makes, you know, it all that stuff makes the language, for me at least, less readable. Now, maybe if it gets accepted and widely used, then familiarity will overcome that. But it's people are going to struggle with this. And I have a problem with something like that. It always feels like not JavaScript. And let's not forget that I can achieve everything that this can do. I can do with, let's say, by using arrow functions. It's just more typing. I can wrap the function with an arrow function that calls the original function with some of the parameters fixed in place. So it does.
THOMAS_RANDOLPH: Right.
DAN_SHAPPIR: potentially it reduces, it makes things less verbose, but that's not necessarily a good thing. So I'm really, really hesitant about this again, especially because of all of the way to the, of the extent to which it extends the language syntax.
THOMAS_RANDOLPH: Right. I would note that it does, I agree that it's hard to read or to my JavaScript lover eyes, it's hard to read, but it really is only introducing two new characters, the tilde and the question mark. And well, I mean, of course the question mark already exists for turn areas and those types of things, but it's a different context. So it does look very weird, but it really is only two new kind of syntax changes. And to your point about the arrow functions, I agree that for the most part, you can do this with arrow functions being more verbose. In the proposal, he does note that arrow functions, so I'm just gonna quote from the proposal here. Arrow functions lazily reevaluate their bodies, which can introduce unintended side effects. Now, I am not familiar enough with the exact implementation of how arrow functions work to understand what that's saying. But it sounds like by nesting arrow functions to get this partial application, it sounds like arrow function bodies continually get reevaluated or can be reevaluated, which could lead to issues where you just want to do it once, do it the first time. And again, I don't know the exact context of that problem, but there is an issue there.
DAN_SHAPPIR: It has to do with closures. The fact that, you know, is the engine smart enough to recognize that the particular arrow function is or is not dependent on variables specified within its closure? And if it's not, then just do it once. React actually has some wrappers for these sort of things like use ref or stuff like that that try to minimize or mitigate or reduce the number of times that an error function might need to be created. So again, I can appreciate that. It's just that, let's put it this way, I've been using JavaScript for this long without this capability and it seems to me that I'll be able to continue using JavaScript without it. It's not like, you know, with temporal where it's addressing a really painful issue for me or big int that you literally could not do currency applications in JavaScript because you had issues with numbers, you had to have like really sophisticated libraries in order to overcome it. This one is not solving such a huge pain point. And, but on the other hand, it needs to really change the language syntax. If anything, it kind of reminds me of one suggestion that I didn't see, one proposal that I didn't see on your list that I was kind of surprised that you didn't put in, which also-
THOMAS_RANDOLPH: There's so many of them I might miss.
DAN_SHAPPIR: Yeah, which also touches on the language syntax, but if anything seems more needed to me, and that's the one about records and tuples. So if I- And even there, I'm kind of hesitant because of the changes that are made to the syntax of the language. So that's a really sticking point for me. I'm not sure it's needed enough. And the cost of having to extend the language syntax in order to support it is pretty severe to me. Let's put it this way.
THOMAS_RANDOLPH: Yeah, that's fair. That's fair. And like, you're right that like, I have only wanted this. a handful of times, a few times. It's messy to do yourself in user land, in our own code. So it would solve that mess. But you're right that the change to the language is almost more trouble than it's worth. And there's a reason this is number six on my list, because it's kind of one of those things where it would be nice to have, but if the opinions like yours prevail, that would be totally fine too. I think it's also okay to have a more minimal JavaScript.
DAN_SHAPPIR: I would be really surprised if this makes it into the language. You know, stranger things have happened. But to be honest, I'd be really surprised. The next one on your list that I see is something that is much more likely to make it into the language than this one. Let's put it this way.
THOMAS_RANDOLPH: I did want to note one thing. I haven't actually experienced this myself. So who knows if it's a really compelling use case, but partial application as part of the language would also allow partially applied constructors, so a function or a class constructor can also be partially applied. So partially applying the constructor would return a function that then uses the rest of the initialization values for a constructor, which I think is, that might be a kind of an interesting use case too that may not be as easy as like, you know, an arrow function. That's, it's kind of an interesting use case that I could see people wanting to use a lot. Like, oh, you know, in my application, I'm always gonna construct this error class or whatever, but it always has to have these two parameters fixed, and then the rest will be up to the application. That's kind of an issue in this case, to like construct objects out of it. So the next one that I've got on my list is UUID, and this is kind of a little surprise one, because this was a STC39 proposal, but it has since been moved out. It's no longer going to be a part of the JavaScript language. I think that's a good decision, because if anyone's not aware, UUID stands for Universally Unique Identifier. It's a random string of characters that, generally speaking, you can expect to be unique in all the other generated versions of that string. This is something that a lot of people use, even if you don't know it, probably some system is probably generating a UUID for a record or your user or just something has this attached to it because it's a unique string that you can use kind of anywhere. It particularly came to prominence, I would say, in like a NoSQL environment where you're just always inserting documents and it needs to be like write safe and then distributed across multiple instances of your NoSQL database. So you can't have an auto-increasing number. You need to have just a string identifier. But of course, it's useful for so many more things than that.
CHARLES MAX_WOOD: Yeah. The other thing that I see used...for often even in SQL where you'll have a sequential insert and things like that, right? Is that if you have a sequential ID that is used in your code, then it's guessable. You have a guessable reference to objects you may not have permission to access. And so yes, it's an obscuring mechanism rather than a security mechanism per se, but It does make it harder for people who with malicious intent to do things that you don't want them to do. And so it's become popular there too.
DAN_SHAPPIR: And here's what I have to say. I would love for this type of functionality to be part of a standard library. I think, I think, I think it's, there are two issues. First of all, it's so common that having it always be available will just make life a whole lot easier, but even more significantly I've seen so many bad implementations of it. So people basically, you know, they need it. So they search, they all find the same solution on stack overflow, which I think is like the highest voted answer in the history of stack overflow, something like that. And it's nice enough, but you know, it uses math random, which isn't, you know, that random. So if you're looking for a truly unique identifier, this probably isn't the implementation that you want to be using. And if being unique is truly important and not just a nice to have. And actually I looked at the proposal and it actually literally said that it needs to be part of something, but they're not sure where and maybe as part of standard library. And that's exactly what I think should happen.
CHARLES MAX_WOOD: Yeah, I agree.
THOMAS_RANDOLPH: So it's actually been moved out to the W3C or the the web incubator community group, which is they're the ones who kind of vet ideas to go into the web platform. And it's being actively worked on and implemented in some cases by the browsers themselves as part of the crypto interface, which makes sense because the crypto interface already gives you the abilities to generate random numbers, we'll call them random numbers, pseudo random numbers, random values right from bytes rather than like, math.random, which isn't random enough. And that's what you need to create the randomness required for a string like this. So the implementation is going in right alongside the other crypto and cryptography stuff as part of the API provided for random values, which isn't the standard library that we would want, but it is provided by the VMs. So it won't be part of JavaScript, but it will be part of the browser environment or the node runtime or whatever it is that you use.
DAN_SHAPPIR: Yeah, so just to make the point distinct though, it's not being provided by the VM, it's being provided by the environment in which the VM is running.
THOMAS_RANDOLPH: Yes, that's correct. Yes, excellent clarification. Yeah.
CHARLES MAX_WOOD: Cool.
THOMAS_RANDOLPH: And this will be a V4, right? Which is the one that everyone uses. Of course, people want more versions sometimes if your company wants to namespace yours, but this is gonna solve the problem for most people. I think in the proposal, they say, Oh, this is the, the UUID package is downloaded from NPM 14 million times a week or something like that, which is, so it's like, this is a problem that we should solve.
CHARLES MAX_WOOD: Yep.
THOMAS_RANDOLPH: So the next one on my list is one that I think Dan has talked about at length.
DAN_SHAPPIR: Yes, I have.
CHARLES MAX_WOOD: That narrows it down to a long list of things.
DAN_SHAPPIR: Yeah, exactly. I tend to talk about a lot of things.
THOMAS_RANDOLPH: So this one, I think I sort of classified it in a similar vein as partial application. It's a syntax change that allows kind of more functional programming, and it's the pipeline operator. This basically allows consecutive operations to not be gross, which is kind of the simple way to put it. Like if you've ever, you know, I need to take the output from this function and pass it to this function, and then I take the output from that function and pass it to the next function, you've got this long chain of functions that are all nested and and it reads in reverse, so you've got to read from like the right side back left to see what's happening. And pipeline, the pipeline operator, which the proposal is just to use a vertical bar and then the right-facing carrot to just kind of reverse the order. So the left-hand side expression is evaluated and passed to the right-hand side expression. So you can sort of chain functions together without having to nest them.
DAN_SHAPPIR: So here's a funny story about it. So I wrote a while back, I wrote a blogpost that's actually on the Wix engineering blog site because I was at Wix when I wrote it and I implemented a library that used iterators and generators to perform with iteration methods or iteration algorithms. So instead of using chaining like to do a map and then filter, I used iterators and generators and used the pipe operator and it has all sorts of benefits and I won't go into them now and I explain them in the blog post and we link to that and people can read it and I think it's a nice blog post. And I got a lot of really positive responses, but they were all along the lines of great library, we love what you did, why are you using this disgusting pipeline operator? So, a lot of... So...Somebody, so yeah, so people were really happy with the concept, but were really annoyed with the fact that I used the pipeline operator to kind of implement it. And I get it. And it kind of goes to the same points that I made about the partial application, about the fact that you're introducing significant new syntax into the language and anybody who's coming into the language from Regular JavaScript developers might be really perplexed and surprised by expressions that use the pipe operator. But like you said, I did see the benefits, the fact that it can make it much easier to read because you're just passing the value from left to right instead of, like you said, creating these messy function invocation expressions. But since then, I've written another blog post where I explained why I actually recanted and why I now think that this operator isn't actually needed. And the reason that I showed was that you can actually create like a pipe function that serves a really similar purpose to the pipe operator. So you can achieve a really similar effect. Now it has been shown to me that this is not exactly one-to-one and there are definitely scenarios where the pipe operator has advantages, but they're not that significant. So if I can use a function instead of having to introduce another operator and change the language syntax, then my tendency would be to avoid the big change to the language. So from being a pipeline operator, I've since become somebody who's really wary and potentially opposed, you might say, to this operator because, as I said, I don't think that in and of itself it provides enough value that it merits that change to the syntax. And again, that feedback that I got from so many people just didn't like that syntax. And again, when we look at the next, and one of the next proposals that you have on the list, the emitter proposal, they actually, the function there that they call run, which in my library I called pipe, effectively achieves exactly this behavior. So it exactly shows how you can achieve this type of behavior without having to introduce a new operator into the language. And there's also another thing about the pipeline operator, which is the fact that there are two possible syntaxes there. There's one approach which is called hack pipes.
THOMAS_RANDOLPH: Is it the hack?
DAN_SHAPPIR: Yeah, and there's another approach which is called F-sharp pipes or unary pipes. And it's kind of undecided. The people who've made a proposal prefer the hack pipes, but it's not really been decided. And it's been stuck at level two for a very long time. So like you said about another proposal that's more or less stagnant, it kind of significantly reduces the likelihood that it will actually ever be included into the language. But if people do want to play with it, then I think there's like a plugin for Babel that you can use to add this functionality. So if people want to try it out and see how it works, it's very easy to check.
THOMAS_RANDOLPH: many of the examples on the proposal use the implementations from many libraries. I mean, even underscore has its own sort of its own like piping sort of library to move through objects. But I want to I want to go back in and say, you know, everyone you heard it here first on the JavaScript Java podcast, Dan Shapiro is against pipelines.
CHARLES MAX_WOOD: You lost my vote, Dan, I'm voting for somebody else.
Hi, this is Charles Max Wood from Top End Devs. And lately I've been coaching some people on starting some podcasts and in some cases, just taking their career to the next level. Whether you're beginner going to intermediate and intermediate going to advanced, whether you're trying to get noticed in the community or go freelance, I've been helping these folks figure out how to get in front of people, how to build relationships and how to build their careers and max out and just go to the next level. So if you're interested in talking to me and having me help you go to the next level, go to topendevs.com slash coaching. I will give you a one hour free session where we can figure out what you're trying to do, where you're trying to go and figure out what the next steps are. And then from there we can figure out how to get you to the place you wanna go. So once again, that's topendevs.com slash coaching.
CHARLES MAX_WOOD: So the place that I've seen this is in Elixir, which is a functional programming language. And the pipeline operator that you described is exactly what they use over there. And so, and it's, it's a very powerful and helpful feature in Elixir and is used all over the place when you're writing code there. The thing that makes it really powerful though, is that Elixir functions off of pattern matching. And so when you pass something out of one function, it will pattern match against it in the next function. And so you get some really, really powerful interplay transforming inputs and outputs to get what you need at the end. And so that's where I've seen it used to great effect. And that's what makes me kind of excited to possibly see it in JavaScript.
DAN_SHAPPIR: Yeah, but that's the thing. And again, I've got to paraphrase AJ here. And by the way, this is also available in other functional languages like F sharp. But just because it's great in one language doesn't mean that it has to be, that it'll be great in another language. And those languages have a particular style to them. And JavaScript does not need to be an aggregation of all possible programming languages and programming paradigms that are out there.
THOMAS_RANDOLPH: Right.
CHARLES MAX_WOOD: Yeah, but it already is. That's what they did in the ESS. I mean, did I just say that out loud? I'm sorry.
THOMAS_RANDOLPH: Yeah, there is something to be said for, you know, JavaScript so far has sort of tried to be
CHARLES MAX_WOOD: Yes.
THOMAS_RANDOLPH: There's a lot of influence from. from Rails or Ruby, there's a lot of influence from the C Sharp community, there's a lot of influence from various other languages, and in my opinion, I'll expose my prior bias here, I think that it should be sort of, it should be JavaScript, it should be its own thing. I really like that it has a dynamic prototype based sort of feature, I really like that it really, it can encourage, if you use it a certain way, it can encourage functional programming. And that's why, you know, if you look at the, cohesiveness of my list. It's mostly functional stuff. It's mostly things that enable that. And that's what I think we should lean into. Now, to Dan's point, it doesn't have to be that. We could lean the other way or we'd lean no way. And if we're leaning no way, then yeah, we probably shouldn't be putting in these little things that can be done. You know, we've talked about like various libraries have implemented their own pipe or emitter has their run function or all sorts of things. I've also built my own pipe function. And you're right. It's like, it's a few lines of code. It's maybe 10, 10 lines of code or something. And, and like that's, that maybe is, it's, is the biggest strike against adding this to the language. Um, if it can be done so easily, why should we make a new syntax for it? But Hey, standard library, put it in the standard library. Be like, this is, this is the way you fight things to each other. And like, that's a perfect use case.
CHARLES MAX_WOOD: I would import it like eight times to make it eight times a school.
THOMAS_RANDOLPH: That's, that's how that works. Yeah. Yeah.
CHARLES MAX_WOOD: All right, let's talk about emitters.
DAN_SHAPPIR: Actually, we have one before, which is module block.
CHARLES MAX_WOOD: Oh, we do?
DAN_SHAPPIR: Yeah, so we have like two items. This is, yeah. I don't know if this will come out as one episode or two. If one, this is definitely gonna be one of the longer ones. But yeah, we have two. We're creeping toward two, but yeah. Yeah, so we've got two items in the list, and I might throw in a third one if we have time. Let's go.
THOMAS_RANDOLPH: We can, Dan, you're taking over. We can go through these quickly. I mean. As we noted earlier, this is in order of my preference from top to bottom. So we're getting down here to numbers nine and 10. And this is open for discussion. I'm not really, I don't feel super strongly about these at all, but the first one is module blocks, which is a stage two. So it's already been, it's already been sort of moved up in the priority of like, we expect this probably to make it, but who knows what's actually going to look like this basically allows you to create modules sort of inline. You can just using the module keyword, create a module and you can import it. import it using, you can only use the dynamic import in that case, obviously, because there's no file reference to import a module from. But this kind of would enable features that developers sort of are avoiding right now. So things like web workers, they're hard because they have to be in a separate file and they're compiled elsewhere. And that's one of the main use cases. And one of the main pain points for web workers, people say, I don't want to have this other file that's like this separate JavaScript thing. And inline, block modules would kind of allow you to say this chunk of code in the same file is a worker over here and you can just and you can run it that way and it also has some improvements for like you know our bundlers these days the whole job of a bundler is to take all these different files and make them one file or make them a few small files and this would just be part of language you can you can have a module block that is that is in the same file and is a separate module
DAN_SHAPPIR: it's interesting that one of the proponents of this proposal is the who's actually been on this podcast and is really well known for the work that he's been doing with the workers. I forget the name of the library that he created. The one that makes it possible to invoke function code in workers like a regular function call, passing parameters instead of using post message. You know, the name. And that kind of goes to why he proposes this because he wants to be able, this really enables you to embed the code inside the same file, and then instead of executing it as a function call, execute it in a worker and invoke it as if it was a function. So it's not surprising.
THOMAS_RANDOLPH: Yeah.
DAN_SHAPPIR: that Surma is one of the proponents. And I actually like this one. I would really like to see this part as part of the language. Yeah.
THOMAS_RANDOLPH: Is that library that you're talking about called parallel?
DAN_SHAPPIR: No. I'll find it in a minute.
THOMAS_RANDOLPH: OK. Yeah, I think the ability to sort of segment code as if there are other modules without having to actually create other files or interact with a file system or, I mean, Forbid across the network, right? Like you don't want to load files from a network source. Having modules in line is a really interesting kind of maturation of the...
DAN_SHAPPIR: The library is called Comlink, by the way. It's a really small library that makes it possible to invoke code inside a worker as if it's a function call. So it basically just takes the parameters that you pass in and wraps them and then sends them across via post message and enables you to await for the results. So you can transform the operation of coding a worker to seem as if it's a regular function called with parameters and a return value and stuff like that. It's really nice and it's fairly popular. And again, this highlights why this paradigm is useful because it makes it really easy to be able to use something like that.
THOMAS_RANDOLPH: That's one of those things where, you know, often when people talk about developer experience or the DX of something, I kind of think, well, that's kind of the least important thing that I want to worry about. I want to worry more about the performance of it or what new abilities does this unlock or how do users perceive this? But making web workers so much simpler to use with like one keyword, with a single keyword, making web workers just like, oh, boom, you can kind of do it in line with the rest of your code. That's a huge advancement sort of in the abilities of JavaScript or web browsers and I the DX of that is really important. So I'm a big fan of it
CHARLES MAX_WOOD: Well, one other thing just going into So if you're writing a greenfield project, it it's a little bit different but once you get into the maintenance and Adding new features to a complex system and things like that the developer experience becomes much much more important because you can Move more quickly if you can navigate the code well and so adding features to the language that help with developer experience is actually very, it's kind of a critical piece. And it'll save the companies that are using the language a whole bunch of time and money and effort. It'll make the developers happier to write. Anyway, there are a lot of payoffs for it. And so if this allows you to kind of namespace or segment off your code or give you a better or easier way to think about what what functionality is there, things like that, then in my opinion, it's a win.
DAN_SHAPPIR: I totally agree.
THOMAS_RANDOLPH: So, yeah, I think this is one of those things where it's such a small addition. Earlier when we were talking about the pipeline operator, it's a small amount of change, but it really significantly changes how JavaScript reads for a fairly small improvement that you can do with a pipe function, for example. Whereas this is also a fairly small change to how JavaScript reads, just kind of the module keyword basically in front of a curly brace block, but it dramatically improves how things that you can do that you could never do before, which is the cost value or yeah, the risk reward ratio there is really high on this one.
CHARLES MAX_WOOD: I agree.
THOMAS_RANDOLPH: So let's get to the last one. We've mentioned it a bunch of times. It's the emitter proposal, which it's, to me, I kind of think of it like, all of the operators on observables. So it's basically the ability to wrap values in something that you can then pipe through. You can send the value through a set of functions like filter or map or whatever, or you can call that on the, you can always access those operators on the emitter object itself. I think of it kind of as like an observable subject, if you're familiar with observables, a subject is like a multicast stream plus the pipeline ability that we were talking about earlier, plus all of the observable composition operators. Dan, you're excited about this one.
DAN_SHAPPIR: Yeah, like I said, it reads very much like the blog post that I've written about building an iteration library on top of the iterators and generators. One of my complaints has been that iteration methods or functions or algorithms like filter and map and reduce and whatnot are all implemented on top of arrays directly on the array prototype. So you get them on the built-in array object, but you don't get them on any other type of an object that does provide iterators, like for example, a map that you can actually loop over the values in the map. So if you actually want to do some sort of one of these iteration methods, you actually have to copy everything over into an array and then do it which kind of defeats the whole purpose. And emitters are exactly that. They are a collection of iteration methods that can effectively be applied to anything that has an iterator on it. And that's exactly what I want. That's the thing that will potentially save iterators and generators from being this sort of an unsuccessful or failed language feature, because nobody actually ever really uses them. And that's why I'm very much in favor of it. And I think that, like I kind of said, that if you take the emitter proposal, couple, you know, and obviously, like you said, get and it actually shows it in it doesn't you it uses a global emitter in the example but I would very much like to see it as part of a standard library and having these functions being imported actually and and then you would get all these function as part of a standard library very really easy to use and you could probably also use them to really easily implement observables so either Either you would just use them to implement observables, or you would have an observable also as part of a standard library, but potentially implemented on top of emitters. So either way, it's kind of a win. And like I said, would really like to see it implemented as part of the language, but not on a global object, preferably as part of a standard library.
THOMAS_RANDOLPH: Yeah, agree on that point for sure. I will note, and again, I have to say, I'm no expert here. So. So. I'm reading other people's opinions and sort of trying to understand where they're coming from. One of the main contributors to RxJS has actually opened an issue on this proposal, sort of taking issue in a kind way with some of the ways that Emitter compares itself to Observable. And actually, of course, a contributor to RxJS is going to think Observable is the way to go. But they actually claim that Observable is a more primitive implementation than Emitter. I'm not going to say that I have an opinion on that. I love observables, so that's where I'm coming from, right, my bias. But I think it would be interesting to read that issue. It's a pretty long rebuttal of some of the claims in Emitter that observable is the most creative.
DAN_SHAPPIR: I don't necessarily disagree if everything was being implemented from scratch. If iterators and generators, if asynchronous iterators and generators did not exist, then obviously implementing them and emitters would be much more complicated than implementing observables. But the fact is that synchronous iterators, generators do exist and are already a part of the language. So that mechanism has been implemented already. And adding emitters on top of that is a much thinner thing than building observables from scratch. So again, if a synchronous iterators would not have existed in the language, then undoubtedly adding observable would have been much like to wait than adding an emitter.
THOMAS_RANDOLPH: Sure. Yeah, that makes sense to me.
CHARLES MAX_WOOD: Makes sense to me.
THOMAS_RANDOLPH: I'm excited about this stuff with a... Man, we keep coming back to the built-in modules, the standard library. We really need that. We need a bad... And I'm sad that it's only a state...
DAN_SHAPPIR: I totally agree. And I think it's way past... I don't know why it's taking so long, to be honest. Like I said, Chrome has been...The Chrome people and the V8 people have been playing with it for years. I don't know why it's really taking so long. Maybe they're just afraid to commit to standard library. I don't know.
THOMAS_RANDOLPH: Yeah. It would be terrifying to be like, this is what the TC139 committee thinks should be in the standard library. That would be an anxiety ridden decision.
DAN_SHAPPIR: I would like to mention one more thing. I actually kind of mentioned it before when we talked about the partial application and that's the proposal for records and tuples. It's stage two. It's also been at stage two for a long time. So we'll see if it actually ever gets anywhere. It's fairly well known, actually. Basically, the idea is think about the syntax that we have for object literals and array literals. You know, all array literals with the square brackets and object literals with the curly brackets. And just then prefix them with the pound or hash character. So if you prefix an object literal with a hash, it becomes a record. If you prefix the array literal with a hash, it becomes known as a tuple. And the thing about them is that they're immutable. That's it. It's kind of like they're frozen. So it's like applying object.freeze on top of an object literal or on top of an array literal, except not exactly. because there's another interesting thing about records and tuples is that their definition is also recursive because a record or a tuple can only contain either primitive values or other records and tuples. So that means is that not only are they immutable, they are deeply immutable. So if you just use object freeze, you can still go in and manipulate the values that are referenced by properties, because it's not a deep freeze. There's actually a library called deep freeze, because that's exactly what it does. It does a recursive freeze. So records and tuples are deeply immutable when they are deep. And that enables really interesting behaviors. So for example, we see a lot of cases, for example, in React with some.
CHARLES MAX_WOOD: Hey Dan, I'm going to stop you for a minute because your sound changed. Sounds like you're talking through a telephone.
DAN_SHAPPIR: That's really strange. Yeah, I hope so.mutable and you don't care about the reference you just in there. also slightly on the fence here again because it adds value but it's a question of whether it adds sufficient value in order to justify the the chain the syntactical change to the language and whether you know JavaScript really needs to be that functional. You know if people want a functional language maybe they should be using Elm rather than than JavaScript. It's an interesting question. Right.you know, but, but it's still a really interesting proposal.
CHARLES MAX_WOOD: Yeah.
THOMAS_RANDOLPH: Yeah. I think I personally don't often struggle with the immutability of objects. And so for me, it wouldn't make my day to day a lot easier, but I do, I do totally see the value, especially, you know, especially with the comparison of, of things. Like are these two tuples the same would be very valuable, but I think you're right that like, is this, is this going to dramatically change? JavaScript and I think the proposal talks about libraries like immutable JS or Immer I think is another one and I wonder if I wonder how much of those libraries we can remove With this type of thing. Maybe it's all of them, which I guess would be a pretty big win. I'm not sure
CHARLES MAX_WOOD: Yeah, I don't know anything like I do. I do agree with Dan I like the idea of having tuples and and and I see the benefits there a lot of the immutable stuff It just saves on you know, memory load and it saves on it, you know, it's faster. I mean, there, there are certain benefits come from it, but you know, sometimes it adds complexity. I don't know how heavily it would be used. I think it might wind up being used a whole bunch under the covers for those reasons, but not necessarily used day to day by JavaScript developers.
THOMAS_RANDOLPH: I think it would be really powerful for the communication between, I'll use the word APIs, but the communication between internal things that are, that expect some record and then send some record because you never want to accidentally send a mutable object to somewhere, have them change it and it be modified in your code or whatever. So sending a record in that case and then they can do whatever they want inside their code, but always the communication is immutable sort of at that higher level.
DAN_SHAPPIR: People who are into reducers would really like it. Yeah, anyway, I think that more or less covers the proposals that yeah quite a lot of quite a number of proposals By the way, I don't know if you saw this. I will mention one more because it just can't resist For those of you who may not recall there are the reverse and sort methods on arrays are They modify the object that they invoked on so That's an unfortunate decision that again Brendan Ike made back in the day maybe in order to conserve memory or whatever on those older systems. But when you apply sort on an array, it actually sorts the array that you applied it on. It doesn't return a sorted array. Well, actually it returns a sorted array, but it returns the same array that you passed to it. And the same with reverse. And there's, I don't recall where it is, but it might have been adopted. There's the too reversed and too Yeah, I think it's been accepted actually that returned that are immutable. They return a sorted array, they return a reversed array. And I'm really happy to see that. And going forward, I'll always use that.
CHARLES MAX_WOOD: Nice.
THOMAS_RANDOLPH: Yeah. The in-place stuff is always asking for trouble.
CHARLES MAX_WOOD: Yeah. Yeah. Cause you don't know what else is referencing it. Right.
THOMAS_RANDOLPH: I'm trying to, I'm trying to find these proposals and I, I'm actually having trouble, I'm in the, I'm in the final, the finalized finished proposals. I don't see it, Dan.
DAN_SHAPPIR: I remember seeing it somewhere. I saw it. Oh, here it is. I saw it in a, I'll put a link to it here in our own chat. Where's our own chat. I saw it in a blog post by Axel Rauchmeier. He's like this really well-known guy about understanding what the language is and where it's going. So it's the Acma script proposal, change array by copy four new non-destructive array methods. It includes to reversed, to sorted, to spliced, and another one called with, which I don't remember what it does.
THOMAS_RANDOLPH: Yep, I just found the proposal itself, so there's the link to that as well. Yeah, that's cool stuff. But again, continuing to extend the prototype, and I wonder if it would be better to move, like have a standard library that does this.
DAN_SHAPPIR: Yeah, again, if you look at the emitter proposal, it kind of solves it out of the box.
THOMAS_RANDOLPH: Right, yeah, absolutely.
Hey folks, if you love this podcast and would like to support the show, or if you wish you could listen without the sponsorship messages, then you're in luck. We're setting up new premium podcast feeds where you can get all of the episodes released after Christmas 2020 without the ads. Signing up will help us pay for editing and production, and you can go sign up at devchat.tv slash premium.
DAN_SHAPPIR: Chuck, wanna do pics?
CHARLES MAX_WOOD: All right, well, I was gonna say, I think we're overdue for pics, so.
THOMAS_RANDOLPH: I think so.
CHARLES MAX_WOOD: Anyway, this has been really terrific. We are definitely going to be splitting it into two episodes. But, Oh, it's been terrific. I love talking with y'all. All right. Well, let's, let's make Steve go first. He's been quiet for a little bit.
STEVE_EDWARDS: So we'll start actually, we'll start at an end with the high point of any of these podcast episodes, which are the dad jokes. So the other day I went to see my doctor and he told me that I was really growing as a person, but what he really said was you've gained a bunch of excess weight.
DAN_SHAPPIR: Yeah, highly expected.
STEVE_EDWARDS: Yeah. Yeah. Speaking of doctors, I know a surgeon that actually puts organs in, he puts organs back in upside down. I said, that's not funny, but he's just said it was an inside joke. And then I saw a new story recently where a store clerk had fought off an armed robber with a pricing gun. So the police are now looking for a man with a price on his head.
CHARLES MAX_WOOD: I like that one.
STEVE_EDWARDS: That's sort of a takeoff. If anybody knows Stephen Wright, he has a classic joke about a crazy lady that lived in his apartment building who tried to hold up a department store with a pricing gun. And she said, give me all your money or I'll mark down everything in the store.
DAN_SHAPPIR: That's a good one, actually.
CHARLES MAX_WOOD: You know, Steve, I have a friend who tried to put together a dating app for chickens, but it was really hard for him to get, hence meat.
STEVE_EDWARDS: All right. Thank you. Thank you. Thank you very much.
CHARLES MAX_WOOD: Do you have any actual picks or should we move on?
STEVE_EDWARDS: I guess if those aren't actual picks and no, I don't have any actual picks. Well, just things that anyway, um, I will, I will say one, and this is probably going to be a little contentious, but as of today, yesterday was the day that the federal judge rescinded the Biden mask mandate on airlines and for travel. So hallelujah. Amen. And everything else
CHARLES MAX_WOOD: that makes flying more pleasant. All right, Dan, what are your picks?
DAN_SHAPPIR: Okay, I have a few so my first pick is I'm watching Star Trek Picard and I'm enjoying it. It's a it's a nice little show. It's not amazing You know, that's the interesting thing about Star Trek for me. The the premise is always much greater than the actual execution I'm I'm always I always expect to enjoy the the the various series is much more than I actually do But there's one particular thing that I especially do like about Star Trek Picard, and I think that's a pretty obvious thing, and that thing is Sir Patrick Stewart. He is such an amazing actor. It's astounding to see how much of a better actor he is than everybody else on the cast. It's such a pleasure to watch him act. I would literally just watch him read stuff. I don't even need the, the, the, the, the, all, all the things with the spaceships and stuff, you know, just watching him on screen, especially reprising that role. He's just amazing. And I, and I love, and I love it for just for that. So that's. Yeah.
STEVE_EDWARDS: He could read the dictionary. DAN_SHAPPIR: Exactly.
STEVE_EDWARDS: He's such an amazing actor. So. My wife's a real big fan of that too. She really looks forward to all the card episodes and she's trying to get me into watching it, but I haven't broken down.
DAN_SHAPPIR: Yeah. So that would be my first pick. My second pick is the great Norm Rosenthal, who is actually a past guest on our show, is doing great work working on the various standards, like the HTML standard. And he's actually managed to introduce a really cool new feature into the HTML standard, which is the 103 early hint responses. Basically, it's a mechanism that allows the server while it's still working on the main response to send like a sort of a pre-response down to the browser telling the browser while you wait, please download this and that resource. So you can kind of, you know, so for example, think about, you know, you need to work to generate the HTML, but you can already inform the client that it should start downloading various, I don't know, images or JavaScript or whatever because it will be needed later on. And I can post, you know, put the link to the proposal in our show notes, or accept that, you know, our show notes apparently will have a lot of links in them this time around. So that would be my second pick. And my third pick is the one that I just mention each and every time, just to remember that the war in Ukraine is still going on, still happening. This is so sad, so unfortunate. I really hope that...You know, I'm kind of worried or concerned that people kind of might start normalizing it because it's just taking so long and it's not ending. It just makes me so sad. And I really wish that all this suffering would be over. And those would be my three picks.
CHARLES MAX_WOOD: All right. I'm going to throw out some picks as well. So you mentioned Sir Patrick Stewart. And one of my favorite things that he's read is, and I got this on Audible. It was the Chronicles of Narnia and they had different actors and actresses reading the different books. And Sir Patrick Stewart reads the last battle, which is the final book. And he did a tremendous job. A lot of the other narrators are great too, but I'm just going to pile on cause I've enjoyed that. For me, the best part of Star Trek Picard now I've only seen the first season. I haven't seen the second season yet. The best part of that was just seeing all the other old characters, actors and actresses come back, right? Cause that was just fun. They kept all the callbacks to the old series. For my board game pick this week, I'm actually gonna do something a little bit different. This is something I do with my kids. It has board games on it, like Battleship or Reverse or some of these others. It works through the text message function on your phone. It only works on my iPhone. I don't know if it runs on Android or not, but it's called Game Pigeon, and you can actually text somebody a game, and then when you take turns, it texts you back and forth. And so anyway, it's a lot of fun. And it's a fun way to play some board games with my kids. And so, yeah, I tend to play it with my 13-year-old and 15-year-old are the ones that are really into it. So anyway, so that's gonna be my board game pick. It's a little bit different, but anyway. So I'm gonna shout out about that. And then I'm just trying to think here. There's just so much going on right now. Yeah, I don't know if I have anything else right off the top of my head. So we'll go ahead and let Thomas go. Thomas, what picks do you have?
I've got a bunch, but I will, I'll limit to my top three, uh, with one bonus, which is plus one to kind of remembering what's going on in Ukraine. As of today, I know this will come out much later, but as of THOMAS_RANDOLPH: oday, I think the fighting has picked up pretty badly in the Eastern Donbass region again, which is, which is troubling. So yeah, keeping that in our minds. Um, I'll also pick my notes for this, for this episode or these episodes. I have tons of links to all the proposals. I have links to prior art. I have links to code examples. And so those are all published live. And that can be sort of a resource here in addition to the picks that I don't say out loud. I have this book that has kind of been stuck in my brain for a really long time. It's actually a really old book with a few updates for more modern times. It's called The Design of Everyday Things by Don Norman. I think it's It's not really about programming, although I think it can be really important to read for developers, because it kind of helps you understand the phrase. You might hear phrases like affordances or signifiers or those kinds of things. Those come from essentially this book. And it's how we design things that people can use. I think it's a really kind of seminal book on how design works. And I think it's really important thing. So I'll pick that book. And then... My last one is I found an article that gave a really great overview of what reactive programming is. It's sort of my passion's architecture of programming. So I'll link to this article called What is Reactive Programming by Kevin Weber. It's on a blog from a company. I think it's a really great overview of reactive programming and why it's such an important paradigm in modern development. Yeah, there's lots more links in this and I'll shout out Dan's. Pipeline stuff that he's where he wrote those are I've linked those as well. So that's it for me
CHARLES MAX_WOOD: All right, if people want to connect with you online, I think you mentioned that you're on Twitter.
THOMAS_RANDOLPH: That's right Yeah,
DAN_SHAPPIR: you want to let me know where to I think and by the way, I have to say that definitely worth the follow.
THOMAS_RANDOLPH: So Well, thanks Dan that that actually means a ton.
DAN_SHAPPIR: Thank you.
THOMAS_RANDOLPH: Thank you. Thank you.
DAN_SHAPPIR: Oh sure I call it as I see it.
THOMAS_RANDOLPH: Yeah. Okay. Great. Yeah, my Twitter account is rock wrist r o c k e r e s t And I will say that's kind of Twitter's, I think this might be a paraphrase of AJ, Twitter's where you go to like have hot takes and be divisive. So I have a stance on Twitter and it's for certain things. So give me a follow and see what you think and I won't be offended if you unfollow me. But that's probably the best place to see my sort of daily thoughts. My sort of the canonical place to find me is my main website, which is just rdl.ph, which is my last name without most of the letters. So. RDL.ph is sort of my landing page. But yeah, find me on Twitter at rockrest, R-O-C-K-E-R-E-S-T. And I look forward to interacting with you all about how wrong I was that these are the best proposals for TC39.
CHARLES MAX_WOOD: Sounds good. All right. We're going to go ahead and wrap it up here and until next time folks Max out.
DAN_SHAPPIR: Bye.
THOMAS_RANDOLPH: Bye.
STEVE_EDWARDS: Adios.
Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit c-a-c-h-e-f-l-y dot com to learn more.
Singapore is an urban wellness haven that lets you find your inner peace with rejuvenating spas, yoga studios, and more. And now with Singapore Rewards, you can experience Singapore's hidden gems for free. Enjoy aqua spinning or even a perfume workshop inspired by the scents of Singapore's native orchids – all for $0. Find out more at SingaporeRewards.VisitSingapore.com. What are you waiting for? A Better Way to Holiday awaits you.