087 JSJ TC39 with Alex Russell

Download MP3



00:52 - Alex Russell Introduction


Next Week

Lazy.js with Daniel Tao


[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]  [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]  CHUCK:  Hey everybody and welcome to episode 87 of the JavaScript Jabber Show. This week on our panel, we have AJ O’Neal. AJ:  Yo! Yo! Yo! Coming at you live from a messy desk. CHUCK:  Joe Eames. JOE:  Howdy. CHUCK:  I’m Charles Max Wood from DevChat.TV. And this week, we have a special guest and that is Alex Russell. ALEX:  Oh, hi. I’m happy to be 87th in line. CHUCK:  There you go. Do you want to introduce yourself, Alex? ALEX:  Sure. My name’s Alex. I work on the Blink team at Google. And I’m trying to help fix the offline problem for the web. Previously, I’ve worked on very large JavaScript frameworks and have done some standard stuff. I helped start the team here at Google that has been putting together the Web Components work which you might have heard of. And I serve on ECMA TC39, the group that is working on JavaScript the standard and on [inaudible] you see technical and protection group. We’re trying to help make sure that the APIs that you deal with next are the ones that you like, not the ones that you hate. CHUCK:  Awesome. AJ:  Hurrah! CHUCK:  [Chuckles] ALEX:   No hurrah just yet. We’ll see how it goes. AJ:  Someone intelligent on the committee! [Chuckles] ALEX:  Oh, they’re all intelli -- hey, hey, hey, hey. Let’s be clear. Everybody who works on standards is intelligent. It’s just often that we tend to be data poor. Experience is a good teacher and it’s hard to distribute. AJ:  I realize that in recent days, the people that are working on the standards are really top notch people and probably the ones that had worked on it in the past were just not in the right industry to be making the standards. I also realize it’s really hard because the web is stuck the way it is. And so you can’t just, like even being a very intelligent and understanding the web really well, you can’t go in there and make it work because it’s already broken so bad from before. ALEX:  I would agree to some of that. But I think this is just as important. The people who make browsers are roughly the people who make standards. And the people who make browsers don’t get hired to make browsers because they were amazing web developers. You don’t sort of level up at the end of the web development thing and suddenly you get handed a C++ compiler and a git check. That’s not how it works, right? You get hired to work on a browser because you’re the gnarliest bad-ass at C++. And they let chumps like me in occasionally. So, that means the people who populate these processes tend to have affinities for the underlying system and not necessarily for the day-to-day building a thing. And early on in the web’s history, it couldn’t have been any other way. There weren’t a lot of web developers. No one had been doing it for ten years. So, you had a lot of people sitting around trying to invent a thing best they could. But now we’re in a place where we can start to use our experience on the data that we’ve got about what works and what doesn’t to go influence that process from a more practitioner-based perspective. And that’s a voice that we haven’t had I think enough of in the process of building most of these standards for a long time. So, a lot of what I care about is making sure that web developers’ interests are represented at the various standards bodies and working groups. Because like I said, a lot of times people want to do the right thing and they’re the right people that do those things but they may not be able to tell whether or not one of many options is the right one. They just don’t have the experience of building things. AJ:  Well, I was definitely excited the day that I noticed that they have the MooTools dollar sign and double dollar sign operator in Chrome, just part of Chrome. That was kind of neat. ALEX:  Oh, within the DevTools? AJ:  Yeah. ALEX:  Yeah, the DevTools are largely written in JavaScript. I think this is actually one of those big things that’s going to transform the world in terms of building better APIs is that the more that we get people who are building browsers to be people who write JavaScript for part of their day, the better we’ll do. Our batting average will go up in terms of designing APIs that don’t suck. You really don’t get that flavor of a language. You can sort of read a spec and sort of see how it might work but you don’t really get the flavor for what does and doesn’t work in practice until you got to write a bunch of it. And asking someone who’s a C/C++ hacker to go do that every day without it having an impact on their day-to-day work output is probably a non-starter. So, I could go and sit at all of my colleagues’ desks and say, “Write me 2,000 lines of JavaScript right now,” but they would not very kindly tell me to go stuff myself. [Chuckles] And they’d be right. But if we turned the task of building a browser into something like self-hosting a bunch of JavaScript code, then we’re in a much better spot. So, that’s what I’m excited about. JOE:  You know, you sound very well-educated about this topic. I was curious what your background is before you were doing what you’re doing now. ALEX:  So, how far back do you want to go? I’m older than I seem. JOE:  To birth. ALEX:  Oh, to birth. [Laughter] JOE:  Start with the dinosaurs. ALEX:  It was uneventful. I don’t remember much. I worked out of school doing web application security and network security and sort of did JavaScript stuff on the side and started building JavaScript libraries, because you sort of need that eventually. And eventually wound up getting a gig doing JavaScript in 2003 or 2004 full-time, which was astonishing to me because there was no such thing as a JavaScript job in 2003 or 2004. I don’t know if you remember, but there was this ragtag fugitive group of us who were still writing JavaScript on the side for fun and not much for profit. And we started putting together our tools and started comparing. And a bunch of these things were open source. But we were just a small group of people hanging out on internet forums, if you remember those. And much of which is now lost to history, thank goodness, because we were children. [Chuckles] And eventually, the day job started to need better and better tools. And so together with a bunch of likeminded folks, we put together the Dojo project. And this was like pre-AJAX thing. We were trying to build BI dashboards with charting and graphing and doing lots of data analysis on the client side. And it had to work on Firefox 1.0, which was the new modern thing, and IE 5.5. So, that was the challenge. And so, we put together the Dojo project. And of course, history happened and Dojo was a tool for people who had big problems and knew it. Turns out, that’s not most people and that’s alright. And eventually, I went to Google to work on a product called Chrome Frame, which is where they were foolish enough to let me start writing C++ for a living. And so, I joined Google specifically to work on Chrome Frame and did that for a couple of years. And then have been working more in the ‘How do we evolve web as a platform?’ thing for probably the last two or three years, starting with a bunch of work around Web Components. Dimitri Glazkov and I sort of lead a team to help put together what we’re now seeing come out of browsers as Shadow DOM, Web Components, the template element, and some changes to JavaScript. And now, my focus is shifting more towards the general question of how do we improve the quality of specs overall and this service worker thing? So, how do we make applications that work really, really offline and make them work as well as native apps do offline? That’s that. That’s me. CHUCK:  That’s really cool. We got you on the show to talk about TC39 in particular. And it sounds like that’s kind of a major part of what you were just talking about where you’re trying to make the web better and make JavaScript better and things like that. Do you want to explain a little bit about what TC39 is and why it’s important? ALEX:  Sure. For those who don’t know, TC39 is the cryptic codename for the European Computer Manufacturers Association or ECMA, which is a standards bodies, subgroup which works on JavaScript, the standard. TC39 produces something called ECMA-262 which is the thing that every JavaScript implementation sits down to implement. Obviously, they have to do more than that because the web has got lots of extra stuff that’s outside the language specifically. But TC39’s job is to evolve JavaScript the language. And so, my interests there and those of a lot of the newer members of the committee are to try to improve the language in ways that get more bang for the buck in terms of web developer productivity. You know, there are a lot of things we could add and there are a lot of things we could change. Obviously, we’re constrained by backwards compatibility, which is a really, really heavy burden. But the ability to say what you mean in JavaScript is something that I’m particularly interested in. And it’s something that I think the committee has done an okay job of in the past but has not focused on with regards to the web developer perspective. So, that’s where I’m coming from. Because you build systems that need to scale a little bit and you eventually get yourself into a place where the primitives that JavaScript gives you don’t let you compose large systems and they don’t give you natural tools for doing it. We’ve got some really great things coming in the next version of the language that are going to help out there. The first is a class syntax and the class syntax is not classes. It’s not Java classes. It’s not classes as you know them from any other language. They are JavaScript prototypal inheritance but it’s just [inaudible]. But when you look at it, it reads like a thing that you can make one of using the new keyword. So, that’s incredibly exciting to me. And the other thing that’s really exciting to me is the modules specification. So, modules are a way for you to put together a bunch of code and import it and have the transitive dependencies all loaded for you. And it’ll look like it’s synchronized. So, you’ll say ‘import blah from’ whatever. But because we’re in the language and not using a library, we’re not having to work around the language’s limitations, we can actually make that loading asynchronous but make the execution of it appear synchronous from the perspective of the code that’s loading somebody else’s module. And so, this is the one thing that the language can do, is to use syntax to sort of move it to the host that you can’t really do unless you are a compiler or a preprocessor. You don’t really have the ability to go take those opportunities and turn them into things that are good for end users. And I think that’s what the committee should be doing a lot of and I’m grateful that we’re doing a lot of it in ECMAScript 6. CHUCK:  I guess there are a couple of questions that I have about TC39 and the way that it works. ALEX:  Shoot. CHUCK:  But one of the things that really comes in that I wonder about and AJ kind of talked about this when he was talking about backwards compatibility and things. Backwards compatibility has backwards in it and some of the stuff that we used to do on the internet doesn’t make a lot of sense anymore but we still have to support that stuff. So, do you try and make decisions with the things that we do moving forward with an eye to that and do you find that it limits the decisions that TC39 is able to make regarding the language? ALEX:  Yes and yes. So, TC39 is usually concerned by the ability to not change the language. So, you can imagine that there are a bunch of tools in the toolbox when you’re trying to evolve a language. And one of them, it’s a big hammer, is that you can just get people to opt into a new mode. You can say ‘script type = text/javascript.next’ or something like that, right? Or you could, as we had with ES 5 have a use strict pragma which puts you into a brand new mode of operation in which the things that you think you know can change and new syntax can be introduced without a lot of worry. But those things have a real price. It’s very difficult to reason about code that has lots of modes in it. And at some point, you’re not really talking about the same language. So, this is an active debate, but it’s been settled for ES 6 in favor of not adding any new modes. The tagline is ‘One JS’ which means that the set of things that we can do must be fully backwards compatible. That doesn’t mean that you should be able to use all those things from old browsers, but it means that we can’t change anything that you could write. Any code that would have run before must run still. So, that takes a lot of options off the table in terms of adding new stuff and the form of the new things that we can add as well. That’s okay though. I think that having that responsibility towards continuity is just something that you bite off when you’ve got a really successful platform. And I think for as much as people kind of are frustrated about the web, the one thing to remember is that it’s probably the world’s most successful platform anywhere ever, which is why I’m interested in working on it. Web developers don’t settle for having a billion users. So that means that, “Okay. Well, what about people on a Windows phone or people on a Mac?” You don’t think about that as a web developer. You sort of think about the entire world as a set of users that you could potentially be addressing. And you don’t really think about devices. I mean, you do. You think about the constraints of those devices. But you don’t really think about specific devices if you’re doing it right. And the web maintaining that reach is something that ECMA TC39, I think, is doing a pretty good job of. CHUCK:  Gotcha. Are there features that you guys are kind of working toward that you’re slowly going after because you can’t just jump ahead that fast? ALEX:  The real challenge with adding any new feature to a language, specifically syntactic, is that you have to integrate it. You can’t just throw something in. Let me give you an example. So, there are two new operators in ES6 called spread and rest. And you’ll see them as ‘...’ and you’ll see ‘something...’ or ‘...something’. And they are shorthands for expanding and contracting arrays. So, you don’t have to do things like ‘.apply’ anymore. You can just use ‘...’ to in-place expand an array of stuff, which is really, really, really nice. It’s an outstanding convenience. But any place that you can add that ‘...’ is something that we have to go consider with regards to the grammar productions and the syntax and semantics of what you could have done there before. And we have to make sure not to break anything. So, there are cases where in order to enable certain features, we have to go think through all of the cases in which those new features might interact with other features in the language. So, the one that always totally [F’s us in the ear] is something called Automatic Semicolon Insertion. You’ve seen the fad for leaving semicolons off. This is ASI. And ASI [chuckles] is a language designer’s nightmare. It’s like comma operator in C++. It means that sometimes you’ll write some bad code and it’ll look like it’s doing the right thing because it will mostly work. And then you change it a little bit and then it doesn’t work. That’s kind of bad news. And you can see why it happened and you can see why someone added that. But now, we’re stuck with it. And so, that means anywhere that you might cross a new line, you have to think about the implications of a newline interacting with ASI. Does that make sense? CHUCK:  Yeah. ALEX:  Yeah, it sucks. [Laughter] ALEX:  I don’t recommend you doing this for fun. But I do recommend that if you find yourself with some free time and a lot of interest that you do get involved. One of the things that have been really productive in the last couple of years, TC39 has been getting more people with a web development background to be part of a committee. So, we’ve got a lot more representation now from some folks from Facebook, Yahoo, and many Googlers. And Yehuda Katz from jQuery and Rick Waldron from jQuery are showing up on a regular basis and that has been a huge boon to changing the terms of the debate in favor of making the cut for each of these decisions in a way that favors what web developers would imagine would be the right thing to do. Does that make sense? CHUCK:  Mmhmm. ALEX:  But you kind of have to predict your users a little bit here. You can’t go and invent something so totally alien. You can count on it effectively being the de facto thing but you can’t just be like, “Ah, we’re going totally to the right here,” when before we were zagging to the left. And having that influence has been incredibly productive. But yeah, in terms of [inaudible] features we’re working towards modularity, being able to structure your code in a way that feels like it meant to live together. Today, we have no concept of that and there are a bunch of really interesting things around doing that. Defining the event loop, so if you write something in C, at the core of your application, you’ll have this little while(1). You’ll have an event loop and you’ll dispatch things to threads as you need to. Or you’ll take an even loop from someplace else that seems really productive and you’ll use that. The web sort of has an implicit event loop and now we got a bunch of things contending for it. So, setTimeout was the first of those and setInterval. But now, we’ve got requestAnimationFrame and we’re going to have Object.observe. And we’re going to have mutation observers in the DOM, actually which are shipping in Firefox and Chrome now. And all of those things would like to have a very tight relationship to when JavaScript code execution ends. And the spec has always sort of assumed that you’re going to write some code and it’s going to run from top to bottom, right? There’s no idea of another turn. There’s only sort of, “Here’s your program. And now we’re done.” It’s been a very, very simple language. But in the web context, there’s always been this implicit cooperation with and event fires and now we start a new turn and some code runs. And that’s a thing that’s been outside of JavaScript the spec that has been inside the DOM. But nobody, because it isn’t anybody’s particular business, has really sat down to define that. And that’s something that we’re probably going to sort of bite off defining when we add Object.observe in ECMAScript 7. So, that’s one of those big things that doesn’t seem like it’s really important but until we have it defined, until we actually sit down and do the archeology of figuring out how that thing is supposed to work, it’s very difficult for us to provide you the control that you need to go do things with high performance that might need to cooperate with the event loop. So for instance, data binding. Object.observe is a feature that we developed, Rafael Weinstein developed with Adam Klein and Erik Arvidsson, to enable high performance data binding like the sort you’re seeing in Ember and in Angular and in the mdv library that we’re shipping as part of Polymer. Those data binding scenarios need you to be able to see a consistent state of the world and that means waiting until JavaScript is done executing. And then we’ll notify you of things that have changed in the environment. That’s the only sort of sane model. And to get that, we have to have an idea of when JavaScript is done executing and what it means to be doing something before the end of the turn or the next turn, and we don’t have that today. AJ:  Wait. Explain that a little bit better because I’m not clear on what you’re saying ‘we don’t have a way to do that’. ALEX:  Right, right. So today, if I say requestAnimationFrame, I’m going to get called back in just before the browser swap buffer, right, before it decides to go paint something. And if I say setTimeout or setInterval, the browser is going to put a thing on a timer queue and it’s going to, at some time in the future, usually some time more than 13 milliseconds from now, call me back. Does that make sense? AJ:  Yeah. ALEX:  But there’s no way today to hook into the time that you could describe as when JavaScript is done running, when your code is fully off the stack and there’s nothing else to do but before I go back to the browser and say, “Hey go update some DOM or paint some stuff or handle some input events.” So, because the browser is single-threaded and we have a single event loop, we all sort of are coordinating about it. And so, you can imagine that the way it works when you’re dragging a mouse across the screen is that, let’s say you hover over a link and it needs to paint that thing as being underlined. At the same time, it’s going to dispatch some onMouseOver and onMouseEnter events. And those might run some JavaScript. So now, you have to define an order for those things. Well, okay. I run some JavaScript onMouseOver. When does that happen with regards to that paint happening? And when I’m done with the JavaScript, can I do some work? Because I have to yield back to the event loop to let it go do the painting or to go do the other work. Does that make sense? AJ:  Yeah, tell me if this is also the same realm. The idea of I want to make 15 separate DOM updates but I don’t want to make them when I make them. I want to make them when that round of execution is done. ALEX:  Exactly, exactly, yeah. So defining a hook for that time, which you can just define if we were just talking about it, we can write it down on a whiteboard and be like, “There’s a time which JavaScript is almost about to yield to the main loop and let it go paint stuff but I want to do some work there.” We could talk about that. And in our code, we could write down, “Look, I’m about be done,” at every point where you might be exiting and go check and see if there’s some work to do on the queue. But that’s a real pain in the ass and nobody really does it that way. It’d be better if the system gave you a hook to do that, right? AJ:  Have you used connect or express much? ALEX:  I haven’t used them in Angular. I apologize. AJ:  Okay. Because they have a system that maybe makes sense for this type of scenario where you define basically an array of modules. And every time an HTTP request comes in, it goes through the array. And the top thing in the array is normally something like your cacher or your logger which actually has the ability to overwrite the response. So, it comes through the stack and everything has an opportunity to modify the things that are going to happen at the end. You do all of your work and then you call send to send the response, and this is all Node.js server side stuff. ALEX:  Yeah. AJ:  So, you call send to send the response and then it goes back through and hits all of those modules that had hooked in a second time. ALEX:  Yeah, that sounds very similar to what you would be able to do with Object.observe in this way. Anyway, one of the things we’re trying to do here is to define how all of these different things would define different buckets between mutation observers, requestAnimationFrame, Object.observe, and promise delivery which is something else that I’ve been working on, how they all interact with each other and when those buckets get filled and drained. That’s just something that we have to define [inaudible] for. So, that’s something we’re working towards as well. AJ:  So you said promise delivery. Is there going to be some sort of promises spec that actually makes it into the language, like ‘this is how we do JavaScript’ kind of deal? ALEX:  Yes, there is. I started working with a bunch of people in almost a year ago now -- God, this stuff is moving so slow -- to try to come up with a consensus promises design. It eventually wound up being A+ compatible. We sort of [inaudible] design in April and May and then a bunch of bikeshedding happened. But the good news is that as of the Boston meeting, which I think was September, we have a design which is going to be in ECMAScript 6. So, it will be in the next version of the language. We’re implementing in Chrome now. And I know that Firefox is implementing now. So, promises as part of the standard are going to be in. Our initial tack was to go do it in DOM. So, I worked with Anne van Kesteren to get a version of promises into DOM. And we’ve leveled up from there to get them into language proper, which is pretty badass actually. AJ:  Yeah, that is amazing. CHUCK:  How many of the features that go into future versions of ECMAScript or JavaScript come from these ideas where somebody goes out and actually implements a library that does it? ALEX:  I think quite a few. If you look at the module system thing, many languages have module systems. JavaScript has had many. I’ve built a couple. Erik Arvidsson has built at least one. A lot of the folks in the room have been building module systems. I worked with James Burke on Dojo and Dojo eventually sort of -- I guess Burke did a lot of the AMD work that’s happening now. So, modules are a thing that we know we need and we’ve got a lot of experience with the question of resolution. Yehuda Katz and Dave Herman have been doing the heavy lifting on ES 6 modules. So, all credit goes to them for getting it to the state that it’s in now, and Jason Orendorff. But it’s looking really good and it meets all of the needs and it has all the pieces that you’d need to plug into it with to make your own module system go. So, if you want to build a module loader that can be compatible with AMD or with Node modules, you can do that. You have to plug in a boot script to make that work. But the native module syntax is really nice as well. And so yeah, kind of having the community experience feeding into the requirements list is really one of the most important things. I think it’s also worth cautioning though that one of the things that people often expect out of the standards bodies is that they are going to go and just rubber stamp somebody’s library. The question always come up, “Why didn’t you put jQuery into the DOM?” And the answer is usually that you have more opportunities to do a good job when you can change the core of the system. And you would do things in a different way if you change the core of the system, right? The designs that we came up with for libraries like in Dojo or jQuery are just not designs that we would have come up with if we were able to change the whole thing. If you could actually go change DOM, you would just go put these methods on the DOM itself. You wouldn’t go wrap everything. Those are the sorts of areas where you have to redesign things to fit into the system well. And so what you’re looking for is the experience of, “This is a really productive pattern. This is a really productive way to do it to work. This is a thing that I would like to be able to do,” and less the form of, “This is exactly how I want to do it.” And so, you hope that I have enough of the right people in the room, you can validate this stuff. And by doing early implementations and by doing, like with ES 6 Erik Arvidsson and John J. Barton and to a very small degree myself and Peter Hallam have worked on a system called Traceur which is a transpiler. It lets you use ES 6 modules and classes and a bunch of these new spread and rest operators and a bunch of those sorts of things to write ES 6 code today and transpile it in JavaScript to ES 5 code, so that can run almost everywhere now. And getting early experience with systems like that helps you validate whether or not this thing really works for you. And that tight feedback loop which we’ve also had now with Web Components and the Polymer project, it’s incredibly valuable in helping you road test whether or not your new thing is going to actually fly. Because you think you have a good idea based on experience, but it’s really nice to have some data behind the eventual system as well. CHUCK:  That makes sense. I want to back things up just a little bit and talk about how does an idea, let’s say promises or modules or something, when you want to put this into the language proper, what’s the process for doing that? Does somebody make a proposal then you talk about it and vote on it? ALEX:  Yup. CHUCK:  Or is it more complicated than that? ALEX:  Nope. We operate in TC39 under what’s called a champion’s model where if you’re really hot under the collar about a particular idea or a particular technology, you come up with a proposal and you put it on the agenda for a meeting. And that does mean that you probably have to be in meetings in order to move something forward or find someone who is. But if you’ve got something that you’re particularly passionate about, please reach out to me. I’m not hard to find online. There are lots of good ideas that are out of scope of JavaScript the language. But there are other places where a similar model works. The W3C, specifically at wg, it’s very easy to be a voice for a particular thing. The most important factor in success or failure of being an advocate is being able to find people who are implementers to work with you to go verify whether or not your idea will fly. And then go and try and be reasonable, as reasonable as you possibly can, and do the quiet behind-the-scenes [inaudible] diplomacy to get to people who are going to be most invested in your idea, excited about your particular design. And that’s not something you can force. And it’s not a defense of smoke-filled rooms in any way. It’s just an acknowledgement that standards are people. It’s like soylent green, right? It’s people trying to be the best they can. And they often need more information to do that than they have right now. And so the best thing you can do to try to advance the cause for a particular feature is to give those people that information or help them see it your way. CHUCK:  Mmhmm. ALEX:  And there’s no secret sauce to changing minds, right? [Laughter] ALEX:  But being a dick is probably a quick way to not change anybody’s mind. CHUCK:  Yup. How do most of these conversations happen? You mentioned meetings. But isn’t there also a mailing list and things? ALEX:  Yeah, there is a mailing list and it’s relatively high traffic, ES Discuss. There is now ESDiscuss.org I think, which is an incredibly useful frontend onto the mailing list and es-discuss summaries on Twitter give you a pretty good sense for the tone of the debate, which is really good. It’s worth noting that we’re switching to a new process in ECMAScript 7 which I’m incredibly excited about. And this is all down to Rafael Weinstein, the man behind Object.observe and mutation observers in DOM. This new process looks a lot more like the train model that we use for Chrome releases where new features get accepted. They’re small and the thought is once a year there will a be a new version of the spec and if your feature didn’t make it in, if it didn’t get to the end of the process before that train left the station, then it’ll just be on the next one. Because right now, the way we’ve been doing ECMAScript revisions has been this very long monolith project. And I got initially involved in standardization for JavaScript in the battle days of ES 4. I don’t know if you’ve heard anything about that. But it was as bad as anybody says it was. I guarantee it. And it failed. We had a release that totally failed. ECMAScript 4 never saw the light of day. It was huge. It was a multi-year effort and it got us nothing. There were a bunch of targeted small fixes that came out of it for ES 5, some of which have been over time shown to be great, some of which are a little bit problematic. But in general, ES 5 happened because it was small and target. ES 6 has taken a very long time, longer than any of us had expected or hoped. And part of that is down to that integration process that I was talking about earlier. You really do need to sit down and spend a bunch of time thinking of how each feature is going to interact with each other feature. And it’s very difficult to do while you’re designing a feature. So, the idea here behind this new process is that we will get more complete features into the pipeline earlier and get them into drafts and see how they shake out. But a one-year timeframe gives you enough time to consider a bunch of things without having to stop the whole world when somebody wants to add something new. It’s up to that person to then go try and do a bunch of that early integration. And you don’t have to hold up the entire train of potentially done features. So, the spread and rest operators have been done for a long time, class syntax has been done at least for probably 8 to 12 months now. Those are things that probably could have shipped in a release that we didn’t have, a release ready to go out the door for. And they’ll be in ES 6 but it’ll be nice to not have to hold the line on features like that and give [inaudible] to go start putting stuff into their browsers early without the risk on the basis of a new full revision earlier rather than later. CHUCK:  Are there things that you find that people misunderstand or misconstrue about TC39 or ECMAScript or just this process in general? ALEX:  Where to start? [Laughter] CHUCK:  What are the big things or one or two of the big things? ALEX:  Okay, so let me start by saying that there’s a hierarchy of toolmakers, right? And I have sat in many of these chairs. I haven’t necessarily done them well, so you can critique me and my work on all of these levels including the work that we’re doing in TC39 as being just bad. That’s fine. But I think that the model holds, which is that you have people who are building just sites. You’ve got people who are building tools for people who build sites. You’ve got people who are building tools for people who build tools who are building sites. And then eventually, you have people who are building the platform itself. And maybe those middle two tiers fold into each other. It’s hard to tell. But you know, npm is a great example of a tool for people who build tools. And then Node modules are a great example of tools. And then you’ve got people who are consuming them and putting them together in individual packages or products. The same thing holds from the client side where you’ve got Bower which is a tool for people who build tools, et cetera, et cetera. And so the language is the slowest moving, one hopes, in some ways, but most powerful area for us to change. You can make relatively small changes that have a very large impact that’s outsized. So they’re sized to what you would expect to happen as a result of a relatively small change. But the result is that you have to serve a much larger constituency. At each of those levels, the set of people that you are trying to do right by gets larger. And so the conflicts potentially between those people and what they think is right gets larger. Does that make sense? If it’s true that you can’t please all the people all the time, that gets ever more true the larger the group of people is that you’re trying to serve. And TC39 and most of the other web standards bodies are trying to serve the entire world, or at least the developers who have to build things for the entire world. So one of the pathologies that I think we see about people who are trying to just jump in and change something in the standards world is that they assume that because something is important to them, it’s important to everybody else. So one of the most important things you can bring to the discussion is empathy. You definitely need to have a view and be able to make a case based on what you think everybody else will need. You need to be able to gather data. And data is… Empathy is easy when people are telling stories, but the plural of anecdote is not data, I guess is the quote. So gathering data and being able to make a larger story about what people are doing in aggregate is an incredibly powerful tool. It’s our best storytelling technique for making the case that something is an important feature for the web. So for instance, the fact that all of the JavaScript libraries that I can think of, when they get to a particular size all grow their own module system, lends incredible weight to the idea that we as a committee should go take that burden off of the tools themselves and go put it in the language. It’s a good argument for prioritizing modules over other things people might care about. Does that make sense? So, one of the misconceptions is that because it’s important to you, it’s important, and I think that’s probably the tip of the iceberg but I guess I’ll leave that one there. The other ones are to do with who’s doing what and why. And I think it’s just important to remember that the people who are working on these committees are people. And they have a particular experience and they’ve got shortcoming and faults like everybody else. And you can expect more of them than you would maybe someone who’s sitting in a seat with less power. And you should call them out for doing things that are in your view destructive. But making change is the predicate for making things better. And so you should expect them to try to make change. And when they don’t, I think that’s the worst thing. And that’s not usually what we get purloined for. [Laughter] ALEX:  People are usually angry that we’re not making changes in exactly the same way they would have. And I think that’s generally shortsighted. The longsighted view is to suggest that we’re not making enough change quickly enough. CHUCK:  So, one other question I have related to this. It seems like when we talk about a lot of this stuff around ECMAScript and JavaScript, most of the references you’ve made have been web-focused. And I’m wondering, do you into consideration very often things like Node.js or some of these… ALEX:  Yeah, absolutely. CHUCK:  Server side systems and… ALEX:  Sure, absolutely. But it’s worth noting that server side systems have it easy. And I think this is an important point that usually gets lost in the debate, which is that if I’m building something for a server side system, I generally speaking get to call the shots in terms of the deployment environment. I also get to call the shots in terms of often the hardware, or at least I can make reasonable constraints about them. The available bandwidth to get code and to run code and the available CPU aren’t necessarily infinite but it’s certainly knowable, if not individually certainly in aggregate. It’s just this sort of thing that you have much less ability to change in the client. The client is a harder target. And anybody who tells you that the server is harder is lying to you, lying to you. I’ve been on both sides. And I can tell you that they are lying to you. It’s like someone who’s a server engineer saying that client side engineering isn’t very, or that they’re building websites. That’s just the HTML, right? CHUCK:  [Chuckles] ALEX:  Yeah, right. I’ll happily have you come in with my three-column CSS that has to be compatible everywhere, right? CHUCK:  Yeah. ALEX:  Let’s talk about that. So it’s worth acknowledging that different skills, they can all be hard. But the constraints that you got in the server side environment are generally easier. And so between being able to consume new features fastest, people who are using Node or are using other server side deployment environments for languages generally get to call the version of their VM. And that usually means that they get to use newer features faster until it’s like a pervasive thing. You might get stuck in a Java shop having to support Java 1.4.2 forever, effectively, certainly longer than a [inaudible] life cycle. But if you’re working in Node, you almost always get to say, “Use the latest Node. Use the latest npm package.” And they’ve done a good job insulating some of their users with semantic versions from some of that churn. But I think in general, it’s just easier to come up with an environment and a deployment story that makes sense for you than it is on the client. And so between there being many, many more web users and web developers than there are server side JavaScript developers and there being a much easier on ramp to using new stuff on the server, I think we definitely owe the client as much attention as we can give it. In part because if you let a server’s easier requirements dominate, you do things that are suboptimal for the client which you just can’t recover from like you would be able to when you have more resources like you do on the server. AJ:  So question: Are there people that are on the committee that are core people in the Node community? ALEX:  The Node community has chosen not to represent itself I think is the easiest way to put it. It would be great if someone from one of the large Node-hosting firms were to sponsor someone from the Node community to come to meetings and advocate their view. We do try to be responsive to them, but I think it’s worth noting that there has been a lot of back and forth about this. And a lot of it comes down to different expectations about how things can run. The module system is in particular very contentious in a way that I find, frankly, astonishing. The argument seems to be you guys shouldn’t do a module system because then people will use it. [Laughs] It’s like, “What?” I thought that was the point. AJ:  I have noticed a peculiar thing about the Node community. There are some people at the head of it that have this anarchist attitude, which I think is really strange. ALEX:  Oh, that’s fine and it’s fine for them. But the job of the standards committee is to serve everybody who’s not them. AJ:  Well see, but here’s the… I would love to see some Node representation in the committee. I guess if they don’t want to do it, they don’t want to do it. Maybe we can all just, all 20,000 people that listen in, like at Joyent, and say get someone from Node on the committee so that Node doesn’t do crazy awesome things that then cause problems and vice versa, make sure that Node actually takes advantage of things that are coming down the pipeline. ALEX:  It’s worth noting that Node has the opportunity to take advantage of new stuff just as soon as it’s in V8. So they’re privileged from that perspective. Node gets the best of this stuff. So they would be an ideal testing lab and initial deployment environment for a lot of these new features. They would be the best case scenario users of new language features. AJ:  I just think it’s been really strange how Node’s been around for a couple of years and there have been new browser APIs that have solved the same problem as the Node APIs. And now Chrome’s coming out with their, not server side but if you will, server side platform. And so we have these couple of different platforms that are really, really close. And I would love it if everyone got on the same room and were like, “Oh well yeah, it’s only two keywords different for us to do it this way and that way.” Like the array buffer implementation or the module system or other small things like that that hugely, hugely affect your ability to reuse code. ALEX:  Yeah. I think I have some experience there. I worked for a company called JotSpot for a while where we were building an application platform that we disguised as a wiki. And it was JavaScript on the server side and JavaScript on the client obviously. In two thousand and, what was it, six? [Chuckles] 2007, can you imagine? And it turned out that our ability to share code was relatively minimal because I guess at that point clients weren’t able to be nearly as modern as servers, although that’s changing pretty rapidly. And at the same time, we did discover that the different constraints that you have specifically about being able to load code quickly on the server change what you were willing to do. I hope that we can actually get to a point where we can share a lot more stuff once we have the service worker implementation. Because that will let us more cheaply cache a lot of stuff that we’d like to be able to depend on in our apps. We don’t have that yet, but it’s coming. So yeah, I think there’s a future where we’ll share more stuff. Like I said, I hope that like you say, the folks at Joyent, the folks at other, Heroku, other large Node beneficiaries will find willing folks from that community to come help us out and design things with us. But folks like Domenic Denicola are pretty well-known in the Node community. He’s definitely made the transition. He’s helped us out in terms of getting promises finally pushed over the line late this year. So you know, like I said, standards are just people. It’s just people trying to do the right thing. And so to the extent that those people want to participate, it’s generally the case that they can find a way to do it. CHUCK:  Awesome. So overall I’m kind of curious. What do you hope people get out of the conversation that we’ve just had? ALEX:  Please don’t be a dick. [Laughter] CHUCK:  That’s good advice for a lot of people out there. JOE:  I feel comfortable saying mission accomplished on that one. CHUCK:  Yeah. [Laughter] ALEX:  I think the way to put it that’s maybe more tactful is that when it comes to making progress in the world, convincing everybody else that you’re right is significantly more important than being right about specifics. You have to be right in general. You have to have the right shade of it. But getting everybody else on board is a thing that most people are, at least in our community, are less able to think of as being a good thing versus an absolutely correct technical answer based on all of the particular constraints that you’ve got in front of you. The idea that you might get an answer that’s good but not great, and that that might still deliver an enormous value is something that as trained engineers where you get zero points for getting the wrong answer, is something that is very much a cultural norm that we have yet to build facility with. [Laughs] Does that dress it up enough? Just please don’t be a dick. CHUCK:  [Laughs] Great. Awesome. JOE:  Very nice. CHUCK:  Alright, do you guys have any other questions before we get into the picks? JOE:  I was curious. What feature do you personally hope most makes it into JavaScript? ALEX:  Traits. So we’ve got classes but we have no composition mechanism for classes. Inheritance is a pretty weaksauce way to go build stuff. So the way that we build large systems, or that I build large systems in JavaScript, has been a mix of inheritance and mixins. And so mixins are the way you do OtherClass.call(this) in your constructor, if you know what I’m talking about, and copy properties in. And that’s a really productive way to go use compositions that have inheritance to construct aggregate things that are bigger. And if you’re going to try and build a system that scales and not copy a lot of code and not have this terrible back pressure on an inheritance hierarchy where you wind up moving things up the inheritance chain just because some random subclass over there might need it too, composition is the way forward. And JavaScript badly needs a composition mechanism. We didn’t get it done in ES 6. It was hard enough getting classes past some of the folks in the committee, and not for the reason you’d imagine. But now that we’ve got them, we have an opportunity to do a good job by putting together an official version of the mixin pattern here, too. And I’m really excited about that potential. JOE:  Awesome. So here’s another off the wall question. Which backwards compatibility issue do you hate the most? CHUCK:  That is a good question. [Chuckles] ALEX:  You’re going to have to give me a minute. [Laughter] ALEX:  It’s a very long list. [Laughter] CHUCK:  I want a blog post now. Just put the list on a website somewhere. JOE:  Yeah, really. CHUCK:  These make me crazy and here’s why. JOE:  [Laughs] ALEX:  I think the one that makes us least able to have nice things is Automatic Semicolon Insertion, ASI. Yeah. CHUCK:  So, I have a question about that. Because it seems like it’s something that’s built into the browsers and stuff… ALEX:  Oh no, no, I take it back. It’s not ASI. It’s got to be +=. It’s got to be the plus operator and the dot operator. Oh, dot operator. I’m sorry. Like I said, I can’t choose. [Laughter] ALEX:  The dot operator is the craziest part of JavaScript. In case it’s not clear, the way dot works to both dereference things and to set up the caller is super clever and super insane. It means that we can’t ever have bound methods. You can’t rely on them even if they are. And it just constrains our ability to design other features in a way that makes sense with regards to the thing on the left-hand side. AJ:  What were those two things you mentioned? What were the two parts? ALEX:  Oh, for the dot operator? AJ:  Yeah. ALEX:  Yeah, so you know how other languages, if you have a class, you usually get bound methods? CHUCK:  Yes. AJ:  Yeah. ALEX:  Like I can extract a method and call it and it’ll still have the ‘this be the thing’ that I pulled it off of. AJ:  Yeah. ALEX:  Yeah, it is nice. JavaScript doesn’t work that way, which means that… AJ:  Passing [inaudible] is nice. ALEX:  Yeah. Passing callbacks around is a real pain in the ass. CHUCK:  So, what is the two-minute version of how that works? ALEX:  The two-minute version of how? CHUCK:  The dot calling notation works. ALEX:  Yeah, so the way dot works is that you have an object and you say dot and that extracts the thing on the right-hand side using an index lookup. And then if there’s parens, it calls it. But through magic it doesn’t just call it. It calls it and says, “Ah the thing on the left-hand side of the dot over there is the thing that you’re going to be called in the scope of.” Does that make sense? CHUCK:  Uhuh. ALEX:  Yeah. And it’s that little magic. It’s that little, “Aha wink, wink, nudge, nudge,” moment where it goes, “Ah yeah, but look just behind you over there on the left-hand side of the dot. That’s your caller,” that means we can’t have nice things because if means that if you just [detract] a method normally and don’t have the parens, it won’t be called which means that you lose the thing that extracted you. And now you’re just a function floating free in space. Does that make sense? CHUCK:  Aha. Okay. AJ:  So, if there were an ampersand for when you want to pass… ALEX:  Yeah. AJ:  Like [arguments] in C, that would make it easier if that operator for passing a reference were separate from the operator for looking up the caller. ALEX:  Yeah. I’ve proposed something like what I call soft-binding a couple of times now and the committee thinks it’s a good idea. And it’s got problems. Just because of the way JavaScript works, it means that it’s incredibly difficult to repair. But I think between that and Automatic Semicolon Insertion, they probably screw about the same amount. CHUCK:  Now is Automatic Semicolon Insertion an official part of the language? ALEX:  Oh yeah, you bet. There is definite text in the spec for ASI. CHUCK:  Okay. JOE:  It’s part of the grammar. CHUCK:  Because when I first heard about it, I was like, “So is that just a convenience thing that the browser does?” Okay, so that makes sense. So there are actual, “This is how this is supposed to work and the rules are the way the rules are.” ALEX:  Yeah. JOE:  We’ve designed this language to be broken on purpose. [Laughter] ALEX:  And I assume that it started as someone doing exactly what you said. It was probably just, again I wasn’t on the committee at the time, I assume that just made it in as some browser vendor was like, “Yeah it kind of sucks. You should just be able to figure out where the semicolon is in these cases.” And they did it and then boom. Now you’re stuck. [Chuckles] CHUCK:  Yeah. It just seems like there are some weird cases where you would expect it one way and you get it another. And it also varies. Like if you’re used to one language that does that kind of thing one way and another language that does it a little bit different way then yeah nobody’s happy with the way that it handles certain cases. ALEX:  Yeah, yeah, yeah, so just shrugging it off and making it an error would have been right. Well in retrospect, might have been a better thing to do. The right thing to do was a [inaudible] judgment that I can’t make. But yeah, it might have been a better thing to do. CHUCK:  Right. But now that it’s in, if you try and pull it out, then you break a whole bunch of people’s stuff. ALEX:  Yeah. That’s a no go, yeah. AJ:  So what are the possibilities for creating a second language? Both Google and Microsoft have tried to do it. But obviously, Microsoft’s not going to want to play with Google and Google doesn’t want to play with Microsoft. So the idea that… And then Apple just does their own dang thing and doesn’t even look either way at anybody. And it seems like a real great solution would be to have a separate language, but is there any chance that a committee could get those three big players to agree on something? ALEX:  Oh don’t count out Mozilla. You need four players. [Chuckles] AJ:  Well, but Mozilla is pretty easygoing. They’re not a problem. Nobody is like, “Oh that darn Mozilla. They’re the reason we can’t have nice things.” [Chuckles] They started us having nice things. If it weren’t for Mozilla, the web would suck. ALEX:  I agree with that. CHUCK:  I think there’s more to the story in just about every statement you made about every company you said something about there. ALEX:  Yeah, that’s fair. Microsoft actually probably did more for the web than any other company I can think of until the middle of the last decade. Honestly, if IE hadn’t stopped so far past the mark of being better than Netscape, we would never have had serious web apps. There’s just so much… Anyway, I’ll stop my little fan boy moment with Microsoft. The way I put this is that sort of because of the game theory involved, trying to get all those players to coordinate about a new thing, the replacement for JavaScript will be the next version of JavaScript. Does that make sense? CHUCK:  Mmhmm. ALEX:  You could try to bootstrap a “new language” but I personally, and this is just my personal view. This is not a Google thing. This is not anybody else. This is just me looking at the pieces on the board going, “Hmm.” AJ:  I was kind of assuming that was everything you said today. ALEX:  Oh, good. Ah, good. CHUCK:  [Chuckles] ALEX:  The way I look at this is that it just seems, and perhaps this is a lack of vision on my part, but it seems implausible to me that you’re going to incentivize all of these players to go coordinate on another language that’s very much like JavaScript, which JavaScript could eclipse most of the virtues of in the near future. Look at things like asm.js out of Mozilla or a bunch of the features that we’re adding in ES 6. We’re able to actually go and take value off the table with new versions of the language and with new versions of the DOM APIs that takes some of the breathing room away from other up and coming languages that might fill the same niche. And that makes getting the agreement between all of those parties to go implement a new version of something else and make it compatible with the web… To me it just seems almost insurmountable. Good luck on anyone who’s willing to try and who has a language that’s compelling enough to make that a real possibility. CHUCK:  So what I hear you saying basically is that because JavaScript solves enough of the problems in a reasonable enough way, and because it could conceivable move ahead to fill the space that a lot of these other value propositions that a new language would have, there just isn’t enough of a value proposition for a new language to be built that everybody is going to agree on that makes a ton of sense? ALEX:  Yeah. And as JavaScript continues to improve and as JavaScript VMs continue to improve as compiler targets, again look at asm.js, a lot of the optimizations that we’ve done in the last couple of years make other languages like CoffeeScript and even the Traceur output that much more performant. You have to have a really compelling mega-feature to get developers to jump from one to the other. For instance, the way you use TypeScript today is you run it in JavaScript. And the way you use Dart today is you run it via JavaScript. And the same thing is true for [inaudible] and CoffeeScript and a lot of other languages that you could imagine could have more efficient and more highly optimized runtimes. But in the name, to get the reach that you really want, you’ll probably be running them on top of a JavaScript VM for the foreseeable future. CHUCK:  I also wondered too if there’s… If we did invent another language, would we just be inventing a new problem set for us to solve 10, 15 years down the road just like where we’re at with JavaScript right now? ALEX:  Oh yeah, absolutely. That is the legacy of legacy. As soon as your platform is a successful one enough to encourage you not to change it quickly anymore, all the problems that you thought were relatively small will become enormous. Look at Windows. Windows is the product of its own success, for good and for ill. CHUCK:  Mmhmm. ALEX:  Same thing is, I guess less true of iOS but they don’t really care so much about having enormous reach. They just would like to have, I guess from my view, it seems like they would like to have all the people with lots of money as opposed to without lots of money. But Android has a real backwards compatibility burden out, too. And this is just what happens when you’re a successful platform. The real question is can you as a new platform provide enough value to eclipse the last thing that’s got a lot of legacy baggage? Can you provide enough of a value in that delta to go make it worth doing? And that’s just not something that falls off a tree. You have to really be running at it. It’s hard to do. Like I say, good luck to anybody who thinks they can. It’s a really ballsy thing to do. I work on JavaScript because I view our problem as not really being a language issue. I think that we can definitely improve the world via the language. But I think our large problems on the web are platform issues. How do the bits play together? How do they integrate? How do they talk to each other or do they talk to each other at all? So my view is very much that improving the language that we program the web with can have some value. But there’s a lot more bang for the buck to be had in fixing DOM and fixing the way we build component systems and fixing the way that pieces talk to each other than there is in changing anything about the language at all, including its speed. CHUCK:  So, one last question that I have and that is, do you think it will ever be possible for us to sunset some of the features of JavaScript that are painful? ALEX:  That’s a really good question. CHUCK:  Will we get to the point where we’ve got some of these other tools that make the pain with this mostly defunct and so if we remove it it’ll allow us to move forward in other ways? ALEX:  I don’t know. There are some places where we’ve been able to talk ourselves into a position where we’re like, “Yeah no one’s using that,” and make some changes that would be backwards incompatible. This is the same burden that everybody on every major platform that’s successful has. Can you change the behavior of a Windows API? Only if nobody’s using it. [Chuckles] Can you take features off of the web today? The answer is really, only if nobody’s using it. So for instance, we’re talking now on blink-dev about removing XSLT support from Chromium. And the question is who’s using it? It’s not whether or not there’s a spec for it or whether or not it’s the right thing to do. It’s just a question of is it paying for itself? Is it a feature that we would like to continue to have to support or have to continue to support? And what does it cost us to continue supporting it? And that is definitely a case by case kind of decision that you answer with data. So from the Chromium perspective, we’ve got what we call use counters which are a great way of us figuring out what percentage of the web’s traffic actually uses a particular feature and getting that kind of data out of JavaScript is probably going to be the way that we’ll ever be able to make a case for or against particular problematic features getting dropped. AJ:  So heard a rumor that the blink tag isn’t going to be supported in Blink and here you are talking about features that you know everyone uses. CHUCK:  [Laughs] ALEX:  Yeah, yeah. It’s a tough one. I’m kidding. It helps that CSS marquee is now in place and you can blink things using CSS in many cases. So you’ve got options. And you can make a blink Web Component. So welcome to the future. [Laughs] CHUCK:  Yay! AJ:  So, are you also going to get rid of marquee as well as blink? Because that would be awesome. There are so many websites I would visit more often. [Chuckles] ALEX:  I don’t know. I would actually have to go look at the use counters for marquee. I will note that the CSS working group has recently ratified a marquee specification, CSS marquee. Go look it up. I’m not kidding. CHUCK:  Alright ALEX:  Well, on that downer. [Laughter] ALEX:  No, actually marquee is an incredibly important feature for much of the world where text doesn’t fit immediately and you may have very long words or you may need to scroll in vertical areas in order to get the full meaning of something that wouldn’t otherwise fit. So marquee is not a feature that the web can actually take away because our English language preferences aside, it’s just something you need in other places. AJ:  So, what you’re telling me is pretty soon, I can expect that my Kenwood MP3 player in my car will be running JavaScript for that little title show feature? ALEX:  Yeah, you bet. CHUCK:  Eventually, everything’s going to be running JavaScript. ALEX:  No, no, no. That will be CSS. You can do that in CSS. CSS can do that without JavaScript. AJ:  Oh, okay. So, they’ll just have a little CSS chip on the board there and makes it marquee for me. Okay, cool. ALEX:  I think given the price of the CPU, it will be sentient soon enough. [Laughter] CHUCK:  Perfect. Alright, let’s get to the picks. Joe, what are your picks? JOE:  Right. I’ve got two picks. The first one is an iOS game. It’s called Death Tower. And I picked this up. It was pretty cheap. And it’s kind of like a little mini-RPG where you just go from room to room. And it’s really quite addictive, 8-bit type graphics. Super fun, very cheap, but really just had a blast playing it. So I’m going to pick that, Death Tower. And then the other thing I’m going to pick is the Samsung AirTrack, which is a soundbar. I just picked one up and installed it last night and I was so pleased with it. We just don’t have enough volume coming out of our TV. We needed more volume which is the only reason I bought it. And it’s so small. It fits perfectly right underneath the TV. I had no idea that it did this because I just never bothered to care because all I was really looking for was just more volume, but it has Bluetooth. So, I was able to hook up my phone to it and play Pandora over the speaker just by being in the same room. It was so nice. I just absolutely love this. It comes with a big subwoofer that puts out really great base which is also wireless by the way, which was very cool. So, I really enjoyed, I really like having that AirTrack. It’s a lot better buy than I thought I was going to get. And that’s my picks. CHUCK:  Awesome. AJ, what are your picks? AJ:  I’m going to pick the movie ‘The Host’ because it was actually a really interesting thought provoking movie. And it had terrible reviews. So when I first was getting it from Redbox, I had the expectation that it’s just going to be something that I was seeing in order to make fun of it, like when Twilight came out and for the first week every time I was with my friends, I just randomly unbuttoned my shirt and pull open my chest hair and say, “Sparkle, sparkle, sparkle.” I was kind of hoping for something like that but it turned out to be completely different. And then it was a good movie [chuckles] that wasn’t just pure nonsense entertainment. But it actually has a story to it and it’s kind of cool. So I know it’s a little late. Everybody else that wanted to see it has already seen it. But don’t pay attention to the 5 out of 10 on IMDB. It’s actually interesting. CHUCK:  Yeah, have you read the book? I’m just curious. AJ:  I have not read the book. But I have it both in English and in Spanish sitting right here. And I’m going to try to learn Spanish more by reading it a chapter at a time. So, I’ve started on the first chapter. CHUCK:  I think the book was solidly good and I thought the movie was solidly mediocre. AJ:  There were a couple of parts where the acting was subpar, but I didn’t feel that it was so bad that it detracted from the movie, especially in consideration of lots of other movies that are extremely popular with very poor plotlines and poor acting. CHUCK:  Interesting. Alright, well I’m going to jump in with a couple of picks. The first pick that I have is ‘The Desolation of Smaug’ and that is the new Hobbit movie that’s coming out next week as we record this, this week as you listen to it, if you got it when it came out. And I’m just really excited to go see it. My wife actually got me tickets for my birthday. And yeah, I kind of dropped a hint that it had to be 3D IMAX. So, I’m thrilled. I am totally excited to go. So on the movie front, that’s something that I’m really enjoying. I’ve also been enjoying along the same entertainment lines, the classic Doctor Who videos. And they’re black and white. They recorded in the 60’s. I got into the show with the newer revitalization of the series. ALEX:  David Tennant or before? CHUCK:  Chris Eccleston. ALEX:  Yeah, yeah, yeah. CHUCK:  I got started with that. David Tennant is definitely my favorite Doctor so far. And I think my favorite companion was Amy Pond. But anyway, I love the series. So I started watching them and then I started listening to a podcast by a friend of mine named Samuel Lewis. And he has a podcast series called ‘Going through Who’ and he’s going through all of the classic who and talking about the stories and things like that. And so he’s actually got ‘Doctor Who Guide’ where you can go and get all of the past episodes. I believe you can also get them through less legitimate means like BitTorrent. And so then, you can watch them and then you can listen to him and his panel talk about them. And it’s been a really fun podcast to listen to, especially going and watching the show and then comparing notes. Yeah, that was a little funny the way that they filmed that, things like that. ALEX:  Awesome. CHUCK:  So, it’s really good. So, I’m going to pick both of those. And then my last pick and I might have picked this last week. I’ve been listening to an audio book called ‘Duct Tape Marketing’ by John Jantsch and I’m really enjoying it. It’s just been really awesome for my freelance business. It gave me some ideas with some things that I can do or do better. And so if you’re interested in that, running your own business, doing any kind of marketing for an open source project or anything like that, it’s a terrific book and you can go pick it up. I’ve been listening to it on Audible. So either way is great. Alex, what are your picks? ALEX:  Oh, I guess I mentioned earlier ‘Unlocking the Clubhouse’ which is a wonderful book which I recommend everybody who has anything at all to do with computers, please, please, please read. It’s a data-driven analysis of why we don’t have nearly the representation that we should in our industry among women and girls. And it lays it out both in data and in a series of stories told from the perspective of people going through the process of trying to become computer engineers. And it’s wrenching. And even though it’s written in 2003 I think, it’s still an incredibly valuable insight into what’s wrong with our industry, one of the things that’s wrong with our industry. On a happier note, I’ve been playing a lot of the new XCOM expansion, 'XCOM: Enemy Within. And if you are a fan of XCOM and you have not already picked it up, I highly recommend you do it. The new game dynamics are a lot of fun. I guess I’m kind of addicted to XCOM so I would say that, but yeah there it is. Oh, there are new episodes of ‘Have I Got News for You’ and ‘Only Connect’ on the BBC so if you can get those, I can’t recommend them highly enough. My wife and I spend a lot of time watching those. So I’ve got lots more stuff that I like, but I guess I’ll leave it there. CHUCK:  Awesome. Well, thanks for coming on the show. It’s been a terrific conversation and really interesting to get a behind the scenes look at a lot of this stuff. ALEX:  Yeah, thanks so much for having me. CHUCK:  Alright. Well, we’ll wrap up the show. We’ll catch you all next week.

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.