 Hey, everyone. I am so excited for my discussion today at the OpenJS World keynote interview with Alan Worsbrock of Worsbrock Associates. Alan was a project editor of ECMAScript specification from 2008 to 2015. Alan, thank you so much for joining us. Thanks. It's great to be here. It's great to be keynoting here at the OpenJS conference. Now, Alan, you're going to have to tell us a little bit about this paper and the conference that it was supposed to be a part of. It was supposed to be about from the history of programming language conference that happens every 15 years, but it couldn't happen this year. Tell us a little bit about this fascinating conference that makes me think of Tolkien almost. Yeah. Well, the ACM, Association of Computing Machinery, holds this conference. It's every 12 to 15 years, depending on how they get organized. And it tries to get into the conference, the people who are involved with major programming languages, to write down and document how that language came to be, to provide the history and really a record of where we came from. And so as we go forward, people understand why things are the way they are. I'd really like to borrow from Douglas Crockford, who you write about in your paper. And Douglas Crockford was very instrumental in the evolution of JavaScript. And he said JavaScript is the most misunderstood programming language. Well, it starts with the name, right? Because it has Java in its name. So people assume that it has something to do with the Java programming language. Yet technically, it's a very, very different language and is designed to do different sorts of things. But people come into it expecting it to be like Java and it isn't. Now, the reason of that actually goes back to the really very origins of the language. Because in 1995, Netscape was trying to introduce for the first time programming into the capabilities that people developing webpages had. Before that, all there was was HTML, declarative HTML. And they thought they would do that with a scripting language. But at the same time that happened, Sun Microsystems came along with the Java programming language and started promoting it for web technology. And so there, within Netscape, there was essentially kind of this race between a simple scripting language and this more complex language that Sun was promoting. And in the end, there was sort of an internal datant that said, well, we'll do both. We'll incorporate Java, but we'll also have this simpler scripting language to not confuse the world, although it ended up doing just the opposite. We'll name the language JavaScript to make it appear that they're tightly integrated. Now, you wrote in the book that Brett and Iker calls that the rallying cry articulated by Mark Andreessen, who was at Netscape at the time and is famous for his time there, was saying Netscape plus Java kills Windows, which seems to me now kind of funny because this was really more a discussion. If you think back about really the conversations more about the web, really, then Java versus Windows. But in 1995, it was Microsoft and Windows that was dominating all of personal computing and stuff. And for anything new to be introduced that wasn't originating with Microsoft was very unusual and very difficult to accomplish and stuff. And so if you think of the web as a new different sort of platform, that platform to some degree needed to compete with Windows. And so that's part of that slogan. Really, then what were the impacts of JavaScript at the time? What about it showed how deeply integrated it was into the web stack? How did that distinguish it from Java? Yeah, that was really probably the biggest difference. Java was its world onto itself. It wasn't really native to the web. It was an add-on to the web. And their slogan was right once, run everywhere, and they would run the same in the browser as it would on a desktop, as it would on a server. And it was Java that was defining everything about the world, what the UI would be like, how you'd interact with it and stuff. JavaScript, as it was developed at Netscape, it was highly integrated with the native web technologies. The first versions of JavaScript, the only way to include JavaScript code was to include it in line within your HTML files. There were script tags contained JavaScript, but there wasn't the option to point off at an external file containing your code. It had to be there right in line. And then the interface from JavaScript into the browser technologies in the HTML, JavaScript essentially invented the DOM at the same time. JavaScript was invented. The DOM was invented. And so when you programmed in JavaScript, you directly manipulated the same abstractions, the same concepts that you used when you wrote the HTML. So now looking back on it, before we get into the discussions about the standard, because things were developing so rapidly at this time, but who are the people? What was it about this group of people that made them so unique for the time? What was it about them that really you think is special? Because JavaScript, in some respects, has always been underrated. But this was actually a time when there was just really intense innovation happening. What is it that you reflect upon about this group of people? Well, I think the people who are most successful, like Brendan with JavaScript, was people who understand what their piece of the technology fit into everything that was going on around them. So trying to make the system that they're part of work versus there's always lots of people who have their own thing, their own technology they developed and try to find a way. Well, can I use this new thing to leverage what I'm pushing or what I'm devoted to and stuff? And so I think in the case of the web, it was the people who really embraced the ugliness, if you will, as a web. There's a phrase, worse is better. We originated from Richard P. Gabriel, who is one of the developers of CommonLisp, and he's basically saying the technologies that tend to succeed are those that are just barely good enough. They're good enough to get the job done, but they don't try to be the best possible solution. And those tend to be the most successful. Worse is better. And this also was a time when now that you were opening up the browser for programming, you were thinking of it as a web stack, but there were all kinds of different developers who were building things and all had to work together. Right? And so now you have this, what you call, browser game theory developing. And how did that manifest in creating a standard? And I want to move into that part of the discussion. Well, that really started with as soon as JavaScript was introduced, we had Microsoft, who was creating Internet Explorer to compete with Netscape. And the original HTML, they kind of had to be the same. But now there was this new thing, JavaScript. And if Microsoft didn't have JavaScript in IE and Internet Explorer, then web pages that used JavaScript wouldn't work in Internet Explorer. So even though they hated the idea, they wanted people to use basic for scripting and stuff, they realized they had to provide JavaScript to simply, or people, web pages wouldn't work. And the whole point of the web was anybody could create these pages and anybody could have a browser. And there were multiple people building browsers. And so you had to have the same technology in all of them. And part of what we call browser game theory is this idea that if you're a Netscape or a Microsoft or a Mozilla or even a Google, and you have this great idea for browser feature, and you add it in, you add a new part of the technology scrap, a stack that a developer could use, well, if it's only in your browser, nobody's going to use it. Yeah. And it really then laid the foundation for a lot of the web technologies that we see today. And how we think about interactivity really, I think, you know, at the most abstract, in terms of how you think about, you know, we hear a lot of discussions today about microservices and all the components that must work together. But here we're talking about the browser. And so the standards became incredibly important. So you say that there were essentially, what we started to see was like this bifurcation though, there were these two separate design efforts that were happening. What happened there? So Brendan and I created, basically created the first versions of JavaScript. And that was copied fairly closely by Microsoft and other people who were working on browsers and stuff. And that, and that then led into the creation of an official standards effort under ECMA. And for the first four or five years, through what's called ECMA script three, most of what that committee did was was simply rubber stamp, Brendan's design, cleaned up some rough edges, clarified some things that were not clear, but it was really the original design work was Brendan Ikes. But by the time in 1999, when ECMA script three was completed, Brendan was had gone off to help create Mozilla. Netscape was in decline as a company, Microsoft's market share was growing. And it had less interest in JavaScript. That the standards committee was still there and was responsible for moving the language forward. But nobody on the committee had actually done any design work with the language before. They'd only sort of done maintenance up to that point. And now suddenly they had the job trying to move the language forward. You know, so now we then came into the next phase of your book where there's the failed reformations, when we started to see the difference between really those web technologies versus the more traditional technologies who said, this is just not really applicable. You know, really, this doesn't make any sense to our, you know, to a traditional technology practices. Right. So essentially, if you go back to worse is better, you can kind of say, well, the worst is better people launched a web to the point it was was well on the way of taking over the world. And the better is better people came in and said, well, this is this is kind of ugly. This isn't so good, we could do better than this. Let's, in many cases, let's start over and see if we can replace what's there with something better. And this wasn't just happening with JavaScript. It was at the same time X HTML was being introduced and the W3C even said, I think it was in 1998 that HTML was going to be put into maintenance mode and that hopefully nobody was going to create any new HTML pages anymore and stuff. Well, similar thing was going on in the standards group is JavaScript. They're saying, oh, we're going to create this new thing, a script for and it's going to be a serious programming language. And we're going to, you know, do all the technology we have available that all the academic programming, academic language designers have come up with. And we're going to apply this really going to make a good language here. That's good enough for the web. You got involved in around 2007. So you were witness to some of these failed reformations. What did you find that was noteworthy now? I mean, you talk a little bit about it in the book. Perhaps you could highlight some of those for us. Well, sure. I mean, the the main thing in my experience as a language designer and working with various technologies is so I actually came from a small talk background. And one of the things I recognized there was that when people try to drastically change the language to fix a perception that usually didn't work out because for various reasons, because the language technology didn't fit together and the existing users wouldn't adopt it. And so when I was asked to look at what was going on with that script standardization, and I kind of recognized this is one of these situations where somebody is taking what was a dominant versus better style solution and saying, we're going to fix this. And the way we fix it, here's a whole long list of things that are kind of fundamental to what the existing language is. So static typing versus dynamic typing, for example, was a big one. But we're going to take this long list of features. And we're going to change the language so it embraces all these other things. And that was where I said, well, efforts in the past I've seen to do this was other languages tended to have not worked out. That's why I personally thought it was worthwhile trying to get things on course of one more where you build upon what you already had there in JavaScript and what the developer community was doing and what they were used to and yes, recognizing there are improvements that could be made, things that could be added, but had to be done in a way that preserved the existing web. Or as we now say in the standards area, don't break the web. It had to be done in a way that didn't break the web. So you were part of the 3.1 working group, correct? What impacted ES6 out of 3.1? Well, the bits of ES3.1 did was show that there was an alternative to this complete redo effort that was ES4. It showed that it was practical to do something that was incremental building upon the existing standards and the existing languages and use and that there could be agreement among the people in the standards group and among the people who build browsers on how to move JavaScript forward in an incremental way. Feature-wise, there was a few new things in ES. ES3.1 eventually was named ES5, so there was a few incremental things like the addition of JSON support and what have you, but the most important thing about it was saying here's a way we could go forward. Here's a way we could work together on the foundation we have and add to it. Now we're 2020. So what are the developments that you're following now? Are they related to JavaScript? Who are the people that you're following? What is the story that you're following as it moves forward? Well, so boy, the world of JavaScript now is completely different. When I first got involved, there was literally a handful of people who were involved in JavaScript standards and over the course of development of ECMAScript 6, there was really only about, there was various people involved, but there's really only about 10 people involved continuously through the effort who really set the direction now. Because of the success of that and the success of JavaScript that's come onto it, there's probably over 100 people who are officially registered as participants now in the ECMAScript standardization process. So it becomes a much more different thing and there's lots of people now each with their own idea of what direction to go. And so it's a more difficult process to move things forward because of that popularity. One of the problems with programming languages is if you add too many features, even if they're all good features, the language itself becomes too complex. So I think the balance today and going forward is one of choosing what are the really important things to add. And there definitely have been a few over the last five years that are really important. And there are others that people are thinking about, but there are so many good ideas and you can't add them all. And when you're dealing with a large group of contributors, it's hard to sort those out because people don't become involved with a language design effort or standardization effort to not do stuff. They come there to, oh, this is my opportunity to add my favorite feature to the language. And if everybody does that, you get a mess. Well, Alan, I want to thank you very much for taking the time to talk with us for the OpenJS World Keynote interview. Alan Worsbrock, who was project editor of the ECMASPIRIP specification from 2008 through 2015, and the author of the book-sized journal, ACM History of Programming Languages Conference. So we're coming up with a 25th anniversary. So thank you so much for joining us, Alan.