KENT: This is the beginning of the show for our first ever JavaScript Air. We're super excited to get started on this new live broadcast podcast. So today, we're going to be talking about the past, present and future of JavaScript and we're really excited. But before we get into it too much, I'm going to give a couple of shout outs to our sponsors.

So first, Egghead.io. They're our premier sponsor and they have a huge library of bite-sized web development training videos. Check them out for contents about JavaScript, Angular, React, Node and a bunch more. And then Frontend Masters is a recorded expert-lead workshop with courses on advanced JavaScript, asynchronous and functional JS, as well as a lot of other great courses on frontend topics. And actually, Kyle Simpson has a couple of courses on there. I highly recommend you check those out. And then finally, TrackJS. TrackJS reports bugs in your JavaScript before your customers even notice them. And with their telemetry timeline, you'll have the context that you need to actually fix them. Check them out and start tracking JavaScript errors today at trackjs.com.

And, cool, so during the show, if you're watching live, you can go to Twitter and if you have any questions, use the hashtag #jsAirQuestion and we'll address your questions at the end of the show -- live during the show.

And just a couple of general announcements, remember to follow us on Twitter and Google+ to keep up with the latest. And we're also on Facebook. And next week's show is the same time, same place, "Learning and Developing JavaScript." It's December 16th with Ashley G. Williams and Kyle Simpson. So, it's going to be awesome!

Let me go ahead and introduce our panelists really quick. We'll have another show later to talk about how awesome these panelists all are. So for today, it will just be names and faces, so that we can have some time to chat about JavaScript. It's going to be awesome. So when I say your name, make sure to unmute yourself, wave and say hi so everybody knows who's who. We have Dan Abramov.

DAN: Hello!

KENT: And Brian Lonsdorf.

BRIAN: Yo.

KENT: Kyle Simpson. [Chuckles] He made a finger gesture. I'm not quite sure what it was but I'm sure it was awesome.

[laughter]

BRENDAN: No gang signs, please.

[laughter]

KENT: And then we've got Lin Clark.

LIN: Hey there!

KENT: And Matt Zabriskie.

MATT: Hello.

KENT: And Pam Selle.

PAM: Hello.

KENT: And Tyler McGinnis.

TYLER: Hello!

KENT: And so that's our panel for this show. My name is Kent C. Dodds, I am the host. And totally love this community and JavaScript in general. This is going to be awesome. So let's go ahead and give our guests some airtime really quick. Brendan, could you introduce yourself to our viewers and listeners and tell us who you are, what you do and what you're up to now.

BRENDAN: Hi, I'm Brendan Eich. I created JavaScript in 1995 in a mad rush. I have been making up for it ever since. I founded Mozilla with other people in 1998 and I'm doing a startup called Brave Software -- brave.com.

KENT: Do you mind talking about that startup? I have not heard of that before.

BRENDAN: [Chuckles] We're still stealthy so you'll have to wait. But there's a MailChimp form you can enter your email into there. And there's an Easter egg, if you are diligent about view source.

KENT: Oh, snap. I'm pretty sure that we're going to get a lot of those Easter eggs uncovered. [Chuckles] That's interesting to me.

BRENDAN: [unintelligible]

KENT: [Chuckles] We know that the Easter Bunny has hidden something. Cool, so let's go ahead and get into the content of our show, Brendan. We want to talk about JavaScript in general. This show is all about JavaScript and the web, and some of the amazing things that you've done. Like, Brendan, you've created my job and I just wanna personally say thank you [chuckles] that, like, my wife and children eat and are clothed because of the work you've done. [chuckles] So thank you very much.

BRENDAN: Who knew? [Chuckles]

KENT: [Chuckles] Yeah. So Brendan, I know that you've told this story probably a hundred times, please, a hundred and one would be great for our viewers. Could you briefly talk about where JavaScript came from and yeah, like, where did you come up with the idea? What was the original intent?

BRENDAN: Sure. So I'd have to go back a little bit in time. I was at Silicon Graphics (SGI) in their glory days from 1985 (before their IPO) to 1992 when they become very big company. And I left but I knew some of the early people and the Founder, Jim Clark. And so when he did Netscape, he and one of the SGI people, he picked up, Kip Hickman tried to recruit me in the spring of 1994. And like a big idiot, I said, "no, I've got to keep working on my start up," that I did in between SGI and Netscape called MicroUnity, which you might find made some references to. George Gilder wrote about it in Forbes ASAP. It was one of those early mid-nineties, do-everything rock band startups that was trying to innovate in semiconductors to software to beyond.

And of course, as Clark pointed out to me, when I joined Netscape, it was likely to fail because when you do ten hard things and the odds ratio for each of those ten hard things is independent, the total odds ratio of success by the multiplication principle, is the product of all those fractions. So one in ten odds for each of those things: semiconductor, new micro kernel, new instruction set architecture, new digital signal processing, analog and digital circuits on the same chip, new user code model for doing what we now think of as superscalar and SIMD, that's like one in tenth of the seventh or tenth of the eight odds of success. So MicroUnity was not going to work. It had a lot of patents so it still made a lot of money for some people -- not for me. But I stayed there in 1994, like an idiot. And when Netscape friends called again in 1995, I went.

And the reason I went was because they said, "Come out to the coast! Do Scheme in the browser." (I was already out in coast actually but I wanted to refer to Die Hard there.) [Chuckles] So I came to Netscape to do Scheme in the browser but when I got there, they said two things to me. They said, one, "Oh, we can't hire you into the client, into the Netscape navigator team because we're short of head count and we'll hire you into the server team instead so you can work on HTTP/1.1" (or what they hoped became 1.1). Second, "Oh, we're doing a deal with Sun Microsystems to integrate Java into Netscape, so we're not sure we want to do Scheme in the browser anymore." And that was kind of a drag.

So I worked for a month from April to early May in the server team with Robert McCool and Mike McCool, the McCool twins, who wrote NCSA HTTPd (which through a fork, became Apache) and Ari Luotonen who did Netscape proxy server. And we actually did interesting things using kept connections. We tried to multiplex streams onto HTTP/1.1. It was a lot like SPDY but it was way ahead of its time and it wasn't going to happen. And for better or worse, I switched to the Netscape client team in early May and I wrote JavaScript's prototype -- the Mocha engine -- in ten days in May, 1995. And it wasn't Scheme. It was not Schema in the browser, of course. It had to look like Java, it had to be done quickly because a lot of people at that point were saying, "Well, do we really need two languages? Why not just Java?" Or "Will developers understand that there's a second language?"

And critically, Bill Joy of Sun Microsystems and Marc Andreessen, co-founder of Netscape said, "Yes, they will understand because it's like what Visual Basic was to Microsoft Visual C++" in the Windows stack at the time. We need a more accessible, easy-to-use language you can buy by the yard, you can start using line by line. You know, anybody can program in it, you don't even need to be a programmer. It's very approachable. That's for the order of magnitude of too large a population of designers and amateur programmers who are critical in an ecosystem to building, let's say apps or web pages.

And so Mark and Bill Joy got it. And that's why I did the ten days of crazy implementation to prove that it was a viable idea. They also gave me another constraint which was "Oh, we want to have this in the server side for our LiveWire (sort of PHP-like thing)." So I'm thinking that it's programmable in the Netscape's sever the HTTP::Daemon then that can hit a database, put some data through a template and generate some HTML, have a little bit of scripting on the server as well as the client side. They wanted an engine for that and that's what the Mocha engine was. And particularly, that's why I wrote a bytecode interpreter and compiled all the bytecode from source.

So that's what the genesis of JavaScript was. But it was called Mocha and then LiveScript because we couldn't get Sun to sign a trademark license, until December 4th 1995 when Bill Joy, who believed all the way, said, "I'm going to sign this as Sun's founder." Nobody else I think wanted to do it. The next day, I think I heard his name was mud. James Gosling and all the Java people were like screaming, cursing and wanted to kill Bill Joy because he signed this trademark license to allow "LiveScript" to be renamed "JavaScript," which, as Douglas Crockford told me when I met him like six years later, he said, "It was a huge marketing scam." And he was right.

KENT: Awesome. [Chuckles]

PAM: So I have a question, Brendan. Hi.

BRENDAN: Hello.

PAM: So like many functional programmers, you wanted to write Lisp and then they wouldn't let you. So what do you think about ClojureScript and bringing Lisp into the browser?

BRENDAN: I'm in favor. And I should also note something I shared at dotJS in Paris two days ago; the WebAssembly proposal which is going forward through all four top browser type vendors has an S-expression syntax, not for downloading because that's inefficient. It's probably less efficient than even JavaScript source, but for view source and tooling, it's Lisp in syntax, in its clothing. So yeah, the circle is not complete.

BRIAN: I have a question too. I was wondering if this was your first crack at writing like a bytecode interpreter. I heard you had hung around Stanford reading white papers on the subject. But you know, is this your first try and it just worked?[Chuckles]

BRENDAN: No, I was a Physics major for three years at Santa Clara University. And I was frustrated because this was 1979 through ë82 and it was an awesome time in computing, right? The Apple II was born in the late seventies. There were still a lot of people building computers from scratch. And yet I was doing physics and my department chairman would say, when I asked him about summer job options, he would say, "Have fun mowing lawns" [chuckles]. So also, physics, I think stagnated a bit. It's a different topic I won't get into here.

So I ended up being a lab assistant on DEC-2060 and VAX systems (which I loved) and UNIX. And I switched to Math Computer Science in my fourth year and I started writing, immediately I loved the theory of formal languages, parsing regular languages, regular expressions, lexical analysis and parsing and compiling. So I started writing my own parsers, compilers, parser generators. At the time, in the early eighties, there was a sort of an arms race to generate efficient parsers from certain kinds of grammars, the LALR(1) grammar in particular were hot. And I wrote the parser generator. And I did a lot of hobby implementation of programming languages.

And I was inspired throughout the eighties by Brian Kernighan and P.J. Plauger (I think his name is pronounced). And Kernighan and Pike did a book on UNIX where they had a little toy language called HAWK, a classic Rob Pike language. And even before Hawk, there was AWK, A-W-K (Aho-Weinberger-Kernighan, I believe). And I had the source through academic or later through SGI commercial UNIX licenses. So I studied all these things. I studied all the ugly C code [chuckles] that was used to implement these things. I was a C programmer. I was a kernel hacker as well as a programming language buff. So I have implemented a lot of hobby languages.

And then at SGI at some point, after doing a lot of kernel hacking, we realized you could do a network management software stack on Ethernet (10 megabit Ethernet at the time), and one of the things you wanted was to turn on promiscuous mode catching packets on the net and dumping them. So I wrote a packet filter language that could be efficiently compiled with the kernel. It was a Berkeley Packet Filer in Berkeley Unix that used bytecode. I wrote something simpler with to behest one of my mentors and colleagues that compiled a general expression language over the header fields of the IP protocol, the TCP protocol or UDP into a short set of Mask and Match sort of bitwise filters. And that was fun. And that turned into a product the SGI sold. And I ended up running another compiler for that that took a general protocol description language that I designed that could express TCP/IP or AppleTalk or DECnet. And that allowed my colleagues at SGI to write protocol descriptions in a higher level, declarative language. And my compiler would turn those into decompilers, pretty-printers and packet filters for those languages, those protocols. So this turned into a network management product.

So I had some experience writing these things. And then in MicroUnity I wrote an MPEG-2 editor that would parse the MPEG-2 video, multiplex bit stream and turn it into something you could edit and then turn back into a bit stream. So you can generate you know test inputs for our video decoder because MicroUnity, in addition to doing ten hard things at once, I was trying to build a set-top box to decode video of what you might think of as like a streaming video before it's time, MPEG-2. So I had experience writing compilers and parsers and lexical scanners and that allowed me to do JavaScript extremely quickly. Like in the first day, I've knocked out the sort of C-like parser because I knew C grammar by heart; I knew all the weird corners of it like the adjacency and the precedence hierarchy of the logical and the bitwise operators, which was a pretty good evolution from the B-language where there was only one set of such operators that did both bitwise and logical duties.

BRIAN: Right on.

KENT: Brendan, you're on a totally different plane from where I am. I feel like so low right now [laughs]

PAM: Kent, I mean, running a compiler is within your reach. [chuckles] You can do it.

BRIAN: Actually, you end up getting to be a popular design pattern these days with all the functional stuff like DSLs coming back and everything. It's exciting.

PAM: Yeah. We're going to write you a DSL.

BRENDAN: That's right. The people who use Scheme for pedagogy encourage people who learned it to early on, write their own language processors. And I think it's great.

LIN: So I have a question. If there were a parallel universe where you were able to have done Scheme in the browser, where would the web be in that parallel universe today?

BRENDAN: So I don't know. I mean, there's so many variables but it might not be that far from where it is. The syntax may not matter as much. Scheme, you know, is beautiful and minimal and a very few special forms. And the flip side of that is you end up writing a lot of industrial Scheme code using macros. So you need a hygienic macro system and then you end up writing macros in a way that may not be portable to other environments where they don't load the same macro libraries. So you have to include macros I think in order to get the full effect.

Things like call/cc (call-with-current-continuation) which is like functional go-to, it is where you capture your current program state and then reify it as a function that can be called to jump back to that state. That's awesome but it's often to low-level, so people write macros and Scheme on top of call/cc, and those macros become much more understandable and easy to use correctly across a large scheme of programmers. And then because Scheme is not sufficiently standardized, let's say, (there are standards, obviously but different industrial uses of Scheme I've heard about. I've never worked directly with Scheme) end up reinventing the wheel differently. And it's sort of like C in the early days; you had to have a standard library, stdio, stdlib, what became stdlib and you had to have them well-implementedÖ and they sometimes didn't agree. Back in the 80s, it was rough. Things were different. Things did not agree.

KYLE: I have a question on the whole design side of the language. It's pretty common for people level the claim against JavaScript that there are mistakes or bad ideas in its design. Some of us maybe sense that pain and maybe others of us maybe don't see that as much. But I'm curious, from your perspective, do you feel like there are language design decision mistakes or do you think it's more a question of needing better resources to learn JavaScript the way it was designed?

BRENDAN: Oh, [chuckles] so, first of all, there were clearly mistakes. I worked for ten days without much sleep. And even then, I made mistakes afterwards based on early inside Netscape user testing. So I've talked about this a lot in my writing and speaking. There were mistakes for sure. And you know, you readÖ Dennis Ritchie wrote a very humble and educational history of the C language and he admitted there were mistakes and sort of path-dependent errors or consequences of evolution, like I mentioned the bitwise and logical operators being adjacent in precedence. And you just can't help some of these things, so it's the kind of absurd to say no language should have mistakes. All languages have mistakes, including our fine English language; a Germanic languages that's heavily been influenced by of Norman Conquest of 1066, right? English is an ongoing mash up between different languages. And it has irregularities and what look like mistakes to people who speak other languages.

So JavaScript had mistakes, but it also had I think a sort of natural language degree of sort of magic to it. It's the property that Larry Wall actually aspired to with Perl which is this sort of "do what I mean" quality. And it's very risky to try to design a language that has that property because often, it will do what you don't mean and you won't get an error message and you'll only find it if your test coverage is good enough. But when it works, it works very well.

So you're right, there was some intentional design and there were some mistakes. I mean, the one I talked about rather explicitly like on Stack Overflow is that the double equals operator will, given two operators of different types, will try coercing one or the other or both to a comparable type. And that can lead to trouble; it makes that double equal operator not be an equivalence relation in the mathematical sense, it's intransitive in particular. There were other problems to do with NaNs that I won't get into but that's kind of corner case; you know, signed zero, negative and positive zero.

But it remains, that you know the "1" == 1. And that's intentional but not in my original design. That was after the ten days, this team that was doing LiveWire, the server side embedding of my engine were dealing with a lot HTTP headers and form data in HTML forms that had numeric strings and they wanted to make it easy for the programmer to compare "1" to 1. And like an idiot, I gave them what they wanted. And that's why I changed from my original design which was very C-like, that said, "if the types differ, the thing is not equal. Forget it." And that's what led to the triple equal operator.

When we started to standardize JavaScript with Microsoft, everybody in the room, Guy Steele was there, one of the creators of Scheme with Gary Sussman, all said, "Oh, this is not good. This is kind of a messy operator. It's sloppy. It converts. It's not equivalence relation. It's not transitive." Guy was actually philosophical; he said, "You know, we can have another operator; Common Lisp has five versions of eq and eql and so on." And the Microsoft guy, Shon Katzenberger said, "Well, you can add this triple equal operator I've been experimenting with." And I had been saying, "Let's make a break. Let's do a JS 1.2 (this was 1996 or early 1997). Let's just change double equal to be strict." And Microsoft trying to gain market share on Netscape couldn't stand for it. Shon said, "No, we can't break compatibility. People are using double equal in a sloppy way. Let's have triple equal." And that's what we did.

KENT: So Brendan I think that you called yourself an idiot at least three times on this podcast. [chuckles] That makes me feel a lot better, I guess, about myself, but [chuckles] I don't think you're an idiot.

BRENDAN: I don't mean to be pretending to be humble. I think what I did then in particular was trying to please people by doing things that turned out not to be sound. And you know, maybe in the long run, they were the right decisions but I think it's better to be strict than sloppy. And it's better to make people write type conversions explicitly than implicitly. So in that case I was an idiot [chuckles]. Otherwise, not.

KENT: Makes sense. It's actually very interesting.

PAM: Yeah. Well, I wonder about you said you did some early user testing and it sounds like a few things might have been going on there, in that, you know, classically in end user testing, you give people what they want; it's not necessarily what they need. And then the secondary thing of oh, how enterprises can destroy the best-laid plans with, you know, everyone's opinion in the opinion wars.

BRENDAN: Both are true. And you know, Perl at the time had and still has, 4.5 has a sloppy sort of double equal operator. It will compare unlike types by doing conversions. It doesn't go as far as JavaScript. It doesn't try to convert string to number. String to number is obviously a lossy comparison because the string foo is not a number. So what happened with JavaScript is it turns into the NaN value of IEEE 754 and NaN is a number, actually [chuckles]. And it's in all our hardware; it's in Java, it's in C++, it's in C, it's in the floating point units and sort of vector units of all our hardware.

So I went a little far I think in converting arbitrary strings to numbers where Perl didn't. But for other cases like Booleans and empty string to false and things like that, JavaScript and Perl were the same. And this was something I pointed on in Stack Overflow. And I often joke, "Oh, it was the 90s. People were sloppy then." But maybe that going a certain distance in that direction was okay. Like I said, it's hard to rerun reality with different parameters and see what would have happened.

KYLE: Since you're specifically on the topic of strings to numbers, I wonder if you remember or could recount for us one specific case which is that the empty string, when coerced to a number, becomes zero. Do you know what the genesis for that or the reasoning behind that was?

BRENDAN: Yeah, I think as I mentioned, Perl does that too. And a lot of languages that deal with form field input do with do that because they want to allow the shortest possible input to turn into the number zero without an error or without nagging the user to type zero. And so you end up, in a lot of cases, with a defaulting sort of a union type where it's a specific kind of refinement type where it's either number or the empty string which means zero. Obviously, I went further and I let any string to convert to a number and I say that's a problem. But that particular case, it was quite popular and it remains in a lot of languages.

DAN: I have a question which is not exactly about the very beginning of JavaScript but more about the middle. The question is that when did you start noticing that people create real applications with JavaScript? Because in the beginning, it was just language to like change a a rollover menu or something like that but then people started building applications. So how did that happen?

BRENDAN: Great question. I've talked about this at least since this past summer in Prague. I talked about some early single page applications built in 1995 and 1996. Netscape 2 was a real platform push as a browser. It wasn't just a browser; it was a platform that scared Microsoft. Microsoft had already offered too little money (I think $100 million or something) to Netscape in late 1994 and then Netscape principals like Jim Clark and Jim Barksdale said, "Get out of here." And then they knew that Microsoft was coming after them, especially when they launched Netscape 1 later in fall of 1994 and started getting huge traction. And it had [chuckles] you know, what in hindsight, was very insecure Secure Sockets Layer for ecommerce. But it was obvious that what the web was going to sweep aside proprietary systems like AOL, CompuServe and Microsoft's prototype sort of knock off those system codenamed Blackbird.

And so, people started building applications right away because in Netscape 2, we weren't just doing JavaScript; we were doing frames and framesets. Eric Bina, Marc's coding partner in Mosaic and first for a Netscape guy, I liked to work with him quite a bit. Eric's retired from programming, as far as I know. I think he's horticulture, second-degree holder from UIUC. His wife's a professor there or somewhere else. And he's raising plants and doing biology experiments. But Erik did frames and framesets which allowed tiled user interface like AOL had in the day. And Marc was very excited about this. And with JavaScript added the framesets and frames, we could do things like JavaScript colon URLs for link href attribute values. You could do onClick handlers, you could automate, even locally without a server, response to a click, you could also do things like XHR by forcing a submit of a hidden form in a zero width and height frame in a frameset. So you could do background I/O, you could do async I/O.

So people like, somebody named Bill Dortch who I've recently reconnected with on Twitter, he had a company called hIdaho Design designs (like Idaho with the ëh' in front) and he built single page applications. And the one I showed this summer in a talk, it's in the web archive from 1996, webarchive.org, it's an art gallery of I think mostly Idaho-resident artists' sort of western art. And it's totally a single-page application like what we would build today except it's frames and framesets which we do not use, now we use iframes or divs or whatever, table layout. And it had its own data that it downloaded that was a catalog of the artists' works. There was no JSON then because I didn't have time until '96 to start doing JSON or what became JSON, which became standardized later in ES3. But you could call "new catalog" or "new artists" to call your own constructor, which would then assign to "this.title" and "this.year" and "this.price" and "this.(whatever description)" to create a catalog of artists' works, including the images that showed the works. And so there was this entire downloaded data set for the art gallery and the single-page application allowed them to navigate through it. And that was all in 1995 and 1996. So it didn't start with Ajax in 2005; this stuff was actually prototyped in ë95-ë96.

TYLER: So going back to those first days, did youÖ I've always wondered, as someone who's kind of doing something that's going to, like, fundamentally change the world, did you realize that this was gonna to be big? Did you have like any thoughts that this was going to be big or was this something that's kind of like something that you were doing to fulfill like a job task or something?

BRENDAN: Well, to tell you the truth, I knew it was important because timing is everything in life, right? If you did something greatÖ I mean, there are awesome languages that have been done at the wrong time and the wrong place. Walter Smith, I believe, did Newton Script, which I wasn't aware of, but showed some similarities to JavaScript through conversion evolution just by being in the same field of force like having been in the wake of Self and thinking about problems in similar ways. I ended up making something that had some commonality with NewtonScript and I knew nothing about NewtonScript. Years later, I found out about NewtonScript.

And Walter Smith, you know, did it and the Newton failed, right? It was the joke in the Simpsons episode where the bullies at the school assembly hear the nerd, Martin, asked some suck-up question to Principal Skinner and one of them says, "Take a note on your Newton: ëHit Martin later.'" And the Newton's handwriting recognition was so bad, the Simpson authors were joking about it because he writes, "Hit Martin later" and it gets translated to "hi Martha bake" [chuckles] And then the bully gets so mad, he chucks his Newton at Martin the nerd and hits him on the head with the Newton. Newton failed and Walter Smith went on to work at Microsoft, I think. I don't know what he's done. He's probably done very well. But he didn't keep working on it.

When I was doing JavaScript, I knew it was at the right time and the right place to not be a Simpsons joke. It was going to be big. How big, I didn't know because it was so underfunded, it was just me there were a lot of quirks and bugs. (There were a lot of bugs, frankly.) But my cubicle mate Jeff Weinstein whom I knew at SGI and MicroUnity started (mumbling) to join Netscape. At one point, we were talking together about what's going to happen to us when Netscape starts to go down. "What are you going to work on?" Jeff was doing security. He took over the Secure Sockets Layer, the crypto module and protocol code from Kip Hickman, my friend from SGI. And Jeff said, "What are you going to do?" And I said, "I'm probably going to be working on JavaScript for twenty years." [chuckles] And I was right.

So perseverance matters. If you're in the right time and it's going to become this thing that spreads virally and takes overÖ like, I beat VBScript. If I didn't do it in a rush, it would probably would have missed Netscape. Not only Netscape 2, but as James Zawiski documented well in his blog, Netscape 3 was originally going to be Netscape 2.1. And what was supposed to be Netscape 3 became Netscape 4 and was a cluster-f of colossal proportions due to Netscape's first four people burning out and Netscape management acquiring a company that didn't know how to do browsers and giving them the keys to the kingdom. And so Netscape 4 was late and Netscape 3 was still my Mocha engine. If I hadn't done that work in 1995, I probably would have missed the window. And I think it's probable that IE3 and then IE4 would have pushed VBScript so hard, that without JavaScript, you'd be writing VBScript. We'd be having a VBScript Hangout and I wouldn't be here.

KENT: Well, I'm glad that you're here. [Laughs]

DAN: I have another question which is it feels like in the past two or three years, there's been more evolution in the JavaScript world than in the past ten years. So what exactly changed? I mean, apart from browser vendors implementing fast engines, what has changed in terms of organization and working on JavaScript itself?

BRENDAN: So the big change for me (and I've talked about this recently too, last like 3 to 4 years, I've talked about it in Strange Loop in 2012, I believe) is that the developer community like ten years ago would say, (and it was a much smaller community) "I wanna write pure JavaScript." Like the fake Twitter account @realDonaldJS, they would be saying "I want to make Vanilla JavaScript great again." And they would not want to run any tools; they didn't even like running a linter and they certainly didn't believe in build steps. They did not have the automation we have today that we take for granted like Gulp.

That's changed. And I think now compiling, especially like BabelJS is here to stay. And it allows us to smooth over the differences in recent browser versions, as well as handle some older versions. And since browsers are now all evolving faster, even Microsofts' evolving faster, it's going to continue to be an important factor. So compiling, even if it's from ES6, which is a standard from the future, (it's not finalized), module or errata is here to stay. And that sped up the pace in evolution dramatically. And beyond that of course we have more languages compiling to JavaScript. And then there's WebAssembly which I'm sure we'll talk about later.

KYLE: Since you're talking about transpilation, so, we saw with ES6 that most of the features in ES6 were expressed in terms where they could be pretty directly transpiled to ES5 equivalent. But I've seen several proposals for ES2016 and beyond that are suggesting features which are basically whole new primitives that can't really be transpiled to older versions. I'm curious your perspective on the direction the language ought to takeÖ

PAM: Can you give an example of such a primitive?

KYLE: Yeah, so there were things in ES6 for example like proxies have no previous thing so they can't really be transpiled. But there are several proposals that are being talked about that really can't be built on existing, even ES6 primitives. So I'm just curious if you have any perspective on that direction of evolution for JavaScript.

BRENDAN: Sure. So by the way, in ES6, there are also not just proxies but modules have aspects that can't be expressed in ES5. And things like super in classes, class hierarchies. But you know, in every language, there is what you might think of as the kernel semantics; the irreducible set of primitives. And then are affordances built around those primitives that are composite or you know, composed of primitives together. That's natural. You need a language to be usable. If it only has the primitives like Scheme without macros, it's pretty hard to use. And that's why macros are used (like I said early on) to make affordances usable, APIs, veneers on top of things like call/cc in Scheme.

But JavaScript always has had to be usable, so it always has had composite affordances. In fact, because I did it in a rush, I made some of the "primitives" the parts that were irreducible, that couldn't be broken apart into smaller parts, composite. Functions were composite; they were used as constructors and procs, top-level functions, procedures. They were also used as lambdas or function expressions and they were used as methods. You might think of four different forms that could be used to split those out into a narrower set of primitives. Some of them would bind this automatically for you like in a lexical way, like arrow functions do or if it's a method, they would bind in a dynamic way.

But I didn't do that. I did functions and they were big fat composite, pseudo-primitives, quasi-primitives. And I did it because I was in a mad rush. And I did objects similarly too. Objects could be like dictionaries in Python but they also had a prototype chain, so you could get dictionary namespace pollution from the prototype, which everyone knows about. And that was powerful on the flip side because you could use the prototype to add methods and share constants (mostly methods) and do sort of classy or even purely selfish prototypal programming.

So JavaScript needed to have not only a kernel language within itself that had more reduced primitives that were truly minimal. And also, it needed to be larger in the sense that it had missing primitives that weren't there at all, like modules. And sure, you can rig up modules as the CommonJS folks did. And it's great that they did that because we like people paving thoseÖ blazing those trails, let's say we have like the cowsÖ I don't wanna switch metaphors too much but the cows should step on the cow paths first before the standards body tries to pave them and turn them into Boston's streets. [laughs] I think Boston's a nightmare to navigate because they paved the cow paths. But that's better than designing by committee where they often get it wrong and they build a superhighway to nowhere. [chuckles]

So if you buy all those metaphors and you can forgive me for calling developers cows, I like that the CommonJS blazed that trail, but at some point, you have to say, "let's add the primitives because they have certain properties that you can't enforce in the dynamic composite form that you created on top of JavaScript's older primitives."

So JavaScript's kernel language is growing. ES6 is growing. Proxies are a new thing, couldn't be expressed in ES5. And there's a few more things to add ñ not many ñ and I think the kernel will stop growing at some point. And WebAssembly will also help take the pressure off JavaScript's kernel language, to serve two masters: to both be a great language for human coders where you might grow the kernel language inside JavaScript just for those human coders; and a great language for compiler writers where you may have completely independent needs that aren't particularly great for human coders.

KYLE: You said that you think it's going to stop soon. I have to push back a little bit because it seems like there is a never-quenching thirst for pushing JavaScript classes. And in particular, when I was asking the question a moment ago, I was thinking about some of the new proposed things like the privileged or private visibility in class chains which is going to use, you know, internal properties in interesting ways, I guess I'll say. So do you think that classes themselves will kind of settle down or is this where everybody is going to shove new features into the language for a while to come?

BRENDAN: No. First of all, it's hard to keep shoving new features in it. As a language matures, it just gets more difficult to reconcile them with the existing kernel primitives. And the committee is acutely aware of this because a lot of people in the committee are implementers. And as I've said in recent talks, some of them were getting to be a little cranky about all the burden of implementing ES6 features. But what's happening with classes is we're actually codifying not just the pattern that people wrote with function constructorsÖ the constructor pattern, let's call it, sometimes it's called the prototypal pattern. We're also considering like Yehuda Katz' private data proposal because the engines already do this for the built-in objects like the DOM objects. And a lot of those objects are now self-hosted like V8 with a magic extension language built on JavaScript. They're written in JavaScript with some extra syntactic magic to allow you to reference private fields, which cannot be accessed outside of the module or scope in which those private fields are defined and which efficiently map into directly addressable slots in the object.

So I think that's legit. I think that's bounded. It's not going to turn into like another endless quest for, you know, more object-oriented features. And it really is. in some ways, trying to allow JavaScript to self-host the host objects, the DOM in particular, that it always wasn't this [?] in JavaScript, this magic, you know, backdoor into C++ where you get objects that didn't behave like a Vanilla JavaScript object would. They had private state, they had magic intercession capabilities, getters and setters and beyond. And I think it's fine to extend a mature language with the kind of metaprogramming and efficient private state kernel features that are missing in that regard. I think once you do that, the door closes. So I'm not too worried about this being a runaway train.

KENT: But how do you draw the line then between saying like you're saying adding those features in the language for those that, you know, those language affordances for various use cases like the self-hosting and the WebAssembly stuff. (So I'm jumping forward now because I know we're going to talk about that.) How do you draw the line and say, "It ought to be added to the language" or "here we have this other side door, maybe some of that stuff should come in through that door instead."

BRENDAN: So there's two ways to answer that: one is, would the human authors of JavaScript, benefit in significant numbers, fromÖ do they have a use case that we need to serve with better kernel primitives and better affordances that are composite? And that I think actually can be answered independent of the WebAssembly question. In the case of private data, I think the answer is yes. I talked to people at dotJS about this and they want not only private data; they want TypeScript or Flow or something like TypeScript. And that's going to be harder to standardize. It may almost be tool time, it could be a separate spec built on top of the ECMA-262 spec. But I think that's legit.

But you make a great point; if WebAssembly's here already in all the browsers, certain things, certainly threads and shared memory, and possibly SIMD. The case for SIMD in JavaScript is pretty strong independent of WebAssembly. But also things like, guest host stratification where you can put a language in WebAssembly that has its own garbage collector but doesn't create uncollectable cycles because it actually hooks into the JavaScript garbage collector before it actually uses JavaScript garbage collector. That's all on the road for WebAssembly. That probably shouldn't go into JavaScript. And if we had WebAssembly now, I bet we wouldn't be entertaining a proposal for threads and shared memoryÖ shared array buffers in JavaScript.

I wrote a blog post in 2008, I think called "Threads Suck," where I said we would never add shared memory threads with data races to JavaScript and yet, we're considering this proposal very carefully made because we lack WebAssembly in older browsers. But WebAssembly, is on a fast track. There's prototypes in V8, Chakra and SpiderMonkey and I think depending on Apple's secrecy, even in JavaScriptCore. So I bet middle of next year, we'll start to see some WebAssembly decoders shipping at least in nightly builds are flagged, so you can actually generate the bit coded syntax for WebAssembly which is much more concise than JavaScript and load it into the same one VM that everybody implements for a spec. And that's where the opportunity arises to do things, new syntax for new semantics in WebAssembly and not expose that to JavaScript.

But this is a sort of tricky pragmatic, as well as philosophical question because we're racing between getting WebAssembly out and sending JavaScript. Do you do it in both? Do you do it only in WebAssembly? Some people think JavaScript should have every affordance WebAssembly has. I early on said for usability and human coders, JavaScript should optimize in ways that might exclude things compiler artists want, so I do see a bright line where certain things should only be for the compiler writers of WebAssembly and those syntactic expressions should not map onto semantics that are exposed through JavaScript expressions.

DAN: I have a question about the future. Can you imagine how an application might look in ten years' time? Like, what is it able to do with threads and so on? How does that fit together?

BRENDAN: Yeah, some things are immortal; like UNIX is immortal. In the old days, UNIX was processes, not threads but we had this pool of threads. And threads get overused but they have some uses and I'm thinking of game engines that you know, have to have a big scene graph that's shared among threads that pragmatically farm out the work across cores. And there's no a priori, no declarative way to say to say, "This part of the screen graph is for this thread and this part is for that thread or this core and that core." You end up doing it dynamically on the fly. You use sort of work-stealing schedule and other techniques. And then you parallelize using SIMD and of course, GPU through OpenGL or WebGL.

So, I think we will see WebAssembly emerge as an important transfer syntax, let's call it, akin to JavaScript. Two syntaxes, one VM. And the one VM is important otherwise you get garbage collection cycles and you get the cost of guest hosts or mutually conflicting host-guest conflicts between two VMs like the Dark people were facing when they're trying to port Dark VM into Chrome, which they've ended. So it's a critical evolutionary step for JavaScript to be a language that has a very detailed specification and a common source language which everyone can use. But then to go to a second source language, WebGL which is a binary language and have that be efficient and adapted, I think will happen.

And a friend in Mozilla said, "WebAssembly is going to be in the hardware, man." And that I believe. So in twenty years, I bet we'll see some kind of flattening of WebAssembly, optimizing, I don't know if it will be ARM or Intel. I don't want to speculate that far or their licensees. But this stuff is going to be here for the long run and it's going to map to all the hardware features ñ which means threads, SIMD, GPU, you know. Even OpenGL 4.5 or whatever, as powerful as it is, it doesn't quite get all the computational power in the GPU, the teraflops of parallel floating point units to things like SPIR-V and Vulkan coming out of the Khronos group that are worth looking at that go well beyond the OpenGL or the subset that is WebGL, which is itself is trying to move to WebGL 2.0 based in OpenGL ES3. Just extrapolate that conservatively and you'll see a world where portable safe code that doesn't have array buffer overflows or stack overflows or obvious security problems can [?] the entire functionality of your awesome hardware.

KENT: Hey, Brendan, thank you so much. I think we are winding down on our time and we wanna be respectful to you, the panelists and our viewers, so I think we're going to start wrapping things up. We do have quite a few questions on Twitter for you, so the discussion is not over [chuckles]. So the first question that hasn't been discussed necessarily during the show is from Jason Trill he asks, "What are your thoughts on static typing in JS? Will we ever get static typing in the runtime?"

BRENDAN: So we've debated this in the committee. And well, first of all we're not going to rush it in because that would be a mistake. We have to have things like TypeScript and Flow which are static type systems that produce warnings in your tool but which generally, outside of their check modes, generate JavaScript that can then have runtime errors that a real static type system would not allowÖ [disconnected] Öglobal inference so we don't have to write so many type annotations. We need these experiments to be adopted and used and sort of de facto standardized before we put anything into JavaScript.

The other thing I would say (and I said this in dotJS) is we might end up writing for a standard type system but it might not be in the browser, it might be a Tool Time type system just like TypeScript and Flow. And that might be enough because it will tell you when you misspell a property name. It will tell you when you made other obvious errors. It will find even more sophisticated errors using its more sophisticated control flow analysis. And that could be a separate spec from ECMA 262 and that could be enough.

What we know from academic research in dynamic languages like Racket which was originally called PLT Scheme which was an academic version of Scheme, was that people have done things like Sam Tobin-Hochstadt did Typed Scheme now Typed Racket, or typed PLT Scheme. And it used the module system to do a statically typed language inside one module and you can have another module that was purely dynamic, Racket. And when they interact, values could flow through into the statically typed module, that would violate the type checker but they would be wrapped in a proxy, essentially, a chaperone or one of these other Racket proxy-like things and you'd get dynamic errors. So you would still not run code that had type errors. You would fail at runtime. Kind of like JavaScript today where errors were at runtime.

So it isn't clear that we can actually benefit by putting the static checker into the browser into the runtime. It might be best at tool time. It's also the case that when you add the static checker, just like when you add other static metaprogramming like macro processing into the browser, you're going to slow down the browser on certain benchmarks. And no browser vendor wants to slow down on the benchmarks, so it's going to be hard to add the static checker or I would say even macros like SweetJS to the browser, but they might end up being viable Tool Time standards.

KENT: Cool. That is a very interesting answer, thank you. The next question is from Alex Booker, "Was it surprising to see JavaScript on the server (Node) become so prevalent? What do you think about NodeJS in general?" And I think it's kind of part of your original plan, right?

BRENDAN: Sure. So LiveWire was JavaScript on the server at Netscape in 1995. Did not succeed. Netscape's entire [chuckles] business was crushed by Microsoft. The browser became free with IE being bundled with Windows ë95 and ë98. And Microsoft copied a lot of the Netscape servers and Active Directory killed the LDAP server that Netscape bought from the University of Michigan, I believe, as ateam.

So JavaScript on the server is not a new thing but when Node came out, I think Ryan Dahl, (again, timing is everything) hit the right time to make it really simple to create sort of I/O-bound, very efficient servers. My Python friends pointed out that it's easy to make a short Python server and they're right but JavaScripters could do it. And people writing JavaScript on the client and then they go full stack to the server and that's super powerful. So obviously, Node was huge for JS and it's still huge. And I'm still excited about what can be done there and it's still evolving.

KENT: Absolutely, yeah. And it's totally enabled all these cool tools that we use that have totally changed the face of frontend and backend web development, so I'm excited too. Next question, I'm so sorry I can't pronounce his name "shaneckel" he asks, "Do you have any opinions on Swift lang or more generally how you think the divide between apps/browser will go?"

BRENDAN: That's a good question because couple of observations: one is that Chris Lattner of LLVM and Swift Language fame, in his personal blog (Apple marketing never would have acknowledged this) but in Chris' personal blog, he credited Rust as the first or second influence on Swift. And I was the executive sponsor of Rust in Mozilla, and both Swift and Rust are built on LLVM, Chris' compiler framework that he lead starting at the University of Illinois in Urbana-Champaign. So there was something going on with LLVM (kind of misnamed because it's not so much a VM as a compiler backend framework) being a powerful way to cross-compile static languages or let's say lots of languages that have frontends for LLVM to the web. That was demonstrated first by Alon Zakai at Mozilla, the creator of Emscripten. But if you think about it, going from C++ to JavaScript or ASM.JS or WebAssembly to Emscripten or one of its successors or modes, is it's not that much different from going from Swift to LLVM to JavaScript. So I think that we'll have a general cross-compiler instead this n-squared problem of different compilers having to map different target languages including the web. We'll have LLVM as the central multiplexer for source languages to target languages including JavaScript and WebAssembly. And that will make, Rust even possible on JavaScript as well as Swift.

KENT: Very cool. Well, the future of JavaScript in the web is bright. Next question from Ville M. Vainio, "Where do you see shared memory multithreading for JS going in the future?"

BRENDAN: So I said it would happen over my dead body. I'm not dead yet. My friend Lars Thomas Hansen has proposed it. He works for Mozilla but he's working with Google people. He's proposed that as an extension of JavaScript via shared array buffer and Atomics object, the top level global object called Atomics, that has what you might think of as spinlocks and mutexes and Linux's fast user level mutexes, condition variables, since you can build with those things.

Lars is proposing this because WebAssembly isn't here yet and people want to write Unreal Engine 4 and across compile it from C++ and Pthreads and OpenGL and OpenAL to JavaScript and WebGL and WebAudio. And for threads, there's nothing right now. Workers are these isolated things with a painful API. So if we added what Lars is proposing working on it with other people including at Google, to JavaScript it can be done pretty quickly but we're in a race with WebAssemly. So part of me (and I'm really torn about this), wants to have the WebAssemly to be the only answer for shared memory threads. But part of me sees the pragmatic appeal of what Lars is proposing. And I don't know what's gonna to happen. I honestly don't. If WebAssembly gets done fast enough, I think it takes the pressure off everyone to put what Lars was proposing into JavaScript. And that's the perfect example of what I said earlier that the human coders benefit by leaving out the possibility of data races and shared memory for all time from JavaScript.

KENT: Cool. I am really sorry, there a couple more questions. I just don't know if we're really going to be able to get to them all and still wrap things up. [chuckles]

BRENDAN: Three more minutes. I have three more minutes.

KENT: [Chuckles] If you don't mind staying on, I don't mind keeping it. Anybody can jump off at anytime if they'd like to but I really would like to respect everybody's time. So I'll just askÖ I think there's a question somebody asked on Google+ Hangout page that I think would be really interesting to hear you answer. The question is "Where do you see JS in the next five, ten or twenty years?"

BRENDAN: So you know just getting ES6 done and still not implement it fully, though with Chakra which is open sourcing Chakra Core is like +90% done. It's going to be a big deal and it will take time for people to absorb that. But every time I go to conferences more and more hands go up when I ask who's using BabelJS. That's going to go for a while, you know, ES7 async function, async await, great affordances that people want. Maybe the private data stuff, we'll see. We'll make sure it isn't the wrong thing.

I think in ten years, it's hard for me to predict, my crystal ball doesn't go that far. But I do think WebAssembly will then start to be used a lot. Like right now, Facebook has a significant number of game studios, launching games a lot of them based on the Unity engine, you know, tool, that are cross compiled to ASM.JS and WebAssembly. They simply load faster. They load a lot faster because even with gzip, the concise syntax wins. They take less memory when load because you don't have to expand them into JavaScript or deflate them into JavaScript and parse that. ASM.JS is bigger than WebAssembly, inherently.

So I think that's going to be huge and that's going to take a while for the ecosystem to absorb. And when it absorbs it, we'll get inevitable requests for more features. Like more with GPU features like WebGL is based on OpenGL ES2 which is pretty limited and old; not many shader programs and not many features. People want to use GPU for general computations. So there's a common extension to OpenGL called compute shader. That would be wonderful to have in JavaScript in the safe way, but that seems to be beyond our current standards' horizon. I think that will be big in the next five to ten years.

KYLE: There's a question on Twitter and I wanna make sure we don't miss this. I think this would be really good even to wrap up on, perhaps. Nicolas O'Donnell had asked, "Brendan, what are your tips for somebody starting out learning JavaScript?" I mean, we've talked about this amazing language and all the future; how do people get into it, in your perspective, most effectively? Do they start with the frameworks? Do they start with the language itself? What are the resources or tips you can give?

BRENDAN: So I was accused by Yehuda Katz on Twitter for being behind @realDonaldJS Twitter account and @realDonaldJS wants to make Vanilla JavaScript great again. I am not behind that account but I do want to people to learn JavaScript. I don't think they should just skip it. It's sort of like in the old days, people should learn assembly or in the 80's learn C code at least. And I think there's still value for some people to do even that. But learn JavaScript and learn NodeJS and write your own services as well as clients, write your own Gulp customizations. And really learn the sort of the groove of the language.

I worry about things like Meteor. I have a friend who works there, Ben Newman from JavaScript Standards Body from TC39, but these tend to be sort of closed-world sort of enterprise-oriented tools that suck people in. Angular has this flavor too, not to beat on it. I like compositional libraries, I like programmers to learn the native language before they learn some, you know, sort of constrained dialect.

KENT: Cool. That's a good tip. Thanks, Kyle, for bringing that up. And I think that's probably a good one for us to wrap up on. So we're going to go ahead and we're going to speed through these tips and picks. So if you have more than one tip or pick, just pick your favorite and we're just going to do one. And then in the show notes in the audio podcast, I'll put all of your picks so don't delete them from the doc but just on the show, just pick one. So, Brendan, why don't we go ahead and go with you. I hope we've prepared you for this a little bit but do you have anything in particular that you'd like to pick or any tip that you'd like to give to people?

BRENDAN: That's a good question. I mean ESLint is a huge and we're using it and there's a great talk by Elijah Manor about how to use it well that's on YouTube.

KENT: Sweet. If you can maybe find that link, we'll add it to the show notes. ESLint is the bomb. Cool. Lin, I think you're up next.

LIN: Sure. So this week, I was working with some folks who were using web pack for the first time. And they were looking at a larger-than-expected file size coming out of webpack. And I suggested using dead code elimination, which was new to them and that reduced their file size in half. And so I just wanted to make sure that people know that there is a thing called "dead code elimination." It basically eliminates the code that your program is never going to touch anyways. So check that out to see if your tool has dead code elimination. And my pick is actually Dan Abramov's series on Redux on egghead.io. We are using redux on Firefox dev tools, and so there are a lot of people who are new to it on that team and those videos are going to be great for them. So thanks, Dan.

DAN: Thank you!

KENT: Awesome. Brian, why don't we have you go next?

BRIAN: All right, I guess I have an obligation to shout out to ForwardJS in February. You know, Kent, you're speaking, right? [chuckles] And we got Kyle coming and I think Tyler will be there and you know, everybody else should show up. So we should do one of these there. That's all I got, ForwardJS in February.

KENT: Cool, thanks. Dan, what do you have for us?

DAN: I don't really have any picks. I'm so overwhelmed the first week, second week at Facebook. So I'm like starting Mercurial and not really looking at JavaScript. So I don't have any picks right now.

KENT: Nice. So was that like an anti-pick for Mercurial? [chuckles]

DAN: Yeah. [chuckles]

KENT: Nice. Kyle, do you have any picks for us?

KYLE: Yeah, just one and it's very timely. It's happening like maybe even today in some of your cities. Hour of Code. If you're not aware of that, you should go check out, go look up Hour of Code. It's an initiative to teach mostly targeted to high school students but to teach people about coding, an opportunity to volunteer your time to help somebody else learn. So I think everybody should to take that. I especially would remind you that you don't really know something until you've taught somebody else. So that's a great way to do it.

KENT: That's awesome. Really solid advice. Matt Zabriskie, what do you got for us?

MATT: I was at a Last Call JSConf last week and I don't know how to say his last name, Earle Castledine, announced that his company is releasing something called gl-react where you can do in-the-browser WebGL or on like Rack Native's, OpenGL. Pretty cool project for React. I thought it was pretty neat. As far as tips, I mean Brendan kind of already hinted at this anyway, but as we talked about the past, present and future of JavaScript, just a plug for BabelJS, where it kind of allows you to use the future of JS in your apps today. If you're not already using that, you should definitely invest some time and look into it.

KENT: Awesome. Thanks. Pam, what do you have for us?

PAM: All right, well, I'm actually going to change my pick from what I wrote down so that it's more JavaScript-y. So I'm going to pick RxJS Next, so the next version of React extensions for JavaScript so that they get a shout out on the first episode of JavaScript Air. And I also +1 to Kyle's Hour of Code. I did an Hour of Code with a bunch of people today and it's really great. So if you don't get to do it this year, definitely try to work with your local community to do it next year.

KENT: Cool, thanks. Tyler?

TYLER: Two picks: I just added my second one. So, the first one is going to be Matt Zabriskie's beard because it is looking really good today. Second one is this really cool game called Flexbox F4oggy. Basically, it allows you to learn Flexbox as you're playing this cool game. So I don't know who made it, but it's awesome. So who ever made it, thank you.

KENT: Cool, yeah. Plus one to Matt's Zabriskie's beard. It has a twitter account. It's so awesome, so check that out. For me, just really quickly, I highly recommend that you just learn JavaScript. I think that's really valuable and Brendan touched on that. So MDN has some fantastic resources. I'm making some Egghead.io lessons based off of some of those articles to talk about you know, raw JavaScript APIs and DOM APIs. So learn that. And then my next pick is plop. It's a Node module that is super awesome. You should check it out. It helps you generate codes, like you can generate all the files you need for your React component or Angular directive or something. So that's that. I think we're going to wrap up.

So let me just give a couple final announcements and then we'll all say goodbye. So if you have any suggestions for future shows, we do have shows coming up but you can go to suggest.javascriptair.com and it will take you to the form you can fill out to suggest episodes and guests. If you have any feedback for us, feedback.javascriptair.com, that will give you a Google form to provide us with feedback. We'd appreciate it. And as always, follow us on Twitter, Google+ and Facebook to keep up with the latest.

Next week's show is at the same time, same place (hopefully on time), about "Learning and Developing JavaScript" with Ashley G. Williams and Kyle Simpson. And that's our show. Thanks everybody for tuning in! Thank you very much Brendan for taking the time to be on our show with us and answer all of our questions. It's awesome. Thanks everybody!

LIN: Thanks!

DAN: Bye!