Dan Shappir takes the lead and walks the panel through the history of JavaScript and a discussion on ES6, TypeScript, the direction and future of JavaScript, and what features to be looking at and looking for in the current iteration of JavaScript.

Follow JavaScript Jabber on Twitter > @JSJabber

CHARLES MAX_WOOD: Hey everybody and welcome to another episode of JavaScript Jabber. This week on our panel we have Amy Knight. 

AIMEE_KNIGHT: Hey hey from Nashville. 

CHARLES MAX_WOOD:  AJ O'Neill. 

AJ_O’NEAL: Yo yo yo coming at you live from the debate-o-sphere of my bedroom, the office room. 

CHARLES MAX_WOOD: Debate-o-sphere? Now I'm confused. 

STEVE_EDWARDS: That's a new one. I like it though. 

AJ_O’NEAL: Because today's debate. 

CHARLES MAX_WOOD: Ah, it's fight night. Dan Shapir. 

DAN_SHAPPIR: Hey, hey, coming at you with a bit of a head cold, but you're not in the same room with me, so what do you care? 

CHARLES MAX_WOOD: Well, we're sad for you. Steve Edwards. 

STEVE_EDWARDS: Hello from the left coast in Portland. 

CHARLES MAX_WOOD: I'm Charles Max Wood from DevChat.tv and this week, Dan put forward this topic. Basically, it's the evolution of JavaScript. Dan, you had a couple of ideas of where to start, so I'll let you kind of get us rolling and we can complain. I mean, talk about the process that JavaScript goes through to change. 

 

When it comes to test maintenance, the biggest complaint that teams have are flaky tests. Tyco is a Node.js library built to test modern web applications. It creates highly readable and maintainable JavaScript tests. Its simple API, smart selectors, and implicit weights all work together toward a single goal, fixing the underlying problem behind flaky tests to make browser automation reliable. Tyco is open source and free to use. Head to tyco.dev and get started. That's T-A-I-K-O.dev. 

 

DAN_SHAPPIR: So I've been having discussions with various people about, you know, do they know JavaScript? What does it actually mean to know JavaScript? What is JavaScript? Is it, if I just know ES5, do I actually know JavaScript? Is ES5 even still a thing? So I thought it might be worthwhile to have this kind of a discussion about what JavaScript is, where it's at, how we got where we are, and hopefully talk about where we're going. So that was the basic idea. And I thought that it might be worthwhile to begin this with a discussion about where JavaScript came from and how we got to where we currently are. I'm a bit of a history buff. And the big reason for that is that I want to know where things are, why things are the way they are. How did they get to be the way that they are? I think a better understanding of how things came to be and how they evolve over time usually leads to better understanding and appreciation of these things. And that this is especially true for technology because understanding the thought processes of the intentions of the people are often very smart people created leading technologies can make a big difference in how effectively you use these technologies. So that's like the motivation for this discussion. And I think all of this is definitely true for JavaScript, which is why, like I said, I want to spend a few minutes talking about its creation and evolution. So for anybody who doesn't know this, JavaScript was created way back in 1995 by Brendan Eich while he was working at Netscape. It's a pretty famous story about how he created it in 10 days, the so-called 10 days of glory. And actually, you can learn a lot about this if you listen to the interview that Chuck, I think you had with Brandon Eich, and what was it, episode 124. I think we can post a link. 

CHARLES MAX_WOOD: Yeah, we'll get a link in there. But yeah, it was a fun conversation too. 

DAN_SHAPPIR: Yeah, I think it's an awesome story. It was an excellent episode. And I definitely highly recommend listening to it. If you recall when we had the episode 400 and we're talking about favorite episodes that was definitely one of mine so it's definitely worthwhile to listen to it again or the first time if you've not heard it. So anyway Brendan created JavaScript in 95 but at that time obviously hardly anybody was using it but it started catching on fairly quickly and in 1996 Netscape submitted the specification of the JavaScript language to what was then known as the European Computer Manufacturers Association or ECMA for short. Interestingly, they kept the ECMA but dropped that whole European thing. So ECMA is not an acronym anymore, it's just their name. So Netscape handed it over to that association for standardization to make it something that wasn't specific to Netscape but was like a web standard. And since there were various copyright issues around the use of the word Java in JavaScript the language standard became known as ECMAScript, which Brendan himself has likened to the name of a skin disease. But be that as it may, ECMAScript or EAS for short, that's the name of the standard language specification. And then JavaScript itself is just an implementation of that specification. So I know a lot of people kind of get confused between what JavaScript is versus what ECMAScript is. So that kind of makes the differentiation between the two. 

CHARLES MAX_WOOD: Funny detail just to add to that, because it's called JavaScript, they borrowed the trademark that was owned by Sun Microsystems, which was then bought by Oracle. And so the trademark for the JavaScript name is owned by Oracle. 

DAN_SHAPPIR: Yeah. Which is so great for all of us. 

CHARLES MAX_WOOD: I know. 

AIMEE_KNIGHT: I didn't know that. 

DAN_SHAPPIR: Yep. Yeah. There's this running gag, scary, slash scary story about the day when Oracle decides to do something with it. It'll be interesting to see what happens if and when that does happen. Anyway, they haven't so far, so there's still hope. In any event, inside ECMA, there's a special technical committee that's working on the ECMA script standard, and that technical committee is known as Technical Committee 39, or TC39 for short. So I assume a lot of people have heard the term TC39, that's where it comes from. TC39 members include representatives from all the usual suspects, Google, Microsoft, Mozilla, Intel, PayPal, and so on. And it's this committee which is responsible for what goes into ECMAScript and what is kept out. The original JavaScript implementation that Brendan and I created became ES1. It was quickly followed in 1998 by ES2, which was the first version of JavaScript that I actually got to work with. So back then we didn't even have stuff like exceptions. So you didn't have things like throw, try and catch. Closures were not yet a thing. There were no regular expressions, which is, I'm not sure if that's a good thing or a bad thing. But anyway, the language was much more limited and constrained at what it currently is. And by the way, if you're interested in my personal experiences with JavaScript at that time, you can listen to them in my interview and my JavaScript story with Chuck we can put a link to that as well. It was lots of fun. It was an interesting time. 

CHARLES MAX_WOOD: Back in my day, we used to bang two rocks together and call it programming. 

DAN_SHAPPIR: Yeah, at least you had rocks. Anyway, ES3 quickly followed in 1998, which did add try and catch, which was really useful because handling all errors using window.onError is not a lot of fun. It added regular expressions and lots of more stuff. And interestingly, by the way, we had a recent episode Ben Collins, where we spoke about the Google Apps Script engine, and it turns out that that thing is still using ES3. They do have plans to update it, but that's what it is using for now. So this technology from 1999. After ES3, there was an attempt to have JavaScript undergo a major overhaul. In 2000, TCE39 started working on ES4 which was supposed to be released in 2008. So they gave themselves up to eight years to work on it. And it was supposed to include a whole bunch of exciting features, including optional type annotations and static typing, classes, a module system, destructuring, generators and iterators. Stop me if this sounds familiar. 

AJ_O’NEAL: It was Microsoft. TC39 was Microsoft at the time. And I love that. What is TypeScript? 

DAN_SHAPPIR: Yeah, the interesting thing is that Microsoft actually kind of killed it. There was this whole argument between Brendan Eich himself, who was representing Mozilla at the time, I think, and the Microsoft representative. I don't really know, I don't want to go into the detail of all the politics, but failed. It just didn't happen. 

CHARLES MAX_WOOD: JavaScript Jabber episode. So I'll put links to both of those in there too. And you can kind of get a little bit more background on that. 

DAN_SHAPPIR: Yeah. Interesting times. So the, but it is definitely true that a lot of this stuff either eventually found its way into ES6 or into TypeScript. So it's not lost and gone forever. So like I said, ES4 failed. It was never really released. 

AJ_O’NEAL: And it was in the Macromedia, not Macromedia was the thing that is now owned by Adobe. Adobe Air. 

DAN_SHAPPIR: ActionScript. 

DAN_SHAPPIR: Yeah. ActionScript was heavily influenced by it. I think it was based on it, but it's not the same thing. 

AJ_O’NEAL: Oh, really? 

DAN_SHAPPIR: ActionScript is an implementation of the ES4 specification. 

CHARLES MAX_WOOD: I was going to say it's an ECMAScript implementation. 

DAN_SHAPPIR: So yeah. But since the ECMAScript specification was never officially released, it is what it is. Instead, in 2009, what we got was ES5 which was a very intentionally a very like limited evolutionary step beyond ES3. Originally it was even called ES3.1 and then it became ES5. And that's what we had in 2009. And that's kind of like the for anybody who's like a bit longer in the tooth with JavaScript, when they talk about the real JavaScript, that's like ES5. So that's where we were like in 2010. And then you know, the web started to get going again, you know, thanks to the decline of IE and Chrome and Safari and the resurgence of the web. And we started, we got HTML5 and CSS3. So there was a talk about the need to push JavaScript forward and maybe bring back some of those features that they wanted to have in ES4, but we never got to have. So work started going on in 2011 on ES6.

CHARLES MAX_WOOD: I have a question about that real quick. Was there a real catalyst for that or was it just, hey, we updated HTML and CSS and now it's JavaScript's turn? 

DAN_SHAPPIR: Or to be honest, I don't really know to give the answer to that. I assume he could try to bring in one of the people who was involved in the committee at the time. I do think that there was a feeling like with companies like Google, that the web needs to go forward in order to succeed and you know, Google's fortunes are really tied to the web. So they. So, you know, all these companies felt like they really wanted to advance the web platform. And in order to do stuff like that, they needed JavaScript to advance. You know, if you remember Steve Jobs' famous email about how Flash is bad and the future is the web and promoting stuff like Canvas for doing those types of interfaces, then you need a more sophisticated programming language to kind of back that up. So it might have been that. But again, I personally was not involved in that process. So it's conjecture in my mind. 

CHARLES MAX_WOOD: I will also say on that that probably a third of the My JavaScript Story episodes that I've done and a bunch of the My Angular Story episodes that I've done, a lot of people basically say, yeah, I got into Flash. Steve Jobs killed Flash, and then they moved over to JavaScript. And so I think there's some influence there, too. 

DAN_SHAPPIR: That makes a lot of sense. So in any event, TC39 was again looking to make significant enhancements to the language, but they wanted to avoid the pitfalls that kind of caused ES4 to fail, to derail in such a way. And one important decision that they made was to avoid having this one huge release and instead to have a sequence of incremental updates. And that's why we had this whole confusion about the name ES6 when they kind of decided to drop it and go with ES2015 and then ES2016 and so on to indicate that every year they intend to add a bit more features to the language and like move it along in a more incremental sort of a way. Although of course the first one, the ES2015, was the more dramatic one in many regards. It's also worth mentioning that there's this term ESNext or ES.Next, which is a dynamic name which refers to whatever the next version is at the time of writing. In other words, it's the collection of finalized proposals of extension to the language. Any comments or anything to say or ask about this interesting story? If not, then I think it might be worthwhile to talk a little bit also about the process of how new features are introduced and eventually become part of the ECMAScript standard. 

CHARLES MAX_WOOD: The only thing that I'm wondering there is, is this the same process that they went through before or has the process changed once they decided, oh we've had ES5 forever, let's update it? 

DAN_SHAPPIR: I think that the process these days is much more open than it's ever been. I think that part of this, the reason for that are the lessons that they've learned, but also I think part of that is that technology enables more openness. All the proposals are on GitHub. Anybody can go in, view them, comment, create pull requests. You know, we used to have forums that enabled discussions and discourse in the past, but undoubtedly things are much easier now that they've ever been. So I think that's also a big part of it. I think part of it is like the lessons they learned, that the more open it is, the greater the chance of the success. There have been technologies that enable progress, like Babel makes it very easy for people to try out and demonstrate proposals by creating a plugin. That's in fact one of the prerequisites these days that you actually have a working demonstration for your proposal that the people can play with and see how they feel about it. And these things are definitely easier to do than they've been in the past. So I think it in the past, if you wanted to demo something, you probably needed to be one of the browser vendors. Otherwise, how were you going to actually show the feature that you want? Now, you can just create a Babel plugin. So I think that makes a big difference. Anyway, so essentially, anyone can propose, in addition to the ECMAScript specification, there are several stages that proposals go through. I'll actually post a link to a document that TC39 has online, which highlights this process. But briefly, you've got a stage zero, which is called the straw person, which essentially anybody can submit an idea. To take it to the next stage, which is called a proposal, is for the committee to start evaluating it. You need a champion to promote it, to push it along. They can't have you just making, you know, a proposal and saying, Hey, I have an idea, you do something with it. No, you have to yourself, either yourself push it along or find somebody to push it for you. But there needs to be somebody that is like the champion, the promoter for this proposal. They also need some sort of a document that describes the need, describes the research that was done provides a high-level API description, complexity, use cases, et cetera. So they actually need to have some meat, not just a title. Stage 2 is a draft. It precisely describes the syntax and semantics. And if you get there to stage 2, it means that you're expected to eventually be included. So the move from stage 1 to stage 2 is actually huge. Now, obviously, there have been cases where things made it to stage two or even beyond and then got pushed back. But moving from just a proposal to something that actually is expected to someday be included is obviously a big step. Stage three is a candidate. This step is for refinement by the implementations and by users to get feedback and see how we can make it better. And stage four essentially means that it's finished and it'll be included the next time we actually have a standard. Now it's also in this context worthwhile to mention that browser vendors tend to sometimes jump the gun. So occasionally you will see various features appear in browsers even while they're still at stage four and not yet officially part of the standard. So they're finished, they're supposed to be part of the upcoming standard and they're already inside browsers. So that kind of is the background for the discussion that I wanted to have. And the real discussion that I wanted to have is talk about what we think about where JavaScript is. For example, one of the things that I suggested to you to think about was about, as an umbrella term for all the features after ES5, features that you like. So what do you want to start with the good or the bad? 

AIMEE_KNIGHT: Classes. 

DAN_SHAPPIR: That example of good or bad. 

AJ_O’NEAL: I'd like to ask the question. Well, like what is the value in any language? Like where's the real value lie in a language? 

AIMEE_KNIGHT: I feel like that that's an awesome question. Thank you for asking that. Well, I had an immediate thought and then. I second guessed myself. My immediate thought was I would choose the language based on like the end goal. Like what language is going to handle numbers the best? What language is going to be the fastest? Like what do we need? But then that's when I started second guessing myself and thinking about like, which is the easiest to learn. 

AJ_O’NEAL: And you don't have that option in a browser. Well, I guess you do with Waziland. 

AIMEE_KNIGHT: Yeah, yeah, yeah, yeah, yeah. I guess, yeah, I was thinking more back end, but yeah. 

AJ_O’NEAL: No, no, no, no. I that that, but that's what I meant. My concern, like I think when I think of a language much of what's, what makes Ruby great rails, what makes Python great FB profit, scikit, you know, what makes PHP great Wikipedia WordPress, right? Like what makes something great is what you're able to do with it. 

AIMEE_KNIGHT: Yes. 

AJ_O’NEAL: That has real value that can turn into business value. 

CHARLES MAX_WOOD: Yeah. But the issue is, is that you could build a Wikipedia without building it on PHP, for example. Right. 

AJ_O’NEAL: Yes, you absolutely could. 

CHARLES MAX_WOOD: Right. And so the unique value for that versus some of these others is essentially your ability to get the work done. Right. So it, it boils down to the abstractions and APIs, the libraries and the amount of work that people have put into making it do the job well under those circumstances. 

AJ_O’NEAL: And that is why I don't like ES6 because none of the things that we mentioned are part of ES6. 

DAN_SHAPPIR: I'm not sure what you mean exactly. 

AJ_O’NEAL: Yeah. Just ex ES6 is all syntax sugar. There's no improvement to your ability to get work done with the language that wasn't there before. It's all this spinning wheels on, Ooh, how can we make this syntax different? How can we make this syntax more like some other language that's already good at what it does? 

AIMEE_KNIGHT: And that's, that's my whole issue with classes, but we can get into it. Like I'm not, 

CHARLES MAX_WOOD: here we go.

AIMEE_KNIGHT: Object oriented programming is the way that they've been designed and anyways, I'm going to be called 

AJ_O’NEAL: object oriented programming is great. I don't have any problem with that. But you could do object oriented programming in JavaScript since like ES2. 

AIMEE_KNIGHT: And my argument is it was easier back then than it is now. 

DAN_SHAPPIR: Well, yes, like classes are like kind of a for for good or bad. Yes, classes have kind of like become a poster child for ES6. And I think that regard they do ES6 a big disservice. I definitely think that ES6 has a ton of stuff that goes way beyond classes. I currently, I hardly use classes at all. And I still, when I'm forced to work in an environment, which occasionally happens when I work on old source code, where I have to forgo using ES6 features, it has become really painful for me. So I'm really appreciative of a lot of the other stuff that ES6 has gotten other than classes. But you all are definitely correct in that, you know, even ES3 was like, what's it called? NP-Complete? It's like, Touring Complete, sorry. I confused my terminology. 

AIMEE_KNIGHT: Can you define that really quickly for newbies listening? 

DAN_SHAPPIR: Touring Complete basically is that whole thing with Alan Turing, if you've seen that movie about how he won the war. He was a genius in that. He invented the concept of what is a computer language minimum requirements for a computer language in which you can use to write a code that essentially does anything. And any other language beyond that is quote-unquote syntactic sugar. It's just making your life as a developer more enjoyable. And you know, if we go to the extreme, you can write anything theoretically in assembly language. But obviously, none of us want to do that anymore. We want to use languages that are more expressive and make it easier for us to implement higher-level abstractions. So just because something is essentially a syntactic sugar does not make it by definition in my opinion a bad thing. You know, sugar is sweet and we like it. So it's not... 

AJ_O’NEAL: And it's slowly killing us all. 

DAN_SHAPPIR: Yeah, but only if you use too much of it. Without sugar at all, you would also die. 

AJ_O’NEAL: I want to distinguish between a language and the standard library and the libraries. 

AIMEE_KNIGHT: Can I just define TuringComplete just a little bit more clearly for folks really quickly? Go for it. Like in a one sentence answer. It basically means the language can compute the answer to a problem. I don't know. 

AJ_O’NEAL: As if it has while. It has, it just needs if and while, right? Just needs branch executions. 

DAN_SHAPPIR: Doesn't even need that. You can do everything with recursion. 

AJ_O’NEAL: Sure, sure. 

DAN_SHAPPIR: Yeah, anyway. We were talking about the fact that a lot of people look at ES6 as classes, and a lot of especially people who are more experienced JavaScript developers consider classes to be a bad addition to the language, and consequently consider ES6 to be not such a good thing. And I kind of disagree with that. But I will definitely accept that if I look at the ES6 features that I hardly use, ES then classes are the top of my list. I used to use them a lot with React. Now we have hooks. So now it's a bad thing to use them with React and I don't use them anymore. 

AJ_O’NEAL: So, but I still want to, I want to bring up this distinction between a language and libraries and standard library, because you said something earlier where you kind of clump them together. Like what is a language versus what is a library? 

DAN_SHAPPIR: Well, you use, I would need to distinguish between a standard library and the library. Of course. And JavaScript for good and bad currently doesn't really have a standard library, hardly at least. 

AJ_O’NEAL: It has math. 

DAN_SHAPPIR: Yeah. And it has some method, iteration methods on arrays, but that's more or less it. Everything else is mostly either the DOM or Node. It doesn't really have a standard library. And that's a shame. I tend to agree. I think that had JavaScript had a better standard library, then maybe some of the additions that are being proposed would not have been needed. A lot of the stuff that, for example, if you look at enhancements to, let's say, a language like C++, a lot of the things that were added to it were not enhancements to the language itself, rather they were enhancements to its standard library. But like I said, JavaScript didn't really have that. I do think that some of the enhancements that were added to JavaScript would have been difficult to do as a library, especially given some of the restrictions of the JavaScript language. Like, for example, I think that a sync await are a good thing, and there couldn't be a part of a library. Promises are essentially a library, but the sync await need to be enhancements to the language itself. 

CHARLES MAX_WOOD: Yeah. Arrow functions is another example that comes to mind where the syntax is a little bit different from what you can do with just the rest of JavaScript. 

DAN_SHAPPIR: Well, yes and no. I had an interesting talk, I need to find it and put it in the show notes, about things that you can do with ES6 that cannot be done with ES5, An alternate title for this talk is things that Babel can't do for you. And there are not a lot of things. There's proxy and there's like a two primitive or like, like I only found like four things more or less that you can't do with that. You can't have like compile the language into ES5 and do it for you. And you can get by. 

CHARLES MAX_WOOD: Yeah, you could compile that. You could create a grammar for it. 

DAN_SHAPPIR: Yeah, you can do that with like with bind or by just avoiding this, which is mostly what I do these days. I don't have this anymore. So the fact that with arrow functions, this is statically bound is, is nice, but I hardly care anymore. 

AIMEE_KNIGHT: So that's, that's specifically kind of when I say classes, like I said, I'm, I'm all good with object oriented programming, but I think sometimes. And not to like criticize anything. I know there are reasons why things were done the way they were, but for me, particularly, and maybe also it's because I learned just doing inheritance with the prototype chain, sort of bare bones without classes. But you get into issues with ES6, this binding when you're using classes, and then getters and setters. It just seems to me like it's not a smooth experience when you're trying to work with classes. There's a lot of gotchas and boilerplate that you have to wire up that I kind of wonder if it would have been preferable just to stick with the old way of doing things. I'm curious what other people think. 

DAN_SHAPPIR: So I'll give my brief two cents and here's the thing. I used to have a lot of discussions with people who were JavaScript opponents, who would enjoy putting down JavaScript. And one of the main complaints that I would hear a lot is that JavaScript isn't really an object-oriented language. And I would say like, how can you say that in JavaScript? Everything is an object. It's more object-oriented than whatever language you're using. But they would say, hey, but it doesn't have classes. And you need to have classes to be an object-oriented language. Now, obviously, this is a falsehood. You need classes to have to be a class-based object-oriented language. But that does not equate to being an object-oriented language. But again, it was like this point that would use to repeatedly bash JavaScript. And if it was used against me, I'm sure that it was used against people in the TC39 a lot more often than that. So I'm thinking that at one point or another, they basically just said something like, F that will add classes to the language. Now, when they did that, they didn't want to break the language implementation. They can't really do that. They can't make changes that change how break back on compatibility or whatever. So what they essentially did was implement classes on top of the existing prototypical inheritance mechanism. So when you're using classes in JavaScript, you don't see it, but you're actually using prototypes. It's really just syntactic sugar in that regard. Pretty sophisticated syntactic sugar. It's not a trivial thing that they do, but still, you could do everything that you do with classes without classes at all. And that's exactly, by the way, what Babel does when it compiles code with classes, or when TypeScript does the same thing. But the result is that because classes in JavaScript are built on top of TypeScript, they actually behave somewhat differently than classes in languages where classes are like a built-in thing, like a core aspect of the language. And in that regard, they, to an extent, created more confusion that they solve. So now you can say, Hey, we have classes. So you can't make that argument anymore. But realistically, when you look at it, it's, it's kind of different and not really necessary. 

STEVE_EDWARDS: Hey, Dan, I got a quick question for you. You had mentioned earlier, you're going to put your two cents in. So my question is, why is it a penny for your thoughts, but you put your two cents in because somebody is making a penny somewhere. 

DAN_SHAPPIR: I don't know. I'm, you know, you're, you're the Americans. I'm, I'm, you know, English for me is like sort of second language. You tell me anyway. So yeah, so I dislike classes. I can give in several other examples of stuff like that is problematic in year six. They added an exponentiation operator. Why? Who needs it? Who asked for it? Who has ever used it? I don't know. Proxies are actually a cool feature, which I mentioned, but like I said before, they can't be polyfilled. And because they can't be polyfilled, then hardly anybody ever uses them because nobody wants to create something that doesn't run on IE11. But they are useful for debugging, by the way. There's this cool iterators-generators feature, which I actually really like a lot. I wrote a couple of blog posts about it and gave some talks about it. But unfortunately, hardly anybody ever uses it. So there's that. And module systems in the ES6 modules are certainly a hot topic. I know that AJ has a lot of interesting opinions about modules in year six. 

AJ_O’NEAL: I don't really know that I have that many interesting opinions about them. I think the opinions I have about them are the opinions that everyone has. They're not well defined and they're not necessary. 

AIMEE_KNIGHT: I sent a theme here. 

AJ_O’NEAL: Well no, like there's no definition of how to use a module, so nobody's been able to implement it correctly and everybody has to run everything through Babel. Node doesn't know how to implement a module. There's module syntax, but there's no direction on like, what the heck is a module or how should it be included or how, you know, like the things that are important about what require does, which is tells you what's the name of the module and where do I get it from and how do I get it into the program? Those are not well defined about module. With module we have, well, here's a syntax that theoretically is gonna work with everything, but it's all implementation specific. So don't worry about how it's gonna work or if it's gonna work.

STEVE_EDWARDS: I feel better. I thought I was the only one that had all that confusion about modules. 

AJ_O’NEAL: Are you being serious or are you trolling me? 

STEVE_EDWARDS: I'm being dead serious. Okay. I'm being dead serious. 

AJ_O’NEAL: I just want to make sure because you haven't spoken a lot and you could be trolling me, but you also could be 100% honest because I'm being over the top right now as the show antagonist. 

STEVE_EDWARDS: No, I've listened to people talking about modules and it's just I come away even more confused after hearing people talk about modules like, okay. How exactly do I implement this into my JavaScript app? 

AJ_O’NEAL: The answer is Babel. Like you write it in something else and you let Babel to compile it down to a... 

DAN_SHAPPIR: Well, it's worthwhile to mention that Chrome and Edge, the new Edge at least, and I think other browsers as well, actually do have native support for ES6 modules. So it's not like you have to have Babel in order to use modules. Now, whether or not this support is something that you actually want to use is still an open question, but it's there. And it is getting better. Part of it, by the way, has to do with the infrastructure of the web also evolving. I think with modules, one of the interesting stories about that Brendan Icke said about how JavaScript was created was that, if you may recall, originally it was supposed to be Java that was going to be the language that real developers working in the web were going to use. And JavaScript was supposed to be this kind of a glue language that designers use or you use to kind of glue together real applications that you wrote in Java. And because of this, Netscape management actually placed restrictions on Brendan in terms of what he was allowed to add originally into the language. So for example, he wasn't allowed to add classes. So in that context, he actually did kind of a hand run around them and added prototypes which are arguably a more powerful and flexible mechanism. And also one which made the language much more extensible, which was really important for a language like JavaScript in order to succeed. But they also prevented him from adding modules into the language. So for the longest time, you didn't really have any sort of a built-in module system. And modules really need to be a part of the language itself as a library is really problematic. Now the problem was that the world couldn't wait for that language limitation to be resolved. So when Node came along, they introduced this whole thing of CommonJS and require, and on the web you had the AMD modules and then the UMD and all this kind of stuff, but it was really limited and you had to use tools like Webpack because otherwise it just couldn't work. And ES6 modules are kind of an attempt, a belated attempt perhaps, to add some sort of a module system which theoretically can work everywhere. And certainly it's not without its problems and limitations, but yeah. 

 

Wish you could speed up your release cadence and skip the rollbacks and hot fixes? What if you could move faster, limit the blast radius of unforeseen problems, and free up individual teams to deploy as fast as they can develop like decoupling deploy from a lease, gradual rollouts with automatic telemetry to detect issues before they show up in operations graphs, and the ability to prove whether your features are hitting the mark using real user data, not the highest paid person's opinion. To learn more and sign up for a free trial, go to split.io. 

 

AJ_O’NEAL: So let me try something else. First of all, I think big languages are bad. I think it's inherently bad. I think it is a moral evil to create a large language. Like got languages like Go that there are less than 25 words in the entire language. And then JavaScript is like approaching 60 words now, which, you know, that doesn't, maybe doesn't sound like it's that big, but like JavaScript is a huge language. So first of all, I think big languages are inherently evil because it's more you have to learn, it's more edge cases, it's more crap to deal with. So the jump from ES3 to ES5 was removing keywords, removing aspects of the language, removing syntax, making the language smaller, easier to program, easier to parse. Like if you were to write an ES3 parser versus an exclusively ES6 parser, your ES6 parser would be less code and less error prone. Right? So that, that's one thing. The language I think should be small, but let's throw that out the window. I'm just going to defenestrate that idea for a second and say, okay, let's pretend that everything that's added in the language in ES6 is good and that there's no problem with making a giant language that has 16,000 ways to do everything, then let's, let's take a look at something completely different from JavaScript and see what its approach in evolution has been. Okay, so let's look at jQuery and the DOM. So here we have the C++ thing, and then this thing that's written in JavaScript to kind of adapt that C++ thing to make it more easy to use. And if we look at the history, people looked at the way that jQuery worked and the way that people were using it to get work done. They looked at the problems that jQuery was solving, and then they implemented jQuery in the browser. API for API, everything that jQuery ever did is now in the browser, typically with the exact same name and with the exact same arguments. Now there's some, that's not entirely true because there's a lot of stuff that you just can't do in the DOM like you can in JavaScript. And so it has to remain different from the way you do it in JavaScript. And there are some shortcuts they didn't put. Like most browsers will alias the dollar sign is document.query select and they'll. They'll alias dollar sign, dollar sign as document.queryselectall in the debug console. But when the people that have been working on the DOM were working on it, they worked on it from the perspective of what's a problem that is being solved that has a good solution, and how do we just ease that over? So now we have all of jQuery in the DOM, and jQuery is not really necessary. It's still nice to have for some compatibility reasons. But all the work that went into those decisions about the DOM, 100% of the work almost was taking something that worked well and implementing it so that people didn't need to carry around extra weight. So my problem, like let's throw out the whole huge language issue. My problem is that ES6 has not done anything to help JavaScript developers like the DOM has and other things that are somewhat related to JavaScript or other languages like any other pick any other language they add to their standard library. They figure out what people are doing and they say, oh, how can we make it so that people don't have to do this? ES5 added pretty much all of Lodash, right? Or underscore or whatever, you know, it's called like all those things. That was a good move on ES5. ES6 yes, they have added like three or four functions to string, like pad start, pad end, whatever. But by and large, my issue is that it's a wasted effort of spinning wheels that makes a language bigger which I think is a bad thing, but throw that out. It's just like, let's get into a room and talk and talk and talk and talk and talk. And at the end of the day, what tools do people have to make their lives easier? Babel. We didn't need ES6 to have Babel. 

DAN_SHAPPIR: Who uses the DOM these days anyway? I mean, we're all using frameworks. So, you know, the fact that the DOM got all this jQuery functionality is interesting, but I think that a lot of our listeners aren't actually using it. 

AJ_O’NEAL: I don't know. 

CHARLES MAX_WOOD: I think you'd be surprised. 

DAN_SHAPPIR: Yeah.

CHARLES MAX_WOOD: I think that most... 

DAN_SHAPPIR: I was intentionally being contrarian, by the way, when I said that. Another thing that I might say is that DOM itself is a really big mess. 

AJ_O’NEAL: Oh, absolutely. Absolutely. But the improvements to it have been improvements that matter. 

DAN_SHAPPIR: But I think a key point, like... So I do want to touch on the size of JavaScript, but before that, I want to touch on another aspect of JavaScript, which kind of distinguishes it from other programming languages, and I've heard Brendan Eich talk about this several times. And that's the fact that it has to be textually compatible with previous versions. When you have other programming languages that are compiled, that you deliver the code compiled, or you can specify which compiler version to use, you need to be perhaps binary compatible with previous libraries and so forth. JavaScript...My code needs to be able to run and work on really old browsers, which means if something is ever introduced into the JavaScript language, it can't ever go away. So if I want to introduce a new and potentially better way of doing something, I can't eliminate and remove the old way. ES5 did. I have to add the new way. And yes, they did with the use strict mechanism but not a whole lot more than that. 

AJ_O’NEAL: Yeah, but I'm just pointing out that ES5 did in fact make the language smaller. And one of the sad things about ES6 to me is that it throws ES5 out the window. Now nobody's using strict. All these errors that ES5 would catch are now being silently dropped. I mean, like- 

DAN_SHAPPIR: You can still use strict. 

AJ_O’NEAL: You can, but the mentality around it is like get rid of everything ES5. Just throw it away. Use with. Don't use strict. Don't let the errors be handled properly. Let Boolean return false for true. Like, you know, we've... 

DAN_SHAPPIR: I've not seen anybody, you know, again, your experiences are your own, but I've not seen anybody promote the use of with as a side effect or consequence of using ES6. In fact, I think most of our problems are developed... No, I phrased that incorrectly. Yeah, I think most modern, most newbie JavaScript developers don't even know that the keyword with even exists, which is actually a good thing. But you know, anyway, let me put it and again, and talking about the size of the language. So too, so it, first of all, it has to do with that fact that I mentioned that you can add stuff in, you can never take stuff away. So I really would have preferred JavaScript to be a block scope from the get go. I kind of am in a big disagreement with Kyle Simpson about that. We tend to have arguments about it every time we meet, but that's just how I like to write code. So I greatly prefer let over var, and I prefer const over both. But you can't eliminate var because the web would break. So you have to add const and let on top of var. 

AJ_O’NEAL: But adding const and let breaks the web. Now you can't use, like, the thing that ES6 adds are things that will break your application in eight huge number of browsers. People think like, oh, 1%. That's not, that's not big. No, 1% is huge. What if you had a 1% of dying on your way to work? You would not go to work that day. You know, 1% is a huge number. So you have to babble everything and then you're bloating your code size. You're making it harder to debug. You have tooling upon tooling upon tooling. Now you need source maps. Now you need this editor. Now you need this live debugger, which yes to become a professional developer, to become a true professional developer, should you be using all those tools? Absolutely. But should they be necessary for someone to get a Hello World out the door? 

DAN_SHAPPIR: First of all, you can still use VAR. You don't have to use VAR. You don't have to use Consolete. So if you do want to ship, you know, you don't have to use Webpack. You don't need to use anything. You can still use Script Tags that point directly at the JavaScript file that you would write in your notepad, whatever. 

AJ_O’NEAL: I guess my argument here is absolutely mute, okay? It's absolutely mute and I have to recognize that. But someone learning JavaScript today doesn't have a prayer of being able to write a simple application. 

AIMEE_KNIGHT: That is so true. 

AJ_O’NEAL: So I, as an expert, yes, I as an expert, I can use VAR. But someone that's, if I were to say, if someone says to me, Hey, what language should I learn? I'm going to say, well, you should learn Python because you'll learn how to program. And at some point you have to learn JavaScript because you have to. Could I ever recommend JavaScript as a first language to someone? I could have back at ES5 because the language had just been made smaller and the tutorials that were coming out on the web were a lot of them were by professionals. It was a good landscape and a good time to be getting into JavaScript. So somebody would ask me, should I learn JavaScript as my first language? Now I'd have to say no. Just learn how to program first and deal with that ball of wax later. 

DAN_SHAPPIR: I have to say an interesting thing about choosing a first programming language. So my daughter is in high school and she was starting studying computers. And the first language that they taught them, of course, was Java because Java. And then they taught them assembly language and then they taught them Python. Actually, she studied Python on her own and it is kind of a summer program, girls who code sort of a thing. And when she studied all these three languages, I asked her which one of those three she preferred, which she liked the most, which she liked the least. And I expected her to say something like, I like Python the most, then Java, and like Assembly Language, that's a drag. And she surprised me by saying that she liked Assembly Language the most, Java Second, and Python the least. And I asked her, why is that? And she said, well, coding in Python is not challenging. So it's just too easy. 

AJ_O’NEAL: So I, I don't have any argument against looking for a challenge of something to do, but 

CHARLES MAX_WOOD: I think this conversation has been relevant to how it's evolving, but I'd like to talk a little bit more about how it's evolving and a little less about what, what the impact is. Cause I think we've kind of made our points here. 

DAN_SHAPPIR: So I was, so, you know, to try to make it a more positive discussion and perhaps as contrarian.

 

Maybe we can try. I'd like to list some of my favorite ES6 features. Would that be worthwhile? 

AJ_O’NEAL: I'll list some of mine too. I have some. 

DAN_SHAPPIR: Okay. Go for it. 

AJ_O’NEAL: No, you go first. You get the juices flowing. 

DAN_SHAPPIR: Okay. You need to think of some to mention. 

AJ_O’NEAL: I think I have three in mind, but I think I might be able to come up more. 

DAN_SHAPPIR: So my first favorite JavaScript feature is a totally, totally syntactic sugar, but I get so annoyed. Like I said, when I don't have it. And that's field shorthand notation. That means that instead of when doing object literals, instead of writing a colon a comma, you can just write a comma. Now it sounds so ridiculously simple, but it just makes my life so much easier, both when I write and more importantly, when I read code. It just makes less of a cognitive overhead. It also kind of forces me to use the same names throughout, which is definitely a good thing. So that's one JavaScript ES6 feature that I really like. And conversely to that, well, actually complementary to that would be a better term, I really like destructuring and default value. I think that destructuring in arguments is like a lifesaver. But even in assignment, it's just, again, forces me to, or causes me to use the same names throughout the application for the same thing. And avoids repetition, reduces the likelihood of mistakes, and also kind of enables named arguments. All of these things are things that I really, really like, and I think make the code a lot more readable. Another thing that I really like, which I actually mentioned before, are const and let. Actually, the code that I write, I try to be const everywhere, and when something isn't const, often it's it kind of causes me when something can't be const, it kind of forces me to rethink and maybe change the code so that it can be const. And overall, again, it makes my code a nicer. And in general, I like for things to be block-scoped, even though sometimes making things block-scoped in JavaScript causes unexpected complications. And there's this really cool video that Jack Archibald and Surma from Google did on the complexity of block scoping in the for loops, which is amazingly complex and amazingly surprising. And I'll try to find that video and place a link to that. And oh, one more thing that one more that I want to mention, spread operator for arguments and collections. I think that everybody can agree that using spread for arguments is way better than using that wacky arguments object which was kind of like array, but not really. And it's better avoided if at all possible. Now somebody else. 

AJ_O’NEAL: Okay. I'll, I'll do this. Now I'm going to, I'm going to talk about ES6 from the perspective of what I like in a programming language, not from the perspective of how they completely broke JavaScript and made it not work with JavaScript anymore. So I love it when a programming language has destructuring and in my documentation for JavaScript, I use destructuring. Cause I feel like enough people are somewhat familiar with it, that it should make sense in documentation. Like you can tell, oh, I'm passing in an object and it has these things. So I think destructuring can, it looks a little funky when you're used to just, you know, object assignment and stuff. But I think that it can reduce some mental load and help provide better self-documenting code, especially when you're working in this language where really the best pattern is to only pass in one object and have that object contain everything because of promises and this, that, and the other, async, await, et cetera. You really kind of just want one value in, one value out, wherever you can, if you want to keep your code as simple as possible and composable as possible. I also, I love any feature that they've added to the standard library almost entirely. So pad start, pad end, there's a couple of array methods that weren't actually included until ES6, even though they were kind of proposed in ES5 or already widely used. So anything that is a polyfill, I almost love all of that stuff. And I wish there were more of those things. I wish that especially a big one for me is datetime. I wish that that had somehow made it into the specification of the language since you're gonna need it whether you're in Node or whether you're in the browser. And Node ends up implementing a lot of these quote unquote DOM APIs like the datetime stuff and internationalization stuff that I wish would just make it into the real standard. 

DAN_SHAPPIR: If I can pause you for a second, actually there is a proposed feature called temporal, which is supposed to add much better time and date management to JavaScript language and would hopefully fix all of our problems with that. 

AJ_O’NEAL: Good, I was hoping that there would be a conflicting API between the way that the DOM handles date time and the way that JavaScript does so that we can have six different ways to learn it. So that's excellent. But no, I can't complain about getting something that I want, hopefully. Hopefully if they make it completely incompatible with the way the DOM API works for daytime and internationalization, they'll make it incompatible in a way that's easy to use and works because the DOM API is like so backwards from how you need to worry about time zones and stuff. Anyway, features of the syntax that have changed that I like. I really do like, I think the dot dot dot stuff is good. The spread operator. I like that as a language feature. I I have mixed feelings about Async Await. So I do a lot of freelance work. I work with a lot of people who are not experts and who have no intent of being experts in JavaScript, but that need to use it or need to be familiar with it in some way. So a lot of where, you know, what I'm talking about comes from is the simpler I can make my code, the easier it is for other people to understand, the less knowledge and tooling, etc. that they need in order to be productive and, you know, work with me, then the smarter I look. And the more complicated or more explanation requires, the more I look like an idiot. Right. So as someone that works with other people that are not dedicated to JavaScript, but I'm doing JavaScript code, I like to be able to explain what I'm doing simply. So async-awake is double-edged sword because it, depending on what the person's background is, it can make it simpler or it can make it more difficult. And it's just, you know, it's, it's similar to promises, but it's different. But I, I do find it to be useful. I find it a little frustrating that I. There's not really a way to just use async-await. You're going to have to use promises as well. I don't know what the solution would be, but I wish that there were a way to just go full-on async-await and not have to also have promises for the type of flow control that I want. But I do think that it does. As a language feature, it's nice to have because we need languages that can both do things concurrently and in parallel. Now JavaScript. Web workers and some other things like that kind of allow for parallel processing, but that's not really what it does well. Concurrency, JavaScript as well, and Async08 does help with that. And I think there might be one or two other things that I have kind of started adopting in things that I'm not necessarily publishing or that things I'm publishing where I know for certain the only way that somebody would use this would be in a browser that has this support. Like some of the stuff I do with crypto libraries. I can be relatively certain that if they're depending on node crypto to exist or for the browser crypto to exist, that they probably have those features because they probably they must have an evergreen browser. You can't, I don't think you get any of that crypto stuff without having an evergreen browser. So there are some other features that if I'm like, well, I know that it depends on this, then I'm okay using this syntax because I know that they probably have an evergreen. But that said, I do feel like I cheat my principles a little bit on that because it's, I feel like it's better to be consistent than it is to be variant. Anyway, so I do, I do actually believe that as, as the way, if I was writing a language from scratch, there are a number of things from ES6 that I would want to include as a language that I'm writing from scratch that doesn't need backwards compatibility. 

AIMEE_KNIGHT: I'm going to share some stuff that I like that like I'm using right now, but then some stuff coming down the pipe that I'm super excited about that probably, I feel like doesn't get talked about as much. So a lot of the stuff that's already been said, like I have the same thoughts about async await and I don't know, I have similar thoughts to that as I do classes. I feel like people not familiar with the asynchronous nature of JavaScript can like easily overcomplicate things by like adding it, not necessarily knowing like what it's doing. 

AJ_O’NEAL: Object oriented programming and concurrent programming are at odds with one another. If you need something that can be unit tested, you can create, you can write object oriented programming. If what you're doing cannot easily be unit tested and it's concurrent object oriented, bad idea. Agree or disagree? Agree, it sounds like. 

AIMEE_KNIGHT: Yes. A couple of the simple things like destructuring, love that. I actually really, really, really like template strings. I think that, I don't know, just from a readability and simplicity standpoint, that was huge for me. It's such a simple thing, but it's huge. 

AJ_O’NEAL: I wish we had Sprint F though.

AIMEE_KNIGHT: And one thing I'm seeing people doing now is an intro to React is rather than using React, using these template strings to build little mini components. And that seems like a very cool intro to thinking and building in components rather than building out page by page or something. So that's kind of cool. One thing coming down the pipe that I really like, because I am a very defensive programmer, so I do a lot of checks in my code. So optional chaining, I don't know if everybody is familiar with that, but that's supposed to come land this year. It looks like- 

AJ_O’NEAL: Is that the question mark operator? 

AIMEE_KNIGHT: Yeah. 

AJ_O’NEAL: Awesome. 

AIMEE_KNIGHT: So I'll drop a note. I just popped it open as we're talking, and it looks like it actually has support in Chrome 80. So we can use it right now. Yeah. So this enables, like, if you're used to, you get back a data structure from a back end, foo.bar.baz. You can use the question mark to drill down directly and check if baz is there. So you don't have to do all the guards that you used to have to do to make sure you don't get, like cannot read property, whatever, of undefined. 

STEVE_EDWARDS: Oh, I want this so bad. 

AJ_O’NEAL: So this is not exception handling operator. This is just the, this is more like objective C, not like rest. 

DAN_SHAPPIR: A more undefined is not an object. Hey, it's not a function, sorry. 

AIMEE_KNIGHT: Yeah, yeah, yeah, yeah.

STEVE_EDWARDS: I'll just bring up a couple of points that stuff I use on a daily basis that has already been mentioned, the spread operator, destructuring, the string templates took me a little while to get my head around for some reason, but I finally figured out, you know, I get so used to string, concatenate variable, concatenate string, took me a while to figure out that's all one big string. But once I got my head around it, it makes a lot more sense and it was definitely a little easier to, to read. And that's all I got. 

CHARLES MAX_WOOD: Yeah. I mean, a lot of the sentiments that have been expressed are in line with where I'm at as well. I generally like async-await just because I think it's, I don't know, in some ways it's easier to reason about than promises. In other ways it's kind of not. And a lot of the poly fields actually just turn them into promises. So yeah. 

DAN_SHAPPIR: The tip I have, I do have a tip I'd like to share about the async await. My approach with the async await is to try to do a separation of concerns. So I try to encapsulate the flow of a specific item within a function and hold on, off, on, doing parallelized interactions until as high up as possible in the function called chain. So a specific function, for example, would, let's say, download something using Ajax and then convert it to JSON, for example, and then do something with it. So I try to have a single flow within a function. And that function can be in a sync function that does a weight within it, because it is a sequence of things. So they can happen exactly one after the other. And then I can paralyze as high up as I can, as I possibly can. That's kind of like my tip about how to be more effective with and get them more benefit out of the use of a single. 

CHARLES MAX_WOOD: Yeah. I mean, I definitely agree on classes. I find them confusing. And I find that at least in JavaScript, I much rather just reach for a prototype or do things in a functional way, because I'm never sure quite how it's doing classes. So yeah, I think you all have pretty well covered a lot of the places that I come in at with a lot of this stuff. 

DAN_SHAPPIR: I would like to mention also a few things that are coming down, you know, are like upcoming features. There are a few that I'm happy about, and there are a few that I'm much more, let's say, ambivalent about. So optional chaining was mentioned. It's a stage four. So it's going to be part of the language. And as was mentioned, it's already available in Chrome 80. So you can start playing with it even without Babel. I also like big ints. They are a needed addition to the language. Some people just need to do computation with large numbers. So for them, big ints are a must. I mentioned temporal. Hopefully a good solution for time and date management. The date object that JavaScript has, which was inherited from Java, is pretty bad. Everybody, I think, agrees. Standard library. It seems that we might start getting more things as sort of a quote-unquote standard library that are not just things on top of prototypes, like string.prototype or array.prototype via the concept of built-in modules. There's like this one experimental built-in module, something like a key-value storage module. Hopefully, they'll be adding more of this stuff. So we will start having some sort of a quote-unquote standard library as part of the language. It'll be interesting to see how this thing is kind of received because the JavaScript community really likes having this approach of to each their own. So like, you know, try to standardize all of the web community on a single framework. Let's see if you're able to do that. So it's kind of a similar thing with the library, whether a lot of people will like it or not. Things that I'm kind of more ambivalent about, there's a proposal to get observables into the language, kind of like what you have with RxJS. Not sure if that needs to be an actual part of the language itself. If somebody wants to do functional reactive programming, their Excel library is not sure why that needs to be added into the language, maybe as a quote-unquote standard library, but even then. There are some things that, other things that I'm really ambivalent about, things like do expressions and pattern matching and like a special syntax for frozen objects and sealed objects. All of these kind of deviate from the existing JavaScript syntax and even semantics and have uncertain benefits and I'm really worried.

CHARLES MAX_WOOD: Yeah, it's funny you talk about some of those because I've seen Ruby struggle with this too, right? A lot of Rubyists went to Elixir and pattern matching is a big deal over there. And yeah, so they tried to put it in the Ruby language and they kicked it down the road about four times because they couldn't get it right. I don't think they're ever going to get it in the language. But yeah, it's, and AJ kind of made this point too, you know, it's, we don't need this in JavaScript, right? We don't need JavaScript to be whatever this other language is. Right. And so by adding some of these features in, yeah, it, it deviates from the core of what we're thinking of for JavaScript. And yeah. 

DAN_SHAPPIR: It's an interesting point that, you know, you've got this, these guys on the TC39 committee and the scary thought is that, you know, they're there. So they have to do something. And the thing that they do is, is add stuff to JavaScript. So the question then becomes at what point does the somebody on TC39 say enough's enough, we're not going to be adding any more to the language itself. And then what, you know, does that make us redundant? It's an interesting question, I think. 

CHARLES MAX_WOOD: Yeah, I think the conversation there needs to be, our job isn't to add stuff to the language, our job is to maintain the integrity of the language. And so then if there becomes a feature that, you know, enhances the ability of the language to do what it does already, then we have the conversation right? Because then we're maintaining the integrity of the language instead of some other funky detail one way or the other. 

DAN_SHAPPIR: I think that maybe also WebAssembly will take some of the pressure off because with JavaScript being the only programming language in the browser, if there was a certain, JavaScript was a multi-paradigmatic programming language from the get-go. So you could do object-oriented in JavaScript or functional in JavaScript. But if you wanted to do functional programming JavaScript, you might feel that it was lacking certain features that you expect to have in a functional programming language. And then you would press on the, you would want additional language features that are related to functional programming, let's say, for example, pattern matching, to be added into the language. Well, now with WebAssembly, you can say, OK, then if I want to do functional programming for the browser, then I'll just use a different language and compile that into WebAssembly. So maybe that will take some of the pressure off or reduce the rate of change to JavaScript itself. Be interesting to see. One feature that I forgot to mention, which I'm really kind of unsure about, sometimes I really like it and sometimes I really don't, is the pipeline operator. I actually wrote a blog post about implementing like a collection library for JavaScript and using the pipeline operator to chain operations. And it makes the language really expressive. But again, it really changes the kind of the look and feel of the language. It kind of doesn't look like JavaScript anymore. So I'm kind of a bivalent about it. And I definitely appreciate that it can be challenging for especially junior developers to wrap their heads around, you know, this extension to the syntax. 

 

Are you freelancing or mood lining or maybe you've thought about going out on your own? Every week we have a group of developers at various stages of a freelancing journey on The Freelancer Show to talk about becoming better at freelancing. We also bring in experts to talk about marketing, SEO and delivering high quality to clients. So if you're interested in going freelance or you are freelance, check it out at freelancershow.com. 

 

CHARLES MAX_WOOD: Anyway, this has been really fascinating and I know we got to wrap up soon. So I'm going to push this to Picks. AJ, do you want to start us with Picks? 

AJ_O’NEAL: I do. So first of all, I want to thank everybody on the show today for being so respectful and kind and logical because I'm glad that, I mean, I hope that I don't come across as too brutish, but I'm really glad that, you know, we can have a hot discussion, you know, and be friends and love each other and, and disagree respectfully. And then I've got a couple of other picks. One is expert secrets. It is a book. I believe the author is the person who the CEO of ClickFunnels. And so it's a marketing book and a lot of us, you know, programmer type people were not really marketers, but it's got a really good message and it speaks. I haven't gotten too far through it yet, but he kind of speaks to marketing is really something that in the negative aspect. A lot of us, we think about marketing in the negative aspect. We get this really negative feel about it because it's lying to people, it's cheating people, it's being dishonest. But from his perspective, the way that he's achieved success is seeing marketing as the why. How do you reach your customer and serve them? Are you serving them well? Are you meeting their needs? Discovering the way to communicate with your customer to serve them so that you give them the best value out of anybody else that's giving them value to find it. And so he has this very service-oriented perspective on business and how kind of, you know, there's this quote by Zig Ziegler, you can have anything in the world that you want. If you figure out how to help other people get what they want. That's not exactly what it is, but kind of like that. He's kind of got that approach to the book and I'm really enjoying it. And it's changing some of my negative perspectives about and beliefs about marketing and, and certain business practices to see how they can be done in a true and honest way that helps everyone and that is fair. So I really appreciate that. Also, I got into this thing called Course Creator Pro, which is it, it's kind of a different style than, than, than what a lot of us as programmers might come at something because it's this filmmaker who started out as a guy in high school, college, just doing weddings and then upped his business and was able to do corporate and then. You're up to it again and again. And eventually, he's like, I should just teach people how to do what I do. And then it was really successful with that. And then he said, well, I should teach people to teach how I taught. And so if you are an expert in something, probably like the type of person that's making six figures, but not necessarily. And you want to know how to help other people get to the level of success that you've had in not a generic way, but in the way that you've experienced your success and to be able to find committed people that want to learn from you. It's a paid course and I put in my affiliate link, but I don't know if I'm going to be hugely successful like he was, but I feel like it's a really good template and approach to things and I've always been interested in helping others learn. I definitely have to curb some of my habits in order to do that better, but it's something that I feel like is helping me. I'd advise other people to take a look at it, at least watch the webinar that he has and you know, if that's, if that's an area you're interested in. And then lastly, really quick one, the bronze series seven. If you're a man or if you have facial hair or if you have hair that you believe a bronze series seven could eliminate for you, it's probably the best shaver on the market. Not according to just my own experience of my years of use with it, which by the way, you do have to replace the head regularly, but it seems to be like a favorite among many people. And if you don't mind getting a cheap one that somebody has used to shave once or twice on eBay, instead of paying 200 bucks for it, you could pay 40 bucks for it. But yeah, just little thing. Awesome. Makes me happy. 

CHARLES MAX_WOOD: All right, Amy, what are your picks? 

AIMEE_KNIGHT: Okay. Um, I am going to make a pick just to read and I'm not going to give any commentary. But I think it's something important in tech that we should, because it affects us and no matter what side you're on, I think there's like pros and cons. I just think people should be aware of a lot of the talk about unionizing for a lot of different tech companies. So this was something that I saw on Hacker News this morning for Kickstarter. I know that there's conversations, you know, it's just like a general conversation in the tech community. So something to be aware of. I kind of wanted to make a food pick and I keep forgetting every week what I actually want to pick. I'm going to pick broccoli sprouts. Super random. They're kind of hard to find. You can like Jimmy John's and get them on sandwiches there. The only place that I can find them in Nashville, you can't even buy them at like sprouts and I don't know if you can get them at like Fresh Market or Whole Foods. I typically order my groceries online lately because it's like really, really saved me a lot of time. And I know that when I tried to order them, like on Amazon Fresh or Whole Foods on Amazon, I couldn't find them. So the only place I've been able to find them is Publix. But anyway, it's like broccoli sprouts. They're awesome on sandwiches. And that'll be my health pick since I haven't started. I haven't done those in a really long time. And that's it for me. 

CHARLES MAX_WOOD: Nice. Dan, what are your picks? 

DAN_SHAPPIR: Okay, so I have a few picks. For those of you who don't know, it turns out that Chuck participates in podcasts other than this one. And yeah, and a few, yeah, he's kind of unfaithful to us in that. But turns out that some of the others that he's recently been involved with are awesome. And I've been having such a great time listening to them. And I want to list a couple of them that have been especially excellent. So one of them is this whole series of Clean Agile. Chuck is doing with what's, what, how are they called? The clean coders? 

CHARLES MAX_WOOD: Yeah. The clean coders podcast. 

DAN_SHAPPIR: Yeah. So, so you had that one, the first one with uncle Bob, which was just so excellent. And I had an awesome time listening to that. And I basically sent it around our company and I think everybody there is more or less listening to it. So I can't recommend it highly enough. Another one, which I found to be excellent was on the Adventures in Dotnet show. Episode 19 the one where where Richard Campbell talked about the history of dotnet kind of a bit similar to the conversation we had today in some respects like I said I'm a history buff and I've lived to those to do those times and you know I had my own perspectives on it and I really enjoyed I really enjoyed that one a lot So so that so there's that and another one that I wanted to mention was the React Roundup show that you had with Becca Bailey, talking about state management and React component design. And you kind of also veered into talking about programming in general. And again, I found it to be just an excellent episode and highly recommended. So those three podcasts, but do listen to all of them. They are really good shows. And the other pick that I had was an experience that I recently had at the company where I work at Wix. So Wix Engineering kind of organized an internal day for what we called a blog storm. That people who had some idea that they wanted to write a blog about something, so get everybody together in one room. We had to talk about being effective bloggers and how to promote your personal brand. And I thought that it was very forward-looking from the company to help us promote our own brand beyond just our existence within that particular company. And then we just sat down the entire day and blogged and also helped each other and edited what each other wrote. And it was really cool. And I think some really nice posts are coming out of it. So if anybody who's listening has the ability to do something similar in their own company, I highly recommend it. And those are my picks. 

CHARLES MAX_WOOD: Awesome. Steve, what are your picks? 

STEVE_EDWARDS: So actually I have two picks. I had one until I heard Amy's pick because I wanted to issue a companion with her broccoli sprouts. My pick would be Beano to go along with broccoli sprouts. Just to, shall we say, offset the natural effects of food such as broccoli. Second pick is to expand on my joke that went over like a lead balloon earlier about putting in a penny in putting in your two cents and pending for your thoughts. That was one of my favorite comedians named Stephen Wright, or probably he is my favorite comedian. He's got a style that's all his own real deadpan. And so my pick is gonna be his original HBO special from 1985. And then that he made that into an album called I Have a Pony. Just hysterical, some of the jokes, I quote them to this day. And they're so great one-liners that you can just squeeze in, you know, to a conversation like you know, for instance, if your foot falls asleep, you can say, man, I hate it when my foot falls asleep during the day because that means it's going to be up all night, that kind of stuff. So put the link to that special that's on YouTube. 

CHARLES MAX_WOOD: Nice. All right. Well, I'm going to throw in some pics here. So I just started watching The Expanse season, I think it's season four. And yeah, looking forward to seeing how this one goes. I've read the books. They tend to stick pretty close to the books. So I, you know, I can't complain about that. I have really, really enjoyed the series so far. So I'm gonna pick that. It's on Amazon Prime. The first couple of seasons were on a Sci-Fi and now they're on Amazon Prime because Sci-Fi canceled it and Amazon picked it up before it died a horrible death. So anyway, I've been enjoying that show. So I'm gonna pick that. Another one that my wife and I have been watching just for fun is The Masked Singer. And we've been enjoying that. Of course, I have so little pop culture knowledge that I I'm not very good at guessing these people. I didn't watch the first two seasons when they were live. So of course, you know, the one or two people that I'd actually heard of on any of those that I might have been able to guess, you know, I wasn't, I wasn't sticking around to do that or I wasn't around to do that. 

STEVE_EDWARDS: So how does that work? Do they pick one per episode or is it one for the whole season or how often do they do that unmasking? 

CHARLES MAX_WOOD: I think they unmask at least one per episode. So anyway, I've been enjoying that. And my kids have really been enjoying. What is it? Lego builders on Fox 

STEVE_EDWARDS: Lego masters 

CHARLES MAX_WOOD: Lego masters. They've really been digging that. So I'm going to shout out about that as well. And those, those are my picks. Um, this was fun guys. 

DAN_SHAPPIR: Yeah. Talking about JavaScript in a JavaScript podcast. Who would have thought? 

CHARLES MAX_WOOD: I know imagine that. 

AJ_O’NEAL: Well, I mean, it's just been so clouded with all these frameworks and stuff. You know, we haven't had time. I hadn't had, hadn't had time.

CHARLES MAX_WOOD: Haven't had time to talk about JavaScript, been busy talking about frameworks. Is that what you're saying? 

AJ_O’NEAL: I dunno. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. To deliver your content fast with Cashfly, visit c-a-c-h-e-f-l-y dot com to learn more.