Latest Shows:

 RNR 167: Rapid Prototyping with Perttu Lähteenlahti —

 MJS 148: Farzad Yousefzadehr —

 iPS 291: App Store Subscriptions with Jacob Eiting —

 TFS 368: How to do Personalized & Relevant Ecommerce Marketing with Rytis Lauris —

 DevOps 036: An Overview of MicoK8s, Charmed K8s, and Other Ubuntu Infrastructure Tools with Alex Chalikias —

 RRU 109: SVGS in React with Elizabet Oliviera —

 .NET 027: High performance databases with RavenDB with Oren Eini —

 AiA 282: Fauna and Cloud Databases with Evan Weaver —

 RNR 166: Working From Home with Will Gant —

 OO 007: How to Hire Developers without Tech Skills —

 iPS 290: Building Community Based Apps with Tamar Nachmany —

 TFS 367: Bookkeeping and Finances with Paul Kogan —

 DevOps 035: Rapid Infrastructure Automation with AWS CDK —

 VoV 107: Cypress Testing with Amir Rustamzadeh —

 RR 460: How to Brainstorm Introverts with DeeDee Lavinder —

Subscribe
  1. Home
  2. JavaScript Jabber
  3. 120 JSJ Google Polymer with Rob Dodson and Eric Bidelman

120 JSJ Google Polymer with Rob Dodson and Eric Bidelman

  • Aug 6th 2014
00:00
Download MP3

Panel

Discussion

02:08 - Guest Introduction

Picks

Next Week

Broccoli.js with Jo Liss

Transcript

JOE:  So, what’s up?[This episode is sponsored by Frontend Masters. They have a terrific lineup of live courses you can attend either online or in person. They also have a terrific backlog of courses you can watch including JavaScript the Good Parts, Build Web Applications with Node.js, AngularJS In-Depth, and Advanced JavaScript. You can go check them out at FrontEndMasters.com.]**[This episode is sponsored by Codeship.io. Don’t you wish you could simply deploy your code every time your tests pass? Wouldn’t it be nice if it were tied into a nice continuous integration system? That’s Codeship. They run your code. If all your tests pass, they deploy your code automatically. For fuss-free continuous delivery, check them out at Codeship.io, continuous delivery made simple.]**[This episode is sponsored by WatchMeCode. Have you been looking for regular high-quality video screencasts on building JavaScript done by someone who really understands JavaScript? Derick Bailey’s videos cover many of the topics we talk about on JavaScript Jabber and are up on the latest tools and tricks you need to write great JavaScript. He also covers language fundamentals, so there’s plenty for everybody. Looking over the catalogue, I got really excited and I can’t wait to watch them all. Go check them out at JavaScriptJabber.com/WatchMeCode.]**[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 120 of the JavaScript Jabber Show. This week on our panel, we have Jamison Dance. JAMISON:  Hello, friends. CHUCK:  Aaron Frost. AARON:  Hello. CHUCK:  AJ O’Neal. AJ:  Yo, yo, yo, coming at you live from San Mateo, California. CHUCK:  Joe Eames. JOE:  Hey, there. CHUCK:  I’m Charles Max Wood from DevChat.TV. And this week we have two special guests. We have Eric Bidelman. ERIC:  Bidelman. Hi. [Chuckles] CHUCK:  Bidelman. I should have asked. ERIC:  No problem. You’re not the first one to get it wrong. AARON:  Beetlejuice. ERIC:  Beetlejuice, Beetlejuice! JAMISON:  [Chuckles] ROB:  And Beetlejuice. ERIC:  [Laughs] CHUCK:  We also have Rob Dodson. ROB:  Yeah. Hey, how’s it going? CHUCK:  You guys want to introduce yourselves really quickly? ROB:  Yeah. So, I’m Rob Dodson. I’m a developer advocate here at Google and I work primarily on the Polymer project helping to get Polymer in people’s hands and also to help folks learn about Web Components and these cool new emerging standards. ERIC:  Yeah. And my name’s Eric Bidelman. I’ve been at Google and their developer relations team now for almost, a little over six years, and primarily focusing on HTML5, and working with Polymer and Web Components now. It’s been my focus the last couple of years because I’m a web developer and I’m super excited about this stuff as a web developer. So, I want to help other folks get ramped up and start using it. CHUCK:  Awesome. AARON:  That’s awesome. CHUCK:  So, the show title says Google I/O. Are we talking about the conference or are we talking about something else? ROB:  We can talk about Google I/O. We can talk about Web Components. That’s really Eric and I’s field of expertise at the moment, is Polymer and Web Components. So, if you have questions about that, I think that’d be a good place to… JAMISON:  I’d love to talk about the Polymer stuff. CHUCK:  I was going to say, how about yes? ROB:  Okay. AARON:  Yes to everything. CHUCK:  So, Polymer, HTML5, Google likes that stuff? ERIC:  Google loves that stuff. ROB:  Yeah. It’s good for the web. Do you want us to maybe give a quick summary of what Polymer is, what Web Components are? CHUCK:  That would be perfect. ROB:  Okay. So, Web Components are a set of new emerging standards. So, basically trying to come up with a really good strong component model for the web so that developers can build widgets, bits of UI, even non-visual components, and have them have really strong encapsulation, good scoping for things like styles and markup. And so, there are about four different specifications that make up Web Components, each one by itself [inaudible]. When you combine them altogether, you get this really powerful component model. And Polymer is just a really opinionated way to work with Web Components. So, one thing that it does is it adds polyfill support for any of the missing Web Component specifications. But the other thing that it does and the more important thing that we think that it does is it just gives you a good direction for how you should build and create your Web Components. So, there’s a lot of developer sugaring that we’ve added to Polymer just to make it a lot faster and a lot easier to get up and running creating components, creating data bindings with them, loading them into your page, things like that. So, from the really high level, that’s those two technologies. CHUCK:  Cool. Are people out there actually using stuff right now? Is Google using it? ROB:  Yeah. So, we’ve been using it. The Polymer website is built using Polymer. Chromestatus.com is built using it. There’s a site that actually just went up recently from Michael Bleigh, the creator of Divshot, called Ele.io, E-L-E dot I-O, which is like a JS Bin type site but it’s written and created using Polymer elements. And probably the biggest thing is the material design stuff that we were showing at Google I/O is built using Polymer and Web Components. So, that’s all open source right now. If people want to go to the Polymer website or go to our GitHub board, they can actually grab those elements and start playing with them. And also, Salesforce. Salesforce has been building stuff with Polymer as well. ERIC: Yeah, I was going to say don’t forget Salesforce. They got really stoked about Web Components and started moving their mobile SDK to have an offering with Polymer components because it really makes sense for their developers. Also, a little known fact, I think I shared this in one of my I/O presentations, is that the Chrome OS keyboard and the media player in Chrome OS are actually also built using Polymer, which is cool. So, I like to think of any time you’re chilling on Chrome OS and you’re listening to your tunes or watching a movie or something, you’re doing it through Web Components. JAMISON:  So, I have a question about Web Components in general. It seems like it’s unclear in my mind what parts of Web Components are based on the spec and what are just people implementing stuff. I know that various frameworks do different kinds of component-y things. It seems like a vague term to me, at least. Can you clear up some of that? Or is it still just pretty up in the air? ERIC:  So, I can take a stab at this one. So, I’ve been in, when Polymer started which is now over two years ago at this point, but the longer term initiative here is through all the specifications, the Web Component APIs. So, this has been in the works for over four years now. So, the Chrome team and members of the Blink team have been working in a standards body, working with Mozilla and others, on trying to get, just identifying the necessary APIs that we were missing from the web in order to build just really complex, really awesome applications, just general APIs for productivity. That’s really what Web Components is all about. And if we get nothing more out of it than that, it’s a win. I think Rob, myself, anybody who’s touched the stuff so far can contest that it’s very, very valuable and it makes your life very productive. So, there are a lot of these lower level primitives that they put in just to make things that other frameworks for instance, have implemented. So, they’ve implemented stuff in JavaScript. But hey, why not add something that everybody’s doing directly to the browser, right? This is very akin to something like document.querySelector or some of these other APIs that jQuery made popular. And now of course, those are built into JavaScript. They’re built into the browsers. Everybody can take advantage of them natively. So, there’s all that specification work, and like Rob said there’s the four main specs: the Templates, the Shadow DOM, there’s Custom Elements, and what am I forgetting? And HTML Imports. ROB:  HTML imports, yeah. ERIC:  Yeah. That’s the one everybody takes for granted because it’s by far probably the easiest. But it’s also probably one of the most important ones. So, those are the four main specs. And other interesting players are things like Object.observe. These are primitives that are landing that aren’t really under this Web Components umbrella term. I think of Web Components as the new HTML5 term where it’s this catch-all of all this new stuff in the platform. But the four primary ones are the template, shadow DOM, custom elements. ROB:  And HTML imports. ERIC:  And HTML imports. [Laughter] JAMISON:  You forgot it right after saying everybody forgets it. ERIC:  Yeah. ROB:  Yeah, so that’s the main difference I guess, is that we have those four specs. And you can go and you can actually read through the specification. All four of the specs that Eric listed are now actual features that are shipping in Chrome. They’re just part of the platform. And that’s all stuff that other frameworks have had to invent for themselves. And now, it’s just there. They can just leverage it natively, which means they can write way less code. They can take a lot of code out of their codebase. And hopefully, it can make things a bit speedier for them as well, because they’re not having to build this whole universe on top of a browser. JOE:  What about other browsers and how standardized are those specs? And are the specs recognized as standards yet? ERIC:  Yeah, so Templates has been there the longest. And that one’s been, now it’s in Firefox. It’s in Chrome. Safari’s working on it in a nightly. It’s in a WebKit nightly build. So, that one’s been around for now maybe a year or two. Custom Elements went to last call recently, earlier this year. Shadow DOM is still evolving but it’s getting to the point where now it’s pretty stable. Obviously Chrome has stable Shadow DOM. So, we’re probably not going to iterate on it too quickly from there. But we’ll adopt any changes the standards committee has come up with. And then HTML Imports is still, I forget exactly where it is in the standards process, but it’s also pretty well-defined at this point. JAMISON:  Okay, time for a confession. I’ve heard the word Shadow DOM a thousand times. I’m a professional web developer. I don’t know what Shadow DOM means. [Laughter] JOE:  It’s the only thing I know out of everything that you said. But it’s also got the coolest name. It sounds like something out of an anime. ROB:  Yeah. [Laughter] JOE:  Look out for the Shadow DOM! AJ:  I’ll take this one. ROB:  It’s the most effectively named. ERIC:  Yeah. AJ:  Jamison. The Shadow DOM is when you salt your DOM and then crypt it with an MD5 salt. [Chuckles] JAMISON:  Is it like the dark web? ROB:  It is. It’s like the dark matter of the web, yeah. JAMISON:  [Chuckles] ROB:  You can’t see it, but it’s there, exerting force. AARON:  Anti-web. ROB:  Yeah. ERIC:  It serves a purpose, yeah. ROB:  So, the Shadow DOM in a nutshell is basically like a separate little document tree that you can put DOM into. You can put HTML markup and CSS in there. And when it all gets composed together, that stuff’s going to render, but it is protected from the parent document. So, someone is not going to, if someone writes a CSS selector or something like that, it’s not going to affect the DOM nodes that are inside of that tree. So, it gives you CSS scoping. If someone writes JavaScript or they’re using jQuery and they’re like, “Oh, I want every paragraph on the page,” it’s not going to find a p tag that’s in that separate little tree, because it’s encapsulated in there. So, the really best example is if you look at the video element. And when you use a video element and you give it a controls attribute, you see all these little controls at the bottom. You see a play button and pause and scrubbers and things like that. But you don’t have to write any markup to make those controls show up. You just add that attribute and they magically appear. And so, if you go into the Chrome Dev Tools and you turn on Show user agent shadow DOM, you can actually inspect that element and you can open it. And what you’ll see in there is this little hash symbol and it says shadow root. It’s like a little document fragment. And inside of there, you’ll see that those controls are actually just like divs and inputs and things like that, but they’ve been hidden from you in this little tree. So, the nice thing about that is it lets you make these components which you can compose together very nicely because they’re not bumping into each other. Their styles are not colliding. Their markup’s not all over the place. It’s like a big composability feature. And you’ve actually been using it all along and you didn’t know it, because input and text area in video, these all use shadow DOM. JAMISON:  That’s pretty cool. ERIC:  Yeah. The way I think of it too is it’s all about scoping with Web Components. It’s scoping the problem. It’s scoping how we develop. It’s narrowing your field of what you’re trying to achieve. Let’s define that functionality. Let’s wrap it in a component. Make that thing reusable. And so, like Rob said, for the first time we can actually scope CSS. We don’t have to have this global style sheet that we add to over time hoping our styles will just work out in our app. We can actually just define that stuff inside of the component and it’s just scoped to the component by default. So, you have some guarantees now as a developer that your CSS isn’t going to leak out. And if somebody’s embedding your component, that stuff’s not going to actually leak in and affect how your component looks because you’ve spent a lot of time making it look awesome. So, you don’t want that to be mucked with. So, it’s really cool. The feature is again, it’s all about scoping. And this is something that Polymer uses out of the box. We just say, hey we think it’s really valuable to have DOM and CSS scoping where everything is self-contained. So, by default, when you create something in Polymer, you’re creating it using Shadow DOM. So, you get those features for free. JAMISON:  So, I’m so used to the workflow of working with the DOM as a tree. It seems like if everything is made using the Shadow DOM, then it’s all going to be one level deep and you won’t be able to dig down into stuff. Is that a problem that comes up? Or does that even make sense? ERIC:  It does make sense, yeah. We actually have examples of this where some of our demo applications, the entire application is your html tag, your body tag, and inside of that you just have one element. You have app-my-awesome-app-maker or something. This is the name of the tag that you’ve created. So, your entire app is one single html tag, which is kind of crazy. But it just goes to show you how far you can actually push that stuff. The example that I usually like to show and explain to people why Shadow DOM is important is because if you take a look at Gmail for instance in the Dev Tools and you inspect the markup that Gmail renders, this is a really complex application. But if you look at it, it’s all constructed using divs and just a bunch of gobbledygook. So, it’s actually as a developer, it’s hard to come in there and maintain that code, know what’s going on. And ultimately, a lot of that stuff is just implementation details of Gmail. And so, that’s really what Shadow DOM brings to the table, is it’s giving developers now the opportunity to hide some of the implementation details that aren’t necessary for users, or other developers I would say, of their app or their page to actually look into. But having said that, this is the web, you can poke around. As Rob said, you can turn on the Dev Tools and you can drill into stuff now. So, as a developer you have full control. If you want to, you can muck with someone’s Shadow DOM. You can use the document.querySelector to get inside. You can edit things and change things in CSS. So, we didn’t want to remove that ability, because that’s actually, the hackability of the web is really important. A lot of us grew up on learning web development just by viewing source. We want to preserve that sort of tradition and being able to hack and change things if you need to. So, by default it gives you some guarantees and some encapsulation and scoping principles. But you’re totally as a developer, as a user of someone else’s component, if you need extra manpower you can totally drill in and do something to your liking. ROB:  Yeah. One way that it was explained to me which I actually really liked was by Scott Miles who’s one of the architects of Polymer. And he was like, think about a program that you might write in C++ or Java where you’ve always got a main function that kicks off the entire program. And the first thing you learn is don’t put your entire program in the main function. Break it into objects and have things that are local to those objects. And you can think of Shadow DOM in a very similar way. For basically most of the history of the web, index.html has been the main function for your website or your web app if you want to think of it that way. And we’ve just been throwing everything in there. Your entire site goes in index.html. There’s no bundling up and scoping of these things. And so, Shadow DOM lets you think about your page more as objects and that can be really useful for just your mental model. JAMISON:  That’s really cool. I’m glad I know what Shadow DOM is now. ERIC:  [Chuckles] Now everyone’s an expert. Yay! JAMISON:  Hooray! AARON:  Knowing’s half the battle. CHUCK:  Yep. It’s like dark matter. [Laughter] JAMISON:  Chuck’s got it. AARON:  So, I’ve got a question. I don’t understand how Web Components are going to be efficient in terms of the network traffic, because I’m going to just include a bunch of links to components on other places and they’re all going to pull down their own CSS and scripts and blah. So, how is that efficient? Because normally today, we go through a build process to try and get everything into one JavaScript or a few JavaScript files, and a handful of CSS files. How is Web Components a thing that can be efficient? JAMISON:  It seems like you’re counting on HTTP 2.0 at that point, right? If you’re actually pulling them down from different places on the network. ERIC:  Yeah, one thing that we have… you’re absolutely right. So, the notion here is that with HTML Imports, in using Web Components you can load in someone else’s component. And maybe that component you’re loading loads ten other components or uses ten other things that it needs to get its job done. And so, I think the way I think of this is that first and foremost, Web Components makes us more efficient as web developers and we’re more productive. And then web best practices still apply. So, as we had developed tools over the years for just regular application development, we’re also going to need tools for this world of Web Components to learn things like what an HTML Import is and how to deal with it. So, we actually wrote a tool. It’s called Vulcanize. I forget the actual definition on Wikipedia, but it has something to do with polymer. It’s the process of polymerization or something. So, it was named appropriately. But it’s pretty cool. It’s this little Node script that you can run. You can also use it with Grunt or Gulp. And it’s essentially our recommended build tool for crushing and concatenating a list of HTML Imports and of the dependency tree. So, you can tell it to do things like, “Hey, I want to have a single HTML Import.” And so, you can reduce 100 network requests, if that’s what your app is doing, into a single one. It can do things like inline CSS and minify HTML and CSS. And it can also deal with things like CSP. So, if you’re in a CSP environment like Chrome Apps or something, you can separate out your JavaScript. So yeah, really cool tool. And it’s definitely, right now tooling for Web Components is still very new. We’re only a couple of years into this. And as of Chrome 36 this year at Google I/O, this is the first version where there’s native stuff, with the native APIs in all the browsers. So, as people start to discover this and need additional tools for their workflow, I think you’re going to see some really cool stuff come from the community. JAMISON:  You said CSP back there. ERIC:  Yeah. JAMISON:  Define that. ERIC:  Yeah, so CSP, Content Security Policy. JAMISON:  Oh. ERIC:  Yeah. It’s basically, for those that don’t know, Chrome Apps is a good example where this is in use. So, you can implement this on your server just for extra security measures to prevent things like XSS attacks. But Chrome Apps by default, if you’re building one of those, it actually has this built into the system. So, we want to make it, the application that a developer creates, very secure by default. And so, with that comes restrictions in what you can do. You for instance can’t have inline script tags. Now, that’s just a no-no in CSP world. So, you have to reference an external script or source equals instead of inlining a script, as one example. AARON:  So, Vulcanize. It’s a Polymer build or it’s a Web Components build or it’s a build for both? ERIC:  Yeah, good question. So, right now it’s evolved to be more of a Polymer tool, just because we have this declarative way to create custom components with the polymer-element. And we have some other Polymer features that it knows about that aren’t part of the Web Components standards. But I think what’s going to happen over time is that this will evolve hopefully, by means of the Polymer engineering team doing it or by means of the community actually helping out, is to adapt it into a generic build tool for Web Components. I think that’s really, really awesome and definitely needs to happen. Biggest thing that it does is just… it’s simple what it does. It just traverses the imports in your file that you load and just goes off and discovers those and creates them and concatenates them in one file. So, it’s pretty trivial what it does, but ultimately it’s a huge performance boost. And if you’re worried about network requests, that’s absolutely the way to go. AARON:  Are you guys going to be mad if I ask you a question from Angular land and you guys keep talking about it in Web Component land? Is that cool? ERIC:  Yeah, that’s cool. AARON:  So, one of the things I like about Angular is you can have these things called directives. ERIC:  Yeah. AARON:  Which are like the new attributes that HTML didn’t use to support, right? And I like that I can take one element, some random div, and I can put a directive on it and then it does a new thing that it didn’t use to do. But I also like that I can put two directives on the same div and now it does two things it didn’t use to do. So, they’re really composable if you modularize them into what you want them to do. You can plug-and-play them and you get both effects on one element. ERIC:  Right. AARON:  Is there a way to do this with Polymer or with Web Components? I’m not seeing one. Can you guys talk about that? ERIC:  Yeah, sure. So, there’s actually not a direct comparison for annotating an element with two different features as you described. That’s actually something we typically… what we typically do for something like this is you create two components for each purpose. And then you compose them together inside of another component. And so, one thing that Custom Elements does give us now is this common way to extend other people’s work. So, we don’t have to rethink about using somebody’s other, some framework API to extend an element or a component. There’s actually a standard way with Custom Elements to do that now. So, if you wanted to you could easily create this new element that has both those features together and that composes these elements together and these components together to have both of those features. So, instead of annotating, you’re working more at the component level and composing. AARON:  Right. ERIC:  There’s also, there used to be a thing I’ll just mention. There used to be this thing in this Shadow DOM spec or one of the specs, that was called decorators. Decorators actually, it was the ability to annotate an element with CSS. It would say, “Hey, be this fancy button,” or something. And it would inherit all this cool CSS and whatnot. That actually, it’s in a holding pattern. It’s not going to really progress. I guess the browser engineers think it’s just too impossible to implement and it’s not going to be performant in any way. [Chuckles] So, we don’t want that. Obviously, we don’t want to introduce any new APIs in the web that are just crap, especially now we’re in this mobile world where everything has to be lightning fast. But yeah, that’s where that is. AARON:  Gotcha. JAMISON:  I wanted to ask about the Polymer stuff that was announced at Google I/O. I didn’t follow it super closely, but I gather there are a bunch of new components introduced basically, right? Is that accurate? ERIC:  Yeah. For a long time, we’ve been developing Polymer as this sugaring library to make Web Component development really easy. But we also wanted to bend and create some really compelling components for people to just use. I think there are two kinds of developers in the world of Web Components in this new ecosystem. There’s the kind that are going to author components. These are the really fancy awesome library and UI frameworks out there. They can create components that are really awesome for people to use. And then there’s just your regular web developer that wants to just drop something in on their page and have it start working. And so, those are your consumers of components. And there’ll be two flavors. There’ll be people that develop stuff and there’ll be people that just consume stuff. So, what we did was a while back we started creating our core-element set which is essentially just a useful collection of things you would normally do on the web. So, there’s a component for doing things like selection, so doing multi-select. Collapsible widgets, things that every UI framework out there does but we wanted to show people how to do it in the world of Web Components and how to structure these things and compose different elements together. And so, that’s been growing for a while. We probably, at the end of I/O last year we started hitting that road pretty hard, and creating a bunch of useful stuff. And that’s still continuing to evolve as we ourselves discover the best practices of building applications based on components. And then at I/O this year, Rob can probably talk more about this. He’s our design dude. But we launched and we talked about material design and the UI portion of our component set which is based on Google’s material design. Rob, you want to talk a little bit more about it? ROB:  Yes. The material design stuff was, it’s like the core-elements give you a really good base to build upon, and in material design stuff we want to have more of an opinionated look-and-feel to things. And in particular, we want to make sure that we have this really nice unified UI across all the different device platforms that are out there, because as a web developer these days, building a website is no longer like, “Oh, it’s got to work on a desktop and laptop and phone.” Now there’s a bunch of different form factors for phones, there’s TVs. Now we have wearables. And so, the whole idea of material design has primarily been, let’s make something that works good across all of these platforms. And the element set makes it really easy for you to just drop these elements into your application and get up and running really fast. And so, there’s this really awesome power that comes from that where, as you’re building something and maybe you’re building a mobile app and you’re like, “Yeah, I want to have a toolbar up here and I want some content that scrolls underneath it,” just being able to bolt together a couple of elements makes you feel like you’re using something that’s closer to UIKit from iOS versus just cobbling together a bunch of HTML and CSS. And I think that’s really where we want to head with this, is we want to build these element sets that give developers the sense of they’re working with a really solid SDK versus just copy and pasting widgets all over the place. ERIC:  Yeah. Just to reiterate, being able to just declare something on the page and start using it and not have to muck with JavaScript or CSS is extremely powerful. And it just makes you, it starts you off at hero rather than zero. [Chuckles] So, the CSS is all part of the element. The JavaScript is all part of the element’s prototype. And so, you just as a user, if you want to scaffold out a mobile application, you drop in a core-toolbar, you drop in a material design scroller panel or something, and an app drawer that slides out, and all that stuff is again just built into the element. So, you have to think about less when you’re building with Web Components. JAMISON:  That sounds rad. AJ:  So, here’s a question I’ve got. With the Web Components, what is the package manager for that going to look like? And what about server-side components? Because if we had a good widget for adding a credit card, shouldn’t we have some super easy to add widget into your Node or whatever for the API for that? ROB:  So, I can take the first half. The first half was about package management, correct? AARON:  Yup. ROB:  The package management that we’re using right now is Bower, primarily because it’s configurable. It’s pretty easy to get set up with and it’s oriented towards frontend packages. And it does a really good job of making sure that when you’re pulling down a dependency, that you’re pulling down only, you’re only pulling down that dependency one time. Basically, it’s deduping things, versus npm, which is put the dependency over and over and over again into Node modules folders. And then you’re going to need to run dedup on that. So, we’ve chosen Bower initially, not that we’re ruling out npm or anything like that. We’re still definitely interested in other package managers and how they can work well with Web Components. We want to make sure that whatever we use is the best tool for developers. So yeah, we’ve initially focused on using Bower, but we’re definitely open to exploring other options if folks have compelling reasons why they want to use something different. ERIC:  And this is one of those things, too. We mentioned Vulcanize as a tool that’s come out of the need for something to have a build tool for Web Components. But maybe a new type of package manager is necessary for the world of Web Components, too. Right now Bower is the new hotness for frontend development, but it’s still pretty young. But there could be something in the future that the Polymer team or the Web Components ecosystem adopts just because it is built and suited more towards this component development. I think all tools today as far as package managers for the web are a little bit different. They have their own strengths and weaknesses. But Bower just happened to be the most closely aligned one that we needed at the point of getting people up and running and installing stuff. JAMISON:  So, I wanted to ask about the role of Web Components in existing frameworks. It seems like you mentioned it already, but I think we could talk a little bit more about it. So, especially stuff like React that’s already component-ish. Do you see a future where the state management stuff of React is all still around but it uses Web Components underneath? Or do you think that these are two separate evolutionary trees? ROB:  I think that that could still exist for some things. It depends on… the interesting thing is that Web Components open a million doors. And so, there’s a million ways to do things. But I think that one of the things that I’ve been looking at is Flux from the React team. Have you guys seen that? AARON:  Mmhmm. ROB:  Yeah and just starting to explore that and to see if Flux does a good job of handling a cycle of how data flows into your elements. And then how it, once your element is ready to respond to a change or something, how that flows back through the circle. And I think that perhaps something like that totally works with Web Components, because at that point you’re just treating your component as just a little view. But you can, if you want, go then more complex. And you can have components that are like view controllers. You can have components that are managing the state of all of their children. I’ve taken the React tutorial even and just rewritten that as Polymer elements just to see if I liked passing data around that way. And it totally works. But at that point, you’re sticking to a pattern versus something that’s actually built in directly. React has this notion of state versus prop. And a Polymer element doesn’t have anything like that. You’re just saying, “I’m only going to send this data this one way.” So, I think you can do it really any way. I think that there will totally be room for all those approaches. ERIC:  And I know for instance, I know the Angular team is really interested in some of the specifications and the lower level primitives. And so, I think for 2.0 they’re considering adding in native support for things. Like when you create an Angular directive, maybe you’re using the Custom Elements API under the hood. Or when you create a directive, you’re using Shadow DOM to get some of its benefits, like CSS scoping and DOM scoping. And so, again it’s the beauty of the whole system now, is that it’s at its lowest level, it’s all just new stuff in the browser. So, if you’re a framework author, if you’re a regular developer, you can take advantage of that stuff. And you can go low to the metal and touch the native APIs. React is an interesting one just because it completely bypasses any notion of DOM. So, the browser’s lowest level is the Document Object Model. What React does is it actually it creates a virtual DOM. So, they say, “Hey, look. We’re going to just bypass this completely and avoid it,” just because it is too clunky. It’s too hard. And so, they have their own system for dealing with that that pushes out changes. What Web Components is really doing is embracing that, embracing the DOM and saying, “Hey, we can add APIs that are actually [chuckles] meaningful and usable, and make this stuff fast.” AARON:  I think Web Components adds more to the game as well, just as a standard and as an API. It’s bringing things like scoped CSS that whether you’re in React or Angular or Ember or jQuery even, you should be able to benefit from things like scoped CSS. So, the levels of how much Web Components benefit everyone depend on what you’re trying to do. But everyone should be able to use some part of the Web Component API if you need it. ERIC:  Totally. Template is also a really good example. It’s a single new tag that you can drop in on your page. And anything inside of it is just totally inert. So, it’s actually a true template. It’s true templating in the DOM. So, if you’re creating an application that uses HTML, it makes sense to scaffold out and create templates in HTML to do that. And so, it’s really cool because it has features like not making a network request. If you have an image in a template, it’s not going to fire off that request until the user, the developer, actually activates that template. And this is really hard to do, just by polyfilling in JavaScript. It’s almost impossible to do. And so, this is the hurdles that frameworks have had to go through over the years, is to implement a lot of this heavy business logic themselves. And now, they can just start using these native features for free, and taking advantage of what they do. JAMISON:  You guys are deep into Web Components and you’re very excited about them, and it’s very easy to talk about awesome stuff they do. Are there any weaknesses or potential problems that come along with all these new APIs and with the idea of Web Components? ROB:  I think that the one thing that’s really, really, really tough for a lot of folks is taking something that maybe worked in the world before Web Components and then trying to stuff it into a Web Component. And it’s what, I personally, as soon as I learned about Web Components the first thing I did was I was like, “Great. I’m going to take Twitter Bootstrap and I’m going to shove it into a Web Component.” [Laughter] ROB:  And everyone has this first inclination, because it makes so much sense. You’re like, “Bootstrap is components. I’m just going to make them into tags.” But then you run into the fact that the Bootstrap style sheet is just one big long style sheet that was written assuming that it could touch every part of the document. And when you are suddenly scoping bits of the markup, scoping it so that the CSS can’t reach it, the CSS would actually have to be in the Shadow DOM with it and you would have to write that element from the ground up, that’s where people I think get really confused and really frustrated initially. And it feels like they’re like, “Ugh. Why doesn’t this just work?” And well, it’s a totally different model. And so, there’s a lot of stuff that we have right now, like jQuery plugins, things like Bootstrap, Foundation, and frameworks like that, that totally will work as Web Components but there is going to have to be a time investment there to rebuild things as Web Components, leveraging the scoping and the encapsulation instead of trying to fight against it. So, that seems to be one of the biggest hurdles that people run into for sure. ERIC:  Yeah, and I think my little spiel for this at I/O was B.C.E., Before the Common Era, but what that means now is Before Components Existed. Like Rob said, there’s this time before Web Components where everything was written to be like it was just this global context. And you had complete control over the universe. But now, we have to get developers in this mental model of changing their views and changing from this global context to again, think about the problem that you’re trying to solve and create a very specific component functionality for that problem. And that makes application development much, much easier, too. We’ll be able to scale our apps a lot better by reusing different chunks. So, there’s a lot benefits there, but I totally agree with Rob. One of the biggest pain points we see today from folks is just, “Hey, can I use, insert library X or component framework Y, inside of a Web Component?” The answer is, sometimes, the answer is maybe not, because it just was built in this time before this stuff existed. The thing that comes up a lot, since this is a different way to think about building web apps, a lot of people come into components or play with Polymer for the first time and they’ll create some really basic, trivial components. I think the x-kitten element. JAMISON:  [Chuckles] ERIC:  That just renders a bunch of kittens on the page, is something that obviously is a toy. But I’m really interested in the proliferation of an ecosystem and actually growing this to be something that any web developer can take advantage of. I shouldn’t have to reinvent the wheel every time I start an app. I can go get somebody else’s awesome component they’ve created. That’s probably not going to be an x-kitten element, but it could be an awesome calendar widget or something. So, that’s what I’m super excited about. It’s just being able to not have to start from scratch each and every time I create something. AARON:  We’re about out of time. Can I ask a couple of Google I/O questions? ROB:  Sure. ERIC:  Sure. AARON:  How long before and after I/O is life at Google not normal? I know there’s ramp up and there’s ramp down. And I was at I/O and there was so much Dart and Polymer this year. It was everywhere. So, I’m imagining you guys had, all the Chrome dev evangelists were going insane. So, how long is life not normal? Are you guys back to normal yet? Or yeah, that’s what I’m asking. ROB:  [Chuckles] ERIC:  I’m still tired, personally. Rob, what do you? ROB:  Yeah. I am also, yeah, a little worn out still. Leading up to I/O is interesting because I don’t know if people realize just how much time we spend on it, how much work goes into it, how much prep there is. Everyone’s rehearsing their talks multiple times, writing their decks, getting them approved, trying to figure out what your messaging is going to be and your demos and your examples. And it’s huge. It’s a few months of that’s it. And it’s like a meteor or something heading towards the earth and you see it up in the night sky. And it starts to get bigger and bigger and brighter and brighter very slowly, until it’s all you can see. And then it just happens and it’s like a big blur. And the afterwards, everyone just goes on vacation. Everyone’s like, “Done!” [Chuckles] JAMISON:  That sounds a lot like Doomsday. ERIC:  You are still on vacation, too. ROB:  Yeah. Yeah, I am. People are still taking vacation right now. They’re just like, “Ugh. I’m out.” JAMISON:  So, the meteor approaches, hits, everyone dies. ERIC:  [Chuckles] And then they come back to life as zombies. ROB:  There we go. [Chuckles] AARON:  Zombie [moves]. ERIC:  I think to be completely honest too, for certain groups like Rob and I, we don’t really ramp up on I/O until early next year. But there are teams now that are planning the next I/O, immediately after the previous one just wrapped up. So, it’s a crazy, huge production. And how it all comes together is still mind-boggling to me. I’ve been at Google for a while now. I’ve been on every I/O. And it’s just amazing that it all comes together. We figure out the messaging, things actually launch when they’re supposed to, and all that jazz. But it’s an exciting time. I think now, the aftermath of I/O is usually where you pick up the pieces and decide the polish, for instance. The Polymer team, we’re just figuring out, “Okay, we had all this great momentum at I/O. We got a lot of great developer feedback. How do we take that now, do something really interesting with it?” So, you’ll see us over the next couple of months polish what we have, maybe build a few new tools and things that people are wanting from us. We have now time again to do them instead of ramping up and getting crazy during I/O time. ROB:  Yeah, the other interesting thing is how it changes. I think before I/O the team, we had people who are interested in the project and we had people filing issues and things like that. But it was a big announcement at I/O, like material design being built with Polymer. And we had all these sessions. And so, now even the way the team works, we have to adapt to increased interest. The vast number of GitHub issues that are flowing in, people asking questions on the mailing list, people who are brand new to Polymer. And that’s a big, big, big task, maintaining all that support while at the same time as Eric was pointing out, continuing to polish the elements. The nice thing about it though is that we benefit so much from the open source community. That Polymer is an open source project is a huge advantage because developers come and they’re like, “This thing should work this way. Here’s a PR. Here’s a pull request to patch it up.” That’s awesome. That’s amazing that people spend their time working on it and making it better for everybody. ERIC:  Yeah, we love you guys. CHUCK:  [Chuckles] AARON:  Yeah, you guys did great. I was really impressed. I actually got lucky I got to go to lunch with the Chrome Dev Rels. Yeah, it was pretty cool. So, I think I saw both Eric and Rob there. ERIC:  Nice. ROB:  Yeah. We were around. JOE:  I think we do need to ask the only question that anybody cares about, and that is can you get me a ticket to Google I/O? [Laughter] ERIC:  You have to build some… AARON:  Will Joe Eames be at the next I/O? ERIC:  You got to build something kickass in Polymer. That’s what you got to do. JOE:  Yeah. ROB:  There we go. Yeah, then we’ll put you on stage. [Chuckles] ROB:  Then you’ll have to speak and that’s always nerve-racking. [Chuckles] JOE:  I was speaking on behalf of all of our listeners. They all want to know how they can get a ticket, if you can get them a ticket. ROB:  They all have to build awesome stuff with Polymer. JOE:  [Chuckles] We’re going to have 20,000 Polymer components built. ROB:  Do it. ERIC:  Every day they change it too, a little bit, the registration. So, I know this past year they put in a couple of Easter eggs here and there in documentation and their SDKs. I think we’ll do more of that in the future, because it does encourage the developer community to get involved and try to, if you’re using our stuff, you’re on our documentation, you should be almost rewarded for that and get a ticket to I/O. So, we’ll see what they do next year. I have no idea. That’s obviously out of our hands and something that marketing does. But if I had my way, I would let everyone into I/O. AARON:  You’re so nice. ERIC:  Thanks, man. [Chuckles] CHUCK:  So, do wonder though. Do these Web Components affect SEO? ERIC:  Good question. We actually have, this has come up a lot because when people hear Shadow DOM, then they think everything’s hidden away, right? Is the browser, or sorry, is the search engine going to be able to index that stuff. And so, right now we’re in this world of basically just JavaScript polyfills. So, in any browser except Chrome that has all the native stuff, you’re going to get essentially just a JavaScript polyfill for Shadow DOM. And so, what happens is it’ll just output DOM as it normally would in a web application. So, any search engine that understands how to run JavaScript or indexes that stuff, indexes a dynamic application, will be able to work pretty well with that. And I think Google actually, we just made an announcement recently sometime earlier this year, maybe right before I/O, that Google was a little bit smarter than it used to be as far as understanding JavaScript applications and be able to index dynamic content like that without much effort on the developer’s point of view. As you move to a world of native Shadow DOM where whatever thing Google search is running, it’ll be one of these things that search engines will just have to adapt to. Again, this is new for web developers but it’s also new for the whole spectrum. If you have things in Shadow DOM, at some point if your search engine understands the entire rendered tree, the composed DOM tree, as it should, then they will just have to adapt as developers build apps on top of this stuff. So, we actually have an FAQ entry on this, if you guys are interested, some place in PolymerProject.org, that goes into a little more detail here. ROB:  Oh, one thing that I want to add to that is your components, typically the content that goes inside of them, that content… let’s imagine it’s a blog post or something like that, all the text content of your blog post, that is not going to be in the Shadow DOM. That’s going to be in the light DOM in between your custom element tags. And so, even if the crawler or whatever, I’m thinking of something, maybe if there are search engines out there that don’t run JavaScript, so even if that crawler can’t run JavaScript, it should still be able to just see that content and be able to index that as just text inside of an HTML unknown element or something like that. So, that’s a best practice, that you shouldn’t be shoving this content that you want to be indexed, make sure that that is in the light DOM so it’s readable easily. ERIC:  Yeah, that’s a really good point, Rob. I think Shadow DOM definitely, that’s your implementation detail. Your important stuff should be surfaced to the outside world. I think, in Shadow DOM it’s called insertion points. You can render things from the user’s world inside of the index.html page into your Shadow DOM at very specific locations. I think Angular has a feature like this. It’s called transclusion or something like that. It’s a very similar notion where you take and you re-project content from one space into the other. And it’s a rendering thing. That’s all it is. But as Rob said, if you have links, if you have important text, there’s no reason that shouldn’t live in the main document. JOE:  So, I’m sorry. Did I miss the coining of the term light DOM? [Chuckles] ROB:  I think that, yeah. We’ve [inaudible]. ERIC:  It’s an unofficial term. ROB:  Yeah. JOE:  I’m imagining some kind of future religion. [Laughter] ROB:  It is fun to imagine the Light DOM versus the Shadow DOM. JOE:  Yeah. ERIC:  It’s very Star Wars-y, yeah. JOE:  Yeah. Are there other forms of the DOM and do Midi-chlorians matter? ERIC:  [Chuckles] They always matter, always. CHUCK:  And if one’s the Light DOM and one is the Shadow DOM, then what is casting the Shadow DOM between the light DOM and the Shadow DOM? [Chuckles] JOE:  Right. ERIC:  The browser. I don’t know. JOE:  [Laughs] ERIC:  Yeah, this is actually, it’s a really good point, because it’s not an official, if you go look at the Shadow DOM specification, you won’t see the term Light DOM in there. But it’s this loose term that the Polymer team and members of the Chrome team have come up with to describe these two different rendered trees. There’s all the stuff that the user has. A user of a component can put other elements, a span, a div, an h1, inside of your element. So, a classic example is a form tag, just your standard HTML form tag, where you can put a bunch of elements inside of it, a select, an input, different tags. And what you put inside of that element actually matters. The form tag understands to do something interesting with those tags, those very particular tags you put inside. And so, what a Web Component can do using Shadow DOM at insertion points is say, I want to render this stuff from the light DOM, the user world, into these placeholders in my Shadow DOM. And so, you can do things like you can create a component that renders a tab strip and takes someone’s h1 tag and put it at a very specific location, style it in a particular way to look like a tab. And take their content, maybe it’s a div or a paragraph tag and render that at a specific location inside of your Shadow DOM. So, it’s pretty cool. It’s very powerful and it’s super amazing when you start to compose a lot of these elements together. They become useful in certain contexts. JOE:  Cool. What do you guys see as the future of Web Components and Polymer? ROB:  I personally see you take these components, you build a better platform for developers to build upon for both UI stuff and non-visual stuff. But thinking just in terms of UI, I really, really, really like the idea of a version of HMTL that is very app-centric and is more like UIKit where you have these primitives that you can build that help you create great multi-device experiences. And right now, so much of HTML is document-centric. You’ve got headers and paragraphs and things like that. And we’re trying to give you elements that are toolbars and menu buttons and things that you actually want to use in something that’s more of an app and less of a page. And combining that with new technologies like Service Worker, which we haven’t really talked about today, but Service Worker basically gives you much better access to the caching mechanisms that the browser is using, and network requests. And I see this world where you can build these really powerful multi-device apps using Web Components, using Service Worker, to give you good offline support. I don’t know. That’s just the web of the future in my mind. That’s where it’s all headed. ERIC:  Yeah. I think there’s a lot of opportunity too, to take some of the existing clunky APIs in the web and make components out of them. So, IndexedDB’s a really good example, just a really powerful, low-level API for offline. But there’s no reason users should have to ever touch the grossness [chuckles] that it is. You should be able to write a Web Component that makes it a little nicer, and to be able to compose and use inside of other components if they need offline functionality. We get a lot of questions too, like, “Hey, how do I do testing with Web Components? How do I do routing with Web Components? And these are things that are totally solvable. We just need to show people the path forward and how to component-ize if you will, that API or that library. So, coming up with best practices for that, fleshing out how to create an end-to-end application on top of components, is I think what we’re going to spend a couple of months on. JOE:  Awesome. For people that want to learn Web Components and Polymer, do you guys have favorite resources that are out there for people? ROB:  I love Eric Bidelman’s talks. ERIC:  [Laughs] I love Rob Dodson’s talk. [Chuckles] ROB:  And Matt McNulty’s talks, even. Yeah. The talks, I think are a good place to start, because they’ll give you a quick, if you just google, on YouTube, if you look up ‘Eric Bidelman Google I/O’. Eric’s talk at I/O was a great high-level introduction to not only Web Components, but Polymer as well. And then hit up the Polymer website. We have a section there called Platform which is dedicated to explaining the actual Web Component bits. We also then have the majority of the site, which is explaining Polymer itself. And HTML5 Rocks also has a bunch of great articles which cover Web Components specifically, the actual standards there. So yeah, my personal path to learning them was to understand Web Components first, just because I wanted to know, I didn’t want it to seem like magic was happening that I didn’t know about. I wanted to know approximately what everything did. And then I started using Polymer because it just made me much faster when I’m developing components. ERIC:  Yeah. It’s good to know those primitives too, because we’ve been trying to talk about for a long time. And Polymer is based off of all these standards, so it’s good to understand the features that are brought to the table by things like Shadow DOM. And just to show, if you read the Polymer docs and you see all the features that we’re using for CSS for instance, they’re all just the native Shadow DOM stuff. We’re just leveraging them. We’re helping developers build Web Components using that technology. So, it’s cool to understand as a developer what’s available to you. If you don’t want to use Polymer, you don’t have to. We just make it easier to get up and running. The other thing I’ll say about resources on the web, and Rob can probably attest to this as he was [chuckles] ramping up on stuff, is that it’s changed so much even within the past six months to a year, that a lot of stuff out there is slightly outdated or slightly stale. So, as you’re… [Chuckles] ROB:  Well, my blog included. [Laughter] ERIC:  Alright. Rob’s going to take an action item to update his blog when this is done. ROB:  Yes. ERIC:  But it’s tough because Shadow DOM has been declared such this gnarly new API that has changed, and particularly the styling and stuff, its styling features, that a lot of stuff that was written is changed a little bit. So, if you want the most up-to-date, check out the HTML5 Rocks articles. We try to keep those updated. Polymer’s got some stuff on the general Web Components APIs, but it’s mostly centered around how to build apps with Polymer, and it discusses the Web Component features in the context of Polymer. But those two are good. And then yeah, any presentations that are mostly within the past six months will probably be pretty good. CHUCK: Alright Aaron, what are your picks? AARON:  Alright. I’ve only got one pick this week. I’m sorry. I’m reading this series of books. I know I do books every week. I’m sorry. I do about one a week, because I have a 35-minute commute each way. So, I’m doing books. I don’t talk about the crappy ones. I only bring the good ones here. So, the series I’m doing right now, it’s awesome. It’s called The Iron Druid Chronicles. And it’s a nine-part series and it’s so, so, so good. I know. I picked this last week. But I’m picking the next one in the series. It’s called Tricked. It was really good. So, if you haven’t read Tricked, go ahead. Read it. It’s a really, really, really good book. And they’re not super long reads. They’re eight, ten-hour books. So anyway, yeah, that’s my pick. CHUCK:  Cool. Jamison, what are your picks? JAMISON:  Three picks. Last week I was at The International, which is a tournament for Dota 2 which is a video game, which makes me the coolest person on this podcast, I’m pretty sure. [Chuckles] JAMISON:  And it was amazing. So, my pick is The International. It was in the KeyArena in Seattle. 10,000 people all watching some people play video games, yelling at the same time. It was pretty fun. My next pick is a presentation that someone gave called ‘The unreasonable effectiveness of dynamic typing’. I’ve been thinking out loud about static versus dynamic type systems. And I don’t have a ton of experience with static type systems, so I’m trying to figure out the use cases I guess, and the tradeoffs between them. And this is a really good talk that reviews some of the research that’s been done. And the talk admits that there hasn’t been hardly any research considering this is a trillion-dollar field and this is a big deal in that field. But the small amount of research that has been done seems to suggest that it’s faster to develop programs in dynamically-typed languages and that type systems only save you from a very small percentage of bugs. So, it’s actually faster to debug them as well. So, I thought that was interesting. And then the last pick is a website called Fit Men Cook, which sounds like it could be kind of racy. AARON:  They do. JAMISON:  But it’s actually… [Chuckles] JAMISON:  It’s actually just recipes. I’ve been trying to eat healthier. And I’m really bad at thinking about what to create as food in the abstract. So, I need a recipe. It’s just a good source of recipes for people trying to eat healthy. Those are my picks. CHUCK:  Awesome. Joe, what are your picks? JOE:  I’m going to make just a couple of picks here. The first pick is going to be the Toastmasters Organization, which is all about helping you be a more effective presenter and organizer. And I’ve been attending a local Toastmaster meeting for a while now and really enjoying it, and finding a lot of value in working on my presentation skills. So, I’m going to pick the Toastmasters Organization for my first pick. And the second one is going to be a card game called Villages, which just recently had its party. It successfully funded on Kickstarter. They just got everything printed and they did a party at a local game store, because the guy who did it is a local, to launch the game officially, even though he’s had versions of it out since 2011. But it’s a trip-taking game. You lay down three cards at a time but it’s all played out like you’re building villages with knights and dragons and all kinds of things. And it’s strategic but has luck to it and has really cool pixel art, and a very fun game to play. It plays 2-5 players, pretty cheap. It’s $20. Awesome game, really enjoyed it. So, that will be my second and last pick. Oh wait, no. I have a third pick. I’m picking ahead, because by the time this comes out, this movie will have been out for a few days. But I’m going to pick ‘Guardians of the Galaxy’. I haven’t seen it yet. I have tickets to go see it in two days, at opening night. AARON:  Did you love it? JOE:  No, I haven’t seen it yet. AARON:  No, but when it comes out, you’ll have seen it. Did you love it? JOE:  Oh. Yes, yes. [Laughter] JOE:  I loved it. It was awesome. And if I hated it, then we’ll have to edit this. AARON:  That’s a ringing recommendation right there. JOE:  Yes. CHUCK:  [Chuckles] JOE:  I’m so excited. On Rotten Tomatoes, it’s getting 97% out of reviewers, which is just nuts. And I’m sure I’m going to love it. So, I’m going to say I loved it. And if I didn’t love it, then I’ll have to retract that statement next week. [Laughs] CHUCK:  Do you know how much grief I get when I pick stuff that I haven’t seen or used? [Laughter] JAMISON:  Well, if you pick stuff you haven’t seen or used but that someone has paid you to pick, you’d probably get more grief. CHUCK:  That’s true. I don’t do that. [Chuckles] JAMISON:  So, at least it’s not that. JOE:  Marvel actually paid me for that endorsement. They sent me a check for 16 cents. [Laughs] CHUCK:  You, wow. ERIC:  Worth it. [Chuckles] CHUCK:  Awesome. Well, I’ve spent all day today at the LessMoney, which is an online training conference Google Hangout thing. And it’s been really good. We’re talking about building freelance businesses and basically moving up from just me to being an agency. So, it’s been really good. And that’s really the only pick I have. So, I’ll pick that. I guess I can pick the other product that those guys have. It’s LessAccounting. And that’s what I use to do my books for my business. And they told me that just last week, they put in a budgeting component. So, I’m pretty excited about that. And those are my picks. Rob, what are your picks? ROB:  Okay. So, I wanted to pick some music because I like to try to code to music, but sometimes it’s really hard if the music has too many words or anything like that. I can’t concentrate on the code that I’m writing. So, I’m going to pick this album called ‘Cold Spring Fault Less Youth’ by Mount Kimbie, which is, I don’t know how to explain it. But it’s some interesting electronic type music. But it’s really good. It’s really awesome, definitely worth a listen. Let’s see. Lately I actually, last night I just finished this book called ‘Flash Boys’ by Michael Lewis, which is about high frequency trading. So, it’s an explanation of Wall Street high frequency trading, how it actually works, how the whole system is crazy and rigged. And the endless pursuit of speed on Wall Street, network speed, things like that, which is pretty interesting. And the last thing I’m going to pick, I’m lame for picking this, but whatever. I’m actually excited about it, is the Samsung Gear Live, the actual Android wear watch. And I’m not picking this because I work at Google. I’m picking this because I actually think this thing rules. So, I got one at Google I/O. And initially I was like, “Yeah, I don’t know. It’s a smart watch. Okay.” I couldn’t figure out how it really fit into my life. And the first few weeks that I wore it, I was not that into it. And I realized that I was just being overwhelmed by notifications. So, I learned how to turn off all the notifications. So now, it only shows me calendar notifications and Hangouts and IMs and the weather, and that’s it. And it’s awesome. If I’m just sitting somewhere, it will just vibrate and be like, “Oh, you got a meeting in ten minutes.” And then I can run to the meeting or something, which is really, really, really handy. AARON:  I used to miss those meetings, but that watch helps me, too. ROB:  Yeah. I really like this thing. Those are my picks. CHUCK:  Awesome. Eric, what are your picks? ERIC:  My picks. I got, so speaking of recipes, somebody mentioned recipe, I’ve also gotten really into cooking lately. And I actually had a birthday recently. So, my girlfriend took me to Vegas. We did the Vegas thing as a couple. It was actually really fun, though, because we got to do things like Grand Canyon via a helicopter. And one of the dinners we went to was at Bobby Flay’s restaurant. And if you guys have never been to one of his restaurants, it’s totally awesome food for a reasonable price. But I actually ended up buying his cookbook which is called ‘Grill It’. And so, I’ve just been getting into that lately. Despite the fact that I work at Google and I get free food, [chuckles] it’s still nice to cook for yourself and know how to do that every once in a while. So, he basically uses four main ingredients. It’s honey, some kind of spice, some kind of citrus, and some kind of meat. But they’re always super easy to make. But they’re actually really good. So, I’ve been getting into that. My other pick just came down the wire, actually. It landed in Chromium recently. It’s basically a new API or an extension of the scroll to API or scroll into view API. So, this is typically what sites do. They’ll do a smooth scroll effect using JavaScript. But this is actually adding it natively to the browser now. So, the browser can do things like optimize it, put it on its compositing thread, all that great stuff. So, this is really nice, because with one little API change, one addition, we get smooth scrolling that all these sites are doing anyway, for free. Again, just an extension of the web platform. So, small change but actually really big for performance. Those are my two. CHUCK:  Alright. Well, thanks for coming, guys. It was a great discussion and a lot of fun. ERIC:  Cool. Thank you. ROB:  Thank you for having us.[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] **[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]**[Do you wish you could be part of the discussion on JavaScript Jabber? Do you have a burning question for one of our guests? Now you can join the action at our membership forum. You can sign up at JavaScriptJabber.com/jabber and there you can join discussions with the regular panelists and our guests.]

Most Popular

Ruby Rogues

087 RR Book Club: Practical Object-Oriented Design in Ruby with Sandi Metz

Jan 9th 2013
Ruby Rogues

131 RR How to Learn

Nov 13th 2013
JavaScript Jabber

124 JSJ The Origin of Javascript with Brendan Eich

Sep 3rd 2014
JavaScript Jabber

146 JSJ React with Christopher Chedeau and Jordan Walke

Feb 11th 2015
The Dev Rev

Automate the Pain Away

Dec 19th 2018

Current Sponsors

Suggestion Box

Subscribe

On social

Adventures in Devops

DevOps 036: An Overview of MicoK8s, Charmed K8s, and Other Ubuntu Infrastructure Tools with Alex Chalikias

React Native Radio

RNR 167: Rapid Prototyping with Perttu Lähteenlahti

My JavaScript Story

MJS 148: Farzad Yousefzadehr

iPhreaks

iPS 291: App Store Subscriptions with Jacob Eiting

The Freelancers Show

TFS 368: How to do Personalized & Relevant Ecommerce Marketing with Rytis Lauris

Ruby Rogues

087 RR Book Club: Practical Object-Oriented Design in Ruby with Sandi Metz

Ruby Rogues

131 RR How to Learn

JavaScript Jabber

124 JSJ The Origin of Javascript with Brendan Eich

JavaScript Jabber

146 JSJ React with Christopher Chedeau and Jordan Walke

The Dev Rev

Automate the Pain Away

Sign up for the Newsletter

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