the panelists discuss the ES6 module loader polyfill, SystemJS, and jspm with Guy Bedford.

Special Guest: Guy Bedford.

 

  I like the idea of explaining, of dangling the carrot like, “This is what you could have.”

  Hey everybody and welcome to episode 115 of the JavaScript Jabber Show. This week on our panel, we have Jamison Dance.

  Hello friends.

  AJ O’Neal.

  Yo, yo, yo, coming at you live from where I am.

  Joe Eames.

  Hey there.

  I’m Charles Max Wood from DevChat.TV. And I have the recorder running this time. We also have a special guest this week and that’s Guy Bedford. 

  Hi everyone. 

  You want to introduce yourself really quickly?

  Yeah, sure. I’m a web developer based in Cape Town, South Africa actually where I get to work on a travel website. But I really enjoy working with a lot of open source projects and have got quite involved in the open source community recently. In particular, projects I’ve been working on are the ES6 Module Loader Polyfill, SystemJS, and jspm. Yeah, so that’s it.

  And those are all module libraries, right?

  Yeah. They’re libraries focusing on very similar problems, which is dealing with how to manage modules in the browser. So, the ES6 Module Loader Polyfill provides ways with dealing with ES6 modules in the browser. But today, SystemJS builds on top of that making it more useful just like Polymer does for Web Components. And then jspm is a package manager for the browser looking at how we can tackle some of these package management problems. 

  Got it.

  So, SystemJS is a library built on the idea of ES6 modules working in the browser. Is that a good summary?

  Yeah, exactly. 

  I mean, would SystemJS exist if ES6 modules were shipped right now?

  Yes, it builds directly on top of the Polyfill. 

  Okay.

  So, if ES6 modules were in the browser, SystemJS sits just on top of them. And it basically adds things to make them useful, like loading AMD modules as well. So, it has a compatibility layer so you can also load AMD modules in the browser, load global modules with a shim, those kinds of ideas. 

JAMISON:   So…

  This sort of, sorry, yeah?

  I was just going to say, let’s say I am a web developer who has found one of the module systems out there like AMD or CommonJS with Browserify, or whatever, and I’m muddling my way through it. Why do I care about all this new stuff coming? Why do I care about ES6 or things built on top of it like SystemJS or jspm?

  If you are currently dealing with AMD or CommonJS or something like that, it’s something that you should care about for the future. Right now in your projects, you probably want to stick with simple ways of doing things. And if you aren’t already interested in using ES6, it’s certainly something that’s worth thinking twice about. But the future we want to get to is one in which we have a module system for the browser that allows us to write code in the same way and share code written in similar ways, and to be able to load and build that code in similar ways. And without that, we’re going to continue to have a very fragmented environment, making it much more difficult to share code. So, it’s all about enabling code sharing and enabling strong conventions around how to work with modules. Module management is something every other language has. And we can only really get package management right for the browser once you’ve got a proper way of doing modules in the browser. 

  So, I’m curious. How do modules change the story of building applications in JavaScript going forward? Especially the ES6 module specifications. 

  So, do you mean in terms of how you approach the process of putting together an application?

  Yeah.

  Or the actual build itself? Okay. I suppose the most important thing about modules is you want a way to just be able to require a component in your page. And it’s a problem that we all deal with in web development, is how do you properly isolate your views? And this is something that modules can potentially help with. Ideally, you’d have a world where you could just say, “I want to require this login form,” and then stick it into my page. And you would just be able to then use that functionality. And this is something Web Components work on as well. And we’re dealing with ways of making Web Components work with ES6 modules. But we’re all very much working on the same sort of problem, which is coming up with the work flows for how to make this stuff work easily in the browser.

  Yeah, that makes sense.

  So, do you want to talk a little bit more about each of those projects? The ES6 module polyfill?

  Yes, ES6 Module Loader Polyfill.

  Okay. ES6 Module Loader Polyfill. What does that do?

  Alright. So, the ES6 Module Loader Polyfill is exactly what it says it is. So, to explain that I suppose I should tell you what the ES6 Module Loader is. When you write module syntax in the browser, you’re writing in import statements. And that’s telling the browser to go off and fetch that module, execute it for you, and then run your code after it. For example, if I have a piece of code that’s dependent on jQuery, I want to write import jquery and then it’ll run that first before running my code. 

So, how does the browser do that? Well, it has its own module loader that will go and deal with this stuff. And this is a module loader that’s defined in JavaScript. So, it has a fetch function. It has a way to know where to find jQuery and these kinds of things. And this is all specified through the loader hooks of the module loader. So, the module loader polyfill basically was this exact same loader with the same hooks and the same functions as you would get in the browser when it’s implemented. Does that answer the question? I’m sorry.

  Yeah, it does. So, that seems like a difficult thing to polyfill. It’s not, how do I explain it, it’s adding new semantics to JavaScript, not just new syntax, right? How do you polyfill something like that where you’re not just translating the source into some… I’m struggling to ask this question clearly. 

  Yeah, certainly. So…

  Well, yeah. Do you want to sound off the question for me?

  Say the thing I was trying to ask. [Chuckles] And then answer it.

  So yeah, obviously we don’t want to be loading ES6 in the browser passing it into a parse tree. And we use Traceur to do the parsing, which itself is 500 kilobytes. So, it’s not exactly suitable for production. That’s what you do in development. In production, because of the fact that this loader has the ability to have compatibility layers for AMD, CommonJS, for globals, we can actually build our modules into something that isn’t ES6. And then we have a loader that will support that with the right compatibility layers so that you can use that in production. So, it’s just a build step that builds the modules’ intermediate format that allows them to work the same way.

  So, does that mean the dream of being able to use AMD and CommonJS and ES6 in the same project, is that real? Can I do this?

  Yeah, you can do it today with SystemJS.

  Cool, alright. That was a good segue. So, we’ve moved on to SystemJS. That’s the compatibility layer you were talking about?

  Yeah. So, SystemJS builds on top of the ES6 Module Loader. And it supports existing AMD modules. It supports CommonJS modules like you would get from npm. And through a shim config, it will support globals as well. If you’re familiar with RequireJS, it’s very similar to the sort of thing you’d write with an AMD-style loader. 

  So, I assume it compiles all of those down to some intermediate format? Is that how it works?

  It can actually support AMD and CommonJS directly, without needing to compile them.

  Oh, wow.

  And that’s because it’s got this compatibility layer which can just change the execution environment of the underlying module files. So, it deals with module sources. The loader is actually XHR and eval-based, because the spec is based on parsing sources. So, suddenly that gives us the opportunity to be able to rewrite the code slightly and make sure that everything’s given the right environment. 

  So, when you say it’s XHR-based, that means built-in support for loading modules on the fly in…

  Yes, exactly. 

  That’s something. Well, so you’d use that to split up parts of your app in production basically, right?

  Yeah, so…  

  Oh, go ahead. 

  No, sure. Go on. 

  Oh, I was just going to say, so you spoke about SystemJS and jspm a little bit at MountainWest JS Conference. And one of the things you mentioned was some support for HTTP 2.0 and some of the cool production things that enables you to do. Can you talk a little bit about that, too?

  Sure. So yeah, it very much carries on from your point about dynamic loading in the loader. 

  Sure.

  So, the way the loader works normally in the browser is it’s requiring everything with separate requests. So, today if you use Browserify you’re building everything into a single script. So, there are very different ways of going about this sort of thing. But the idea is that in ES6, you are sending separate requests in an environment in a few years’ time where HTTP 2.0 is fairly widespread. So, we can assume the existence of HTTP 2.0 in the timescale of the spec. And the problem of having lots of separate module requests is no longer the issue that it is today. 

So, in that kind of a world, you don’t have to worry about bundling, which is very convenient. You can just make the requests as you need them. And that’s really nice for dynamic loading as well. Today, we can still bundle. And that’s what we need to still continue doing today. And then you end up tiered bundling approaches. And we’re solving all these problems as well. But a lot of the complexity around that comes because we’re dealing with solving… we’re working around difficult situations that are created because of the fact that we don’t have HTTP multiplexing already today. So, I think things will get simpler. But things need to get a little bit more complex before they can get simpler.

  So, you can load partial apps right now but you have to, when you say tier bundling, you mean you have to split your app into multiple pieces, some of which might kind of overlap. And it adds a lot of complexity to your build process, right?

  Well, jspm tried to make this fairly simple. So, jspm provides bundling in the same way that you’d expect with all this. You can bundle a module and it’ll bundle all its dependencies. And then the other thing is to provide bundle arithmetic. So, I want to be able to have my core application code loader initialization. And then later on, I want to click on a new piece of functionality which is going to load a new section of my app. And I want to negate those two trees, so that kind of loading. And there are bundling methods for doing that kind of thing. 

  Oh, okay. So, you shouldn’t have overlap in that case, because it’ll automatically detect things that are in the first bundle and not include them in the second one. 

  Exactly. Yeah, so these are the work flows we’re working on. 

  That is sweet. 

  Yeah.

  Yeah, it’s very impressive. 

  Yeah, it’s a lot of hard problems, but it’s fun stuff to work on. 

  What about the things that aren’t really packaged up as modules? So, let’s say you’re pulling in some library that isn’t really set up to be pulled in as a module. It’s just set up to be pulled in as a script tag on your webpage and executed that way?

  Yeah, so existing global scripts, and that’s probably still the majority case that we have. And that’s what… RequireJS and AMD loaders have this idea of a shim configuration. So, you say this global script depends on this other global script. And it creates these variables in the page. And we provide the same thing for SystemJS. And what that allows you to do is write with either upfront configuration or meta syntax in the file itself. You can say what its dependencies are and what its globals are that it writes to the window. And then it’ll pick that up and treat it as if it is a module. 

And so again, we’re dealing with having to make all the processes that can deal with all these other types of systems. And that’s where the majority of the workload actually is, in supporting these cases. But we’ve done it pretty well now that you can load globals. You can load things directly from npm. So, we support any module that works with Browserify. It should work with jspm, for example. And so, a lot of the work is on supporting these legacy use cases. I say legacy, I mean legacy in many years’ time. But yeah, there are stories for these kinds of situations. 

  I want to go back to some of the stuff you were talking about when you were mentioning the future, when HTTP 2.0 is widespread. I’m sure there are people listening that aren’t familiar with HTTP 2.0. Do you want to explain the features that make it easy to do dynamic module loading of individual modules in the future? So, the problem right now is when you request a module, if it has 20 dependencies then you’ll basically be making dozens of requests all at once. And there’s a limit to how many requests you can do at once. And so, things will be blocking and it’ll be sluggish, basically. Is that a good summary of the problem? And then do you want to explain how HTTP 2.0 helps that?

  Sure. That’s a pretty good description. In [many] browsers, you’re typically limited to between six and eight HTTP requests. So, anytime you put a script tag or a link tag into the head of your page, you’re generating a new HTTP request. And at any given time, you’ll only have six or eight of those going before the next batch can happen. And those connections are kept open. They’re able to be shared for the next request. But you do have that underlying bottleneck. And HTTP 2.0 and the work on Speedy is based on the idea that if you just had one connection that carefully contained all those other connections, then you wouldn’t need to have the problem of lots of separate requests. So, instead of having many requests, you have one request. And then just multiplex your requests through that single wire basically. So, it’s just a different way of doing that communication. In a lot of ways, it seems pretty. It’s a nice idea. And it’s a very nice way of looking at things.

  Is the underlying technology of that voodoo? Because it sounds like voodoo. [Chuckles]

  I don’t think it’s officially voodoo. But yeah, it’s using the same system. But it’s multiplexing. So, you’re putting two connections over one, basically. And yeah, it’s looking really great because well, Speedy is now going to be supported across all browsers. So, it’s pretty much in there. And Safari was the last to go recently. And Speedy is the natural evolution into HTTP 2.0. It’s where the HTTP 2.0 spoke starts. So, it’s definitely coming. It will just take a while. So, this stuff is looking quite far into the future. And I think you have to work with quite large timescales when you’re looking at spec stuff, unfortunately. But it’s really exciting to see where things can be.

  That’s absolutely crazy. I don’t think I could have come up with an entire question the rest of the show after listening to that.

  [Chuckles] If you want to learn more about HTTP 2.0, man I always feel like I’m going to say one few, too many P’s or one too many P’s. 

  And that really changes the context of what you’re saying if you do that.

  Yeah, it does. Words are hard. Computers are harder though. But if you want to learn more about the coming new upgrade to HTTP, Ilya Grigorik’s book about, I think it’s called ‘High Performance Browser Networking’ has a really good section on it. That’s just an aside. But it’s got a better overview than I’ve read in other places.

  So, you’ve been talking a lot about modules and module loaders and ES6 modules and stuff. When do you think we’ll see ES6 modules get supported in the current browsers? They’re not supported today, right?

  Yeah, there’s not support today. It will be a while yet.

  Why?

  We have, okay. So, the ES6 specification, it’s going to be confirmed I believe next year. And ES6 modules are fully drafted into the spec. They’re being reviewed at the moment. And the specification for that is pretty much there which is really nice to see. After that, the next stage, there actually needs to be a separate spec to get them into the browsers. And that’s because of the fact that the way that the ES6 modules interface with browsers is through these loader hooks, so how does the module loader know how to fetch a module? It has to know that it has to plug into the browser’s fetch mechanism. And there’s a very simple spec to create the system dynamic loader in the browser and to define its loader hooks, which still needs to be written. 

So, at the moment it’s based on this pseudo-implementation written by Mozilla. And so, we need to see that spec. And once you’ve got that spec, then browsers will be able to start implementing. So, I expect it won’t be before next year. It’ll be, if we’re lucky, next year. But the important thing is that we can start to create these work flows today. And we can actually start to work through the problems and the ways of dealing with ES6 modules in the browser already today in a way that’s production suitable. So, if you’re interested in ES6 modules, you can actually start using this loader and seeing what it’s capable of. And the production workflows that we have today are suitable in IE 8+. So, it’s looking far into the future but it’s fully supported now. 

  So…

  Another… oh, go ahead, Joe.

  I was just going to ask, if you can do everything that modules are doing today, then what’s the benefit when modules are actually supported by browsers? [Harmony] modules, that is. 

  Yeah. So, we do still need to build modules into this intermediate format to make them work in the browser. When modules are natively supported, eventually we’ll be able to not do that. But that’ll be a while again, because we’ll need to wait for browsers to have full adoption of ES6 browsers. So, it’s many, many years’ time. So yeah, it certainly will be a process. But yeah, so the benefit will be that the workflows simplify tremendously over time. So, as browsers adapt, these projects get simpler. The polyfill becomes no longer necessary. Different types of intermediate compilation become unnecessary. And so, things get more complex to support the future and then things will be able to drop out over time. So, it’s built with this kind of timeline in mind where eventually we end up with this very minimal loader. But it starts off by needing both ES6 Module Loader and a project like SystemJS to get there.

  So, will the transition over time be seamless to the consumer of the module loaders or will the code that we use, that we write, actually change as well as modules become supported and as the module loaders stop dropping features because they’re already natively supported?

  Yeah, so the goal of these projects is to make this workflow as easy as it can be. So for example, in due course, SystemJS would dynamically load the ES6 module loader only in browsers that it sees don’t have it. So, there’s an intermediate period where it could do a quick check and then only load the polyfill if it’s needed. And jspm is very much a project built around trying to give developers a workflow today and working towards that workflow that can then take them into ES6 modules and work nicely with that sort of stuff. I haven’t really properly explained jspm, so would it be okay if I just quickly give a proper description?

  Oh, for sure.

  [Chuckles] Cool. Yeah, so I mentioned the problem around third-party code dependencies. And just like you have Browserify for npm, jspm tries to do the same kind of thing but for the ES6 module loader. You can install anything by just writing jspm install and you can install something off npm or you can install off of GitHub. And it’s built for the SystemJS loader. And the reason that we do that is because it’s only by having a package manager that understands the module loader that you can get as simple as you just want to install something and require it. 

So, it’s this idea that I should just be able to say install and then require the exact same name I just installed. And all the complexity around dependency management, the global shimming, whether it’s AMD or CommonJS or ES6 or has an intermediate format, you shouldn’t have to deal with. You should just be able to say install something and require it. That’s the goal of jspm. And then when you want to go into production, you can write jspm bundle and it’ll bundle it. So, it’s very much, it’s a tricky project to get right. But it’s an exciting thing to be working on.

  So, I haven’t used jspm in person. But it looks like it’s the dream. There have been how many, and there are how many, competing frontend repositories for packages with incompatible standards and stuff. Well, not incompatible, different standard for the module format. And this is the final answer to all of them. Just use whatever you want and then it’ll work. 

  It’s trying to be. And it’s exploring the space and trying to make that possible. And I think we’ve got pretty close to it, which is really great. I think what’s really great as well is these are some really hard problems. And we’ve got lots of great people working on them in different ways. And I think it’s a really exciting time for the web. I think it’s really important that as an open platform, we have a really good story for installing third-party code. And I think the more people that can work on it and create really good solutions for that, the better the work will be. 

  So, I know recently the ES6 modules spec just changed a little bit, and there’s a lot of grumpiness about that. 

  Yeah.

  But I think Yehuda Katz tweeted something about how the reason it changed was because developers built implementations on top of the spec and that informed the committee. That’s how it’s supposed to work. They had some ideas and they showed them to the community and then the community used them and found some problems with them. And now they’re changing it again. 

  Exactly.

  And it sounds like you’re doing some similar things. You’re trying to use it as soon as possible and make it as widespread as possible. 

  Exactly.

  Which makes the implementations better but also makes the specs better, hopefully. 

  That’s the process. And it’s that they’ve got this feedback loop is amazing. So, we’re creating implementations, getting real-world feedback on them, and then sending that back into the spec, which is really powerful. And that’s how the spec process should work, because you don’t want something specified never used or tested. And then suddenly it appears in the browser one day and it’s not quite right. So, that’s what we can do with these projects as well, is we’re able to provide that feedback. The example you mentioned with the module syntax, it’s actually a fairly minor syntax that most people hadn’t used. And one of the major cases that was causing some of the negative feedback, they’d actually used it wrong. So, it actually proved the point of altering it in the spec. 

  Oh, you mean the person’s example, they changed it to this, “look how dumb it is?”

  Yeah.

  They were using it wrong in there.

  I think one of the major examples of the person who built something on top of it, it was using the module syntax wrong, yeah. 

  So, it worked. 

  [Chuckles] Yeah. And it’s good. It’s really nice to see community involvement. And I think it’s, yeah, it’s all good stuff despite occasional complaints.

  So, this is solving the problem from one end, which is everyone writes their modules in slightly different, when I say ‘this’ I mean jspm.

  Yeah.

  Everyone writes their modules in different module formats or syntax. Is there anything solving the problem from the other end as, “I, as a module author, have made this useful code. What do I do to make it so people can use it?”

  Yeah, and that is a problem, because as a module author, you have to support everything because you want to get your code out as widely as possible. 

  Yeah.

  [inaudible] on these different systems. 

  You can’t count on everyone using jspm, so you just say I’ll make it in CommonJS and then whoever wants to can use Require, use whatever they want with it.

  And it is unfortunate. So, module authors do get frustrated by this, because they have to have one version for this format, another version for this, different package to JSON and all this kind of stuff. And unfortunately, that is something that we have to go through. And it’s necessary to making sure

that package management can evolve properly. We need to have systems running side-by-side and let the best win, effectively. So, the way that jspm deals with that is it doesn’t add a new, it has no jspm.json. It shares the package.json information and it has some metadata that can be useful in certain scenarios. And if module authors don’t want to use it, there’s an override service. 

So for example, if there’s a repo on GitHub like bootstrap for example, and they don’t want to support this jspm configuration in their package.json, we can actually override that through, there’s a repo on GitHub where jspm can override that configuration when you first install it. So, effectively making that sort of stuff possible from both sides. So, if the framework author’s frustrated with all these different systems, a user can still go and set up their own configuration and that will work for everyone using jspm. 

  That’s cool.

  Yeah, that’s really cool. So, is it at all like that scenario where the guy goes out and he looks and he sees that there are five standards, and he says, “This is ridiculous. There are five different standards. We need a new standard that unifies them all,” and then all of a sudden we have six standards?

  Well, hopefully not. With some, we’ll reduce over time. But the important thing to realize is that this is a hard problem. And it does take work to solve the problem. So, we need to have people working on the problem and creating the standards to make them better. 

  So, knowing what you know now, who do you hate more, the creators of CommonJS or the creators of AMD? [Laughter]

  Yes. That was a question. [Laughter]

  Do I have to answer it?

  We’re not talking until we get an answer. [Laughter]

  No further questions will be issued.

  That’s cruel. That’s really cruel.

  No, I have a different question. What is the value of using something like this over just using AMD? What do we get out of this versus just using AMD or CommonJS?

  Certainly. I think if you’re happy using AMD or you’re happy using CommonJS today, keep doing that. There’s no reason to rush into ES6. If you’re already having frustrations in your workflows and you’re thinking about ES6 modules, thinking about how modules can be standardized, then try these projects out. But it’s very much, I think, something that will take time. And for me personally, I just got very frustrated with the fact that you had to choose AMD or CommonJS. And having made that decision, you had to live with it. 

And I really just wanted a system of dealing with modules that couldn’t be refuted with a blog post or something like that. I spent about a year building a framework on top of AMD and AMD started to fall out of favor just as the framework was finished. And I found it incredibly frustrating that I built a lot of work on top of a system that could so easily not turn out to be used as widely as I’d hoped. I think with ES6 we have the potential for a really solid foundation. And I think that’s important in development to have solid foundations. 

  So, what are some potential pain points people might experience that would cause them to want to look at ES6 modules and by that extension, your stuff?

  Some of the areas that we can do that might be harder in other systems are things like, well firstly, if you do come up against interrupt issues with different module systems. So, wanting to be able to just write modules in a way that’s… wanting to have a spec-supported syntax for writing modules. So, if I can write an app and know that I’ve written all my modules as ES6, I know that that code is going to be safe in the future. I know that five years down the line, more that code will still be something that’s on solid foundations. Whereas if I’m writing code today that’s only going to be around for a few years, it’s not a problem to use other formats, but with ES6 you can, if I was building a codebase that needed to last for a while, it’s nice to build on ES6. 

And then, the other problems we can solve are things like effectively the transition into HTTP 2.0. So, moving away from bundling over time. Asset loading. So, you can actually load assets in the module pipeline. I can even load an HTML import in the module pipeline if I wanted to, or CSS is a really useful one as well. So, you’ve got a CSS loading mechanism in a module system, which means that you can have modular components that are combinations of CSS template and JavaScript, which is really what we want. And then we’re also working on things around conditional loading and those kinds of problems too. So, how do you conditionally load libraries depending on the environment? And because we’re building those solutions on top of the ES6 module loader, we’re hopefully doing it in a fairly solid way going forward. What else? I think those are probably the main reasons, yeah.

  So, related to that, where do you see things going next, especially from the standpoint of managing code through modules like this?

  Well, what I’d like to see is just it being really easy to start prototyping and building new apps. And for the workflows not to cause so much friction that the thought of including a new library becomes something painful. So, in the same way that npm has done for Node, to see that happening properly in the browser. So, if I want to build a site and just add new, little features to it, it should be an easy install process. With HTTP 2.0, what’s cool is you can actually enable requiring without needing a package manager. So, if I’m using an asset CDN, I can actually load modules directly off that asset CDN without needing to go through an install process. So, I just think that’s really nice to be able to imagine you can have this really complex app, a proper application in the browser, and it can by dynamically loading new modules very easily. And they just fall into this existing registry.

box all -demo’) and that’ll dynamically load a module directly off npm, over 100 modules in the browser. And the page was never designed to load that, but I can just go in and load this new piece of functionality up. And I just found that idea really exciting initially. 

  I have another question. How do people get involved with this, with your project specifically and with the whole ES6 module community in general?

  Sure. So, I think everyone’s got different problems around this stuff. So, one of the easiest ways to get started with ES6 modules is to just start writing your own code in ES6 and then transpiling into whatever module format you’re using today. So for example, you could start writing ES6, transpiling that into CommonJS and using that, or there are a lot of different compilation techniques. So, some of the projects to check out for that is to just start compiling them today, have a look at the Square ES6 module transpiler. And that can just allow playing around with the syntax.

If you want to actually explore more ES6 features, the es.next project is really interesting to try for static compilation. Also Traceur. And to start trying ES6. If you get more interested in the module side of things, try out SystemJS or jspm.io. So, there are different ways you can approach it depending on what your own needs are. And just try it out, play around, and see what works and what doesn’t. And post issues or post questions and people would be glad to help. 

  Cool.

  Very nice. Any other questions before we get to the picks?

  Who’s your pick for the World Cup?

  Mine?

  No. Well, yours too, I guess, but Guy’s. 

  Oh. I abstain from answering the question. [Laughter]

  [Inaudible] it, so I can’t decide. [Chuckles]

  Okay. 

  Who do you think won’t win the World Cup?

  [Chuckles]

  Spain. [Chuckles]

  [Laughs] I wonder how funny that will be in a week. 

  [Laughs]

  Probably not. 

  Eh, it’ll still be funny. World Cup lasts a long time.

  [Inaudible] most of your jokes, Joe. 

  True, very true.

  Just kidding. 

  Guy, I really just wanted to hear you say one offensive thing.

  [Chuckles]

  Just go out on a limb and say one thing about somebody that is controversial.

  It can even be Santa Clause.

  [Chuckles]

  That he’s not real, for example.

  Yeah. You’re the most politic guest we’ve ever had.

  [Laughs]

  Not political. I think he just sounds really nice. 

  Politic is a good word. That’s nice.

  Is it? I don’t know that word. 

  Well, you should have baited me more to say some things. [Chuckles] 

  We don’t know your weaknesses. 

  There’s a lot of conflict in this area. But yeah, no, I’m impressed. We all like each other in this stuff. 

  I think that conflict is because people are excited about it and they care about it. So, it’s a good sign. It sucks when people get angry. But it comes from a place of everyone wanting good modules. 

  Let me ask an opposite question, then. 

  [Chuckles]

  Who do you think are some of the most impressive contributors to ES6 as a whole? Not just the spec, but really making it happen across the entire spectrum. 

  For me personally, I was incredibly inspired by the work that James Berkman was doing on RequireJS. I thought that was incredible commitment and work that he did. I just don’t think he can be appreciated enough for that. In ES6, I wouldn’t name all the names who’ve been responsible for it. But Dave Herman has been the champion of that. And they’ve had to deal with a lot of really hard problems in modules and difficult communities as well. And they’ve been able to navigate that pretty amazingly. And going back over the decisions that they’ve made at quite a technical level, it’s a pretty amazing thing that they’ve done. Yeah. But yeah, there’s lots of really amazing developers. The Traceur team’s pretty cool. It’s a Google project. And the ES6 module transpiler side, they’re doing some great stuff as well. So yeah, it’s pretty exciting to be working with really amazing people. And that’s what I love about open source, really. 

  You know I like Traceur, too. But one thing that really frustrates me is actually how little ES6 it actually supports. There are so many things it doesn’t support.

  The compatibility table’s deceiving, because they don’t support lots of the polyfills. But in terms of syntax, they’ve got quite a lot. But yeah, it’s all a work in progress.

  Yeah, no, definitely. But map and set and proxy and the array stuff, that’s pretty frustrating it doesn’t support that.

  One of the hard things about that is you need a runtime. So, you actually need a polyfill in the browser. So, if I want to be able to support all these array features, and what they have with the Traceur runtime is if they add all these things into a single runtime file, there’s going to be this massive runtime. Everyone’s going to complain that you’d have to load in hundreds of kilobytes just to make stuff work. So, you need to modularly load just the runtime you need. And you can only get there if you have a module loader. So, I think we need to do more work with Traceur to get those conditional polyfills working with the module loader. And that’s stuff that we’re working on.

  Oh, that’s a good point.

  But yeah, frustrations are great to hear. It’s always nice to hear about people’s frustrations. [Chuckles]

  Right.

  It’s the only way to get it better.

  [Chuckles] Right.

  [Chuckles]

  I’m actually in the middle of authoring a course for Pluralsight on ES6.

  Okay.

  And it’s crazy how many different tools I have to use to just demonstrate all the features because no single tool will support everything. So, it’s like four or five tools at the minimum to show everything in ES6. 

  Sure. Yeah, there’s certainly going to be a place for projects that bring them together. And that certainly will be happening. But yeah, it’s a difficult transition. It really is. But yeah, we’re working on it. 

  Cool. Well, this has been an awesome episode.

  Yup. 

  Yeah, thank you. 

  Alright. Let’s do some picks. Jamison, do you want to start us with picks?

  Sure. So, my picks are two today. The first one is XCOM: Enemy Unknown on the iPad. I have it on PC. But it’s such a good iPad game. Well, it depends on what your definition of good is. 

  [Chuckles]

  It’s a great game if you have time to invest in it. It’s not a pull it out for 30 seconds and then tap on some candy or whatever. But the style of the game fits the format of the iPad really well, I guess is what I mean. It sucked up my weekend, so I didn’t get a ton don besides killing aliens. But that’s valuable work too, I guess. [Chuckles]

And then my next pick is an article by Carlos Bueno. He’s a Facebook engineer who writes amazing stuff and everything he writes is really good. But he just wrote one on culture and hiring in tech companies specifically. And the idea of how some of the preconceptions on what a good technology person acts like or looks like or enjoys or whatever creates this weird mirroring culture that selects people that fit into its own definitions. And it just exposes some things that I’ve seen and I’ve also done on accident when hiring or looking for people to hire or whatever. It’s a really good read. And it’s not mean. It’s just pointing out, “Hey. This is some stuff that happens. You might not even know it. And they could be better.” So, I like it. 

  Alright. AJ, what are your picks?

  You know I had one thought and it’s gone now. 

  You reach your [inaudible] for the day?

  Yeah. Yeah, I think so. It’s been a rough week, Chuck.

  This is unprecedented. I’ve never heard AJ not want to speak. 

  [Chuckles] I don’t know if it’s want to speak. I think it’s what to speak about. 

  Yeah. That’s probably not a problem. 

  Joe. Joe, what are your picks?

  So, let’s see. For my picks, I just heard about, speaking of iPad games Jamison, probably the one game that I’ve spent the most time on which again is like XCOM is not a sit down and play for a minute or two. This is a long game that takes a long time to work through. And I’ve picked this in the past. Civilization: Revolution for the iPad. Well, I just found out that Civilization: Revolution 2 is coming out for the iPad at the first of July. So, with no word all of a sudden they’re just releasing it. And I can’t even find what features it has. All I know is I loved Civilization: Revolution for the iPad. And I want them to shut up and take my money. So, that’s my first pick.

My second pick is going to be the World Cup and soccer. I found out that the Sunday game that the US played against Portugal was the most watched soccer game in all of US history. And it had more watchers, more viewers than Game 5 of the NBA finals. It was on some article. The NBA finals had 17 million and that game had 18 million viewers. So, it was an incredibly awesome game to watch. Real heartbreaker at the end, but it was a great game. So, that’s going to be my second pick.

 And then my third pick is going to be party game called Off Your Rocker. I picked this one up at the Marbles store that only exists on the west coast. But you can get it online. It’s a game where it’s really fun. I played it with my kids. So, little kids all the way up to adults. My youngest is nine. And one person leaves the room and everybody else draws a card and they pick from the card from three different things what condition everybody’s going to have. And the person who left the room has to come back in and ask people questions and guess. It’s very similar to a game called Psychiatrist. It’s a party game but it actually gives it more structure and a point system whereby somebody can win. Plus, just tons of awesome ideas to pull from. And I’ve had just tons and tons of fun playing that with my family. So, that will be my third and final pick, is Off Your Rocker. 

  Alright. Well, I’ve only got one pick this week. I went to the Agile Roots Conference. I spoke there this last weekend. And one of the sessions was actually David Adsit had Pluralsight’s copy of the Kanban board game. And it’s not cheap. It’s $450. But it was fun and interesting. So, if you have $450 burning a hole in your pocket and you are interested in such a thing then have your company pay for it. I’ll put a link to it in the show notes. But anyway, I don’t know if I would go spend that much on it. But anyway, Guy do you have some picks for us?

  Yeah, I’ve got a couple. The first one is I don’t know how many people know about a service called jsDelivr. So, that’s a CDN for JavaScript and other assets. And it’s a little bit of a plug because we’ve just worked out an arrangement to provide the CDN for jspm. But it’s a really cool CDN. It’s based on two separate providers. And if one goes down, you still have the other one. It’s CloudFlare and MaxCDN as well. So, that’s pretty cool. 

And then the other one I wanted to mention was I’m always incredibly astounded by the projects that Fedor Indutny produces. I don’t know how many people follow him as a developer, but he’s one of the Node core developers. And he [inaudible] a project called bthread, which was actually a way of writing blog posts into the bitcoin block chain, which I thought was pretty cool. It still blows my mind how exactly it works. But you can have these threaded messages in the block chain and he’s rewritten all the encoding algorithms to make that work. And they’re doing some pretty interesting stuff in that bitcoin world. So yeah, I’m fascinated by those projects. 

  That sounds really interesting. Alright, well I don’t think there’s anything else. So, thanks for coming, Guy.

  Awesome. Thanks so much.

  We’ll wrap up the show. We’ll catch you all next week.

  Alright. Cheers.

[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.]