Transcript

CHRIS: Hey, everybody. Thanks for listening to Shop Talk Show. It's Episode No. 124 brought to you by two lovely sponsors: Environments for Humans promoting their front-end summit. Literally go to FrontEndSummit.com. It's an online conference coming up August 21st here, pretty soon. And a brand new sponsor called SpeedCurve. Go to SpeedCurve.com. It is like a Web app that you sign up for to watch your website for speed and performance reasons. And you kind of put in your own website and your competitors' websites and kind of decide what you want to track and stuff. It's really cool. We're going to tell you more about both of those things later in the show, but for now let's kick things off.

[Banjo music/Intro music]

DAVE: Hello, and welcome another episode of Shop Talk show. I'm Dave Rupert and with me is Chris Coyier. Chris.

CHRIS: What's up, everybody?

DAVE: And who do we have on the show today, Chris?

CHRIS: Mr. Rob Dodson. Hey, Rob. Thanks for joining us.

[Ta-da orchestral fanfare sound effect]

ROB: Hey! Thank you for having me.

CHRIS: Rob! You work for Google, live in San Francisco. Is that right?

ROB: It's all true.

CHRIS: Those are true facts about Rob.

ROB: Yep.

CHRIS: Rob facts.

ROB: Nailed it.

DAVE: Welcome to facts talk with facts -- the facts podcast.

CHRIS: We've got Rob on because he's --

DAVE: All facts all the time here, folks.

CHRIS: We got Rob on because of for many reasons. You do lots of awesome stuff on the Web recently. We've talked in the past because you wrote a guest post for CSS-Tricks all about Web components and what that is and what that means and what's an example of using them and stuff. And it's a fantastic, I'm sure highly referenced, article on CSS-Tricks, so thanks for doing that. Is that kind of your main focus these days? Is that why you're at Google? I feel like maybe even that transition happened, like, after that article was published. Is that even true?

ROB: Yeah. I mean basically I owe my career at Google to Mr. Chris Coyier, so thank you so much, Chris.

CHRIS: What? That's not true at all.

ROB: No, like the transition was, like, really, really quick, but it happened around the time that I was writing that article, yeah. And, yeah, my primary focus at the Googles is working on Web components and, in particular, Polymer. So it's been definitely kind of like a crazy ride because I've only been there for about six months, so it's been a very sudden shift. Before that I was freelancing and kind of was doing a lot of work writing about Web components and writing about Polymer. And the Polymer team reached out and was like, hey, you know what? You should do that over here.

CHRIS: You should do that for money.

ROB: That's kind of how I --

DAVE: Do this for money.

ROB: Yeah.

DAVE: Uh, okay.

ROB: Yeah, yeah.

CHRIS: Cool.

ROB: So they twisted my arm and, yeah, that’s how I ended up there.

CHRIS: Nice. So what is the best way to approach this? Maybe you could help guide us in that there is this thing called Web components that is part of like how the Web is going to work in the future and already kind of works, and then there's a different thing called Polymer that's essentially a polyfill for it, but I'm not sure. Does it work out that cleanly or how do you approach this subject usually when you explain it to people?

ROB: Yeah, so it usually helps to have kind of a general understanding of what Web components are, and then you can figure out how Polymer works in with all of that. So Web components are a set of emerging standards, which really give developers the ability to define their own custom HTML elements. And the example that --

CHRIS: So when you say Web components, it doesn't mean one particular thing. It means a group of things, like how HTML5 means a group of stuff.

ROB: Yep. Yeah, absolutely.

CHRIS: Is that right?

ROB: Yeah, so there's no one Web component technology. It's actually four different basically new specs that are, you know, new standards that are being added to the browser. And those collectively fall under this umbrella that we call Web components.

CHRIS: Okay.

ROB: And the specs are template, custom elements, shadow DOM, and HTML imports. So each of these are like really cool technologies on their own that are being added to the browsers today. But when you combine all of them sort of like Vulcan, you get this way more awesome thing, which is, you know, kind of these awesome custom elements that can do all sorts of cool, magical stuff.

CHRIS: Right. So are they all useful in their own right?

ROB: Mm-hmm.

CHRIS: Is there a use case for each of them independently?

ROB: Yeah, absolutely.

CHRIS: There is, right?

ROB: Yeah, yeah, so like you've got the new template stuff. That allows you -- there's an actual template tag that is being added to the browser now, which lets you create just sort of inert stuff in your document. You know, if you've used libraries like --

CHRIS: It won't render is the case, right?

ROB: Correct.

CHRIS: It just absolutely won't render.

ROB: It won't render, and it also won't make requests for like images or anything like that. It won't run scripts if you have script tags inside of there. It is totally inert.

CHRIS: Ah!

ROB: And it doesn't involve doing any sort of like weird hackery to get a template to actually sit on your page and get ready to be used. Instead, you've got just an actual template element. It does exactly what you expect, and then you can just grab its content out and stamp it on the page. So by itself it's really useful, right? But you can combine that with something like Shadow DOM or custom elements and imports, and you can start to flush out these really robust, custom, HTML elements.

CHRIS: Yeah, that's great. I like the idea of the inert element too. Once in a while I'll use, if I need to chuck data on the page, I'll use a hidden input because it's one of the only HTML elements that's valid in the body or whatever that you don't need any additional stuff to hide. It just is hidden automatically.

ROB: Mm-hmm.

CHRIS: It's pretty cool, but template would do that too. That's interesting. Anyway, so in the journey that happened in the article that you wrote for CSS-Tricks, and I'm sure you've done talks and way more interesting stuff these days, but it's a great article in that it does combine all these things. And the demo was a slideshow, and the slideshow was like think of all the junk that normal HTML junk that needs to go into a slideshow, and wouldn't it be nice if we could reduce that down to the barebones of stuff that could be in a slideshow, essentially just like an element called slideshow or something, and then just a series of images. Why do I need to be looking at a bunch of radio buttons or a bunch of empty divs or a bunch of empty button elements or something? Wouldn't it be nice to kind of abstract all that stuff? That's the idea, right?

ROB: Yeah.

CHRIS: I don't need to see that stuff. Just do that stuff for me.

ROB: Yeah. I mean most of us --

CHRIS: Or it could be like that.

ROB: When we use something like -- let's say you're using something like Twitter Bootstrap, you know, and it's a really awesome library. I really love Bootstrap, but the way most developers work with it is they go to the docs, and they copy and paste like a big chunk of HTML out of the docs, and they drop it in their page. And they're like, yea, I have a nav bar now. But really you don't care about all of the inner workings of that nav bar. You just care about the three links for the various sections of your site.

CHRIS: Right.

ROB: Yeah, that's the real goal is to take a lot of this stuff and compress it down to just more semantic elements, and that way you definitely clean up the clutter on your page. But it also gives you some really interesting super powers as well. One of the other technologies is Shadow DOM, and Shadow DOM allows you to take all of that markup that you have now compressed into this custom HTML element, and it allows you to scope the CSS for that markup just to that element. And so you can write a whole bunch of styles. You can have them be in the Shadow DOM, and they're only going to affect that sort of like encapsulated markup there. And so that's really powerful because it --

CHRIS: It works both ways, doesn't it? Does that mean that the styles that you write inside of that Shadow DOM don't leak up outside of the document?

ROB: Mm-hmm.

CHRIS: But also the styles that are above it in the document don't leak in either, or does that not work both ways?

ROB: Exactly. Yep, exactly, and so that's really, really powerful because it means that you can take this element that you've created. You can drop it onto any site, and you know it is not going to leak styles out and blow up the site. And, likewise, the site is not going to bleed styles in and blow up your component. Right? You get some really nice boundaries there. And there are special CSS selectors that you can use to pierce those boundaries if you know exactly what you're doing. But it does a really good job of preventing any accidental style mistakes, which is kind of the goal here.

CHRIS: Yeah, that's nice. Is there some pushback in that, like, well, but -- I don't know -- that prevents cascading, and that's such an efficient concept for websites and stuff, or is that not? Do people not care about that? Or would you use -- like let's say you want to set a font family that just permeates everything.

ROB: Yeah.

CHRIS: Then you would use one of those piercing selectors to make sure that that happens?

ROB: Yeah, so there's -- you know, some stuff is still inherited. Right? We're not entirely breaking inheritance or anything. But then there are certain things where, yeah, you'll use the specific selectors to do what we call themeing where you're like, yeah, I want everybody to have this particular color or -- I'm trying to think -- this particular amount of padding or something like that. And so there are special selectors for that, but we're also working on actually other elements that you can nest inside of your elements that will go out and find style sheets that they can pull in and use to theme themselves internally. There are a lot of crazy ideas that we're experimenting with in that space to make themeing very possible.

CHRIS: Cool! Cool!

ROB: Yeah.

CHRIS: I thought we'd talk about this because it's just that's -- you do a lot of work in this and stuff, and we have some questions going there, so maybe we can keep defining it a little bit.

ROB: Yeah, should I really quickly just separate Web components from Polymer just so people kind of understand how that works?

CHRIS: Yeah. Yeah.

DAVE: That would help, yeah.

CHRIS: Sure, please do.

DAVE: Let's do that.

ROB: Web components are the very low level standards that we've been talking about so far. The idea behind Polymer is we need to get developers using these things because we need, as they're being standardized, as they're landing in the browsers, we want to make sure that we're standardizing the right things. Right? We want to make sure these new, lower level primitives, feel good to use.

And so Polymer is really two things. It's a platform bundle of polyfills. We call that platform JS. And what that does is that enables Web components in all modern browsers. So you load this JS file and then, regardless of the browser you're in, so long as it is one of the new, modern, evergreen browsers, you can start using all the different Web component technologies.

Then Polymer itself is just an opinionated way to work with Web components. So it adds a bunch of sugar on top of the Web component standards to make it a lot easier and faster and more efficient to create Web components. So Polymer adds things like data binding, a really nice sort of declarative syntax for defining your own element, and essentially just a lot of sugar to make it a lot easier to work with these things.

CHRIS: But I mean it is a polyfill, right? I mean, it is like I want to use this -- or -- okay. Maybe you already covered….

ROB: The platform part is. Platform JS is, and then there's a separate part called polymer.html, and that's where we add all the sugar. So it's really two things. I can help to think of it as two things that fall under this sort of umbrella.

CHRIS: Yeah.

ROB: The idea is that, over time, that platform layer kind of goes away. As Web components become standardized and land in all the different browsers, then you don't need the polyfills. And as that evaporates, the only thing that's left is the developers sugaring that makes it faster to make your own components.

CHRIS: I thought, just because I have you here, I would ask you some things about how I might use it just to see how you might approach it from a selfish, personal perspective. So let's say you went to like the homepage.

DAVE: Free consulting.

[Cash register sound effect]

CHRIS: [Laughing] Say you went to the homepage of CodePen. Right now there's these little demos, the demo on the front page of CodePen, and there's six pens presented there, right? And they have a little iframe that show the demo. There's a little user avatar and then there's these little things like icons showing how many views and hearts and comments and stuff they have.

It seems like the kind of thing that would be a pretty sweet Web component because it literally is a little visual component, and it would be nice if I could just style this thing and then just say, like, pen, and give it like a slug or whatever, just like a very limited amount of information. Then it would build itself, and all this visual style and functionality and stuff as a Web component. And it would just feel -- of course, we reuse the same pattern all over the site. It seems like a pretty good use case for it. Is that whole chunk, visual chunk would be a Web component, or would you make the Web components even smaller than that? Like just the little heart with the number, maybe that's a Web component and the views one is a Web component, or could it be Web components nested within other Web components?

ROB: Yeah.

CHRIS: What would be the approach here?

ROB: The idea is you want to try and get as much composability as possible. Yeah, you'd want to go all the way down to like make the icons Web components. Make the little user avatar; make that a Web component. Right? Then compose all of those together into an even bigger Web component. The nice thing about that is then you can reuse just that icon component in other places in your site. You can reuse the user's avatar in other places in your site. That's the real goal is get kind of more powerful primitives and start composing them together.

CHRIS: That's pretty cool. So there is no limit to how you can nest these things, really.

ROB: No, not at all.

CHRIS: Nest away.

ROB: Yeah, that's what's really kind of awesome and exciting about it is you can do all sorts of interesting mash ups, starting with more powerful primitives and kind of building bigger and more complex things.

CHRIS: And ultimately it still all ends up as like HTML and stuff, right? It's not like -- I don't know -- I guess in a future where this has taken hold, two websites are going to not share a whole lot in common, but they still kind are. They're still using the same technologies to build themselves. But you could build a website that ends up being 100% custom elements.

ROB: Literally.

CHRIS: Isn't that weird?

ROB: It's weird, but it's --

CHRIS: Is that okay?

ROB: Yeah, it's pretty exciting. I think it's pretty interesting. And we're already using, like you're already actually using Web components in a sense, and you don't even know it. So one of the examples that we have in that CSS-Tricks post is the HTML5 video elements. There's a setting in the dev tools we can turn on the ability to show Shadow DOM. And if you actually crack open the video element, you'll see that inside it's just made up of divs and inputs and things like that.

I mean, we're already kind of doing this. We've already been working with Web component like things for a while. We just didn't know it. Input is full of hidden elements. Video is full of hidden elements. Text area is full of hidden elements. And so now it's really the browser makers are saying, you know, it takes us a very long time to add new stuff to the browser and that's a bad thing. And we need developers to be able to move a bit faster. So let's let developers extend the browser. Let's let developers add their own tags to it, and hopefully that'll make us all a lot more productive.

DAVE: Wow. So I've been in the Shadow DOM the whole time?

[Chimes sound effect]

[Laughter]]

DAVE: Whoa! Mind blown.

CHRIS: I think it's been a while since I've seen one of these, but I think they're still out there, right? There's kind of like pattern libraries for components. They're kind of like, I built one for GitHub that shows your profile and how many repositories you have and stars and stuff. It's a Web component. Go ahead and use it. Kind of like a little library. Because they're so modular, you can go ahead and grab it, and it will look the same everywhere it's being used and, you know, be able to be updated and stuff. Are people excited about that future too that we can piece together websites from kind of premade third party components, or is that dangerous?

ROB: Yeah. No, I mean there is a really interesting thing happening where a lot of people, when they first see Web components, I think their mind naturally goes towards UI. And they're like, oh, cool, I'm going to make image carousels and dropdowns and all these other things. But what we've been working on is this project. You know, Eric Bidelman and Addy and a few other folks have been working on this thing called Google Web Components where we're actually taking Google services, like all the JavaScript that's required to connect to Google Maps or something like that and mushing it all into a custom element. So you can have a Google Map tag on your page and just configure it with a few attributes.

You can nest Google Map Markers inside of there, and it's pretty awesome. It's pretty cool to think about their world where instead of having to write just tons and tons and tons of JavaScript, which is what we do now to connect to a service or, yeah, load something from GitHub, like someone's profile, that could instead be an element that we just drop on the page. Maybe we just configure it with an attribute or two.

CHRIS: Pretty sweet. Pretty sweet. We have, everybody, Rob Dodson on, and we're talking about stuff. I think we'll move into -- Dave, do you have any drama or news or anything to cover before we get…?

DAVE: No. No, I'm enjoying the….

[Old car horn side effect]

DAVE: I really enjoy it, so I think we just keep going. I think there's probably been plenty of drama, but as is with the Web, I've already forgotten about it. Shall we -- yeah, speaking of -- I guess one thing that happened was the -- and this is kind of related to you, Rob, was like Google IO just happened, and the material design and all that launched, and it was really awesome. And you guys released a really amazing style guide, so I think that link needs to happen, whether it's like Google.com/design, I think it is. But you guys ended up building out this new material design language in Web components, right? Is that kind of the thing?

ROB: Yeah.

DAVE: Can you explain? Can you give us the high level on that?

ROB: Yeah. So we really want Polymer to be the expression of -- Polymer and Web components to be the expression of material design on the Web. And so we wanted to make our own design system that developers could find really easy to just bolt together and drop into their app. Rather than having them, like we were saying with Bootstrap, we were copy and pasting just reams and reams of HTML and CSS all over the place. We built it in Polymer so that you can just import these elements, drop the new tags on your page, and get up and running.

It was actually a really cool process because there was a lot of interplay between us and the android team, so we were doing a lot of prototyping in Polymer, turning around, showing it to the folks who were also implementing material design in android. And it was a really cool experience because I feel like we're moving towards a bit of, I don't know, maybe like more of a unification of like Web, mobile, native, and all these things. And using Polymer, I felt like, made that a lot easier for us, which was kind of cool.

DAVE: And it seems like a huge proof of concept, right, that you could even build out a whole UI system, a whole kind of -- you know, I think I saw Addy post like a Google auth thing, just an auth component where it'll sign you in with Google auth and stuff like that. The whole idea that you could actually start building out a kind of super rich thing in Web components.

ROB: Yeah.

DAVE: And it seems like you guys have accomplished it. I saw a little bit of feedback like it doesn't work in FireFox and stuff like that, so I don't know if you guys are addressing that, but how --

ROB: Yeah, we had a specific FireFox and Safari bug that we fixed. It had to do with -- it seriously was like a single quote versus double quote thing. It was a totally silly bug that we just missed. But that's been fixed. And there was also some folks who were really mad that the elements were not accessible. And that's something that we are totally working on. Actually a lot of the accessibility stuff has been added since IO. We were in kind of like a crunch to get a lot of things done for IO, but accessibility is extremely important for Polymer and Web components. That's something that we want to make sure is really easy for developers. Yeah, we've been working on that as well.

DAVE: I don't know, man. Accessible is so super easy, I don't know why you didn't hit it the first time, you know.

ROB: Yeah, uh --

DAVE: That's a joke, Internet. Come on.

[Badum-tsh sound effect]

DAVE: All right, anyway, I think this is just super cool. If I were to like talk about a link this month or whatever, this stuff would be it. It's worth a click through. I think Addy, in the chat room, just posted a link to paper elements, demos, and stuff like that. So you could find it on Polymer-Project.org.

ROB: Mm-hmm.

DAVE: It's pretty sick what you guys have been able to kind of piece together. Literally piecing together, like you take this piece and this piece, and you smash it together to create a fully functioning app at some point.

ROB: Yeah. And we want these elements to be like responsive by default and do a lot of the things that right now we're having to implement ourselves. And so that means that you can take some of these elements and you get responsive layout just for free. If you use something like we have an element called core scaffold. You just drop that in your page and start filling it with content, and it just is responsive already. It's all baked in there to the element, so it just works on the phone. It works on a tablet, which is cool.

CHRIS: So I found that was really interesting with your Web foundations or whatever that responsive was a part of it because Google isn't exactly responsive across the board. But Google is advocating. Is that right? Is that kind of how -- maybe you can't speak on behalf of all of Google, but 

ROB: I'm taking the mantle. Yeah, well, material design is a big push for that, right? We want to make sure that we are responsive and really adapting to the multi-device Web. That's really important, I know, for the company as a whole.

DAVE: And is that because it's your fault there's a bunch of android dimensions out there? Is that Google's like --

ROB: I don't know.

DAVE: Okay. I'm just --

ROB: I don't know about that part.

DAVE: Dang!! Let's do a real question. Shall we? Chris, you got one?

CHRIS: I'm going to do a sponsor real quick, if you don't mind.

DAVE: Good call. Good call.

CHRIS: Just because it's kind of interesting. The sponsor, is for the first time, a website called SpeedCurve, so literally SpeedCurve.com. It's done by a guy named Mark Zeman who is now working on this full time, which is like, congratulations, Mark. That's so cool. But it's like a website performance monitoring Web app. So you sign up for it, and you put your website in there or a URL that you want to monitor the speed of. And, of course, it gives you all kinds of good information about the speed of that site, which is cool.

And it uses a bunch of different things, but I think primarily that webpagetest.org, you know, which I'm sure if you hear any performance talk ever, they always talk about this tool. No offense, but kind of gnarly looking website where you enter stuff and it gives you waterfall charts and loading screenshots and stuff. It's pretty cool. They should super definitely hire a good design team to spiff it up, or maybe not because maybe you could just use SpeedCurve, which is a beautifully designed site that takes that data and pulls out useful bits and shows it to you and kind of automates the look of it.

But what's kind of an interesting twist to it is that you enter yours to monitor, and then you pick two competitors who you want to kind of pit yourself against, and you put their URLs in too. And then all the data and stuff that it gives you is always kind of you versus them, which is kind of a cool way to motivate yourself and kind of monitor yourself over time in comparison to them because -- I don't know. I think that's a smart way to handle it, you know, like make sure that you're ahead of your competition speed-wise. That's an important business decision, of course.

I don't know. Check it out. It's pretty nice looking. I've been using it a little bit, although it's bumming me out a little bit because the competitors I put in, in my case, are beating me a little bit and it is providing some motivation. And it gives you stuff about how fast is your backend, when does the rendering start, how about when the DOM is ready, when is the page entirely loaded. And it pits you against your competitor in all cases there.

Mark has been doing a bunch of good, interesting stuff about design. We'll put a link in the show notes, but he analyzed 250 different responsive sites and analyzed how they are handling performance, and some percentage of them, you know, it's exactly the same as the desktop site, and some percent of them optimize stuff and is faster on mobile and stuff. He has some interesting data on that that we'll share.

I feel like it's a good time to sign up for SpeedCurve. He's really digging into it and making lots of cool upgrades to it. You know, he sent me this list of things that he's going to be adding soon to it, which is really cool, one of which is individual asset trending. So you can say, you know, link up your main .css file or whatever and it will measure the size of that over time. So you can watch yourself if that file starts to grow and grow and grow. You have data on that, which how would you get that data any other way? It's kind of a neat idea, so lots more reports, more options, more stuff. Anyway, check out SpeedCurve.com. Let's do it. Let's jump into these questions.

DAVE: I was just going to add real quick, this site is so beautiful. I love charts and graphs, and whenever I need a quick fix, this is where I go. It's beautiful.

CHRIS: Hot.

DAVE: Hot. Looking good.

CHRIS: Hot, hot, hot.

DAVE: All right. Robert Lyle.

CHRIS: Yeah. Sorry about that, everybody. Last week here -- writes in, "Web components are a hot topic at the moment, and it looks like libraries like Polymer are almost ready for production." We can talk about that, I guess. "Have either of you guys had the opportunity to play around with Web components yet? Do you think that they are the future? What do you believe to be positive and negative aspects of breaking up HTML, CSS, and JavaScript into isolated bundles of styling and functionality?"

There are a lot of questions there. I guess we could start with the first one being is Polymer almost ready for production or is it ready for production, or where is it being used in production, that type of thing.

ROB: Mm-hmm, yeah, so we're actually using Polymer on the Polymer website itself, and so Polymer-Project.org uses Polymer. Also, Chrome Status, the Chrome Status site uses it. Was is that? I think it's ChromeStatus.org. Double-checking the URL. ChromeStatus.com maybe.

DAVE: .com.

ROB: Yeah, so we're using it there. The way that I like to think about it is Polymer specifically has sort of like a minimum browser support level. Right? We support all of the modern browsers, so really like the last two versions of each browser, so that's IE10 and above, Safari 6 and above, like current mobile Safari, and also as well, of course, like FireFox, Opera, and Chrome. And so you have to really consider how much of your customer base is on modern browsers. If you feel like you're in a position where enough of your customers are on modern browsers, then sure, go ahead and use Polymer in production.

What I've found a lot of success with just like within Google is there's a lot of people who build prototypes with it because there's a lot of folks who kind of occupy that space of like I'm good at design. I'm also a developer, so I can do HTML, CSS, and maybe like some JavaScript. But when you start getting into really deep in the weeds with EXTJS or Angular or something, I start to get uncomfortable. Right? There are a lot of developers who sort of exist in that space where they're probably comfortable, you know, working with jQuery plugins and running a bit of JavaScript, but they just don't want to get too deep in the weeds. Polymer is really good for those folks because it has a really nice, easy to use syntax. If you can write HTML and CSS, you can make custom elements in Polymer. And so we've found a lot of success with people prototyping with it and also building internal apps where they sort of know that it's only going to be people on modern browsers using it, so stuff that's internal to their company.

The Polymer stuff is pretty baked. We have these element sets that we've created, like core elements and paper elements. That's really what makes up a lot of that material design stuff. There's still some churn in those element libraries because they're so new. But we're sort of tightening the screws there as well.

CHRIS: Cool. And you kind of moved on quickly to be like do you think that they're the future. I think that's a weird question, and you probably like almost have to, you know, like you're a little probably biased in this discussion.

ROB: A little.

CHRIS: Does it really -- does it seem like that the future is inevitable in this regard that there's enough excitement in this, that there's enough like this has to be the case for the future, that maybe -- I don't want to say something ridiculous like ten years or something, but a year, two years, that we're going to see a lot more of this? That this is truly the future of front-end development or what?

ROB: I personally really think so just because you start to master some of these elements. Right? You start to master some of the, like responsive elements. They give you a scaffolding that's going to work across multiple device sizes, and it's as simple as one HTML tag that you're just nesting your content inside of. And I feel like when you have that -- when you feel comfortable using that element, you're just like, man, this is -- personally, it's just so much faster and more efficient to work that way. And so I really see that.

You know, we also have some new technologies. We have things like service worker, which is kind of a cool way to do offline caching. When you start to combine all of these things together, it really, in my mind, gives you a glimpse of what the future will probably be like, and I'm pretty excited by it. I think it makes Web development much more sane. Right now it feels very, very difficult. We have a lot of frameworks to deal with, a lot of tools to deal with, and hopefully we can simplify a lot of that by having some of these better, you know, standards built into the browser already.

CHRIS: I wonder, from a workflow perspective. Let's say you're just a -- you consider yourself a front-end developer, but you occupy that like I'm pretty good at HTML and CSS, and I can write a little JavaScript, and I'm comfortable with that. I can take a Photoshop file, and I can rip that baby up into HTML and CSS and stuff. Is that job going to stick around, or will you continue to work that way and then hand it off to a different type of front-end developer who is then going to break these things up into Web components, or would you expect that that job evolves into being able to cut a PSD up into Web components pieces, literally working with the code they need to do that? You know what I mean?

ROB: Yeah.

CHRIS: Is it fragmenting these jobs even more?

ROB: I think the job that you just described is actually -- that's the people who we see building Web components right now. Inside of Google, those are the people who have been -- who have really, really hopped onboard is the folks who are like I'm good at design. I'm good at HTML and CSS. I'm good at some JavaScript, but I'm not, you know, mastering Node JS or anything like that. I feel comfortable making good-looking components. Those are the people who are using Polymer the most that we've found. So I just see really making their lives a lot easier. It feels like so much of Web design and development has moved into crazy JavaScript framework land, and it's very intimidating for people. And I actually think that Web components will make it a lot more beginning friendly and hopefully bring some of those folks back into the fold.

CHRIS: That's nice. I have one, like, lingering thing in that. Let's say you kind of start from scratch and just Web components the crap out of some new app that you're working on. And that each one of those components then has its own chunk of HTML, and maybe that's in a template or something. And it has some individual JavaScript files that control its functionality. Likewise with CSS, there might even be like a modulenews.css somewhere or whatever.

Then let's say there's, you know, it's a complicated-ish Web app in that there's 12 of these different things all over the page. Is that 12 CSS requests and 12 JavaScript requests? How does concatenation and the traditional things that we think about performance kind of bake into this?

ROB: Yeah. So the way it works is you have kind of like an element definition. That's really what you use Polymer to create, just like the definition for what your element would look like when you use the tag on the page. And so typically you use one of these new standards called HTML imports to load in that definition. And you just load it in one time. After that, you can use the tag as many times as you want, and there's no additional overhead or anything like that.

And if you have a whole bunch of element definitions, so you've got 20 Web components that you want to use, we have a build tool called Vulcanize, which will take all of your imports and just mush them all down into one file that you just load one time. Or if you want, you can actually inline it into your HTML. There's like a little inline flag that you can use with the tool that'll just make it actually part of your main HTML file.

CHRIS: Oh, right. It'll squish it right in there.

ROB: Mm-hmm.

CHRIS: And hopefully you're smart. Hopefully you just do a good job and you're not like mega repetitive for that, right? Because if there was a lot of CSS that a lot of your Web components share, then inlining it 12 times is a bad idea.

ROB: Yeah, so you can have like common -- you can -- using Polymer, you can load in style sheets, external style sheets for your elements, and that means you can have kind of like a common CSS if you want that a bunch of your elements could share.

CHRIS: Oh, right, and it's cached, so no big deal.

ROB: Yeah, and then you'll just have little bits of CSS that's maybe specific to each element.

CHRIS: Cool. All right.

DAVE: Can I ask questions like does Web components kind of take like SAS and, you know, like JavaScript kind of frameworks like require or flight and stuff like that out of like dependency … stuff? Does that take that out of the question? Because I'm like, if I'm authoring, you know, a component, I would like to use SAS. But it seems like I'm limited to CSS if I author it in the component. Am I crazy, or I can use an external style sheet for that little component? How does that work?

ROB: Right. Yeah, you can use an external style sheet. That's actually what we do on. On the Polymer website we use SAS for everything, so all of our components, they just have like a little link tag inside of the template that points to an external style sheet that's generated from a SAS file.

DAVE: And then I can use Vulcanize or something to smash that all together, kind of?

ROB: Mm-hmm. Yep.

DAVE: Okay. Interesting.

ROB: Exactly. Vulcanized, you can really think of it as just sort of like a big concatenater. It just grabs all the things and concatenates them. Yeah.

DAVE: And then that's the common criticism I hear about like, you know, ten versions of jQuery or whatever. Is there any JS management best practices that you've come across?

ROB: Yeah, so HTML imports, which is how we typically load in the definitions for our elements, if you have a bunch of imports that all point to the same thing on disk, then the browser is going to … and it's only going to load that thing one time. What you can do is you could, for instance, have an HTML import that its sole job is to load jQuery or something. You can have an HTML import and inside is just like a script for jQuery. Then anybody else that needs to use jQuery can import that import at the top of their document.

And so you asked about required JS before. HTML imports can actually become a dependency management system for you. If you actually open up really like any Polymer element, at the top, inside of the element definition, usually up at the top it'll list a few imports for the things that it depends on. Then the browser just makes sure to load all of those for you. And if it sees the same thing being referenced, it's only going to load that thing one time.

DAVE: Sweet!

CHRIS: Nice!

DAVE: I'm a visual person, so it's like I have to see it to believe it, but if you're telling me the truth --

ROB: It works.

DAVE: -- it sounds great.

ROB: It works.

DAVE: Okay. But if you're lying to me, I'm going to sue. I'm going to sue Google. Uh, all right, sorry. Next question. We're onto the second question.

CHRIS: (Indiscernible)

DAVE: We did it.

CHRIS: Yeah.

DAVE: All right. Go ahead.

CHRIS: What would you say are the advantages of Polymer over Angular directives, which I don't know enough about all that to even know if those are comparable things? Can we define what an Angular directive is first?

ROB: Yeah.

CHRIS: Because we already know what Polymer is.

ROB: Yeah, so an Angular directive, it's very similar in many respects to a Web components. It's basically like let me create a custom tag that I can use in the browser. And when it sees it, it's going to have a little bit of built in behavior and things like that.

The primary difference is that Polymer and Web components use the Shadow DOM, so we are scoping our CSS styles and our markup and everything to the element instance, so it's not going to bleed out, like its styles are not going to bleed out all over the page. And right now an Angular directive does not have that same kind of power built into it.

DAVE: Right. You could write some JavaScript that interferes with it somehow accidentally or whatever.

ROB: Yeah.

DAVE: Or a style that screws with it or vice versa.

ROB: Exactly. And then this gets at kind of like a larger thing, which people ask about all the time, which is really like what's the difference between Polymer and Angular. Why would I use Polymer instead of Angular? The way that I like to think about it is that Angular is really designed to give you a very opinionated way to structure your entire application. There's sort of like an Angular way of doing like routes and services and dependency injection and all of this stuff.

Polymer is really -- we want to give you an opinionated way on how you can build components, but then how you actually compose those together is really up to you. And the two are not mutually exclusive. So the Angular team has been talking a lot about how in Angular 2.0 they want to have support for Polymer and Web components so that you could maybe have Angular being like the puppet master for the entire application, you know, handling what happens when the URL changes. But then all of the components that it's sort of poking and driving, those might all be Polymer elements or Web components.

CHRIS: Yeah. Okay. Cool. So they are related heavily, but they don't necessarily need to be mutually exclusive, but they could be.

ROB: Yeah, it's really up to you how you want to work.

DAVE: You could be making a project using Polymer without using Angular, and you could be using Angular without using Polymer, and neither -- I mean neither are specifically better, right?

ROB: Exactly, yeah.

DAVE: Okay. Yeah.

CHRIS: It's so cutting edge though that I doubt we could point you to a huge, live project that's using both successful and stuff. Right? It's kind of knew for that.

ROB: Yeah. I can point you to the Polymer website, which just uses Polymer, and it does everything using Polymer. It does all the UI and everything is all Polymer. Yeah, that's one of the things that we're still working on is we want to see more apps being built. That's actually one of the reasons why we created the polyfills in the first place was to get these things into developers' hands.

CHRIS: Yeah, it's kind of like to not screw it up, right?

ROB: Exactly. Yeah.

CHRIS: I feel like somebody was -- the date stamp on GitHub uses Polymer or something. Is that just a troll or are they using it?

ROB: Yeah. No, no, that's true. Well, it doesn't use Polymer. If you go to GitHub, and you look at when a commit happened, it'll say 13 minutes ago or something like that. It's a little like gray date stamp. That's actually a custom element. If you inspect it, it'll say date stamp, and then it'll say is equals. There's an attribute that says is equals time until or something like that. And so they've actually used --

CHRIS: Oh, I see that. Yeah. I mean it's still a time element, so it's not -- they didn't event the time element, but the "is" attribute is weird.

ROB: Yeah, so what they've done is it's actually a custom element. It's called a type extension element, so you can extend built in elements. You can extend native elements and add additional functionality to that. I believe they used our custom element polyfill to do that. They took the polyfill out of that platform layer of Polymer and chucked that in there to do that. So it's kind of cool.

CHRIS: Cool.

ROB: They're dipping their toes in there.

CHRIS: So it has a date time stamp, but maybe the text node part of that element will change, like if I just leave this tab open for an hour, it'll change from three hours ago to four hours ago.

ROB: Yeah.

CHRIS: Just because that's what it does somehow magically.

ROB: Yeah. I haven't looked at the source, but I'm assuming, yeah, what they did was they probably added a little bit of JavaScript in there that's just like running a clock or a timer or something.

CHRIS: Cool. Why not? Perfect little miniature use case.

ROB: Mm-hmm.

CHRIS: Let me do another sponsor. I didn't do the FrontEnd Summit yet, did I?

DAVE: Nope. We did SpeedCurve.

CHRIS: I'm going to go ahead and do it. They are Environments for Humans, and they do these online conferences, right? If you go to FrontEndSummit.com, it will redirect you to where you need to go to their site, and it's a one-day online conference, meaning you can attend it from anywhere in the world, coming up August 21st. It happens from like 9:00 in the morning to 4:00 at night. Of course, it depends on what time zone you're in and stuff.

But like I said, you can join in from anywhere you have a Web browser because you sign into their little thing, and you listen to the speakers talk live. And you have a chat room. And you can kind of raise your hand and then the speakers generally answer questions at the end of them. It's pretty cool.

This one is all about the type of stuff that we talk about here on Shop Talk Show. That is front-end Web development, so there's Mr. Adam Simpson talking about code editors and leveling up your ability to use those things. Tooling for a better workflow with Neil Renicker. I've never met -- oh, from Smart Box. We know them. We've had Ben on before, I think, haven't we? Maybe not, but if we haven't, we should. John David Dalton talking about fearless browser test automation, so he's the dude behind Lodash and takes performance and browser testing stuff pretty seriously, so that will be pretty interesting to hear. Mr. Ben Alman talking about the state of Grunt. You know, Grunt is under more competition than it's ever been under. What is Ben going to do about it? Go ask him questions about that.

DAVE: Dun-dun.

CHRIS: Yeah. It should be a pretty cool conference. One day only, $179, pretty inexpensive as far as conferences go, so level up your front-end skills, FrontEndSummit.com. Let's do another question.

DAVE: All right. This is a shorty, but a goody, Lucas DeSilva writes in, "Is it already possible to use Polymer with Phone Gap?

ROB: Yeah, so we've seen people using Polymer with -- by the way, I'm not a Phone Gap versus Cordova expert, but we've seen people using Polymer with Cordova, which I believe is just the Apache sort of open sourced version of Phone Gap, dropping Polymer elements and Polymer apps into Cordova. We actually have some friends at Salesforce who built a bunch of mobile Salesforce elements, and we had a demo video of the thing that they built in Cordova. We showed that during my talk at Google IO.

I think the main thing to note is that the Web view that Cordova uses, you need to make sure that you're using the Web view that's shipped in android. I think it's 4.4, which is based on Chromium. It doesn't; Polymer doesn't work with the Web view that's based on the old android browser, so, yeah, you've got to make sure that you're in one of the latest versions of android to really get that working over there.

CHRIS: Okay. It just relies, but it's all just JavaScript and stuff, right, but it uses some JavaScript stuff that's not available in those old things. I mean, what are -- do you know what those APIs or whatever are offhand, like what are the things that it relies on that aren't available?

ROB: No. Offhand, I'm not quite sure what it is that's lacking in android browser. I just know that it's one of those things that we --

CHRIS: Yeah.

ROB: We had to kind of like make a decision of either the code has to get really, really, really big because we're going to have to polyfill a lot of even additional things to support a lot of the legacy browsers, and we'll have to spend a lot of time on it too, which would be really tough because we're really trying to push the envelope forward. We want to make sure that we're making the new thing good. Yeah, we had to kind of like pick a line. And I think the evergreen browsers, the last two versions of everything and the Chrome Web view was sort of that line.

CHRIS: Yeah. But it's something like that, right?

ROB: Yeah.

CHRIS: It doesn't support query selector all or something. I mean that's a terrible example.

ROB: Yeah, yeah.

CHRIS: But it's something like that, right?

ROB: Yeah, we didn't do it to spite the android Web view or anything. There's stuff that was missing that was going to be a real challenge to polyfill.

CHRIS: All right, cool. We have one here from -- I think we're starting to venture outside of this territory a little bit. That's okay. I think we all get the point. Corey Briere writes in. Wow, he even put in a pronunciation and I screwed it up. Sorry, Corey. "When working on a project with a team using Git and SAS, what does your guys' folder structure and workflow look like? Is it better for each dev to have their own SAS file?" This is where it gets weird. He's like, "For example, Chris.scss and Dave.scss, or should the team be working on completely separate components pages to avoid doubling work over even overwriting styles? Thanks for a good show."

I just, I put that in there because I found it so strange that I wonder where that thinking comes from a little bit, like what do we think Corey is worried about such that you would want to have our own named files. Is it like the Git is scary and that -- I could see how an FTP workflow is scary such that we might be overwriting each other on accident, but that's kind of the whole point of Git is that you can't do that.

DAVE: Yeah, I would -- my guess is, yeah, coming from working together over DropBox or working together over, you know, like FTP or something like that. That's the workflow Corey is maybe used to. But like you said, Chris, the whole point of Git is you could actually all be working in the same file and you just commit your changes and push them up and then send them back and stuff like that. But what's going to happen is you're going to have a merge conflict, and merge conflicts are, like the first time you see them, they're awful and terrible and scary because there's all these arrows and equals signs and terrible things. And you're like, oh, my God. What happened? Everything is terrible.

But you can get over -- you just have to do it a few times, and then it's way less effort. The only problem is when you guys touch or your two developers touch the same lines of code. Then you have a problem.

But I'm also curious. Rob, you work at Google or whatever. That's a big company. I'm sure you guys are all touching each other's files and things. So how do you handle using people's files?

ROB: Yeah. We just try and make sure that you have a SAS file per component. We try and work in sort of like a component specific fashion. Then merge conflicts can happen, but it's easier to reduce them when you're only working on one component at a time. As long as you're communicating well with your teammates, you're like, hey, I'm working on the sidebar today or something like that, and they know that you're in there and poking around. It can be tough if you just have like one massive, you know, SAS file for your entire site and everybody is changing things at the same time. That would be a problem.

CHRIS: Oooh, it sure would. I never thought about that, but that's kind of like a good selling point for micro, you know, like being really componentized about your SAS is that the chances merge conflicts are lower.

ROB: Mm-hmm.

CHRIS: That's a nice side benefit. I wonder. I'm curious about like working at a big company is like in that you're all human being with different brains and stuff, so you probably have different abilities as far as even using a tool like Git. I'm sure there's some people that are super Git masters and some people that just have higher skills in other regards and use Git because the company uses Git, but occasional get into trouble with being confused about a merge conflict or something.

But at Google there's so many smart people that can you tap into that somehow? Can you call 1-800-Goo-Git and it's only for internal people, and they'll help you through a merge conflict? Or do you just got to be like, oops, I don't know what I'm doing, and then just call somebody on your team? Is that a weird question?

ROB: Well, I get to sit next to Paul Irish, so I can just turn around and be like, "How do I do this?" if I don't want to embarrass myself too much. Otherwise I'll just quietly figure it out.

CHRIS: Power through it.

ROB: Yeah. I'll be like, I don't want him to laugh at me. I think that our team works really not -- I mean, I should say the Polymer team is pretty small relative to a lot of the other teams, so I'm sure there are teams that have people whose sole job is to just make sure the build process stuff is going, like dev ops type people, I guess. Our team though, we -- you know, if we have problems, we just ask each other. We work just like any other sort of small agency or small consultancy, if you want to think of it that way. We just have a handful of developers making stuff for the Polymer website.

CHRIS: Cool. Do we have time for a final one here? Are you okay on time?

DAVE: Let's go. Just find a good one.

CHRIS: This may be a basic one about how Node and Grunt and stuff works. Rich Finelli here writes in that he's starting to use Grunt and stuff, and it's pretty cool. Grunt, we know, is a tool that runs on Node JS, right? So to even use Grunt at all, you kind of have to have -- God, what do you call that file? -- the package.json file or whatever that kind of explains which stuff above Node that you want/need to use in your project. Rich is wondering about using Grunt and Node and Git together. He's curious about once you've run NPM install, you get this Node modules folder.

DAVE: Mm-hmm.

CHRIS: I'm just paraphrasing his question because it's kind of long. Then what do you do with Git? Do you ignore that, or is it easier to just commit that because then everybody can just, when they pull the repo, they just have that all too in there already?

DAVE: I always ignore Node modules for sure.

CHRIS: I feel like -- don't you have to ignore it? I've never seen a Node modules folder … because I think there might be things that are too specific to your specific computer's install of Node and stuff. You really try to never commit that, right?

DAVE: That's my M.O.

ROB: Yeah. I typically ignore it as well. I've seen people talk about committing it, so you can kind of ensure that I guess everyone is on the same page and no one maybe accidentally got a minor version uptick of something. But generally I would say everything, every project I've ever worked on, we've ignored it and just let everyone run NPM and install themselves.

CHRIS: One of the reasons is because it can be gigantic, right? There can be tons of stuff in there.

ROB: Sure.

CHRIS: And it makes your repository enormous.

ROB: Yeah.

CHRIS: I don't know. Maybe there's stuff like file paths can be different on your machine than somebody else's machine, but maybe I'm wrong about that. I don't know. But, okay, there's the idea Rich. Yeah. I guess Addy has a good comment in the chat room here in that if you have some worry about NPM going down, which is a third party service, that you might want to commit them to. Some people are more nervous about that stuff or have good reason to be nervous about stuff like that than other people.

Rich also asks, "So you're working with Grunt and one of the reasons to work with Grunt is to concatenate things." SAS can already do that, but you can use Grunt to concatenate your JavaScript files as well. I'm sure there's Grunt plugins for that. "Do you include things like jQuery or maybe Polymer, the libraries and stuff? Do you concatenate that all together with the JavaScript you write, or do you keep third party plugins kind of separate? Do you make a libs JS and a site JS, or do you just smoosh it all together or what's the deal there?" Rich is asking for advice.

ROB: With Polymer, I usually let Vulcanize handle concatenating all the stuff that I've imported. Then if I have a separate kind of bundle of JS --

[Cuckoo clock sound effect]

CHRIS: Sorry about that.

DAVE: Sorry. The soundboard is on the fritz.

ROB: Perfect timing.

DAVE: All right. Keep going.

ROB: Yeah, I usually try and let -- I'm trying to think here. If I have a bundle of stuff, and I had a bunch of third party libraries, I might bundle those together and keep the Polymer stuff separate and let Vulcanize handle the Polymer stuff. That's something that maybe I need to document a little bit better on the Polymer site somewhere what's the best practice for that.

CHRIS: Yeah. I think Rich might be asking. I mean, it's good to know what to do with Polymer, but I don't know. I would say, Rich, I generally just smoosh everything together, like I think of it not as third party and not third party, but as like what's global and not global. I'll probably have a global.js on most projects, and that's stuff that I know that every page needs.

And it doesn't matter if it's jQuery, which it probably is, or little bits that I just happen to control a dropdown menu or something that I happen to know is on every page of the site. That's going to go in global JS, and that's where I'll put jQuery and my own custom code. But just because it's based on that it needs to go everywhere, not necessarily that it's third party or not would be my advice there, I guess.

DAVE: Mm-hmm.

CHRIS: Any opinions, Dave?

DAVE: Uh, yeah. I think -- yeah, concatenate it all. I mean --

CHRIS: There you go.

DAVE: Unless you've got some special use case --

CHRIS: End strong.

DAVE: -- concatenate the heck out of it. Boom! That's all I'm going to say. All right. Well, I think we have come to the end of the show. And I need some outro music. But, Rob, thank you so much for coming on the show for a Web components deep dive. I know --

[Old car horn side effect]

DAVE: -- I'm personally really excited about Web components now, and hopefully everyone else is. But, before you go, how can people follow you, download your things, give you money? How does that work?

ROB: Yeah, so on Twitter I am @Rob_Dodson. And yeah, I'd encourage everyone to go to Polymer-Project.org and check out Polymer and play around with it.

Also, for folks out there who are -- you know, I listen to Shop Talk a lot, and I feel like there are a lot of developers who have questions, kind of like some of the ones that we had today where it's like what is, you know, what's the opinionated thing that I should be using for the Web. At Google, we just launched this project called Web Fundamentals, and so if you go to Developers.Google.com/Web/Fundamentals, it's kind of like an opinionated guide on how to get up and running doing front-end development to maybe answer some of the questions that folks have.

DAVE: All right.

CHRIS: Nice.

DAVE: Cool! Well, thanks very much and thanks, everyone, for listening. We really appreciate it. We, of course, rely on your questions and answers and stuff, so keep sending those in. If we've made a huge mistake, leave a comment on the website. And follow us on Twitter @ShopTalkShow. And … Chris.

CHRIS: ShopTalkShow.com.