006 JSJ Chrome Dev Tools with Paul Irish

Download MP3





JAMISON: Hello? CHUCK: All right. AJ: Hey Jamison, are you on the right Wi-Fi? JAMISON: I switched to the closet one, so I think I am now. AJ: Yeah that’s why you were dropping off. JAMISON: Yeah. PAUL: Get out of that closet. [Laughter] CHUCK: Hi everybody and welcome back to the JavaScript Jabber podcast. This week on our panel, we have a special guest -- that is Paul Irish. PAUL: Hello! Hi guys. CHUCK: Do you wanna introduce yourself for the two people out there that don’t know who you are? PAUL: [Chuckles] Sure. So I’m a front-end developer. I work on the Google Chrome team and I do developer relations. I also, manage the projects of Modernizr and HTML5 Boiler Plate and launched projects like HTML5Please and Mother F***ng Animated GIF and all sorts of good developer facing fun stuff. CHUCK: All right, awesome. We also have on our panel, AJ O'Neal. AJ: Hey! Glad to be here again. CHUCK: And Jamison dance. JAMISON: Howdy. CHUCK: And Joachim Larsen. JOACHIM: Great to be here. Good company as always. CHUCK: And Yehuda Katz. YEHUDA: Hey, excited to be on today. Great to be here. CHUCK: Yeah, me too. And I’m Charles Max Wood from teachmetocode.com and this week, we are going to be talking about “Chrome Developer Tools” and I think we are all going to figure out real quick that there's a lot to know. So I’m a little curious as we get started, Paul, what features you find that most people request the most often that’s already there? PAUL: A lot. One good one is that… okay so this is probably the best one which is, “Why can’t you guys just have those check boxes for disabling styles on the left like every other tool?” CHUCK: [Laughs] PAUL: This has literally been number one request for 2 years [chuckles] and as of about 24 hours ago, it’s there. [Laughs] That one’s a little not so obvious because in Chrome Canary, you update and you restarted your browser in the past day, you haven’t seen it. But I’m very happy to announce; we now have checkboxes on the left. Might seem like a little deal, but its big deal for a lot of people. CHUCK: I’m going to make a request to move them to the right. [Laughter] YEHUDA: I’m looking at it right now, that’s pretty awesome, Paul. PAUL: It’s good. It’s good. Like from a perspective, it’s really awkward and so it’s nice and close and happy. It’s good. CHUCK: There's balance in the force once again. PAUL: Yeah. So one thing I hear is like, “It will be really nice to be able to like refresh and not have to worry about a browser, my discache to be caching my things. Is there any way to like clear out my cache?” And we don’t exactly have a button to clear a cache, but we just have a setting in the dev tools settings to just disable cache. And so the dev tools setting is actually a good one. So down in the bottom right of the dev tools is a little gear cog icon; when you click that, a bunch of cool stuff is in there. And especially if you are running Canary, there's even better stuff in there. But one of those is disable cache. And so your dis-cache will just not even be honored, and so you always will be getting the freshest things. Don’t leave it on all the time, because of course things will go slower, but that should help a lot when you are doing development. JAMISON: Is that per tab or is it global? PAUL: No, that’s global for the entire instance. YEHUDA: Paul, by the way, so until you told me about that enable source maps things, I actually didn’t know that that cog exists so I wanna put like another, “Hey, if anyone is listening and was not paying attention to what Paul just said, there is a cog there and there is useful things in there.” I spend a very, very long time saying, “Okay, I’m just going to use Safari because there's a disable cache mode.” I never knew about this; and I like the Chrome dev tools better. CHUCK: Everybody, get over your cogless life. AJ: Can’t you also do like Ctrl+Shift+R and refresh that way? YEHUDA: That is not reliable. So, basically Chrome is actually pretty aggressive in caching, and often… so specifically I want caching off when I’m running tests. I never, ever, ever want cache on in tests because it’s always wrong. PAUL: And so there's a lot of cases where in… so if you are using something like a script like require.js like a script loader, a shift command or a type of reload will actually be not fetching the brand new versions when that script loader brings in its scripts. So disable cache is an instance where that would actually solve that problem. JOACHIM: Just a quick question; so disable cache only is on when the dev tools are running? PAUL: So I believe the setting is working as long as that box is checked regardless if you have the dev tools pane open. JOACHIM: All right. CHUCK: Okay. YEHUDA: I have a question for you, Paul. So, I know that Webkit Inspector added like edit your contents a while ago, and me and Tom occasionally are like, “Hey, this is awesome. We should use it.” And we can never get it to do what we want it to do. I think it’s mostly because we always want to be able to refresh and have the edit still there; maybe that’s just not how it works, but what is the use case as you see it for that feature? PAUL: So for keeping track of you changes in CSS and JavaScript? YEHUDA: So letting you basically go and live edit CSS and JavaScript. So for us, if we live edit JavaScript, most of the time, we are going to wanna reload the page because the thing that we are editing has already happened. PAUL: Yeah. So we have a… right now the work flow for that… so what Yehuda was talking about is we have live edit and there's a few ways— [Crosstalk] CHUCK: I love it. PAUL: Sorry, what? CHUCK: I love it. PAUL: Yeah, it’s so good. And so it’s really quite surprising in JavaScript that you could just open up the scripts tab and double click and just start changing things. And you know, like you changing a click handler tabs in different behavior and then you click that button again and it does the new behavior that you just typed without having to refresh all. JAMISON: Wait, you are saying you can live edit JavaScript? Not just the CSS? PAUL: Yeah, that’s right. [Chuckles] Yes. JAMISON: [Inaudible] those people that you were talking about. PAUL: No, I mean like-- [Overlapping talks] CHUCK: The CSS show is on the other channel. PAUL: [Chuckles] So live edit, you can make those changes, you can see it, you can get something what you want. When you go over the resources panel, under resources, you are going to see your JavaScript. And next to the file that you are editing, you are going to see a little arrow pointing down or point to the right and it’s just indicating that it’s keeping track of all of your revisions. And so, there's revision history and you can revert back to the previous revision before your edits. You also can see colored diffs on what exactly you changed or added. And you can right click the JavaScript file and save that to disc. So you just right click, say “save to disc” and declare where it goes and it overwrites your existing file  or what have you. There are currently two Chrome extensions that try and make that a little bit better, because always going over to resources and clicking save to disc and bringing up the file prompt and hitting save is kind of annoying, and so there's two auto-save extensions, so we’ll have these in the show notes, but one is called Dev Tools Auto Save and the other is called Auto Dev Save maybe. [Chuckles] Its very, very similar. And right now, the two authors are trying to merge the best of both. But essentially, the pattern that both are offering is you make your changes and immediately those changes are just saved back to disc and so then, when you refresh the page, its loading up the changes that you had just put in through the dev tools -- which is the kind of development workflow that you want. YEHUDA: Is there a world in which that feature gets into the Chrome tools themselves? PAUL: I think so. And I think… mostly the engineering team would just love to hear about people’s experience with that and would want to see people file bugs request in that. So, if you like that, file a ticket. YEHUDA: So, me and Tom are probably going to because that’s definitely… for CSS it’s really cool; you make the change, it’s basically live. But for JavaScript, 99% of the time, when something has gone wrong, I actually want to redo the thing I just did that went wrong. PAUL: Yeah. YEHUDA: So like click handlers will be there, but if not… I can’t make state go back to zero. CHUCK: Right. So one other question that I have is where’s the debugger? Is there a debugger? PAUL: Debugger? CHUCK: Yeah. PAUL: Yeah. So there's a lot of debugging capability for script in the dev tools. And so, in the scripts panel, you bring up a script, you can click along the left side and place breakpoints. You can right click and place conditional break points that only break when a condition passes. Let’s say that your JavaScript was minified, you can hit the pretty print button at the bottom, (which is the two braces) and minify it and then you can place your break points all over the pretty print and format it to JavaScript. So the debugger works like any other debugger does, you have step into and step over and pause and disable breakpoints. We've been refining a lot of the things that are in there, so now, there's a way to remove all of break points all at once (which was a big request), and-- YEHUDA: What is that way? PAUL: What? YEHUDA: What is the way to remove all the breakpoints all at once? PAUL: So, in the right hand pane where it lists where the breakpoints are, you just right click one of them, there's “remove breakpoint” and there's “remove all break points”. YEHUDA: Indeed. All right. Awesome. PAUL: And one of the other cool features that I came across recently which is, if you are stepping through and you are looking at your scoped variables, and one of them is a function reference, you can actually right click on that function reference and in that context menu will be “show function definition”. So the dev tools are getting really smarter; navigating the front function to function, method to method. And so you can kind of jump around to where these things are defined that you are using at different places. YEHUDA: I actually noticed sometime recently that dev tools made it so that the object inspector caused to string on classes instead of saying class-- PAUL: Ah, it does. It’s good. YEHUDA: So maybe I was seeing something crazy, it goes in the machine. So Ember has a two string in all classes. And it’s like one of our banner features. And for a long time, we have to tell something like, “Hey, make sure you type to string if you wanna know what it is and blah, blah, blah.” And I was noticing… So just a plug, Tom did a whole debugging video for a talk recently at a meet-up and it is basically like a whole like, “Hey! Do you know all these things about debugging? Here’s basically our work flow.” But while we were doing that, we noticed that all the Ember classes actually had their names, which is actually pretty cool. Because before it used to say “class” and that was pretty terrible. PAUL: Yeah. So if you are like defining your own classes, and you wanna have better debugability, define your to string and you'll be able to get that as output to the dev tools which is a bit better with working with object object. YEHUDA: Yup. PAUL: And while we are talking about the scripts panel, it’s a little hard to do in audio but I would encourage everyone to check out Canary. So everyone knows Chrome Canary can run side by side with any other Chrome install, so for developers, I really recommend running the Chrome stable, which everyone has and then a Chrome Canary, so you know what users are looking at and then you can play with the freshest dev tools and the other fresh features. CHUCK: Where do you get that? PAUL: Just Google Chrome Canary. CHUCK: Okay. PAUL: It’s a quick download. So it updates once a day. And it’s not that buggy either, it’s quite stable so it’s great. One of the new features that we have in there is a script navigator. And so before, if you’ve been in scripts and you wanna like bring up one of the files you see that all your Chrome extensions are also listed in there, and now there's a nice way that those are separated out -- your Chrome extension scripts and your application ones. There are all kind of categorized based on what origin they are from, what folder they are in and it’s really nice to work with. And there's even nice shortcut like Cmd+O and Cmd+Shift+O that are jumping between files and jumping between function definitions within files. So if you find yourself wanting to navigate around a lot, the dev tools are now very where all these functions defined and you can just jump immediately to where you want to go with a quick shortcut. JOACHIM: One other thing, I’m going to Chrome Canary now and I see it says, “For Windows XP, Vista and 7 only. Your operating system is not supported for Ubuntu.” PAUL: Linux? Yup. This is true we; do not offer a Chrome Canary for Linux -- which is just a bummer. For Linux, my suggestion is to go to download-chromium.appspot.com. And so the Chromium builds are about an hour old, so whereas Canary updates once a day, Chromium build there's a new Chromium build binary once an hour or so. So that’s the solution there. And you have to update it on your own, which is kind of a bummer, but that’s just where it’s at right now. JOACHIM: And there's no difference between Chromium and Chrome in this context? PAUL: Correct. AJ: Are the dev and alpha channels that used to be in the repositories gone away? PAUL: No, no. So we still have the beta channel and the dev channel. AJ: Isn’t the dev channel Canary, more or less? PAUL: Dev channel updates once a week. AJ: Okay. PAUL: So that's the only difference. So it depends on how much you want it to change. The downside that I've seen with dev channel is if a bug does sneak in to it, you are stuck with it for a week. [Laughs] But if a bug sneaks in the Canary, you are pretty much like with it for about a day. And I've been running on Canary as my primary browsing browser for about a year now and I've had very little problems. CHUCK: Nice. So I have a question and that is how do you decide which features go in? Is it the most popular or do you decide what would add the most value? PAUL: It’s a bit of all of that. So checkboxes is a good example of one where we just had an overwhelming public demand for it. Another one that is brand new is single click edit. So in CSS, one of the big differences between Firebug and Chrome dev tools is if you are editing CSS, it takes two clicks and it takes a double click in Chrome to get into edit mode of CSS, whereas in Firebug it’s a single click. And we just switched it so that it’s now single click. Small little thing that I think people prefer it. So, sometimes it’s that, other times its people really need ways to debug, ways to see their IndexedDB storage and so, we were working with the guys who implemented IndexedDB support in Chrome to get good support for that inside the dev tools. And so that just landed behind the flag earlier today. And so part of it is just platform driven, part of it is from what we hear and another is we have a crazy idea and we are going to try it out and see if people like it. So it’s kind of a mix of all these things. But you can kind of track the… there's a few ways to track the evolution of the dev tools; the best to kind of get a feel for what's happening from week to week is blog so it’s at Peter Beverloo’s blog. It’s at peter.sh. And Peter talks about what's happening in all of webkit in Chrome from a week to week basis and he covers a lot of what is happening inside the Chrome dev tools. And so, if you have been reading that, you read this week that a Color Picker just landed. And so now if there's a little color swatch, you click it and up pops a little graphical Color Picker -- which is pretty handy. So Peters’ blog covers that and you can also watch the Chromium Bugs at crbug.com and also the webkit bugs at bugs.webkit.com. And both of them have a category for Chrome dev tools or the Inspector (it’s the same thing, different names) and you can jump on and watch different bugs, add yourself to the CC, chime in if you have any feedback that would help and kind of get a feel for where the tool is heading. JAMISON: So you mentioned just kind of like wacky, crazy ideas as one of the source of things, I don’t know if you’ve seen that video by Brett Victor, Inventing on Principle. Have you seen that? PAUL: Yes. JAMISON: I want that stuff. AJ: I want that so much. JAMISON: Like, I mean— [Crosstalk] PAUL: So I haven’t seen that-- JAMISON: [inaudible] were interactive like that. So basically he's like an interface designer from a thousand years in the future, I don’t know, he's pretty amazing. But he demonstrates this editor where he has a canvas on one side and on the other side he has his code and he just kind of clicks on these constants in his code to change the numbers so that he can see it changing; how it draws on the canvass live on the other side. It’s amazing. He has a couple other demos on there that were pretty incredible. JOACHIM: So that’s like processing JS demo site? JAMISON: Yeah. I haven’t seen that. But is there any chance of anything more interactive like he showed in that showing up in developer tools? PAUL: Definitely a chance of it. JAMISON: [inaudible] in a really specialized way. PAUL: Right. So doing that inside CSS would be a good first step and that’s not too hard. When I saw that it reminds me a lot of what Lea Verou did with Dablet. And so in Dablet you can get a little pop up preview of lengths of like in transitions, how long my timing is, even what function looks like charted out as a curve and being able to have a little pop up with a slider where I can just adjust from pixels from 10 pixels to 20 pixels and just change that on the fly graphically. And then when it comes to JavaScript it would be really cool to have a GUI to edit your JavaScript on the fly. I think that's incredibly powerful and the team has been looking at it and if you can figure out a UI that scales and works, then awesome. And if anyone else has an idea for how that could work inside the dev tools, please feel free to like send me your design. This is like an open source project, so really happy to get other people's ideas on how this could work. In fact, the color picker that I just mentioned was written by an XML contributor. I think he's based in Missouri maybe and he actually worked with me on the Mother F*** Animated GIF that I mentioned before. He has made the color picker code and integrated it into the inspector source code and now it’s in. So certainly if you have some ideas, we’d love to try and figure out how to make it work inside the scope of the project. JOACHIM: So the UI itself for developer tools is written in JavaScript, right? PAUL: Yeah exactly. It’s a web app. And when you bring that up, you are just looking at JavaScript HTML and CSS. And so you can open the dev tools on the dev tools and just poke around them if you want; it works. AJ: So this sounds really interesting or just a really interesting way to work with code and something I like but, how do design in a way that you could have your build tools where you are compiling your JavaScript together. And also, have that freedom of being able to have the developments easily editable? Any thoughts on that? PAUL: Yeah. Okay so, are you saying everyone should have [inaudible] process to make sure that they are optimized for production, but once you are optimized for production, it makes it quite more difficult to start to do debugging? AJ: Well, I’m saying like for example, in my development code I just have everything concatenated together, but I don’t have it minified. So still if I were to edit that file, it wouldn’t do me any good and I guess I could come up with some sort of process for having every single file included individually as a script tag in the page. Or then you know, there's people working with CoffeeScript and that kind of thing so it just raises the question, with all of these capability of being able to do so much in the browser, where do the build tools fit in and how do they mold into that process? PAUL: AJ, I’m glad you asked. So, this basically introduces the concept of source maps, and source maps are the solution to this issue. The idea behind source maps is that, we want to be able to map some version of source code back to another form. And so this was a joint effort between some developers at Mozilla and some of the Google closure guys and Chrome dev tools guys. And it’s now been implemented into Chrome, so you can try that in Canary. But potentially, so one way you can try this out -- which is you have to turn on the feature -- but let’s say that you have your myapp.min.js, that is a minified version of 6 different Java files that have been concatenated, run through closure compiler and its now in your app in production. AJ: Yeah that sounds pretty mangled. PAUL: Yeah exactly. You can bring it in the scripts tab and you can hit printify, but you know, you are still going to be looking at var a = blank, var b = whatever. So source maps allow you to basically map that minified and concatenated file back that the original six source files. And so, by essentially turning that on and having associated map file, you can now bring up the script debugger and debug in your original six source files, all completely correctly formatted, walk through the breakpoints and debugging and live edit, and get those changes over in revision history. Okay, maybe not live edit, that might be a little bit much. YEHUDA: It seems like you could theoretically do a reverse source map. But that’s definitely not a thing that people have done. PAUL: Yeah and so this is really exciting. So not only can you work for dealing with that issue of, “I have production code and that is not conducive for me to debug it,” but it also means that it enables CoffeeScript debugging, and so I can be able to set breakpoints in CoffeeScript and walk through my code there, and even though the browser is really interpreting that as the compiled JavaScript. So this kind of just kind of landed on the past few months and its now kind of a reality. I know CoffeeScript in particular. The project has to land a few patches and so, those are not available yet. And I think mostly the people don’t really have a good feeling like this exist and what this functionality means, but it means that inside the Chrome dev tools, you are able to set break points in your CoffeeScript files that look like and walk through them and the dev tools are doing the hard work of mapping those source files to the compiled JS that its actually interpreting. YEHUDA: I've actually been working on source maps support to rake pipeline, which is like my thing in Ruby and I think there's a little bit of tooling issues though. The Chrome closure guys have like the Java. So the actual source map format is not good. It’s not like human readable at all, but it’s efficient and so, I think there's Mozilla have something for Node and I’m working on something in Ruby. I think in general getting the tool into like, “Here's how you generate a source map. Please do not read the spec; use this library,” is necessary to get to a point where more people use it. PAUL: Yeah. I think for most people, most people are not going to actually be having to figure out how to generate the source maps. They are really going to be using them through closure compiler, through CoffeeScript or letting people like Yehuda figure out how it works for them. CHUCK: [Laughs] YEHUDA: I think any tool that does… so right now, the hack for concatenation is source URL, but source URL requires eval and that’s unpleasant. So I think anybody who does any kind of concatenation tool should have the very least do a minimal source map for the original concatenation, and that means that its more than just like three people, right? It’s going to be a few dozen people. PAUL: Right. Uglify would be a key as well. YEHUDA: Exactly. AJ: So like can we get some links for this in the show notes? PAUL: Yeah. We are going to have links everywhere in the show notes. [Laughter] CHUCK: We are going to have one hour show and then Paul is going to spend another hour giving us links. AJ: Well I would like that because the source map thing, I haven’t really heard of it yet. I'm Googling right now to see if they can come up-- YEHUDA: Right now it’s un-googlable. PAUL: It’s out there. I’ve been working with Ryan Seddon on this to basically highlight it but yeah, there's not a lot of content out there right now. JOACHIM: Somewhat related to this, what about Node.js debugging via Chrome tools? AJ: Yeah that’s crazy. How does that work? PAUL: So, it’s cool because basically, there is a debugging protocol that is specified and published for how-- JOACHIM: For xdebug? PAUL: Sorry, for what? JOACHIM: Not xdebug? PAUL: I don’t think so, no. JOACHIM: That will be kind of cool as well. I mean that will give the ability to even debug PHP or whatever else. PAUL: That’s exciting. But so the protocol is published for how the webkit inspector handles debugging and so there's a project called Node Inspector that just maps out Node’s debug mode into this. And so you can just use the front-end of the Chrome dev tools… I’m sorry, the webkit inspector, use that front-end and to walk through in a GUI what walk through your Node. YEHUDA: Can you get the spec for that in the show notes or put it in the chartroom? PAUL: Yeah. YEHUDA: I've looked for it a few times, like “Hey I think I can do something with this.” And I can never find the actual spec. PAUL: Sure. Yeah. It’s available through the Chrome dev tool’s Google Chrome site around the extension stuff but yeah that will be in it. CHUCK: One thing that I thought you said was that Chrome is open source? PAUL: Chromium the web browser is totally open source, Chrome is a version of chromium that has some extra things like a PDF viewer and support for H264 codec, but pretty much they are functionally equivalent with some very, very minor differences. CHUCK: So is there a good place to go and see the source code for some of the stuff? PAUL: Yeah. So if you just Google Chrome dev tools, the site for that should come up. And it’s on Google code and there's another link right on the front page called the source; it brings you over to Google code search and you should just be able to walk through it. So there's like 30 JavaScript files that the dev tools are based off of and you can just kind of breathe through how that application is architected; which is pretty crazy. But it’s a lot of fun to look through. I recently posted on my blog about using box sizing/border box for all your lay out. And the Chrome dev tools is actually one of the web apps where I first noticed this in play, where they are using box sizing/border box to you make your layout a lot easier and so I learned that trick from source of this and there's few other really cools things going on inside of it. JOACHIM: So out of curiosity, is there any pressure in you to put the Dart support into Chrome dev tools? PAUL: So I think so for Dart, there are two ways that Chrome dev tools can essentially handle that. One is through source mapping; like kind of what we talked about with CoffeeScript. And I haven’t seen that happen yet, but the Dart folks also recently release Dartium, which is a build of Chromium with a Dart vm baked into it; and then it also already comes with the dev tool support. So there's essentially already support for Dart in one way over there. JOACHIM: What's your feeling in Dart? How’s that going? PAUL: Dart is cool. Dart has a… I think Dart is exciting and provides a lot of control and different development experience than you get with JavaScript, because it has types, module system already baked in, it has a lot of features that can be very exciting for folks. Certainly as far as using it, you can compile it on the JavaScript and you can run it in all modern browsers, but you need ES5 support. So it’s not like you can run like Dart code and compile it in JavaScript and see it run in IE7. YEHUDA: It needs ES5 support? PAUL: Yeah. YEHUDA: Uh, cool story bro. PAUL: So, there's that and but I see a lot of like flex developers, other developers that are attracted to JavaScript as a language, and they like what they see with Dart and so they are playing around with it. Yeah. JOACHIM: Just to go back for a second, what we are talking before about like IDE environments with Chrome dev tools and personally I use Cloud9 IDE locally, I was going to mention because Cloud9 IDE itself has a debugging interface as well, but that’s mostly for the Node part -- the node.js part. And you’re asking for suggestions there and I'm kind of wondering if that couldn’t be something interesting like, you are saying its open to the API for the debugger is open and you can do remote debugging I suppose. PAUL: Yeah in fact, I think-- JOACHIM: That might be something that can be-- PAUL: Absolutely. I think that we might have talked to the Cloud9 folks about this before. But any web-based on IDE could kind of hook in to what the Chrome dev tools are doing and either provide a new UI for the functionality of the debugger or other parts of it, or your changes in the dev tools could be immediately reflected inside the IDE. There's an interesting integrations that are available there that I think we are going to be seeing more of. JOACHIM: Awesome. So, great time to be alive. PAUL: Yeah, totally. [Laughter] CHUCK: All right we got a few minutes before we need to get into the picks. Really quickly, I wanted to go over some of the other stuff that you do. You talking about Mother F*** something GIFs, animated GIFs and you’ve also got… what was it? It was like an HTML5— [Crosstalk] PAUL: HTML5Please? CHUCK: HTML5 what was that? PAUL: HTML5Please, HTML5Readiness, CSS3Please, Move the Web Forward; it’s a lot of those kind of sites. CHUCK: There was another one; it was like a baseline for CSS or something? PAUL: Oh, the HTML5 Boilerplate? CHUCK: Yeah that’s it. PAUL: Yeah. So HTML5 Boilerplate we recently released the 3.0, but that’s it. It’s a fun project. It initially started as kind of a, “I recognize all these things were being reused from project to project and so why don’t we just create a template, a starting template to save ourselves time when creating new projects?” And then it just kind of grew. Not only is it to save time, these are the best practices of the front-end development community; these are the links to see why they are the best practices and this is the best way to put them to use. So it’s kind of become somewhat of a community-managed clearing house of all the best ways to do things in a cross browser environment, in an HTML5 environment for everyone. And one of the other important things that we did is we built a build tool as a default. So anyone getting started with the library has a build script that runs through, does their JavaScript concat and minify, same with CSS even can minify HTML, although turns out that there's very little benefit in that. It optimizes images, which I think people don’t do nearly enough but I think I wanted to have a lot of this stuff just as easy as possible. A test suite that’s immediately hooked up, so that you don’t have excuse like, “Oh, writing tests is hard!” I guess you do still have the, writing test is hard excuse; you just don’t have the, “writing up a test suite to my script is so hard!” [Chuckles] YEHUDA: By the way Paul, you know this already but Ember uses HTML5 Boilerplate as our starting point for our starting kit project. JOACHIM: And it should be the other way around too. [Laughter] PAUL: Yeah, yeah. We’ve kept things as simple as we can, well kept things as baseline as we can, but you know, folks are asking about modules and how we are going to deal with that. And certainly I think it’s a good time to be able to define some better things in a project like the HTML5 Boilerplate regarding building that application stack. So I've been thinking a lot about this recently. JOACHIM: I was going to ask about that. I mean isn’t it difficult to say like, “Okay, this is the best practice.” I mean with our limited insights and experience and stuff like that, I mean isn’t it difficult to say like, “Well this is the way we should be doing it?” Obviously you have a community that kind of gives input, but you know, how mature is our community? PAUL: Sure I mean, okay so I think we know clear floats and there's a best practice on that, is there a best practice on including other modules of JavaScript? Like shepherd.js came just a few days ago from…  so essentially, somewhat polyfill ES6 harmony modules, in ES5. And that looks pretty cool and provides a different way of doing it than using AMD modules. So should we come out and say that this is the right was to do it? Well, it’s really hard to say. So certainly, depending on the maturity on each kind of level of building web apps, it gets more controversial and more hard to come out and say what the best practice is, but my belief is that we need to, because I am tired of every developer being faced with this paradox of choice of all these different options. And so, I think that the more that the community can define what the best practices are and reduce the number of options that all developers have, the better. YEHUDA: I think it’s very of the moment to say, “How do you really know? Maybe this choice is every developer should read the source everybody [inaudible] Everybody should think about it.” But at the end of the day, all that means is that the millionth of the developers who are writing the websites are all having to pay all these multi-week long cost to do these full evaluations. And like you said, we know how to clear floats, but I think it goes beyond that. I think we know a lot of things, and we should stop playing to the JavaScript illumati that is wants everybody to be, everybody what they want to be me, they wanna be Jeremy Ashkenas and that’s just not realistic. And I think it’s not reasonable that those of use who are very good at JavaScript and actually spend a lot of times doing evaluations voice that entire responsibility on everyone else. JOACHIM: There's a long tale of joe developer out there. YEHUDA: Rant over. CHUCK: Yeah. All right. So one last question, with Chrome, it seems like it’s constantly under development. I mean, I'll leave it up for days on end so I don’t always get the updates right when they come out but you seem to have a lot of movements with moving things forward using HTML5, using CSS3, using the new standards. How does Chrome fit into that? Do they tend to innovate quickly on those things or do they wait until more people want to use them? PAUL: Chrome as a browser, as a platform, is very aggressive. And in fact, the goal of Google Chrome is to move the web forward. You go to the Chromium Google project, that's what it says. And so the goal of Chrome was not only to create a fast browser, but also to ignite a browser race towards speed and towards making things better. And so, Chrome is very focused on that. We have a 6-week release cycle typically. So every browser, a new stable version of the browser comes out every six weeks. The other more important part than the fact that we ship every 6 weeks is all of our users is updated over the course of a few days, so I think we have 20 million users and all of those get the update and are running the new version of Chrome over the course of a week -- which is pretty rad and were excited about that. And so, we are always trying to find ways to kind of be able to let the web platform move faster, iterate better and get to the right solutions as fast as we can. CHUCK: All right. Terrific. We are going to go ahead and get into the picks. I checked my email to make sure that we had warned you about picks [chuckles] because we have people come on and go, “Oh, I didn’t know about those,” and that’s my fault. Anyway, let’s go ahead and get those out there. Yehuda, what are your picks? YEHUDA: Actually, I've signed up for the MITX Course on Electronics and I realized that… so I went to look at the prerequisites and it’s like, “Hey, linear Algebra and Physics.” and I’m like, “I haven’t taken those in like ten years!” So I went back and look at the Open courseware stuff. And open courseware has… a lot of the courses have been rejiggered into what they call as the scholar program, which basically the open courseware courses were basically a bunch of material thrown up on the website. The scholar versions are basically divided up into online modules and videos and problems and sort of designed around training. And sort of a micro pick is so I've been doing the Linear Algebra course and Gilbert Strang is the professor there, and if anybody out there ever learned Linear Algebra and found it confusing the first time around, he is so much of a better professor than the one I had in college. Even watching him on video and like actually I understand the whole area. The way l learned it originally was very, very memorization-oriented, and the way he teaches it is very conceptual and my brain likes to learn Math conceptually not memorizationally. So, MIT Open courseware electronics course, specifically scholars stuff and the Gilbert Strang Linear Algebra course in MIT open courseware. JAMISON: His textbook is fantastic too. YEHUDA: Yeah, I bought it. It’s awesome. CHUCK: All right. Jamison, what are your picks? JAMISON: So, one of them is definitely Inventing on Principle – that video that we talked about by Bret Victor. It’s incredible. It’s an hour long and it’s well worth your time to watch. He shows these amazing interfaces that he's done and he also talks about what drives him to create things and it’s just great. Another one is thing called “CodeMirror”, which is a way of embedding executable code in your website. I've seen people use it for like inline executable examples when their doing blog posts and stuff. So I’m in the process of getting that up on my website, on my blog and it’s pretty cool. And then my last one is just D3, it’s a visualization for JavaScript that is really fun to play with and make some really neat graphics. So I'll put those in the show notes too. Those are my picks. CHUCK: All right. AJ, what are your picks? AJ: So yesterday I had lunch with the HTML5 Provo Group. Pretty neat bunch of guys there as well. So if you are in Utah, pick them, right? And then you know, I just was reminded the other day of how much I like local business. I was looking at getting some business cards because I’m doing DJing on the side and --- is super complicated, like you can’t even get to their check out from cart area without going through 10 advertisements. And so I happen to be having a haircut right by this place that does signs and graphics and that kind of thing and popped in and talked to a guy and local owner and he just liked what he did and liked helping people and just so nice to have that community, for whatever it is you might be interested in purchasing or service or whatever. CHUCK: Cool. All right. Joachim, what are your picks? JOACHIM: I'll go with the three.js in pushing the web forward. Three.js is a library for helping to write WebGL programs. CHUCK: All right. JOACHIM: It’s a framework for that. And also I'll go with Quake 2 WebGL, which is an implementation or a court of the Quake 2 in WebGL in your browser. CHUCK: Quake [Chuckles.] JOACHIM: You know, I’m a little bit upset that it’s Quake 2, not Quake 1 which is, you know, what I grew up with like Quake 2 was too slow. CHUCK: I think I played Quake 3 in college. Anyway, I suppose I’m next.  One of the picks that I have is something that I picked up for a couple of my websites. I’m paying somebody to actually do the design for one of my websites. It’s going to be a rather large website. And anyway, I was looking around to see what other options there were, and some friends pointed me to themeforest.net and themeforest.net was just a place where you can go and get HTML layouts. Some of them actually use some of the jQuery plugins to do like animation of different images so you can click back and forth and you can see different images and stuff like that. But you know, mostly it’s just you know, general HTML and CSS. And it’s something that I really… I found a couple that I liked and so hopefully those work out for me as far as the websites that I’m building. And that’s the only pick I really have for this week. So we’ll let Paul give us some picks. PAUL: Nice. Okay I just wanted to first mention Joachim’s picks of three.js, one of the interesting thing is that… so Three has a render built-in for webGL, but it also has renders built in for 2D canvass in svg, but if you might have seen eko.net recently got a redesign, crazy header on top and it uses three.js and the guy behind that wrote a render for three.js with 3D transforms. And so that just came out; so you can now create a scene in three.js library and actually render it in transforms -- which is pretty wild. A pick of mine that I had is from the commit log of Prototype.js Andrew made a recent a commit and he used a little syntax trick that didn’t understand I asked him for some detail in GitHub and its three right angled brackets and its called a zero fill right shift bitwise operator. And essentially it’s an ES3 compatible trick that is like ES5’S two int 32 operation. But essentially, it coerces strings to numbers and false values to zero. And it’s just kind of cool. Another pick that I have is the DOM mutation observers. So if you use mutation events before, you should take a look at mutation observers which are available in Chrome stable now. They have performance that is somewhere around 500 times better. (I’m just going to throw that number out there.) It’s a lot faster and that was recently shipped; we have all the information about in HTML5Rocks along with a JavaScript library which sits on top and basically summarizes the DOM changes. And so that’s really, really good if you are writing any sort of browser extension that hacks an existing page, but it also allows you to kind of watch the DOM and respond to it in a kind of brand new way. YEHUDA: Also, Canary has now… I don’t know if it’s in existing Chrome, but Canary has check box that you can check off the specific mutation observers -- which is pretty awesome. PAUL: Yeah. And I think my last is ToDo MVC, which is the project which tries to have the same in any number of different client side MVC frameworks released a new version 0.3. They have new apps for Dojo and CLojure and updates for some of the existing ones. So, as always, if like we were saying, we think that everyone has to do technology evaluation on their own, but if you are doing that, ToDso MVC has the a good showing of the current options and how the code looks for each of them. CHUCK: All right. Terrific. So just wrap things up, I wanna let folks know that they can get the show notes and there will be lots of links at javascriptjabber.com. You can also give us feedback and suggest show topics for us by going to javascriptjabber.com and clicking on “request a topic” or clicking the feedback tab that’s just kind of floating there at the bottom of the website. Other than that, I just wanna thank Paul for coming again. It’s always fun to have a guest; especially somebody who is knowledgeable about the subject matter. And we’ll catch you all next week! Thanks guys. PAUL: Bye! YEHUDA: Bye! JAMISON: See ya! AJ: See ya! JOACHIM: Enjoy.

Sign up for the Newsletter

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