Today we chat with Thomas Randolph from GitLab, to discuss his Top 10 list of the upcoming TC39 proposals.

 The list…

On YouTube
TC39 and Upcoming Proposals for ECMAScript (PART 1) - JSJ 532

Sponsors

Links

Picks

Special Guest: Thomas Randolph.

Sponsored By:

 
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: Quit saying that. Makes me nuts. 

DAN_SHAPPIR: What can I do? It's almost always warm and sunny in Tel Aviv. 

STEVE_EDWARDS: I know. 

CHARLES MAX_WOOD: I'm 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'm not famous. Let's start with that. 

STEVE_EDWARDS: Yeah. After this podcast, there'll be people clamoring for your autograph.

CHARLES MAX_WOOD: That's right. You'll be infamous. Yeah. There you go. 

THOMAS_RANDOLPH: 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 this month. So who knows? 

STEVE_EDWARDS: Yeah, we already had snow here in Portland last week. We just had one here in Portland, closed all the schools and everything. You know, here they close if you get an eighth of an inch, but it was a lot of snow for one day. So yeah. 

DAN_SHAPPIR: 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 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 Max Wood 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. 

 

CHARLES MAX_WOOD: Thomas, do you kind of want to, you have this list that you kind of rounded up for us. Do you want to kind of tell us where this list came from? Like how you figured out what you were excited about or what was coming and then tell us, yeah, why you ranked them the way you ranked them. And then we can dive into the individual bits. 

THOMAS_RANDOLPH: Yeah, definitely. I mean, the the the basic background or context is that I'm I'm really interested in the JavaScript language. So so how it's how it's put together the the ideas that go into the changes that are made in it. That really interests me. So I follow I follow the TC39 process pretty closely and follow proposals that are being presented for the changes to JavaScript. So there are a lot of them and they kind of vary. You could put them in probably two major camps. It's more like a more of an object oriented or class based one and then more of like a functional sort of functional composition sort of side. And so I lean more toward the functional side. So the ranking that I have here is the things that would enable me to do more of a compositional style application. So I have all sorts of ideas about streaming data and function composition and those sorts of things. So my list comes from that interest in how JavaScript can advance on sort of the functional side versus the class-based side. 

DAN_SHAPPIR: If I can interject for a minute because we kind of jumped right into it. For some of our listeners, they may not be familiar with the term TC39. TC39 is a committee that's part of the ECMA organization that's responsible for what is known as ECMA script which the name that Brendan Eich, the inventor or creator of JavaScript, has likened to a skin disease. But that's the official name of the JavaScript standard for copyright reasons. For those of you who don't know, the name JavaScript actually belongs to Oracle. So they had to pick a different name for the language standard, and that's ECMAScript. But effectively, all JavaScript implementations or engines are essentially just implementations of the ECMAScript standard. And TC39 is that body or committee that's responsible for advancing it. And one more thing that I would like to say about it is that we actually had an episode about the process of how suggestions go through the TC39 committee. That was episode 425, the evolution of JavaScript, and we'll put a link in the show notes to it. But...So if people want to hear more details about exactly how that works. 

THOMAS_RANDOLPH: Yeah, that's great. So we're going to be talking, we'll talk about a bunch of proposals and I'll note the different, the various stages that they're in, cause that's been important to know like how likely it will be in the ECMAScript specification. So a bunch of the ones that I'm excited about are stage one, which is they aren't even sure it's going to, it's going to happen, but I'm interested in it. 

CHARLES MAX_WOOD: Right. So where do we start then? 

THOMAS_RANDOLPH: I think one of the, one of the most exciting things coming that's going to impact a lot of people is the, is the temporal proposal which has been long running, a long time coming. But if you've ever used the built-in date constructor in JavaScript, you've probably experienced some of the pain points with it. It's a- 

CHARLES MAX_WOOD: Defying used. 

THOMAS_RANDOLPH: So, I mean, obviously constructing a date and just being like, what's the string for that date? That's not that painful, but as soon as you try to do any sort of math on it, like, oh, what's four months in the future, things get hairy things get pretty messy, especially if you're trying to do it between two people, right? Like a calendaring system. Like what, what is, what is this time and date on this other person's in insular person's time zone, for example, that stuff is, is hard. 

CHARLES MAX_WOOD: Hold on. I'm having heart palpitations. My stress level is gone through the roof. 

THOMAS_RANDOLPH: Exactly. And there's, there's, there's like no built in way to add, right? Like just add a month to this and this just, it just doesn't exist. You could do something naively and add a bunch of milliseconds to the underlying value of a date, but that's, it's, you're getting into really bad territory. 

DAN_SHAPPIR: If you get even more ridiculous than that, as I recall, some of the values, they are zero based and some of the values there are one based and it's a really, really amusing implementation of date. And by the way, the reason that JavaScript got this really amusing implementation is that Brendan Eich basically copied it over from the Java programming language when he implemented it. So we got all the idiosyncrasies that were baked into Java also made it into JavaScript in the context of the date object. 

THOMAS_RANDOLPH: I think it's important to note that they're actually not baked into Java anymore. So when Brendan was writing JavaScript originally, he was told, make it like Java, because Java was hugely popular and still is. But at the time, he copied the data implementation from Java one. 1.0 and I actually have a link in my notes from one of the authors of this temporal proposal and basically said the implementation that he copied from Java was frankly terrible and it's been deprecated and removed since then and in fact it was deprecated and removed in Java 1.1. We're currently in Java 18. We're in Java 18 right now. Wow. JavaScript has been stuck with that same data implementation since 1997, 96. So it's high time for something. And that's what temporal is. 

STEVE_EDWARDS: Well, yeah. I mean, there's a reason to say there's a reason that moment was so ubiquitous. Yes. And now you get it, you know, the stripped down versions like date functions, date underscore FNS is when I've used those because people were finding better and better and more efficient ways to handle date math inside the JavaScript. So, you know, I think once the temporal, you know, proposal was made, you know, this was a typical response. I think that was out there.

DAN_SHAPPIR: I too have encountered many, many projects that bundled Moment.js and a big issue with that is that Moment tended to be fairly large. And also the fact that I've actually seen projects that for various NPM issues bundled three different versions of Moment. So like 80% of the projects download was actually just Moment.js. which is pretty unfortunate. 

THOMAS_RANDOLPH: Yeah. And I mean, Moment doesn't even ship by default with useful time zone handling. Of course, your browser can handle your own local time zone pretty easily. But if you need to do translation across time zones, even Moment ships that as a separate library because it's such a huge amount of data. There's so many little tweaks here and there and like, oh, we skipped a month in one year, 120 years ago. And like you just have to have that encoded somewhere and that data is a separate download. So any project that needs to do any sort of interesting date time manipulation is shipping one of those libraries we talked about like moment or date functions or some of the moment contributors or creators created a library called Luxon which shares a lot of Interesting DNA with moment, but it is it creates immutable objects Whereas moment is always mutating its own objects Which can sometimes be pretty tricky because sometimes you want to add something to a date and have a new date not change the original one. But all those, all that work was done to paper over this frankly, pretty bad date implementation that's that we've kind of been stuck with. And temporal is, is how we're fixing that or how I say where, but I really have to give huge props to the people who've been working on this for years, Maggie Pint and, and Matt Johnson, Ryan Cholson, and like, there's a, there's a long list of contributors to this, this proposal, but I mean, they've done amazing work and it's to the, like, The complexity of this is to the point where they are actually, they actually need to change the standard ISO 8601 format because while the standard date time format that you're used to is good, it doesn't include things like different calendars. So it assumes the standard Gregorian calendar that we all use, but there are other calendars around the world in different religions and different people groups that use different calendaring systems. And that kind of string permanence doesn't encapsulate that.

STEVE_EDWARDS: So do you know, does it include like the star date calendar from star trek? 

THOMAS_RANDOLPH: Well, I don't know that it does by default. I think that the beauty of this proposal is that you can kind of, you can put any calendar you want in. I think I'm a little out on the limb there because I'm not a hundred percent sure, but I think you can say use X calendar, use this other calendar. And maybe they have to be built in, but maybe you could provide your own too. 

CHARLES MAX_WOOD: So one thing that I'm wondering is, is what we've seen with some of these other proposals is that the proposal looks a lot like something else that's already out there, right? It doesn't, it does, doesn't adopt all of it all the time, but pieces of it. So how, how does this compare to moment or something else? Right? 

THOMAS_RANDOLPH: I think if you will first say that that moment is a huge step forward off of the built-in date object, but incremental, right? So you still have kind of a single object that you're doing, adding, subtracting, diffing on those sorts of things. And it's basically a, a quote unquote moment object, whatever that is. Temporal introduces a bunch of new strong types. So you no longer just have a date type, you have a zoned date time or a plane time or a plane month day, which doesn't have any time, just the month and the day. So there are all these new types that are introduced. So it does look a little bit different from Moment in that way, but if you're familiar with, or if you're a fan of Moment's API, where it just has the.add or.subtract, those things are in the temporal proposal. So when you need to do kind of the typical web application math arithmetic, it's there. It's built in. And that's, I think that's probably the part that will look most like moment. 

CHARLES MAX_WOOD: Makes sense. 

THOMAS_RANDOLPH: Yeah. 

DAN_SHAPPIR: I, it's a shame that AJ wasn't able to join us because I, as I recall, he actually implemented the library on top of temporal because he had, even with temporal, he ran into some challenges doing time zone math in some cases and he tried to make it simpler than the built-in functionality. But be that as it may, it's my understanding, I'm looking at the spec, I see that it's stage three, which means it's highly likely to be accepted. And I understand there's already support for it, some support for it out there. What's the situation with it? 

THOMAS_RANDOLPH: Yeah, I actually don't know the exact support yet, but I believe, I mean, stage three implies they're looking for vendors to implement it and their basic only changes will come from implementation feedback basically. So as engines are implementing it, that's where that's the feedback that will change. I don't know that any browser supports this yet. I don't know that any VM like Node or Dino or any of those. I don't know that they support it yet. However, there are multiple polyfills that are available. So people who are interested in trying it out and in seeing how they could use it in reality, in their applications or whatever could try. Of course, this isn't ready for production. I would never suggest using this in production yet, but the podfills are available to use it. Yeah, so that said, I don't think that there's any VM that yet implements this. I think it's a huge change. It's one of the biggest changes I've seen, other than like ES2015, ES6. This is one of the biggest changes to JavaScript I've seen in my 15 years of JavaScript development.

DAN_SHAPPIR: I think I actually confused myself between temporal and the internationalization functionality, which is already baked into browsers and is also a huge step forward in terms of the ability to support various locales and stuff like that. 

THOMAS_RANDOLPH: Absolutely. Yeah. And actually the library that I mentioned earlier, Luxon, which was sort of an offshoot of Moment, uses the internationalization API to avoid having to ship time zone information because using internationalization, I think helps you with most of that kind of stuff, which I think is why Temporal doesn't have to ship its own sort of localization internationalization information because it can rely on the internationalization API, which to answer your question about what's the support for that internationalization is well supported across most ever room browsers. So that's, that's an API that you can rely on. And if, if that's what you're talking about with AJ building something on top of it. I totally understand. I've used the Internationalization API. It is close to the metal. It's not easy to use. So if you are trying to make that easier, I get that. 

DAN_SHAPPIR: I guess it also has some potential performance issues due to the way in which it works and reaches out to the operating system and stuff like that. 

THOMAS_RANDOLPH: I've heard that. Yeah, that sounds plausible to me. 

DAN_SHAPPIR: Cool. Anything else to say about the temporal proposal? 

CHARLES MAX_WOOD: Are you ready, Steve? It's about damn time. Perfect.

THOMAS_RANDOLPH: I think it is about about damn time. And I'm really excited for this one to get in. It's a big change. Like we were talking about earlier and I'm sure the browser vendors have a lot of things on their plates to get this in. Man, it'll be, it'll be good when it does. 

CHARLES MAX_WOOD: Yeah. Life will be good. Yeah. Cause that, that is probably one of the more painful things that they hadn't addressed. 

THOMAS_RANDOLPH: I mean, at the very least, like if you're still including moment and you get the latest moment version moment can just be a thin wrapper around this browser API and you're shipping one kilobyte instead of 40 kilobytes or whatever it is. So that'll be a big improvement. 

DAN_SHAPPIR: And like you said, there are polyfills for it already, which will make it safe to use. And between you and I, it's getting to the point where it's pretty quickly safe to use modern APIs in any event because of all the evergreen browsers and the fact that you know with Node, you're usually just running the latest version anyway. So even the polyfills are often not as needed as they used to be. 

THOMAS_RANDOLPH: Yeah, and a well-designed polyfill will...just not even load itself if the API is there. So I mean, it's almost free upgrades if you do it carefully. 

CHARLES MAX_WOOD: Cool, well let's move on to whatever's next. 

THOMAS_RANDOLPH: Sure, so my next most exciting thing is import assertions. I think import assertions are a really important step forward for the maturity of the JavaScript language. So I should say ECMAScript, but I'm gonna say JavaScript a lot, because we are on JavaScript Java. Import assertions add a little bit of text to module imports. And they basically allow an importer, the consumer of a module, to say how they want to treat a module import. And it's kind of impossible to talk about this without talking about my next favorite one, which is JSON modules, because they began as one proposal and sort of split off. But Import Assertions gives you the ability to control how JavaScript imports modules. And in the case of JSON modules, you can say, this is type JSON and JavaScript will import that natively and critically not execute it as code. Because as we know on the internet, things can say their JSON file and actually be something malicious. So this, that's kind of the main. 

DAN_SHAPPIR: It's kind of, it's kind of like accept headers to an extent, although with more validation built in, I assume it's interesting because, you know, again, AJ not being present, AJ is a big proponent or so, or like for AJ, uh, if I may is sad to an extent about this whole import thing and prefers that we would just have stayed with CommonJS. And import assertions are an example of where we're getting functionality on top of the import mechanism, which does not exist in CommonJS. And like exactly you said, the ability to specify what I expect the import to be. So I assert that what I'm importing is rather than a JavaScript file, it's a JSON file. And now I think they also support CSS modules as something that you can import this way. And again, if the underlying engine verifies that whatever it's loading actually matches what you assert that it is, and if it isn't, then I guess it throws an exception or something like that. 

THOMAS_RANDOLPH: Yeah. Yeah, I'm not 100% clear on the exact behavior of, you know, if an import doesn't match. But the basic, we can kind of talk about JSON modules and import assertions together, but the basic behavior of, you know, if I say this is JSON, it should parse it as JSON. And if it doesn't, then I assume that it will, I think it will just not work. It just says this module import failed because we couldn't import this. But yeah, there have been lots of, in fact, there are other people who have said, why don't we just use sort of the common JS module where you or method approach where you just load up anything and it just comes in as a module. And some people very wisely said, well, this is a big security problem because we can't just trust that like any module we load hasn't been hacked or something and it's now returning instead of JSON, it's now returning some JavaScript code that could dump an entire user's session into some remote server or whatever. So there has to be a way from the consuming side to say do not execute this, it's just JSON. And you're right that this is enabling, import assertions enable so many other things and CSS modules, like you said, are in the HTML spec, I think. I think HTML has sort of taken the import assertion side and said you can import CSS as well. And they're also talking about the possibility of HTML import assertions, which is kind of reviving the dead HTML imports, which is exciting for people who want to use platform native modules without having to wrap HTML in a JavaScript file or something. 

DAN_SHAPPIR: Yeah, down with JSX. I guess that by asserting a particular type, I'm actually informing the engine which parser to use so that if it's a JSON resource, then it just uses a JSON parser to begin with. It doesn't even try to parse it like an eval or something like that, like a JavaScript. A question about that though. You know, because naively I may ask why would I want to import JSON rather than simply, I don't know, just download, use Ajax or fetch to retrieve that resource and then just parse it as JSON. Why do I need it baked into the JavaScript language this way? 

THOMAS_RANDOLPH: I think a lot of people use JSON as a sort of a portable format. And so rather than requiring a networkless, like let's say you're running a Rails application, right? And a bunch of- 

CHARLES MAX_WOOD: I love Rails applications. Sorry. 

THOMAS_RANDOLPH: A bunch of your application config is owned by the Rails side, right? Maybe it's owned by your server side, but as soon as your front end side is loading or you've compiled a build of your application, a bunch of that config should be shared with your front end. Maybe it's API endpoints or whatever data it is. It seems a little unnecessary to make a network round trip to go load that JSON from the backend and then parse it as JSON in your JavaScript. It seems like during your build step, for example, you could just render that JSON file into your web directory and it's just available there for anyone who wants it. And I mean, maybe even your Rails app uses the same source of truth. I don't know. And in that case, it makes sense to just say import it right from this file. That's where my config is, or that's where my settings are, that's where the enabled user flags are, or whatever it is that I need to load. It's all local, but it's maybe controlled by someone else. 

DAN_SHAPPIR: I think that another motivation has to do with the fact that, like you said, certain resources are so core to the operation of the application that the application is really kind of meaningless without them, and it's preferable to be declarative about their use and basically obtain them upfront. So for example, if I have a certain configuration, like you said, determines how the application actually behaves, then maybe without that configuration, the application can't really run. So by specifying it as an import, I see upfront that this configuration is actually used. And if that configuration load fails, then the application actually fails to load because the way that static imports actually work is that they all need to succeed for the application to actually load. If one of them fails, the application effectively fails to load. That being said, you can use dynamic import which effectively do become an alternative syntax to an extent to actually doing a fetch plus JSON. 

THOMAS_RANDOLPH: Yes. And I think what you said about the kind of the declarative nature of like that config scenario and then importing them is really critical. We can do a lot of things in code. And in my opinion, it's always better to do them in a more explicit way. Like if it's just an import statement at the top, we know that that's part of the dependency tree of our application. And if it's just some function call or something in the start up of our application, that kind of implies that it's a little less important. And I think making it an import is a really great signifier that like, this is something that our application depends on, config or whatever it is. 

DAN_SHAPPIR: So basically I think we covered both points number two, which was the import assertions, as you said, which is stage three, I believe. And also JSON modules, which I guess, yes, it's also stage three. And like you said, they kind of go hand in hand. You said that they originally were like one spec and then got split in two. 

THOMAS_RANDOLPH: They were, yeah. And that's...you'll kind of see that trend with a lot of proposals is that someone has some idea of a real world thing that they want to do, like import JSON modules. And what's easier to get through as a proposal is here's how we're going to do something and then the what, right? So like, what's the mechanism by which we're going to import JSON modules and that'll be import assertions. And then the proposal for JSON modules comes in, which I think is a great way to go about things because it forces...proposals to be a little bit more generic, a little bit more of a primitive for the JavaScript language rather than specific to an implementation. I think it's also really interesting to at least mention that the import assertions proposal talks about something they call evaluator attributes. There's no proposal for it yet. It's just sort of something that they're speculating about. But the idea is that along with assertions about what an import is, you could also provide an evaluator for that that import. So you can say there is a new way that I want to handle this file. And so that could be changing the way that it's parsed on import. And right now, that's not allowed, right? Like right now, the specification says every module import needs to be the same as any other identical module import, which is a great thing for reliability and consistency in your application. Anytime you see one import, it's always going to be the same. Import assertions could allow consumers to change the way that modules are evaluated once they're loaded, which I think could be an extremely powerful way to add flexibility to the JavaScript language. Like say for example, if you wanted to use a type system, maybe you could say load this file and evaluate it as a different subset of JavaScript or a different superset of JavaScript. 

DAN_SHAPPIR: Do you think it'll be primarily used for this purpose or simply as a means to load resources that are not yet part of the spec. So for example, I could theoretically create a YAML parser and then import the YAML file or something like that. 

THOMAS_RANDOLPH: Yeah, I actually am not sure because from my read of the proposal, I'm not exactly sure what they intended evaluator attributes to be because I didn't really see like a strict, like here's what we think you could use this for or I may have missed it. But I think to your question directly, I think, you know, importing something like YAML is probably much more likely to be an initial implementation of this because it's one of those things where a JavaScript YAML parser already exists. So import this file maybe as text or whatever it is and then just bam, you've got YAML sort of already there. Doing something like a TypeScript evaluator, that would be much harder because it's a whole language interpreter, which is a whole different thing. Of course, the mechanism here isn't specified, so who knows if you can provide your own parser or what these evaluator attributes would actually be. I'm just sort of off the cuff speculating here, but it seems really powerful and interesting to me as an extension of import assertions. 

DAN_SHAPPIR: Cool. So let's move on to the next one, which I think is built-in modules or did I skip one accidentally? 

THOMAS_RANDOLPH: No, that's right. Yeah, we kind of skipped JSON modules, but we've already talked about that pretty in depth. So yeah, that's built-in modules is the next big one. And this, unfortunately, this one is a stage one. And if you, I assume that you talked about it in the JS Jabber episode about the proposal process. I feel like I probably would have heard that in the 400s, but I don't recall it. So, um, go back and listen. Yeah, I need to, I missed it. 

CHARLES MAX_WOOD: And for the listener, we'll put a link in the show notes too, so that you can go back and listen and go, Oh, when he says stage four, what is it? Right. 

THOMAS_RANDOLPH: And I'll say it right here. Stage one proposals are not yet even expected to make it into the, into the JavaScript standard and back to my two six two is the standard. Stage two proposals, once they make stage two, they do expect it to get into the standard, but stage one, they're still sort of speculating about what could happen. 

DAN_SHAPPIR: So, yeah, yeah, basically stage one is like, is like somebody expresses an interest in it more or less within the committee. That's more or less what it means, but not much more than that. Yeah. Yep. 

THOMAS_RANDOLPH: There's a committee champion and that's about it.

 

So I'm here with JD from Raygun. JD, when I talk to you, I mean, I really feel the developer vibe and I know that's your background, but is all of Raygun that way? I mean, you know, it just kind of feels like when I talk to other companies, they're a little more corporate, a little more, you know, focused on maybe, you know, raising money or doing other things, you know, but it seems like when I talk to you, you're just, you know, down to earth developer dude. I like to think of myself as a down to earth developer dude. Yeah. Yeah. Right. Raygun is a little bit different. So you know, we're not heavily VC backed. Um, you know, my business partner and I, when we started, we were both nerds. You know, um, I might be the CEO today and I don't write code on the product. Um, but you know, the joke internally is, you know, what's the definition of technical debt Chuck, it's CEO code. Stuff to go with. But, uh, no, we're, we're, we're. Stories. We're a cashflow positive business, you know, we're not heavily VC funded, you know, but we are at a size now where we are expanding and more and more folks are discovering what we're about. But yeah, we often look through things through that lens of a developer, you know, I wanted a 30,000 foot view, but I also want to go right down to an individual data point. Similarly, you know, I don't believe in averages, I want medians, I want P99s, I make better decisions that way. And so we try and drive that sort of thinking into our products and try and be as developer minded as we possibly can be. Yeah. I love that because, you know, for me it's, it's run by people who get me, um, and you're not under pressure from like a VC to raise your prices or, you know, go hyper grow and then, Oh crap, now we're behind the eight ball with our money and now we've got to figure it out. You know, you're just going to keep growing steadily moving. And I just love that. Yeah. I mean, The term these days is often referred to as product lead growth, right? Like get people use the product and say, hey, that's great. I want to give you money. Um, I don't think it's that complicated. Sounds good. Well, folks, if you want to go check it out, you can go find them at raygun.com. You can actually sign up for a free trial right there on the website. 

 

THOMAS_RANDOLPH: Yeah. Built-in modules. I think it's another one of those things that would unlock so much potential of the JavaScript language to, to allow experimentation and expansion without sort of having to change the language or having to add things to the global object of the runtime. You can kind of, the built-in modules proposal suggests that an import would have a prefix of JS colon and then importing from the standard library. And that would allow the TC39 committee to say, well, we're going to put the 25 most commonly used utilities in the JavaScript standard library, whatever it is. Or maybe it would allow a more functional approach. So right now you can call map filter, reduce all those things on arrays, but those functions are attached to the array prototype and maybe you want to just have a generic one of those operators and that could be in the standard library. 

DAN_SHAPPIR: Yeah, I think that this is the one that, again, I'll speak for AJ. I think this is the one that AJ would be more excited about, like the one suggestion that he really wants to be introduced into the language. Basically what we see in a lot of other programming languages is that instead of constantly enhancing the language itself, they instead add functions into a standard library that goes along with the language. Now sometimes the distinction between what is the language standard and what is the standard library is kind of fuzzy or blurry. For some languages it's essentially one and the same. Basically, it's a library of functions and objects and methods that you expect to have accessible from any implementation of that programming language. And like you said, the basic idea here is that I'll be able to, as a JavaScript developer, I'll be able to access these, let's say, functions using imports. But instead of having to import them from some library that I installed via NPM or something like that, I'd be able to get them from the actual runtime environment. So like you said, it might be a JS prefix on the path. Or I saw other suggestion that it might use the at symbol like NPM installs, but with certain well-known names. There are various thoughts here, like stage one. So they're still experimenting with it. But essentially it means that I'll be able to import things that are built into the language engine. And the advantages here are one that I'll get the same implementation always. So it's not like, you know, one, using one NPM, one version of some NPM library, I'll get one thing and then some other version of the NPM library, I'll get something else. In this case, the signature and behavior will be guaranteed. And the second thing is that I could avoid the download because it will be just baked in to the browser or to node or whatever. So again, I avoid the extra download that might go along with the extra functionality. And theoretically, things like temporal or the internalization that we talked about before could have been implemented as built-in modules that you import when you need them. And obviously, I'm also very much in favor of it. One possibility, by the way, you know, Dino is effectively creating this sort of a standard library that goes along with it. So maybe some of that could make it into a standard library like that. By the way, interestingly, the people at the Google people experimented with something like that in Chrome. They created a key value pair library that was built into Chrome and could be accessed using this sort of an import from within the Chrome, but it didn't really catch on. So it seems like they experimented with the concept, but it didn't really go anywhere. So I'd be really happy to see something like that mature into the language I would very much like to get a lot of functionality as a standard library instead of having it, like you said, just be attached with, you know, on top of prototypes. Because, for example, I keep seeing more and more functions making their way on top of the array prototype and, you know, it's starting to get ridiculous to an extent and having it more generically provided via modules when you actually need it and only import the functions that you actually need seems like a better way to go. 

THOMAS_RANDOLPH: Right. Yeah. And I mean, the JavaScript ecosystem has had the kind of upsets, like the left pad thing, right? Like someone removed the left pad function from NPM and a huge amount of sites broke because the package was just gone. And now, of course, we have string padding and it's part of the string prototype. But it would be a lot better if we had just kind of a almost a bare bones string implementation. And in the standard library, we have padding and begins with and ends with and all those all those string prototype functions that are useful and people obviously need them, but they should be in a little standard library. And, and I mean, you might, you might be thinking, well, I mean, I can just download it from NPM. It's, you know, it's, it's half a kilobyte. Why bother? Or I have Lodash. I can do those things. And like you mentioned earlier, imagine shipping Lodash. Lodash isn't a huge library, but imagine if every site in the world could stop shipping it. I mean, it would be a massive improvement to kind of the experience of the web for everyone. 

CHRLES: Yeah, one other thing that, or a couple of thoughts that I have on this. So one is, one thing I've seen with my experience in Ruby and other languages that have standard libraries is once they have the standard library and they start shipping it, then what happens is the core teams actually tend to start to optimize them. And so then you start getting speed ups and size reductions and stuff like that on those libraries because now they're getting attention from people who look at it from the other end. And so I see that as a huge benefit. The flip side is, and this is the only downside I've ever seen to standard libraries, and the workarounds are really not that big a deal, is that they tend to lock in, right? So if you are using this version of the language or this version of the VM, right? So you do node 14 or node 16 or whatever, right? It'll lock in the version of the standard library package that you're getting, right? And so it may lock in the CSV library. Let's say they put that in there. Add a particular version. And so if you want the new features, you actually have to go pull it in yourself, right? 

DAN_SHAPPIR: Oh yeah, for sure. Like the problem with standards is like once they enforce it's much harder to change them and you're kind of stuck with whatever that decision was that was made, which emphasizes the need to be really careful about what goes in or not into a standard library. By the way, another benefit of a standard library is one that is related to stuff that we've talked about in recent episodes, our supply chain security. Because again, if it's part of a standard library, you can pretty much assume that it's been vetted and is safe compared to some of the libraries that people are now downloading from NPM. We've had people on the show talking about some scary story about things that you could accidentally import into your project. 

THOMAS_RANDOLPH: Right. And to both of your points, I mean, about not only optimization, but, you know, supply chain improvements, if it's part of the standard library vendors, whether it's a browser vendor or some VM, like, like Dino or node, they are, they're going to be implementing that's part of that standard library, most likely in a system level language, like C++. 

CHARLES MAX_WOOD: Yeah.

THOMAS_RANDOLPH: if your browser is doing it. So not only will it be faster, but it's also like, this is running outside of your browser environment. And that comes with its own inherent risks, obviously, it can be insecure. But a browser vendor is way more likely to make sure that the code that they write that is running on devices is probably going to be safe and a lot faster. So I think there's huge upsides to moving these common things into standard library. 

CHARLES MAX_WOOD: Yeah, the other thing is the ECMAScript, like you said, the ECMAScript process is slow. I mean, there's a reason for that, right? It's, yeah. But the flip side is, is that, yeah, if it makes sense to put it into the standard, the vetting process can go a lot faster. 

THOMAS_RANDOLPH: Right. Well, I was just gonna kind of, kind of plus one to what you said of like, it can be slow because of the downside you mentioned earlier from the built-in library, because once you put something in JavaScript, once that's running in a browser, you can't ever break it. I mean, they have done it very rarely, but generally speaking, you can't ever change anything that's in the browser. So that's why that process is so slow. 

CHARLES MAX_WOOD: Yep.

DAN_SHAPPIR: I would also like to mention that some of the items that we will mention later that I saw in your list, you might say that they're kind of dependent on the built-in modules. I mean, you could make them globals, like, you know, when BigInt was introduced, they made the BigInt constructor effectively global. And I guess it does make sense to make certain really common things global like that. But a lot of the other things that we talk about are like...something that you might decide to opt in or not. And once something is optional, why have it kind of add noise to your global namespace if you don't even intend to use it? And you're always, like you said previously, you're always running risk of collisions with stuff like that. So having these sort of things as being part of the standard library and importing them into the modules that actually need them and use them makes things that are make things a whole lot cleaner and more tidy, less messy. 

THOMAS_RANDOLPH: Yeah. And actually, exactly to your point of running into collisions, the proposal for this built-in module system actually explicitly says anything that you import from the built-in module system would have a frozen prototype. So we can't get things like smooshgate or how we have includes instead of contains for arrays, because various other tools have already extended the array prototype to have those kind of things commonly used words, which makes sense, of course. Like people wanted to use them back before they existed, but now we can't make changes to the language because it conflicts with those libraries. So the standard built-in library would kind of protect against that future collision possibly, not only by namespacing it, but also by sort of locking down the modules so that they can't be artificially extended. 

DAN_SHAPPIR: Cool. So what's the next one? 

THOMAS_RANDOLPH: So the next one, I think these first four that we talked about are...really important changes to the language. The next set on my top 10 are ones that I'm really excited about personally. I think a lot of people maybe are not, or there's very divided opinions on them. My next one is the observable proposal. It's also a stage one. The last time it was presented to the committee was May of 2017, which that's not a great sign, but I'm really excited about it. If you've heard of RxJS or basically observable streams, this is a JavaScript primitive for that behavior, basically encapsulates a push data architecture rather than a pull, which if you, you know, if you want to listen for click events, you are essentially pulling cause you are saying, I want to listen on this element versus saying when something happens, I want to react to that. So this observable would enable a reactive programming style rather than a more imperative style. This observables are complex they're really hard things to sort of understand. Even when you sort of get the concept, the code is hard to understand because they are these sort of live streams of data that occur outside of your control and you just react to them. So it's hard to get your brain around sort of the push mechanism versus the pull mechanism. But I think it's a really powerful paradigm of switching the flow of applications or the flow of data from requesting or imperatively pulling that data to being pushed that data and just responding. 

DAN_SHAPPIR: So here I'm going to push back on you a little bit. I guess take AJ's place, given that he's not here. So I'm very ambivalent about this. I know that a lot of people are really in favor of it. Interestingly, especially the RxJS people, some people might expect that people who have invested a lot of time and effort in a library would be wary of core parts of the library making their way into the standard and effectively invalidating their library. But I've found that it's very often the exact opposite. People who work on open source projects would love for their open source project to no longer actually be needed because to an extent they've won and they don't have to put all the effort into it anymore. So I think that's certainly the case here. But I have two issues with it. So the first issue is that, as you said, observables are very popular, but the majority of applications out there written in JavaScript don't use the reactive approach, certainly not to the extent that RXJS promotes. And there's a reason for that. And so the question then becomes, if it's something that's relatively rarely used in practice does it really need to be a part of the core language, even as part of a standard library? Because at the end of the day, it's perfectly legitimate for things to be outside of the standard library. If you look at other programming languages that do have a standard library, they very often have really popular libraries that are very commonly used, but not standard. And for me, it's kind of makes sense that may be observable while it is really popular among some people and is definitely used in a lot of cases. It still feels to me as something that might not be quite popular enough, you might say, to actually need to be part of the standard library or the programming language itself. So that's one issue that I have with it. And the other one... 

CHARLES MAX_WOOD: Can I address that for a second? 

DAN_SHAPPIR: No, go for it. And also, Thomas, I just tend to get carried away with... 

CHARLES MAX_WOOD: No, it's all good. So I have the benefit of talking to people in a lot of different communities. And RxJS is actually core to Angular and how it does change detection, among other things. And so having it part of the standard library, having some of the benefits that come with that. Or having it built into the language would really help people in that arena. And I do see people use it in other places, but yeah, they're usually more explicitly pulling it in or pulling something in that it pretty directly lets you know that it's working off of observables instead of the other way around. And so yeah, it's popular, but I think there's a wider swath of people that are using it than you think. 

THOMAS_RANDOLPH: I actually didn't know that Angular was relying on observables or Rx. That's pretty interesting. My use case for observables, and Dan, I want to get your opinion on something you said, but my use case for observables is sort of in that same scope, in the same scope of the framework level. I'm architecting my entire applications, at least the ones that I have architectural control over them, as sort of message streaming architectures where individual components are responding to events that occur and not explicitly bound to other pieces of the application. And that's probably roughly how Angular does it at a very high level. 

CHARLES MAX_WOOD: Yeah, more or less. 

THOMAS_RANDOLPH: But Dan, you know, Dan, you said, you said that there's, you know, there's a reason that it's not super widely used and I want to get your opinion on, on what you think that reason is or reasons. 

DAN_SHAPPIR: Yeah. So interestingly, also at Next Insurance, where I currently work, some of our main applications are Angular applications and also rely heavily on RxJS, which shows both the benefits and also some of the limitations of this approach. From my perspective, the main issue that I see with it is that it requires a significant level of expertise to be able to properly leverage it. If you're not quite an RxJS expert, it can get really Harry and Dicey to work with RXJS code. It becomes almost like magic. It's very difficult to follow the logic. And even people familiar with the applications sometimes have a hard time grasping the total image of where the data flows. Because it's so easy to subscribe to something and then effectively you've created another stream or routes that the data can flow down. And it's really difficult. So something happens, it's observed, and it impacts all over the application. And it's almost like magic. It becomes really difficult to be cognizant of all the things that might be impacted by that change. And related to that is the fact that it's really difficult to debug. You effectively cannot single step through that data flow you will usually, if you look at the call stack, it's totally legible. So you need to know where the data flows to, and then maybe put a break point there. But again, it can be really difficult to, if you're not sufficiently familiar with the architecture of the application, or all the implementation details to know where all the places are, so you can get really unexpected kind of side effects from the fact that that data changes. Think about it like a really complicated Excel spreadsheet where a lot of the cells are kind of dependent, interdependent, and you put just, change just one value and all of a sudden, like half the spreadsheet changes and it's really difficult to understand exactly why that happened. But again, I'm not opposed to this method of operation. Like you personally, I actually like it, but I'm simply not sure that it needs to be a core part of the language. I understand that proponents of RxJS, for example, actually hope that by making it core, more people will start using it. But if you're just looking at it in the context of Angular, like you said, Chuck, then if I'm importing Angular, then I might as well also import RxJS. It doesn't make that much of a difference. 

THOMAS_RANDOLPH: I think one of the benefits of making it a primitive in the language is from my read. So first I want to say, I would never claim to be an observable expert. It is, I like it just like you, Dan, but it is so hard that it's difficult to understand. But even my read of the proposal has simplified my understanding of the high level concept just from reading the proposal because it is so much simpler on its surface when it becomes a primitive. It has a subscriber and the subscriber returns an unsubscriber and that's kind of the...the basic behavior there. And then an observer has a next, every time you receive a value, you get the next thing, and then an error and a complete handler. And that's it, that's the whole thing. And obviously, obviously, there's so much complexity buried under that. It's hidden under the hood. But from just reading the proposal, to me, it seems like it could simplify the concept substantially. And maybe there are, maybe RxJS continues to be a library that builds on top of that primitive with much more complex ideas. But...If you want just, I just want one way to stream data. Maybe you can just use the base observable implementation and it's much simpler. And maybe that could be the entry point for people to say, ah, this is actually a great way to receive events, react to things happening rather than, you know, expect things to happen explicitly. And they could do it with that much simpler primitive. Now, I could be wrong that it's simpler. It seems simpler to me, but... 

DAN_SHAPPIR: Oh, I agree. It is simpler because it, again, it distills just the core concept without a lot of the sophisticated capabilities that, like you said, are available in an RXJS. And, but by the way, if I look at Promises, originally Promises were really simple and really small in terms of the scope of the implementation, but little by little they're getting more and more features that we had in libraries like Bluebird. So the scope of implementation keeps on growing. And it grows because it's actually useful and it's used. But things tend not to stay simple, that's all I'm saying. But I do actually have another issue with Observable. And that's the fact that at the end of the day, in terms of the functionality and the capabilities that it provides, there's actually a significant overlap at least the way that I see it, between observables and asynchronous iterators and generators. A lot of the push type implementations that you can do with observables, you can do using a different syntax, obviously, but using asynchronous iterators and generators. And there's a double problem here, because already we'll be creating two different ways with really different syntax to achieve very similar results. But beyond that, asynchronous iterators and generators are unfortunately not very popular. I kind of consider that, and we had several episodes talking about iterators and generators in the context of JavaScript Jabber, I consider them to be kind of a failure because they're a really powerful mechanism that's built into the language but that is hardly ever used by the vast majority of people. So unless you might be saying that we've kind of failed with asynchronous iterators and generators, but it's still a useful concept. So maybe observables are kind of a replacement. Maybe that's some way to look at it. But otherwise, you're potentially adding yet another similar functionality into the language and with no reason that this one would be that much more popular. So worst case scenario might be that we end up with two constructs in the language that achieve very similar purposes, and both are effectively pretty unpopular and hardly used. 

THOMAS_RANDOLPH: Yeah, that is a huge risk. And I'm not a JavaScript maximalist, but I'm also not a JavaScript minimalist. And so there's this sort of tug and pull inside of me to like, should we just add more? And like the...the best one can win or yeah, should we try to find the right solution and, and optimize that. So maybe it's asynchronous generators. 

DAN_SHAPPIR: But the best one doesn't can't really win because like you said before, once it's in the standard, it can never actually be removed. So essentially your, you keep on adding more and more layers. And while I'm kind of in the same camp camp as you are, I do appreciate what, you know, the minimalist stance that AJ has, for example that you shouldn't add something into the language unless A, it's very much in line with what the language already is, and B, there's a high probability that it's really going, that it's useful and will be used properly. And I'm on the fence with observables. Let's put it this way. 

THOMAS_RANDOLPH: Sure. 

 

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. You know, whether you're beginner going to intermediate and immediate 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. 

 

DAN_SHAPPIR: Chuck, wanna do picks? 

CHARLES MAX_WOOD: All right, well, I was gonna say, I think we're overdue for picks, 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. 

THOMAS_RANDOLPH: But, oh, it's been terrific. I love talking with y'all. 

CHARLES MAX_WOOD: 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, um, 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. 

THOMAS_RANDOLPH: I like that one.

STEVE_EDWARDS: That was sort of a takeoff if anybody knows Stephen right. 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 on 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. 

CHARLES MAX_WOOD: Well, just things that anyway, 

STEVE_EDWARDS: 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 nice little show. It's not amazing. You know, that's the interesting thing about Star Trek for me. The premise is always much greater than the actual execution. I always expect to enjoy the various series 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. He's such an amazing actor. 

STEVE_EDWARDS: 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, except 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 gonna 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 and actors and actresses come back, right? Cause that, 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?

THOMAS_RANDOLPH: 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 today, 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 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. 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 wrote. 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. Do you want to let people know where to... 

DAN_SHAPPIR: I think, and by the way, I have to say that definitely worth the follow. So if... 

THOMAS_RANDOLPH: Well, thanks, Dan. That actually means a ton. Thank you. Thank you for saying that. 

DAN_SHAPPIR: Oh, for sure. I call it as I see it. Yeah. 

THOMAS_RANDOLPH: Okay. Great. Yeah. My Twitter account is rockrist. 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. 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. Thank you so much, everybody. 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.