KENT: And we're live again with JavaScript Air. So just like a half hour ago, I finished up this morning's bonus show about Yarn, and we're doing our very last show of JavaScript Air for now, Episode 48, JavaScript and the Web Platform. We're joined by Brendan Eich who created JavaScript, and that's pretty awesome. So we're gonna be just chatting about some of the cool things that are ahead for JavaScript and the platform and some things that are exciting about this amazing platform.

So before we get into that, I just want to give a shout out to our sponsors that have made many of the awesome things about this show possible. I'm so grateful for them. That's Egghead.io, the show's premier sponsor, has a huge library of bite-sized web development training videos. Check them out for content on JavaScript, Angular, React, Node, and more. Egghead.io is also the host of two free Redux courses from Dan Abramov. Find them at Egghead.io/Redux.

And Frontend Masters is a recorded, expert-lead workshop with courses on advanced JavaScript, asynchronous and functional JS, as well as lots of other great courses on front end topics. Check them out at frontendmasters.com. Also a huge shout out to them for this new thing where all subscribers have access to all of the workshops, like the live workshops. So there are no longer tickets for the workshops, just subscribers can go, which is pretty cool.

And then TrackJS reports bugs in your JavaScript before customers notice them, and with their telemetry timeline... How do you like that, Tyler? "Telemetry timeline." (laughs)

TYLER: That's a tough one. I messed that one up last episode.

KENT: No, no, I messed it up for like the first three episodes, so yeah. Telemetry timeline, it's pretty awesome. You'll have the context to actually fix them. And actually, if you haven't seen the telemetry timeline, go to their website. I'm pretty sure there's a demo there. It's pretty cool. Check them out and start tracking JavaScript errors today at TrackJS.com.

All right, so for this show, it is the last show for the foreseeable future. If you're interested in learning why and that kind of stuff, I have a blog post if you go to jsair.io/sunset, that'll explain why I'm sunsetting the show. But yeah, we have this show today, and it's gonna be great. If you do have questions while you're watching live, use the hashtag #jsAirQuestion on Twitter and I have that open and I'm watching, so feel free to ask questions. We'll answer those toward the end. And yeah, still follow us on Twitter. Even though the show is sort of ending, if I do start it up again, I will start tweeting, so that'll be the best way for you to know that the show has started up again. And yeah, that's pretty much it. So let's go ahead and get an intro. We might have a panelist or two show up part way through the show, but we do have Tyler McGinnis for our panel.

TYLER: Hello.

KENT: And again, I'm your host, Kent C. Dodds. And for our guest we have Brendan Eich.

BRENDAN: Hey.

KENT: So Brendan, why don't we give a quick intro to you, who you are, what you're doing, especially for people who may be new in the community who don't know who you are yet.

BRENDAN: Hi, I'm Brendan Eich. I created JavaScript and Netscape in May 1995 and I've been working on it ever since. I also founded Mozilla.org in 1998, and we took it independent in 2003, did Firefox. We started the browser market, we started HTML standardization with the WHATWG, we started ECMA standardization of JavaScript, and the rest is history. We kind of made the modern web happen, and I was a big part of it. And now, I think it's important to keep innovating on the web and doing things that give you just control of their destiny on the web. And so I'm doing a company called Brave Software. We have a browser on all mobile and desktop, laptop operating systems that blocks third party ads and trackers and protects you and your data. And we hope that that turns into something big with your help.

KENT: Awesome. So already so many questions that I wanna ask. That last little bit you said, "With your help." I'm curious, can you talk a little bit more about the Brave browser, what its goals are, and how people can get involved in helping?

BRENDAN: Yes, so I'll talk about what it is first. So Brave is not just yet another browser. It is on all the operating systems we know and love. It's based on sort of standard and as much as possible open source code, like it's all open source on Mac OS, Windows and Linux, and on Android it's based on the open source Chromium Project code, which you can pretty much build a browser from. So it's all open source there as far as I know, except for things like the video decoders and stuff like that. And on Mac OS it's based on UIWebView, which is the old webview, but it's the one that gives you all the control over network request level blocking, and HTTP to HTTPS rewriting, things like that. So it's open source, so that's one way people can contribute. But the really big idea with Brave is beyond just an open source browser. We've got three of those. Maybe even three and a half, because Chakra core in Internet Explorer Edge is the Microsoft JavaScript engine, and it's open source now. Maybe someday they'll open source Edge, it wouldn't surprise me. And then you'd have four open source engines for the big browsers, and things like Servo from Mozilla coming along.

What's really different about Brave is that we're trying to solve a problem that was an accident of history when-- and I said this at a talk in Vienna last week, when Marc Andreessen and Eric Bina added the IMG element to HTML in 1993 in Mosaic before Netscape, you can find Marc's post about this that said, "Hey, we wanted to add images to HTML, so we did it." The IMG element. You just can embed an image. You can link to your image even from another site. Why not, right? Everybody loves cat pictures. Your friend has cat pictures. You want to hot link them from your site. It's hot linking because if 10,000 friends do that and they all reload their page at once, your server melts down. But anyway, it seemed like a good idea at the time. So images were born, and they could be embedded in HTML but located on a different server.

Then in 1994 at Netscape, Lou Montulli created the cookie. And I think the reason he did this, I wasn't there yet but from going there soon after I heard and saw the code, the idea was to prevent you from having to login every time you went back or restarted your browser and you had a session with a site that knew about you that you authenticated with. Because HTTP was stateless, there was really no way for the site to remember you again. And so cookies were invented to sort of cache your authentication credentials. And it's a little bit of storage for that site in your computer on your resistance storage, your hard disk in those days. And it's sent with every request, and the server can send back an update to the cookie, so it's this little bit of state that can sort of track the site. And in the sense of keeping your login credentials, that tracking is good. That's keeping track of you so you don't have to keep typing your username and password over and over, which kind of gets to be a drag.

So suddenly, just between images and first party cookies, tracking via third party cookies was created, because if you think about it, you can put that cat image on NewYorkTimes.com and on ESPN.com loaded from MyCatTracker.com. And when you go to New York Times, if you haven't been there before, you load that cat picture, it can set a cookie. It can see that there wasn't a cookie already remembered for you, and it can say, "Hey, this looks like a new user. I'm gonna give them number 1234," and that cookie is associated with MyCatTracker.com. Images get cookies, everybody gets cookies, all requested cookies. Now you go to ESPN.com. My Cat Tracker's cat image is embedded there, too. It's maybe embedded with a different URL path name or query, so you can sort of tell if you're My Cat Tracker that it's embedded in ESPN and not New York Times. That's the way that the Cat Tracker site can tell which embedding it was answering that image request for. But now it can see, "Hey, there's a cookie, my cookie, my third party cookie, that has user ID 1234. So I know that user ID 1234 was at New York Times first, 'cause I saw that request and I remembered it in my database. And I gave that user that number 1234. And now, I see the ESPN URL loading that same image, and therefore the same cookie is being returned, is being sent over with the request by the browser, 'cause the cookie is associated with MyCatTracker.org." And sure enough, tracking was invented. And this was not intended as far as I can tell. It was used right away though, because everything on the web gets used. Every single thing -- unintended APIs, accidental serendipitous wonderful discoveries that are useful or dangerous or both, they all get used.

So third party tracking became a thing, because if you think about how advertising on the web works, publishers want to know about you to get the best promotions in front of you. And publishers generally aren't the same as advertisers, marketers. I mean Amazon is, and they know a lot about you and they have a great site where they can market things to you based on just your behavior within that site. But a lot of publishers, like a small blog or even a medium-sized news site, they don't know everything about you because they don't see where you go on the web. But third party trackers can try to get their (laughs) essentially their cat pictures, it's really not images anymore. It used to be that they would use what's called a pixel. It was a one by one image and they would embed that, and you couldn't really see it 'cause it was so small. And now they just use scripts. Because in 1995, I invented JavaScript, and JavaScript can be loaded remotely since 1996, and therefore, JavaScript can do things without even any pixels to track you, and that's how modern tracking works.

And the point of the story is is not that tracking is all bad or all good. I think it's generally kind of bad, it's kind of shady. It wasn't intended, and therefore there's no control over it. There's no way to, as a user or a web developer, to really express it as a clearly intended thing. It just kind of falls out of the image's cookies and scripts that we have as basic building blocks. So there's this problem that the primitives are too low level, and they let... they're tools that allow good or bad to happen. The trackers also could say they're doing good because they're trying to build up a better idea of who you are, so that a small or medium publisher can go to what's called the buy side, the marketing side of ad ecosystem and say, "Hey, I need good ads. I need to make some money so I can pay my server bills, pay my editors and writers. Can you get me good ads?" And the buy side will say, "Here, put this script in your page and it will help track your audience, your users. And because that script comes from a third party that's embedded in a lot of other sites, we'll know a lot about them. We'll have a dossier on them compiled from ESPN, New York Times, and all the other sites they went to."

Okay, well that helps the publisher maybe get better ads, maybe not. I mean, we've all seen how advertising tends to go in these sort of boom bust cycles, where at the end of it you have too many ads and they're bothering you, they're retargeting you or they're showing you parasite pictures or around the web pictures or pictures where you see something that you wanna see and you click on it and you get a listicle with 20 pictures and none of them is the one you saw that you clicked on. That's annoying. And the retargeting is kind of creepy. It can like ruin your children's birthday present if you're shopping after hours when they're in bed and then the next day you're going somewhere and you get retargeted for the ad for the gift you got for them, even though you already bought it.

BRIAN: That happens too in the opposite way, like some random ad will come up and my family will be like, "What have you been looking at?" I'm like, "Whoa!" (laughter)

BRENDAN: Yeah, it's not very precise. The claim that the trackers can build a dossier on you, it sounds very fancy like a spy novel. They often don't have more than a few bits to rub together. You can go to Autotrader.com, and suddenly your cookie does an auto intender, and you go to any site after that and you're starting to get these Ford ads and it's like, "Am I buying a Ford? I don't think so." But worse than these annoyances and the sort of clutter that happens as the annoyances don't generate the payments, the performance, the revenue that the publisher wants, so that the temptation is to add more ads. The really big problem here is that you lose all your data to these third parties, and they take advantage of that. They do things like pairing your online dossier with your offline identity.

I heard about this recently, there's something called Circulate. You put it in your website, it's this third party tracking thingy script. And it looks for email addresses in form submissions and it hashes them, does a cryptographic hash of them, and tries to remember them. And eventually, I think it can match make you with real email identity. And there are similar things that will sync you with your Facebook identity, your credit card identity. I don't know if you've had this experience, you go to a brick and mortar store, you buy something and then you go home and you get ads for it. (laughs) It's like, "Whoa, how did they know that?" There's a little credit card ad tech module at the point of sale, and it sends a signal to some server and there's some back channel where this is all synced up.

That's getting out of hand because it starts to identify you individually. So now not only are they deciding that you like sports or news, they're deciding who you are down to your home address. And that can be abused not only for marketing, it can be abused by criminals and governments. And it is. So the final straw for me was when I realized that malware was getting in through what are called ad exchanges, because as this ecosystem evolves between the marketers who spend money to advertise brands and consumer goods and services, things like that and the publishers who provide the space for the ads, in between those two sides of the ecosystem, a bunch of algae and shrimp and all sorts of snails and other things you get taking over your aquarium, your child's aquarium, happen to come along and fill in and try to take advantage of the money flowing through. And that enabled some predators to come in. And they, I kid you not, this is part of my talk in Vienna, they set up fake ad agencies and they buy cheap ad space, like 40 cents per thousand impression ad space, which gets onto the top sites, like The New York Times had this March, BBC Online had this in March, and these cheap ads actually have malware payloads in them. Sometimes they're very cleverly disguised, like AdGholas, which is think gholas from Dune.

There was a great analysis of AdGholas malware malvertising by Proof Point, and I used an image from that, with permission, in my talk, because it showed that there was the publishers and their happy websites and behind them were the ad exchanges from OpenX, AOL, Yahoo and others. The ad exchanges are like auctions for real time placement of ads. When somebody has got the dossier on you through third party tracking and the publisher has embedded their script, a call goes out to the ad exchange and says, "Here's the cookie. Can you find me the best ad for this person at this moment in the context of this publisher's site?" And then the ad exchange says, "Okay, I've got some ads. I've got some space. Can I get a deal? Do I hear 40? Do I hear 45? Do I hear 50?" They try to get the best pennies per thousand impression rate, or whatever the measure of performance for the ad is. And the criminal gangs are willing to throw money at this, like 40 cents per thousand impressions and they sometimes win that bid. And when they win that bid, the payload comes in. It looks like an ad, maybe it feels like an ad, there's nothing overtly obviously wrong with it.

In the case of AdGholas, the malware loader script was I believe hidden using steganography, which is kind of like cryptography but less mathematically irreversible. It's more like it's just hiding messages or signals inside what looks like noise. And if you know to look for it you can see it. And so the malware loader was hidden inside the image, and a little bit of JavaScript that was probably like pretending to be gamma color correction or something, would pull that malware loader out of the image after the script had loaded on your page as part of the ad. So suddenly, you're on The New York Times and you're getting pawned, right? The Angler Exploit Kit from The New York Times incident would attack vulnerable plugins like Flash and Silverlight. And I don't know if you noticed yesterday, there was bad news for Windows and Flash. Yet another patch for a remote code execution vulnerability in Flash. If I had a dollar for every one of these, I'd be a billionaire. And they're not going away.

So that's what happened. Malware came into this very permissive, deep, kind of fraud-prone ecosystem. And I say fraud-prone because there's another problem besides the criminal gangs, and the annoyances, and the clutter and the money going out and your data getting identified down to where you live, and that's there's fraud in the system. When I showed them the picture of how the ad exchanges provide real time ads, try to find the best ad for the space for the publishers, I pointed out that the exchanges take a fee when the ads come in. And they take a fee whether the ad is fake or real, whether it's malware or even just an ad that is intended to get somebody to click on a fake site, a phishing site or a click bait site. So there's a conflict of interest. The exchange owners want those fees. And they kind of don't care if they're good or bad. So they're gonna take fees whether the ads are good, bad or dangerous. And that kind of conflict arises when you have this deep, layered system with too many middle players, too many agents of agents of agents in between each other, milking the principles who are the marketers and the publishers.

So anyway, long story short, this was all accidental. It's kind of turned toxic and parasitic, and I think it's a concern for citizens around the world, citizens of the web, citizens of nations who worry about this because there's criminality, there's fraud, there's privacy, there's data ex-filtration at a large scale. And it's not good for anybody except (laughs) those middle players arguably who are taking their fees.

KENT: So Brendan, that's like a whole bunch of really cool stuff you just said. One thing you mentioned that Flash has so many vulnerabilities that if you got a dollar every time you'd be a billionaire. (laughs) So I'm curious why that is. What is it about Flash that makes it so consistently vulnerable, and is there any chance like, the web keeps adding more APIs, giving you more power as a web developer, is there any chance that we could see our browsers being just as vulnerable and dangerous as Flash was?

BRENDAN: You know, I don't wanna pick on Flash. Browsers have vulnerabilities. Any significant code base is going to have vulnerabilities. It's kind of a truism. It's a scientific fact, really, mathematical. I was watching a talk by Sergey Bratus, and he said this is a consequence of, you know, sort of undecideability, the Turing and Church developed David Hilbert's 10th problem, which was, Hilbert said, I think it was, "Can you make a mathematical system for solving certain kinds of equations?" and this led to the general idea of "Can you make a computer that can look at a program and decide whether it halts?" The halting problem. And Turing proved you cannot. And this has serious consequences, including we cannot statically analyze our code and find all the bugs. So we have to test it at run time. Stack analyses is good. It's additive and complementary. I still find fuzz testing where you generate travesty inputs and feed them to programs is more productive than static analysis, but you want both. When people learn this sometimes they're, if they are far seen they realize this means security will be a job forever. (laughs) It means you cannot hope for a day that comes when we suddenly fix the last remote code execution vulnerability and we're done. Because living code always changes, and changing code needs testing, because you cannot statically find all the bugs.

So I don't wanna pick on Flash too much, except now I'm gonna pick on it, because it really has gone sour, too. And the reason I think, Steve Jobs killed Flash but he did it with some fist of the North Star super punch that caused Flash to become a zombie that's been lurching around, eating people's brains ever since, and eating my computer's brain until I turned it off the other year. (Kent laughs) Steve Jobs, two of his greatest contributions in my opinion are thoughts on music, where he said no to DRM and thoughts on Flash, where he said basically, "Flash is like this other runtime, and we already have our own web browser. We already have Safari Webkit. We don't need Flash, and Flash is just gonna suck power and be a second class citizen." And I think he was right. I mean people said he was unfair and there were things he said in the blog post that weren't true, like he said, "Flash is based on older code." It's like wait a minute, iOS, Mac OS are based on BSD Unix and the Mach Project from CNU from the early '90s or whenever. There's a lot of old code in Apple software, but the age isn't the thing. It's whether it's living code that's been brought forward. And the problem with Flash, I think, it was a single vendor that had its day and did really innovate with Flash, truly innovated ahead of the web, because the web was being monopolized by Microsoft.

So while we were trying to do Firefox and take back the web, and we did succeed in that, Macromedia was charging ahead with Flash and they did a bunch of cool stuff. They even picked up a version of JavaScript that was designed on paper but never implemented outside of Microsoft's system called JS2. This was the original ES4. It never got through the standards body because ECMA was mothballed in 2003 due to the IE sort of nuclear winter, the IE monopoly. But the Macromedia guys picked it up, and they already had a language based on JavaScript called ActionScript, you know 1 and 2. I think 2 added a few other things on top of 1, might have added some kind of class, I forget. And then ActionScript 3 was the big one where they took these ideas from Wadimore Horwat, who I gave the keys to the kingdom to when I was at Netscape when I went to do Mozilla after I had standardized the first version of JavaScript. And Wadimore was very smart, and he said, "I'm gonna make a big JS2 that's gonna be like the next version that'll have classes, and packages, and namespaces, and all sorts of stuff." Some of that we then tried to also dust off for ES4. And that's why we partnered, when I was at Mozilla with Macromedia, got bought by Adobe. So Flash had this arc where it was doing well, it was innovating, and they did Flex. I don't know if you remember that, XML markup for building apps, rich apps, and you could write ActionScript when you needed to, but you could do a lot with the Flex. That was all cool. And it was a single vendor, so to the extent that they worked diligently and they used fuzz testing and stack analysis, they could've kept ahead of their security bugs. But I think it's hard, because they were closed source and they were single vendor for them to do that. And after Steve Jobs' thoughts on Flash and it was clear that it was not going onto iOS, Adobe had a real problem.

I'll tell a story about this. When I was at Mozilla, we were still facing this hard problem of getting Flash working right on mobile. And the only way I think that at that point Adobe was doing Flash on mobile was on Android. Android was not like Lollipop or (mumbles) or whatever. It was pretty old, and it had this terrible Webkit version. This was like Gingerbread or even earlier. But they had Flash. And Google had thrown engineers at Adobe doing things like the Pepper API plugin version of Flash. This was like a better plugin API. And so there was a meeting, it was a very weird meeting. It was like we were stuck at Mozilla thinking, "How are we gonna get Flash working on mobile? If we're trying to get on Android and there's still a lot of Flash content," which there was then, this was 2011 I believe, "how are we gonna do it?" And we went to Adobe, and we said, "Can we get a really good Flash embedding going for the Mozilla engine, Gecko?" And they said, "Why don't you just use Pepper?" And we said, "We can't really use Pepper because that's like using Chromium, so we'd have to get rid of Gecko or do some kind of a mash up between the two and it would be a lot of work. And we'd rather just take the Flash that we have in Gecko and make it better. Why don't we do that?" And the Adobe people were like, "We feel like we're children whose parents are fighting, and we don't like it. Why can't you just get along with Google? I'll help you get on the phone with somebody at Google," who I happened to know already. And I said, "Look, I'm here to meet with you, not with Google. Why are you talking about Google all the time?" And they were doing this sort of, "Why can't Mom and Dad get along?" And Mozilla is a lot smaller than Google. It was a very strange meeting.

What followed in two days, I kid you not, was they said, "Oh, never mind. We're dropping Flash on mobile," and by mobile, they meant Android, because Steve Jobs had already killed it on iOS, which means it's not gonna be on mobile. If it's not on the shiny, best mobile device, it's not worth putting Android. And Adobe threw in the towel. And that was 2011. But, Flash still on the web, especially on what you see on your big screens, your laptop and desktop. It's still used for ads that were created within the last six years, sometimes five years ago but they're still being sold. In New York, there's somebody, a media buyer is out there looking for space to fill with ads and they have some Flash ads that promote some product that's still on the market. Flash ads are still trending up last I heard from a friend at Microsoft. I think this might be out of date now, I hope it is, but two years ago and then a year ago I heard that they were seeing in Microsoft Edge a rising tide of Flash ads. My solution with Brave is to block those. And I think nobody really needs Flash ads, but this is why Flash lives. It's like a zombie. The reason it's lingering is sort of bad legacy. And since Adobe kind of walked from it and did Creative Cloud and went to a subscription model and said, "We're a services company and software as a service, and then platform as a service or omniture," whatever, there's no incentive for them to really lean into Flash and do all that fuzz testing and all that hard work figuring out deep in the actual virtual machine or in the C++ code why there's a memory safety bug that can allow remote code execution. So Flash is just a sort of toxic, (laughs) brain-eating, vomiting zombie.

BRIAN: It's been forsaken. (laughs) Well, plus it sucks to update. Nobody wants to update Flash. You have to close all your browser tabs.

BRENDAN: It's a pain. Jobs was right. Jobs didn't like extra layers of stuff. And I used to own Apple Mac IICI back in the old, old days. I never got an Apple II in the really old days 'cause I was a high school student or a college student and I couldn't justify it to my parents, 'cause they were sure I'd play games, and they were right. (laughs) I was like, "No, I'll make language flash cards." And they were like, "You'll play games." (laughter) So I never got an Apple II, but I did have a Mac IICI later. It was just a tight little machine, I think it was System 6. And say what you will about Apple, I think they always liked to have a tight hardware software integration. They have IOKit. They have AppKit, WebKit. Some of these are better than others in my opinion, as pieces of software in terms of design and implementation quality, but they don't have a lot of extra fat. They don't have two of everything or three of everything. And so Flash would have definitely been one too many compared to WebKit, especially since the original iPhone was supposed to be about the web. They said, "The web works." Jobs said, he held up the phone, he said, "The web finally works," and that was their app model for the first 10 months.

So anyway, that's why Flash is particularly bad. I think it's been forsaken. I think it's economically Adobe can't justify too much effort on it, but they do try to patch it, and that's why there was a patch yesterday for a very dangerous bug that was being exploited in the wild. And so back to the Angler Exploit Kit in malvertising, the Angler Exploit Kit was the kit that was attacking not only Flash but Silverlight. To be fair, Microsoft copied Flash. They call it Silverlight, what were they thinking? You know, how obvious is that? (laughter) And it has vulnerabilities, too. And Java in its day was the number one source of paid malware exploits. Brian Krebs said this about six years ago, I think. It wasn't JavaScript, it wasn't the browser. But the Angler Exploit Kit, as far as I can tell from the security analysts I followed, disappeared in June. That doesn't mean malvertising disappeared. Now there's the Neutrino Exploit Kit. There's other stuff out there that isn't known. Sometimes these things backdoor your systems. Sometimes they try to make grandma's system part of a botnet. But what some of them do, I think Angler did this, is they do ransomware. And ransomware is really insidious, because grandma's PC is suddenly hostage, and she's reading these laughing skulls message on her screen saying how to buy Bitcoin and send it off to some address somewhere in Russia, in order to get her system back, in order to decrypt her disk. And the really insidious thing is they don't charge too much. So if like it's two Bitcoin, you know, it's 200 bucks, grandma wants her grandkids' pictures back and she's embarrassed, so she pays it. This does not go to Interpol. It does not go to the FBI. So this is an unsized problem, and I think it's pretty serious. Just the capability is dangerous, because if it's not used for overt ransomware, it's used for backdooring, botnets, conversion, and for espionage and nation state misbehavior.

Plugins are a problem. Browsers are a problem. Browsers will have bugs, too. That's why it's important to keep up to date. That's why Chrome, Firefox, and Safari all update very often, and IE updates often now in the modern era. They used not to, but Microsoft learned the hard way and did a good job reforming itself on security, patching over the years. And Brave updates often. We update often just to add features, too, 'cause we're so young, but really do need software, it needs to be living, that means maintained and fuzz tested and analyzed. It means also that you're getting updates to your users or they are gonna be vulnerable. Nevertheless, there's a big black market for exploits. It's the big story in security now. You just can't keep ahead of them. It feels like not only an arms race, but kind of a losing race in that people are using C++ and C, these are powerful languages. C++ is great, right? It's evolving still. It's got lots of great features, formerly unsafe. You can talk about using template types and being careful. At the end of the day, it's unsafe. That's one of the reasons at Mozilla I sponsored Rust, and that's why I'm excited about Rust. We also see other safe languages coming before. I just wanted to say while I was kind of pessimistic about security, because of the undecideability problem. There are better tools and there are better programming languages. And I'll pause there, because that's a hopeful note for the future. I think if we use those better languages like Rust, we will have fewer security bugs down the road.

KENT: That is a nice thing to end on there. (laughs) So I know that like... so obviously Flash is something that we want to not have running on our machines. I've disabled the plugin in my browser, but sometimes I go to a site that requires it to watch a video or something. I have to open an incognito mode or something. But from what I understand, Google Chrome has started to or will soon automatically block Flash unless it's the only thing that's powering the site. Have you heard about that and is Brave doing something similar, or how is Brave combating this problem?

BRENDAN: Yes, I've heard about that. And I think it's a little bit slower. I wasn't sure what their plan was. I think it might be changing since we last looked. At first it sounded like they were gonna turn it off by default, but they had this sort of growing list of sites where they would actually allow it because, as I said, unfortunately, it's still required for some sites. That looks just too dangerous to us at Brave, so what we've done is we've turned it off by default. And if you go to a site that needs Flash, you will get a black plugin rectangle with some kind of a prompt that allows you to turn it on, sort of go into the general preferences and turn it on. That's the first line of defense for us. And then, if you do that, it's still off for any site, but we intercept the thing that tries to load it and we say, "Do you wanna turn Flash on for this site?" And then you can do that. I think you might even have to reload. We really don't make it easy for you, which is kind of intentional. And it remembers for that site, but (laughs) we did something extra. Because Flash tends to have endless vulnerabilities, after seven days for that site, it disables again automatically. (laughs) So why do we need the Flash? And I think that's appropriate, because that zombie's kind of, it's eating everything.

KENT: Wow, that's amazing. I love how hard you've made it. (laughs)

BRENDAN: That's, An-su did all that work, so. And she's fielding different variations on a theme where Flash comes in through some sneaky embedding or some different way that we can't always intercept. So we're working on it. So people shouldn't just assume that we hate Flash so much that there's no way to make it work on a given site. We'll take bug reports and we'll try to fix them, but we're definitely not gonna make it easy and we're not gonna turn it on by default. It is off by default in Brave.

BRIAN: But Silverlight isn't, or?

BRENDAN: No, Silverlight is off. We don't even have other plugins. I think Silverlight is dead anyway. The story there is that Silverlight was important, especially on the Mac because Netflix needed it for some level of DRM sort of software, obfuscate DRM and maybe on Windows earlier they needed it, but then Microsoft, Netflix and Google got together and did HTML5 encrypted media extensions, which is DRM for HTML5 video. And pretty soon, before that spec was even like, might not even been a working draft, I don't even know what state it was in, they started shipping support for it because they wanted to get rid of Silverlight. So Silverlight is dead. And that's good, because the Angler Exploit Kit was targeting Silverlight as well as Flash, and maybe even the Java plugin, which Oracle was a very bad steward of for many years and finally got wake up calls with massive exploits. And I'm not sure how good it is either, but we don't and Brave, we don't do any of those plugins. It's just, plugins are dead. It's just a matter of time. They're the walking dead. (laughs)

TYLER: So I wanna switch gears a little bit here. I think because your engineering background is so prestigious, a lot of people kind of overlook your CEO background. That's something I'm interested in, 'cause you've basically gone from this hard core engineering role to the last few years being in a CEO role. So if you were to give advice to some people doing that same transition, what advice would that be?

BRENDAN: Oh thanks, that's a good question. Well for one thing, doing Mozilla, even though I was CTO for a long time, you have to sit in the rooms where you're making fateful business decisions, you're figuring out how you're gonna survive, what's gonna fund you, which partners you work with, which ones you don't, how you work with them. So it's impossible not to learn that way, and even before that I was a principle engineer at Netscape, there were lots of opportunities like that. But I kind of forswore management too long. So I would say don't do that. If you get to a level of achievement where it makes sense to get into management or some kind of technical leadership position, do it, because you can 'cause more to happen than your own 10 fingers can type, right? That's the real win there. And you can help people grow and do things together that none of you could do individually. So it's great to be an IC, and I did it for a long time.

So when I got to the technical leadership position, then I was doing things like influencing but not managing. Influencing can work, but you end up, especially if you get into a larger organization having to influence person to person, and that gets attenuated across seven degrees of Kevin Bacon and it can be a drag and you can run into all sorts of politics. So management is, without throwing your weight around, with true leadership, management gives you this extra dimension beyond influence, which is that you're actually deciding on the order of work and helping people charge up various hills and build various castles, sky castles. Let's hope they stay up. And the CEO level is just the sort of top of that where they have to be the place where the buck stops as one of our presidents said. Was that Truman? And that means you get the accountability, too.And I think the other thing that I would say that's valuable is, and this is something that I hope came out when I was talking about advertising earlier, you have to have some amount of empathy to model various people's business concerns. Like maybe they are rapacious pirates, but maybe they have some legitimate business needs. And at the end of the day, everybody has to put some food on the table. So you have to look at various interests and how they align and possibly conflict, and sort of, it's like solving a puzzle. Can you get the interests to align more than conflict, or align totally, which can be beautiful? Can you make deals that are durable and that they really serve both parties' interests in some complementary way?

My best example of that was when we did Firefox we had this hot new browser when no one thought you could have a browser, like Internet Explorer was it. The web was over. And suddenly, Firefox was taking back market share from Microsoft, which had never been done in any category that I know of. And Google has got this awesome search engine and since 1998, people are using it instead of Alta Vista or whatever, because they have page rank, they count inbound links as reputation, they can't be fooled by the contents of the document having spammy hidden HTML comments that contain dictionaries or whatever. Google has this great search engine and they figured out how to do search ads, placed results as Sergey called them, and it's kind of beautiful because they can be as good or better than the organic results. They look texty, they aren't really annoying. And by the time we started dealing with Google at Mozilla in 2004, they already tuned up their AdWords system, second or third generation of this search ad business. So we had this complementary partnership, like Google doesn't have a browser, Firefox doesn't have a search engine. That was a good deal. It didn't last, and things never last forever. So at some point the Firefox people that Google was employing, I think this was early 2006, went off to do Chrome. There was a demo, I heard from some of my friends who had been Mozilla hackers, Darin Fisher and Brian Ryner, I think Darin runs Chrome now, the whole group, they did a demo in mid-2006 that was Chrome, and it was awesome. It wasn't, I heard, anything about V8, 'cause V8 was just starting then. It was more like, "We're gonna make this sad tab, 'cause everyone knows plugins crash, and everyone knows WebKit crashes. And it's a drag when your whole browser goes down if it's Safari or Firefox." So they did a demo where they had several tabs, and it's easy enough to have a captive crashing specimen somewhere and they made a sad tab appear and they got a standing ovation. That was the real big idea with Chrome, process isolation. It also gives you responsiveness. It also uses a lot of memory if you let it. (laughs)

So I think CEO management leadership, sorry I went technical again, having some idea of interests and how they might merge and align and be complementary and working on that is good. And to just finish that thought, I'm not sure Mozilla could've done anything to forestall Chrome any further. I think Google, when I talked to Larry Page I think in 2005 and he was all enthused about WebKit, I said, "You guys should probably do your own browser," because they're big enough, they have enough talent, and they can put their own flavor on it. They can decide what it should and shouldn't be. So you have to be willing to let deals like the search partnership end, and Mozilla didn't. And then for a long time it was considered like, "Oh, Mozilla is Google's boy. Mozilla can't get out from under Google's thumb." And there's some truth to that if Firefox over time, I think the peak market share was 27% right after Chrome launched, maybe within a year, and then it declined and Chrome passed Firefox in 2011 as I recall. At that point, people probably had a little bit of a point about the game theory. Like if Firefox keeps going down and you're relying on Google for revenue, at some point they might just say it's a write off or, "Okay, but here's the new deal and the terms aren't as good," or who knows what. I think, this is partly on me, we should've been cognizant of that and looked for another better way to sustain Mozilla. They did eventually go with Yahoo after I left. I'm not gonna comment on that (laughter) 'cause Verizon is buying it and it's kind of all different now. We can talk about that on a different show. But I'll say that for CEOs or aspiring CEOs or anybody thinking about management, you wanna be strategic, too, and not assume everything is forever and have a map of where the future is that you can use to navigate out of your deals as well as stay in the ones that will sustain while the going is good.

BRIAN: Nice.

KENT: I'm sorry. Brian, did you have something you wanted to ask?

BRIAN: I just, earlier I wanted to just say you have to be "brave" not to use Brave. Anyway, you can use that if you want. I can also be your CEO if you want. (laughter)

BRENDAN: The idea was you have to be brave to use Brave, because we make... we make it hard on users a little bit. I'm not really selling it well here, am I? I'm not really a salesman. (laughter) What I mean is, if you're gonna defend your data and your security from malware and from trackers and annoyances and people who are snooping on you, that takes a little bit of courage because at first you might find they're saying, "Oh, you're using an ad blocker. You can't read my great publisher content." Or you might get a page that doesn't quite work right. Or you might have to turn on Flash for one site and then it'll turn off in seven days. (laughs) But whatever you do, it's gonna take a little extra effort, and you should be willing to expend that effort because we aren't passive couch potatoes on the web. That's just a bad model. That's like the TV model. And people worry the web is gonna turn into TV. And to the extent, video is rising and everyone wants Netflix and shows. Sure, why not? I mean, you can't stop that.

But I believe the web will always have a textier side and a more balanced relation between producers and consumers. Obviously, the YouTube stars for the young generation today complete disjoint from the Hollywood mainstream media as far as I understand it. I'm old, so I have to go by hearsay here. (laughs) Anyway, the web is more read write and less passive, and that I think allows for some of the web citizens to be brave and to assert their rights, and that could change the web standards. And that's, to finish the early point about Brave, we're not just in it to build something that's custom. And it's all open source, so what we'd like to do is standardize better standards for things like ad blocking and ads and anonymous ads, and micro-paywalls, micro-payments, anonymous payments, micro-donations. Those facilities are not in the web standards, and people have to cobble them together site by site or go around and do deals with sites. And you don't wanna sign in with nine different micro-payment systems.

BRIAN: Yeah, that's actually the big question I had was around micro-payments, and where you see the future for entrepreneurs in that area. Like, is Medium gonna be a giant monopoly now for blogs? (laughs) I guess it already is, but yeah, micro-payments is very exciting.

BRENDAN: It is, and I think there can be many approaches. At the end of the day, think further out at the end of the decade. If you're building a web that's important for its, I won't say legacy, but its long term, durable, text and video and images content, but you're also building AR and you're sort of PokÇmon Go-ing it over the real world, and you're building VR, which is definitely a gamer thing but can, I think, grow from there, there's some industrial and educational obvious place that are going well, then suddenly you have all these shared assets. And it isn't just the text and the video and the images and the links and the scripts, it's things like 3D models and texture art that skins those models. How are you going to protect those assets? DRM isn't gonna cut it. You're in a shared world. You can't encrypt the pixels with a secret key for each user when there are 50 or 50,000 pairs of eyes looking in through VR on your model. So you're gonna have to order things like watermarking, which I've blogged about in the past. And you're gonna have to consider ideas from Ted Nelson's Project Xanadu, which predated the web, like micro-royalties. And these need to be high integrity. These need to be part of the protocol. They need to be woven into the fabric of this new super web. And they need to be common among all browsers and viewers and AR and VR devices.

So what I hope happens here is future standards will make payments, anonymous payments, micro-payments, sort of frictionless payments, possibly for those who want to see them, anonymous ads. I'm always trying to get people to use, with permission, the Minority Report scene where Tom Cruise is on the lam and he's going into the subway and he's, everybody in the subway, their retinas are being scanned, which I don't know if that's actually practical, but it's really creepy because they're all being identified. There's no privacy at all, and they're all getting sort of beamed sound into their ears promoting custom ads to them. I think that's totally dystopian. I'm not sure it's technically feasible. And it just seems like we shouldn't have that future. We should have a future where, whether you're walking around or you're in AR, a combination of virtual and real, or you're in virtual, you have control over your data and you have control over your identity. And if we don't build that into the standards at the right levels, it's gonna become captured by the walled gardens or the big superpowers, and it's gonna get abused.

KENT: This has been a really interesting show. It didn't exactly go the direction I was expecting, but I'm just like really amazed at the thought that you've put into this and hearing the history of why we are in the state that we are and the things that you're doing. And so with the little bit of time that we have left, I am curious what your thoughts are after a little bit of time with this new yearly release schedule of ECMAScript. What thoughts do you have around that yearly releases of ES specifications and is this going to work out with this yearly train?

BRENDAN: You know, I think it's just better to do it that way, even though there was a small release, obviously, in the shadow of ES6. So I think, ES2015, excuse me. (laughs) Somebody tweeted the other day, and she said, "Slightly drunk here, but I hate ES2015. It's always ES6 forever," or, "Viva la ES6," and I retweeted and said, "Ha-za." So ES20, it's off by nine, it's really kind of confusing. ES7 became ES2016, which is happening. And then ES2017, I hope to have, since nobody else is doing it, I'm back to trying to get 64-bit integers and other number types in. That work goes on, and it's easier to do in small pieces. I think the committee is better off with this annual process. It does make smaller releases with smaller features. That's appropriate for something of JavaScript's age. I keep joking that it's 21, so I've kicked it out of the house. It's got to go find its own way in the world. And it'll probably be going for 21 more years. But the smaller changes and the more careful changes cannot be the only way that we do things.

So there are some bigger changes, and they take more time to cook. So you have to be willing to put them through the stages of the process, from stage zero when they're just sort of an idea, to stage one, when the committee says, "That's something we'll entertain," to stage two, I forget all the rules, but you have to start having spec language, to stage three, when you can actually have vendors implement prototype versions of them under flags or in nightly builds, and then stage four when they're all but done and pretty much implemented. That can happen very quickly for a small proposal, so that's cool. It can even jump stages over several days of meeting of one meeting session. Then the bigger stuff, which requires spiraling around the design, outside in and inside out, looking at it from many angles and starting to user test it through Babel or other techniques of prototyping it that you can do ahead of even the process, that can happen and it needs to happen for some of the bigger changes. Even though JavaScript is mature, there's some growth still ahead of it that can't be done in small increments. And yet, I think the smaller is better. So small is beautiful, and that's why I think the annual cadence is good, in spite of hating the year numbers. (laughs)

KENT: Awesome, cool. So actually, for some of the bigger changes we want for the web, lots of those things can happen in WebAssembly, right? And some people actually are making the claim that WebAssembly is going to totally remove the need for JavaScript in the future and anybody learning JavaScript is learning a dying skill. What do you have to say about that?

BRENDAN: Oh, I think that's clearly false, and there are a couple of big reasons. One is JavaScript is obligatory. You cannot avoid it. Browsers must implement it. WebAssembly will take many years to become, I think, that obligatory. And it will be in nightly builds soon if it isn't already. I think there were announcements this week from Microsoft and V8 and SpiderMonkey and Mozilla. And everybody asks about Apple, and I had a comment on Hacker News about that. It's coming, right? WebAssembly is coming, but it's going to be a while before it's really there and you can count on it. And then when it's there, it's really at first a target language for C and C++ cross compilation. So anyone who is saying, "You don't need to learn JavaScript," are they really saying you go learn C++ to write code for your browser? I don't think so. (laughs) I don't think that scales any more than saying write Java in 1995 did. That's why we did JavaScript, because there are 10 to 50 times as many programmers who can handle JavaScript as can handle a complex, classy, statically-typed language, and that will always be true. And you shouldn't have to write Java or C++ to do simple things in your browser. So JavaScript is the way you do simple things in your browser. WebAssembly won't be.

Now, long term on the WebAssembly road map are things like garbage collection and V tables for efficient objects, dynamic objects, or objects that have multiple inheritance. That kind of stuff will come and it will allow WebAssembly to be a good target language for other cross compilers, like you can imagine Python and Ruby cross-compiling very nicely to WebAssembly in the future. That will take several years at least. So even then, I think it's gonna be a problem of scale. Do you wanna get that Python or Ruby cross compiler and use it? Do you wanna fight the friction of even in a few years WebAssembly still being a little bit of a mismatch, or still an evolving thing that has to be even better at being a target for Python, after it became an awesome target for C++ in the present era. And that means JavaScript will still be the fastest, slickest, most optimized way to go.

Finally, when you're running these WebAssembly modules, and it's a modular system, you're running what'll initially be cross compiled game code or physics engines or VSP or AI that's written in C++ compiled to WebAssembly, you have to cross the barrier calling from JavaScript. And that can get, it should get really cheap over time, but that can be expensive at first. So what I think will happen is there will be a ton of incentives to use JavaScript. It's still the fastest way to get things done. It's still gonna have the lowest sort of overall cost structure. And to do things that it can't do, you can reach for WebAssembly. Because I mentioned it's a modular approach, they can share memory to share the heat. They can share things in memory. That means that a lot of times you can't just say, "We'll add it to WebAssembly," 'cause it ends up popping up in JavaScript, too. So they're kind of co-evolving. So when I say, "All was bet on JS," I could've meant it to say, "and WebAssembly," but there really isn't a future I can foresee. Obviously, anything is possible, like in 20 years, I give it 21 more years, JavaScript will drop dead at 42, and WebAssembly will be it, and that will be the end of JavaScript. I actually prophesied this the other year, but I'm not gonna say what year exactly. I'm joking when I say 21 more years. We'll see.

BRIAN: (laughs) Cool.

KENT: All right, so we can still bet on JS for the foreseeable future.

BRENDAN: For the foreseeable, it's a good bet.

KENT: Cool. All right, well we were actually I think a little bit over, and I have some things I wanna say for our last show, but thank you so much Brendan. This has been awesome. We don't actually have any questions on Twitter, so we'll just jump right into our tips and picks. So yeah, we'll go ahead and have Brian go first.

BRIAN: Oh yeah, sorry, I've got to leave soon. So I just wanted to throw out there that I've been reading this Matryoshka library for Scala, and I think it's something people should look at, because if you didn't realize how many composable recursion schemes there are and you're still writing loops, you should go enlighten yourself. Also, Bartosz Milewski is doing amazing category theory videos on YouTube, so check those out. And also, shout out to the show. I've had an amazing time. Thanks, Kent. (laughs)

KENT: Thank you so much, Brian. Could you get links to those in the show notes? I have no idea what Matryoshka is. (laughs)

BRIAN: I'll throw those in there. (laughs)

KENT: Hey, thanks so much, Brian. You've been an awesome panelist. Cool. Tyler, you go ahead next.

TYLER: Yep, so I don't really have any. I just wanted to give a shout out like Brian did. I guess my shout out is the show and specifically you, Kent C. Dodds. I know it took a ton of work consistently every week to do this. So super grateful, super glad I was able to be a part of it. Just wanted to say thank you for myself, but also the JavaScript community as a whole.

KENT: Thanks, man. Cool, so I, for this last show, have one tip and a bunch of picks. I'll try to go through them quickly. So my tip is start a podcast. So it is a lot of work, but it is a lot of fun, and I have some resources to help you get going that I'm linking up. So like even like an hour conversation that I had with somebody about how to start a podcast like JavaScript Air. So lots of really great resources there if you wanna get into that. I even have, lots of my automation stuff is open source and you can totally use it, so yeah.

And then for my picks, I pick the sponsors. So I tweeted this earlier. The top three sponsors, Egghead.io, FrontEnd Masters and TrackJS, they actually asked me for my reimbursement for the remaining time of this sponsorship. They asked me to donate that reimbursement to Girl Develop It, which I just think is the coolest thing. So yeah, that was like $1,300 of donation, which is so cool. Good on you, sponsors. And then the guests. I have a page on JavaScriptAir.com that has all of the guests. So, I'm just super grateful for them. Couldn't have done it without 'em. I should've counted, but there are like over 100 probably in just this year that I've been doing this JavaScript Air. And then the panelists, I have a link to all of them. They're awesome. And then contributors. So there have been actually a lot of pull requests to JavaScriptAir.com. The whole design was contributed by somebody else, so big thank you to those people. And then the audience, so thank you so much audience for being so awesome. And then, oh yeah, and also I didn't really plan super well. I never intended on making money out of this show, and so I didn't plan super well for making it sustainable and I didn't realize until it was too late that closing down the show and all reimbursements and other wrap up costs was gonna actually cost me a lot of money. So big thank you to people who donated to help ease that financial burden a little bit.

And then just a couple of things. If you're really sad that this show is ending, I am gonna continue to do what are called tech chats. A tech chat is basically, I am curious about Brave and so I talk to John about Brave, or like I just talk to somebody. It's like a water cooler conversation over Hangouts on Air so I can ask questions. So it's almost like this podcast, except it's informal and it's irregular. But I do have a playlist that I am linking up to so you can check those out. And then I have a list of podcasts that I listen to, so if you want to continue to listen to some great podcasts, I have a bunch of 'em here, like React30 is cool. I have a little three minute podcast called 3 Minutes with Kent that I do sometimes. Planet Money is super awesome. Embedded is super cool. JavaScript Jabber was the first one I ever subscribed to. Soft Skills podcast, when there's a new episode of Soft Skills it goes to the top of my queue. It's a super good podcast. The Changelog is awesome. The Request for Commits, mostly Node and Toolsday, those are some awesome podcasts. And Software Engineering Daily is super good, too. And then my AMA, if anybody has questions for me, I like to answer those. So you can go to my AMA and ask those. I have a link there. And then finally, no, second to finally, sorry, like I said I have a lot because I'm not gonna do this anymore, (laughs) KentCDodds.com/links to a whole bunch of stuff about myself. So if you're interested in learning more, then there's that.

And then my last pick is, part of the reason that I'm wrapping up the show is because there's other things that I'm interested in putting my time into, more interested than continuing the show. So SliceJS is this really cool thing that I'm working on that has awesome implications, like this thing that I made up called Ultra Tree Shaking, and also learning code bases and stuff. And I'm giving a talk on it tomorrow night at a meetup here in Utah, which I will probably Livestream, so I've got some links to that. So sweet, yeah. That's all of my stuff. Brendan, what do you have for us?

BRENDAN: Oh, I just wanna say thanks to you. It's been a great run, and really appreciate your work on this. Let's see. I was interested in something called Inferno, which is from Dominic Gannaway. His GitHub name is trueadm. And it's a React-like library, a JavaScript library. I just wanted to turn people onto it. I think if you go to InfernoJS.org it might be the easiest way to do it, but you have to click on the logo to get to the GitHub, 'cause the site is not quite there. That's one thing I wanted to recommend.

The other thing I wanted to mention is something that I realized from Twitter people don't know about, and that's ES6 destructuring parameters. When you use object patterns and array patterns, you can put default values for the missing properties that are being destructured into the pattern using the equal sign. I can't really explain it over the air, (laughs) but check it out. Destructuring in ES6 has this awesome defaulting of individual properties inside the object or array pattern. It's really handy for options arguments.

KENT: Awesome, yeah, that's great.

BRENDAN: That's my tip.

KENT: Well, thank you so much Brendan for starting and ending this show with us. It's been an awesome run like you said. We've had a really good time. Maybe someday we'll start it up again. Thanks so much Brendan. All right, that's it, so we'll wrap things up. Thanks everyone. Bye!