2:15 - Introducing Rob Dodson

• Polycasts with Rob Dodson
• A11ycasts with Rob Dodson
• Twitter 2:35 - What are Web Components? 5:00 - Using Web Components 10:05 - Why material design hasn’t focused on Web Components11:55 - Making Web Components smaller14:45 - Standards of work18:10 - What is “Shadydom”? 21:05 - Benefits of using Web Components and custom elements26:05 - Web Components and Angular 2.031:05 - Eventing and lifecycle models for Web Components33:55 - Testing Web Components35:30 - Benefits of using Polymer38:50 - Clearing up confusion between Polymer, polyfills, and Web Components
• https://webcomponents.org/
• SkateJS
• Polymer Project 41:20 - What does Rob Dodson do?
• Polymer Summit London 2016 42:40 - Seeing how Angular 2 and Web Components connect
• https://github.com/webcomponents/angular-interop
• https://github.com/robdodson/angular-custom-elements
• Custom Element Inter-op with Angular 2 by Danny Blue

Picks:

Men Explain Things to Me by Rebecca Solnit (Ward)Angular Remote Conf videos (Charles)Web Components Remote Conf (Charles)Elon Musk: Tesla, SpaceX, and the Quest for a Fantastic Future by Ashlee Vance (Rob)Stranger Things (Rob)

Transcript

Charles:        Hey everybody and welcome to the Adventures in Angular show. This week on our panel there is me, I’m Charles Max Wood from Devchat.tv, everybody else is traveling either to Angular Connect or I know John Papa is actually heading my way. I’m in Atlanta doing Microsoft Ignite. I’m in my hotel room, I’m on my earbuds microphone and I hope it sounds okay. We also have special guest this week and that’s Rob Dodson.Rob:             Hey, how is it going?Charles:        Going good. You wanna introduce yourself?Rob:             Yeah. My name is Rob Dodson, I’m a Developer Advocate at Google. I work on the Chrome team and I primarily work on web components. I also work on a project called Polymer which is a helper library to make people more efficient at writing web components.Charles:        Gotcha. Do you wanna give us quick rundown of what web components are because we have components in Angular, we keep hearing about components when we talk about React, what are web components?Rob:             I guess the primary difference between components in React or Angular or maybe Amber and web components is that web components are based on a set of specs. There’s about four different specifications that roll up into this umbrella that we call web components. Those are custom elements, shadow DOM, HTML Imports and templates. Of those, the two that are probably the most critical, the foundation pieces, are custom elements and shadow DOM.                     Custom elements is what you define your own HTML tag. Basically when the parser is going through the page and it’s munching through all the various HTML elements in the document and it sees one of your tags that you’ve created, it will create an in instance of a class you’ve created.                     The other cool bit is shadow DOM. Shadow DOM lets you create kind of like a little scooping bubble around your component that’ll let you prevent your styles from leaking out and affecting anything else on the page. It’ll take all the markup that is inside of your component and it will basically encapsulate it.                     For instance if you called querySelector and you’re working on the page using querySelector or getElementByID, it would not find things that you had encapsulated inside of your element shadow DOM. They’re nice and they’re private. That’s good because that prevents someone from accidentally modifying your DOM when you don’t want them to.                     The way that that differs from an Angular component or React component is just that it’s standards based. The API that you use to create that component is actually just natively part of the browser.Charles:        Alright. Looks like John and Ward have joined us. Now that we kinda know what web components are, I think what I’d like to know is just how people use them so I can get my head around where am I gonna plug this in on my web application.Rob:             Yeah sure. There is I think probably two main ways that people can think about using web components. One way would be to build your entire application out of web components. You could for instance start with a very simple component, click button or select element, you’re creating all these custom widgets and then you wrap those up into a bigger component like a view for a whole section of your site, like a login form or something like that.                     You keep composing those into bigger and bigger custom elements until you reach a point where you just got my app custom element. It’s very similar to the architecture that you see frameworks moving towards today. Like in Angular 2.0, you typically have my app component that you’re sort of bootstrapping and then you’ve got all these other components inside of it. You could either build your entire app using components and just start with small components and create a higher order component until you end up that my app component or you could create web components and use them as leafs like the leaf at the end of a tree.                     For instance, if I was working at a really big company, let’s say I work at a company that has like 10,000 employees and they were like, “Hey, we want you to build a UI library for our company. One unified library that all of our developers will use.” It’s kinda tricky because you might have developers that are using Angular in their projects and you  might have developers that are building classic PHP just like static websites, and you might have developers that are using React. You need to find a way, like a common denominator, to build a component that all of those developers can use or for simple widgets. That’s another good use case for web components where you could just build your leaf elements using some of the standard stuff. They play nice with people’s frameworks, things like that.Charles:        Okay. If I build my own element, let’s say it’s a, it really sounds a lot to me like what components do for you in Angular where you can essentially create a component that is, I don’t know, in the Tour of Heroes I think they have a hero tag that you essentially put in. Angular goes in and makes that into a bunch of elements that show the image and the hero’s name and things like that. Is that kind of the same you’re gonna get out of somebody’s custom elements?Rob:             Yeah, it’s the exact same idea. The primary difference is that it doesn’t require a library or framework because it’s standards based and it’s just part of the browser. The nice thing is if you only wanted to build that hero list component one time, you could build it originally as a web component and then ideally, someone can use it in an Angular app or a React app. They could use it stand alone, they could use it however they want because it doesn’t require an initial library or anything like that.Ward:             If I had a hero list app, let’s just stay with that thought for a second, and that thing needed a server to go get the hero list. That doesn’t work because there’s no notion of injecting services or any of that other kind of stuff, right?Rob:           Correct. There’s no dependency injection like Angular has or anything like that. It’s literally just like a standard component, the same way that button, or select, or the audio element are just so these standard elements. They way that you can give them stuff, you can give them stuff either through attributes, you give them string values or numbers through attributes or you can set up property on it or you can pass them something that way, call of method on it.                     In theory, you could take that element and you could pass it a service if that’s the kind of thing that you are constructing but I think when you describe something that uses a service, I tend to think of those as maybe potentially higher order components.It’s probably most most successful for people that are already using Angular would be to build components, web components that are leaf elements. Buttons, drop downs, things like that, and then use higher order components in Angular to then be like, “Okay, I’m gonna pull on the service and when someone clicks on my fancy web component button, then I’m gonna go use my service to talk to the backend or something like that.”Ward:           That makes perfect sense to me. Making a whole application out of web components will make me feel like I was missing all the other infrastructure that I would want to have to assemble something but having it for presentation components makes great sense.                     It makes me wonder, maybe you can speculate on this, why the efforts in the material design haven’t resulted in web components? Why they went web components as opposed to why they went to the Angular 2.0 native components?Rob:             We have built material design as web components. The Polymer team created a web component version that of course requires the use of Polymer, like a helper library to make building this component easier but Polymer can exist inside of a web component. The idea at least is that the outside world does not need to know or care what that web component was built with. There, you could then pull in either a Benevolent component or a Polymer component or whatever and use those for instance in an Angular application.                     I think when material design originally came out, web components were kind of in their infancy and I think a lot of teams got really excited about the material design spec and focus on doing their own implementations. I think what we’ve been working on now is actually, at Google at least, is consolidating a lot of that work under one team, under one UX team who kind of wants to just build a common base set that everybody could rely on. Whether that eventually becomes custom elements or not, I’m not quite sure, but in my mind that would make a lot of sense. It might make it easier for people because you don’t have to do multiple different implementations of the same design spec.Ward:           That sounds right to me. I guess the one other thing that’s going on in the Angular world, and I wonder what web components plays in this, is the efforts to make them super small through tree shaking and all this other stuff. I don’t know enough about web components but you can tell us about what their size and performance characteristics are or what one could expect. Could one expect that that would just be sitting there in your browser or whatever your delivery vehicle is and they’re ready to go? How does it all play?Rob:             Yes. It might help to explain how to create a custom element. To define one of these elements, you just write a JavaScript class. There’s a method on the document called window.customelements.defineelement and you pass it that class and you pass it the tag name that you’re registering. You might say I’m creating a thing. The actual HTML element is fancy-button. That would be like the tag I would use in markup. I’m gonna associate it with this JavaScript class that I’ve created which is maybe also called fancy button.                     That’s essentially the entire overhead of the component. It’s just that classic written. They can be as small as you want. You can have an element that doesn’t even render anything. It could just maybe like do some work like the audio element is kind of an example of something that doesn’t render anything but it does some work or you can have it stand on a template so you could have it render some UI.                     The nice thing is that by being standards based, they can be inherently small because they don’t have to bring anything else with them, just whatever code goes into that one class.                     In theory, if you’re just writing good, fast JavaScript, then you’re gonna get a nice snappy component. It’s a very low level API so it’s not trying to do anything to dictate how you write to or read from the DOM. You absolutely can write slow components if you’re just writing inefficient JavaScript but that’s left entirely up to the developer.                     That’s on purpose. It’s because they didn’t wanna be too prescriptive with the standards. They wanted to keep them very low level. For instance, if library authors, the folks that make Angular or React, wanted to take advantage of them, they could. There wouldn’t be anything standing in their way or dictating how they had to do their components.Ward:           That’s comforting because there’s no limit to my ability to make a poorly performing JavaScript. I got nothing but upside there. You use the words standards based several times. I’m curious about that. I’m a total neophyte out here so I’m just asking dummy questions. Whose standards, how pervasive are these standards? What kinds of browsers are supporting these standards or is it just something Google dreamed up and decided to call a standard?Rob:             Yes. The actual history of web components goes way, way, way back to these things called, I think they were called HTCs in internet explorer, I think it went by another name at one point called XPL2 maybe. It’s a set of ideas that hooks of work at really all the browsers had been trying to get off the ground for a really long time. Basically, this notion of, “Can we make HTML extensible so developers can create their own stuff?”                     I think five or maybe six at this point, maybe five years ago, some folks at Google proposed a new iteration at the time, some of the ideas that I think were part of XPL2, those ideas are what became the web component standards and that is, at this point, shadow DOM, custom elements, HTML Imports and template. Each one of those has its own spec.                     After many years of discussion with the various browser implementer folks, we’ve now reached consensus on basically all of them with the exception of HTML Imports which is still having a lot of discussion. Template has shipped everywhere at this point so you can write a template element in HTML and that will create like a nice little scope part of the document where you can put code that will be parsed but it won’t execute. That’s really handy.                     Custom elements are shipping in Chrome at this point. Custom elements, it went through two iterations so custom elements B0 is shipping in Chrome at this point. There’s another iteration of this spec called D1 which Chrome will be shipping in 54 which Safari is working on as well and I believe Mozilla is working on. Microsoft just said that they would like to work on this. They just hadn’t gotten around to it yet.                     Shadow DOM just recently shipped in Safari 10, that was shadow DOM D1 shipped in Safari 10. Shadow DOM B0 was shipping in Chrome and we are revving up to D1 as well. I can’t remember if or when that is shipping but that’s gonna be in one of the next releases of Chrome. Again, Microsoft just expressed interest in shipping these things in Edge as has Mozilla, they just haven’t had a chance yet but I know that they are working on it.                     At this point, everybody is on board it seems. It seems like everybody is happy with the way the specs have worked out and they’re planning to ship. I think there was a narrative at one point that this was like a Google only thing back in the day. But I think now, there’s been a lot of rounds of iteration with the various folks involved and a lot of discussion on the mailing list and in person meetings. I think now everyone’s pretty happy with it and everyone’s on board.Ward:           You mentioned shadow DOM and again, my mind raises back to when people were uncertain about this whether it would be a standard and all that. There was something called I thought was a Google guy standing up and talking about shady DOM. It was a stepping back from shadow DOM. Can you cast some shade on shady DOM or figure this out for us?Rob:             Yeah, that may have been me. When shadow DOM originally came out, we created a polyfill for it. The difficult thing is that shadow DOM provides a lot of stuff. It gives you scoped CSS, so document CSS won’t affect your component and your component CSS won’t leak out and affect the document. You’re guaranteed that your component will always render as you expect it to which is a very difficult thing to polyfill accurately.                     It also provides markup encapsulation. If you have a bunch of markup in the shadow DOM, someone can’t accidentally query selector for it and mutate it or anything. Again, it’s difficult to polyfill.                     The original shadow DOM polyfill did a ton of stuff to make all that work and it was particularly slow on mobile browsers, mobile Chrome and mobile Safari. Chrome shipped shadow DOM pretty fast leaving just mobile Safari being very slow. For a lot of folks, that just was unacceptable. They were like, “We’re interested in web components but we can’t use this polyfill because it’s too slow.” The team came up with a much more performant sham that they nicknamed shady DOM. This was something that the Polymer team created. It was not as spec accurate as the shadow DOM polyfill but it did basically all the same things that people wanted and it did it in a much, much faster way but it had its own sort of particular API that you had to use to touch the DOM.                     This ended up confusing a ton of people and it’s  just really tricky. We’re getting rid of it basically. We’ll be talking about this in October but the plan is to just ditch shady DOM. Now that iOS and now that Safari is shipping shadow DOM, they don’t have to worry about polyfilling it on mobile browsers anymore. Just ditched the shady DOM thing. We have a much lighter weight shadow DOM polyfill that we’ve been working with that sort of strikes that nice balance between the original polyfill and shady DOM, this will be encouraging folks to use probably around October.Ward:           That shed some light on the situation. I can’t help but abuse the metaphor.Charles:        I’m a little curious. I missed a minute awhile back and I don’t know if this got asked. I did mention that custom elements and at least what I’ve been using components to a certain degree for with replacing tags in my applications are sort of the same thing and why would I use web components? Why not just use Angular in the first place?Rob:             Yes, that’s a great question. I think there’s a couple reasons why you might want to use custom elements, especially for leaf elements. One is if you’re at a really large organization, for instance, we’ve done a lot of work with General Electric and they have I don’t know how many thousands of developers. They want everyone to use the same UI components. For them, because they have developers who are using Angular 1.0, Angular 2.0, they’re using classic PHP pages, they have folks who are experimenting with React. They don’t want to build a version of their UI library for all of those different libraries. Instead, we wanna have a common denominator that people can use. You can write your fancy wide widgets and only do so once, and then anyone using our framework library can use those UI widgets, just take advantage of them the same way to take advantage of all the other HTML tags today, the same way you take advantage of a p tag or a header tag or a button element.                     That’s one of the advantages. And the other advantages, if you don’t necessarily want to use a framework or library, there are some folks out there who prefer to do things without involving a bunch of additional tools or build processes or anything like that.                     Another area of potential benefit is the browser makers, once they have all shipped these specs and standards, this is gonna be an area for optimization for them. As they are tuning the browser and they’re making things faster, ideally, if you’re using standard features, you benefit from those things.                     Those are some of the big areas I think. But for me, probably the biggest selling point is that idea of a common denominator. It doesn’t even have to be a big organization. How many datepickers exist that people have written in different frameworks at this point? JQuery plugin datepickers, ember datepicker, all sorts of different things. It could be really rad just to have a few that were high quality that we knew we can rely on. I’d like to see that too. Breaking developers off the shilohs that they’re in a little bit so we can share more of our code with each other.Charles:        Yeah. I think that’s interesting. I do like the idea of being able to share things outside of Angular. At the same time, if me and all of the other teams that I’m dealing with are just dealing with Angular, I’m kind of like well, I could just share that code. I’m curious if there are performance reasons maybe for doing it? Are web components way more performant than Angular components?Rob:             I would assume, and this is just a total assumption, less overhead involved in getting set up because there is no library that they are dealing with. They don’t have a library dependency. You’re just writing them vanilla. Like I said before, you could totally write a slow web component, you could write a web component that’s causing tons of reflows and stuff like that, reading things when it’s not supposed to.                     That really comes down to the developer and the quality of the component that they built. I think the main idea though is just to not do these things as mutually exclusive like frameworks and some web components, they just can’t work together. You might just find a couple of useful components and you can chuck them into your app. There’s just benefit from that.                     I used to use this jQuery library called Select2. I think it made very fancy dropdown boxes. I used to use a lot of jQuery plugins back in the day. I honestly just see web components as the better iteration of that same idea. There is a couple of these handy components you can just pull in wherever you need them. That doesn’t mean that you have to stop using your framework or anything like that, you just combine the two.Ward:           I’m totally sold on the idea of being able to have what I would think of as a third party library of visual controls that I could consume within my Angular app. I’ll have to try and write those in Angular or even maintain them or any of that stuff. I’d rather make that be somebody else’s problem and just focus on the business problems I’m trying to solve in my application, you’re singing my song.                     I know that Angular 2.0, one of their design goal was, one of the design goals, contemplating design goals is to work well with web components and the whole binding framework, backing in with some of the end. Angular 2.0 is designed to treat web components in a way that seems harmonious. What’s the actual experience of wedding Angular 2.0 with web components? Does it work? Does it not work yet? Are there gotchas? What have you got?Rob:             I haven’t done tons of work with Angular 2.0. I’ve actually been focusing a lot on Angular 1.0 web component interrupt. What I can say is probably the areas where things would be tricky today using Angular 2.0 would be if you were trying to load components using HTML Imports. We haven’t really talked about this much but HTML Imports were one of the specs that were proposed. What it lets you do is create a link tag that points to an HTML file. That HTML file, I think it’s loaded the same way that you can use a system JS to load a JavaScript module.                     That HTML file gets loaded. That HTML file might contain the definition for a web component. This is what a library like Polymer does for instance. They define all of their components and use HTML Imports and load them in that way.                     This can create a lot of confusion because you have Angular 2.0 which is using a JavaScript module loader to load its stuff, you’ve got these HTML Import things that are loaded with link tags that are just in the document. The tricky part there is knowing when is everything loaded. When can I actually start touching the page?                     I think that that idea goes away if you are not using HTML Imports but instead you just write your custom elements using vanilla JavaScript and you use template strings or you dynamically load in a template or something like that. That’s definitely an option for folks who wanna experiment with using the two together, just do everything as an ES module or something like that.                     The other areas where things could be tricky, with Angular 1.0 it was pretty tricky finding and passing data into elements sometimes because of the way that Angular’s data binding system was set up. As we mentioned with Angular 2.0, it’s alot easier because Angular 2.0’s data binding system is basically just like setting properties on elements. So long as you have to find properties on your custom elements, then you should be able to just use the Angular 2.0 system to pass data into them and then use the event bindings in Angular 2.0 to listen for changes coming out.                     I think one of the things that’s really interesting which I’m curious about and I’m kinda curious where Angular developers are in the space as well is people’s opinion on how much state a component should hold. Do they want components to be more like they are in the React land where they are pretty stateless, or do people prefer the idea of components that are stateful and stylistically like which direction are Angular developers headed in? That’s something I’m just not quite sure about, the more I’ve been digging in Angular 2.0 and React, these have been sort of top of mind for me.Ward:           That’s a great question and I think there isn’t one answer to it. Not only is at a question of diversity among the developers and what their architectural preferences are but I think it’s also a difference among the kinds of components that they’re working with.                     Something that you’ve been talking about where web components is at the leaf and its primary purpose, maybe its entire purpose is presentational. That lends itself to a stateless or nearly stateless approach. You give it what you want to show but you don’t make it responsible for going and getting anything or holding onto anything, just take what I tell you and I’ll tell you when I need you to be different.                     That fits the kind of component that isn’t the Angular 2.0 panty on but it’s not the only kind of component that would be in an Angular 2.0 app, there’ll be others that really are responsible for getting state, managing state, and all of those stuff but those don’t sound like web components things for me anyway. It just feels right to me that a stateless web component would slide nicely into the larger picture of an Angular 2.0 app. But again, I’m just talking off the top of my head as I had that experience and certainly sounds like at the boundary we’re in good shape to be talking to each other.                     Now, one thing that’s kinda curious is, again, I don’t know about web components but is there an inventing model, is there a life cycle model so I know I could tell you to destroy yourself or I could know when you’re being destroyed or when you’re being created and all that stuff?Rob:             Yeah, absolutely. Custom elements provide a life cycle system. When you define your custom element class, there are a number of callbacks that you can implement. There’s a create callback. For instance if someone says, “Document, createelement,” like passing your tag name. That will get triggered if they created it in JavaScript or the parser hits it because it’s already in the page. There is a callback for when the element is actually connected to the documents, literally called connected call back. That’s when it gets either actually inserted, or again, it’ll get called immediately after created call back if it was already on the page.                     There’s a disconnected callback when you take it out. There is one called adopted callback which is if you actually take it out of one document and place it into another document, I believe.                     There’s one that’s really handy called the Attribute Change callback which will get triggered anytime anyone changes an attribute on the element. That’s really nice because you can synchronize that with property setters and basically keep your attributes and your properties perfectly in sync back and forth.                     For instance, if you were building a stateless or a reactive component, that’s something you’d probably leverage pretty heavily to make sure that if someone changes an attribute, it triggers the appropriate setter that updates the UI or renders the power it needs to. That’s just a super handy call back because without that you would have to write mutation observers for all of your attribute changes and that we be very tedious.                     As for events, it just uses standard DOM events so you dispatch a custom event and anything that can handle a custom events can listen to it. Again, the APIs themselves are purposefully very primitive and very low level, they don’t try and add too much. Leveraging most of what’s already in the DOM, because every framework in the library should be able to fundamentally work with and listen to the DOM at some level.                     I believe in Angular 2.0 that should just work, it should be able to just hear all the custom events coming out of the element and then use that in its event bindings to trigger the appropriate methods and the controllers of the component.Ward:           Yeah. You know what, it does sound that way and I’m sure the Rx folks are all over thinking about how to wrap it in such a way that we’re using observables instead of callbacks. I know I would think that way.Charles:        One thing that I’m curious about is is there a good way to test web components? I’m pulling the stuff into my application and I’d like to know that this is doing the right thing.Rob:             Yeah. When I’ve done this when I was using Angular 1.0, I just used Protractor. It’s important to make sure that you are testing the components in the actual browser. This is primarily because Phantom JS is based on a variable version of webkit that we can’t even really polyfill effectively for web components. We really, really, really wanna make sure when you’re testing, you’re actually testing in a real browser.                     Protractor is good for that because it will actually pop up in a Chrome window or Firefox window or something and run your test that way. Beyond that, I’ve just written standard like mocha test for them, I’ll pass in an attribute or I will fetch some property and then try and query the DOM to defender as I expected it to.                     I am totally not like a unit testing expert so I’m sure there are Angular developers who have way better approaches to unit testing. I believe fundamentally, it should work with the test tools or most of the test tools that you’re already using in Angular and it should, hopefully, be able to treat it just like any other sort of Angular component.Charles:        Yeah. The other question I have, and this is totally different. I’m curious, you mentioned that you can just write your web components directly in JavaScript, what does Polymer give you that you don’t just get out of the box in your browser that implements web components?Rob:             That’s a great question. The web component’s specs are pretty low level. What Polymer tries to do is find the places where there are pain points and smooth those out. A good example is, I mentioned before that attribute change callbacks, you can listen for someone changing an attribute and then you can make sure to synchronize that to a property.                     If you have an element that has ten potential attributes or even five, that can become a fair bid of code in your class just keeping all those things in sync. Rather than having to write all those handlers in your attribute change callback and then write all those setters for your properties, Polymer just sugars that over for you and you can basically set it up so an attribute property will just stay in sync.                     That’s an example of something where to give developers maximum flexibility and control, the specs did not offer an opinion here. Polymer created an obstruction to make this easier on folks. If you were doing everything vanilla yourself, you’d probably end up writing this obstruction at one point anyways just to save yourself time.                     It’ll also handle for instance creating the shadow root that your shadow DOM markup will go in so you don’t have to write all the boilerplate code to do that yourself.                     One of the nice things that it does, it has its own binding system which can be completely self-contained. It doesn’t have to leak outside the component or anything, that could live just entirely inside of your Polymer component. What the binding system does is it allows you to pass for instance a complex thing, like an object or an array, declaratively to an element. The same way that Angular does it, Angular 2.0 has property binding syntax. Polymer effectively is the exact same thing.                     You can write some braces, even though it looks like you’re passing something to an attribute, just like in Angular 2.0, it’s actually passing it to the property, the corresponding property, and that lets you pass things like objects and arrays and build relationships that way because in HTML you can only pass strings and numbers normally through attributes.                     Those are the kinds of things that Polymer adds. I think of it as a utility belt for web components or the same way that lodash or something like that just makes it easier to do certain tasks.                     The goal of Polymer though is to just be really, really, really tiny, to be this utility built so that way people can build web components using Polymer but not have to worry about that or think about that and it’s not burdensome for someone to then take that component and drop it into their Angular 2.0 app or React app or anything like that.Charles:        I like things that make my life easier, that’s for sure.Rob:             Yeah, that’s our goal. One of the things that we’ve done which has probably been really confusing for folks is we attempted in the past to talk about web components, the standards, the polyfills and Polymer all at the same time. I think when that has done is it has created a lot of confusion for folks and they’re like well, what is Polymer? Is it polyfills? It’s like yeah,  we have polyfills that we ship. And they’re like, is it web components? And it’s like, well kind of, it’s like an opinionated way to use web components.                     I think it just created a ton of confusion. One of the things that I’m really trying to do right now is to split all these things apart. Web components are a set of specs, there are some polyfills that exist for them and then Polymer is just a little utility belt library that makes you more efficient in writing them.Charles:        Is there a good place for people to go to find out about web components and to find out what Polymer can actually do for you and where you’d wanna use it in your app?Rob:             Yeah. There’s a site called webcomponents.org which is focused primarily on just the vanilla specs. One of the nice things that they do there is they also highlight other libraries that use web components. It’s not just Polymer, there’s a library out there which I think is really cool called Skate JS which is made by the guys at Atlassian.                     Skate JS is just another opinionated way to use web components and they support a style which is much more like React. They have virtual DOM built into their components, I think they support JSx at this point which is really cool. webcomponents.org is a really cool site to check out.If you’re interested in Polymer itself, you can just go to polymer-project.org and that’ll be all the Polymer specific stuff. Also, shameless plug, I do a YouTube series on this, youtube.com/chromedevelopers is a show on there that I do called Polycast every two weeks which covers Polymer and web components. Go check that out and just get an idea for the kinds of things that we do with them.Ward:           That’s great, Rob, because my next question was okay that’s what everybody else is doing, but what is Rob doing? This is what Rob is doing. This is your world, what is your world exactly? What is your charter? Why do they pay you?Rob:             What would you say you do here? I’m a Developer Advocate for Chrome. I work with folks like Addy Osmani and Eric Bidelman, our team is really focused on getting developers excited about new web standards.                     I primarily work on web component standards. Just advocating for them, blogging about them, speaking about them, writing demos, things like that. I work a lot with the Polymer team because Polymer is a Chrome project. They’re actually members of the Chrome team that built that library. I do a lot of work with them just building demos, doing tech talks, and things like that. We have a huge event coming up in October, I think it’s 17th and 18th that we’re gonna be doing it in London, a Polymer Summit which is gonna be like a two day full blown conference sessions on the next version of Polymer, Polymer 2.                     We’re also gonna spend a lot of time talking about just vanilla web components as well. We have folks like Paul Lewis coming up to just live code some vanilla web components so people can see the difference between the two worlds and the side which they prefer, how they wanna use these different things.Ward:           That sounds great. The gap for me right here is I wish there was some place where we could see how Angular 2.0 and web components come together. I know that he’s the guy who’s got a lot of insight into the documentation of Angular 2.0, I know we don’t have anything on that. They just seem like they belong together and I’m wondering if you either know of some place or want to start a place where we can see where those things come together?Rob:             Yeah. That is definitely one of the things that I’ve been working on a little bit this quarter. It’s been a little tough because I’m not at all well versed in Angular. I’ve been learning Angular 1.0 and Angular 2.0.                     Primarily, I started off learning Angular 1.0 because most of the developers that I spoke to at the time, we really wanted to know how to make Polymer and web components work with Angular 1.0. I’ve been learning, with Angular 1.0 and Angular 2.0 while at the same time trying to figure out how to operate. There’s a couple of places to go check out. One of them was put together by a few of our Google developer experts. These are folks who are just stand out awesome developers in the community. That is at github.com/webcomponents/angular-interrupt.                     That’s a really cool repo put together by some folks that tries to demonstrate how to use Angular 1.x and Angular 2.x. I think they’re doing it with Polymer, I’m not sure if they’re doing it with vanilla web components, they’re doing it with Polymer.                     Another area that you can checkout is this repo that I’ve been working on. This is just at github.com/robdodson/angular-custom-elements. These are some experiments I’ve been trying to put together, these are for Angular 1.0, these are directives that will make the data binding systems in Angular 1.0 play nice with things like Polymer and also be able to pass things to vanilla web components. Still super experimental but if there’s anybody who is really interested in this space, I would love for them to come file issues or simple requests or help collaborate with me on the repo, it’s just like a fun side project that I’ve been doing.                     There’s also a really good blog post which by one of our GDEs named Danny Blue which was specifically on using vanilla custom elements with Angular 2.0. It’s a medium blog post that he wrote which is very cool. He built some simple components and shows how you can use them in Angular 2.0. We can share that as well.                     I think those will be some good starting points for folks, but this is definitely an area that I wanna keep working on in the upcoming quarters, making sure that the documentation, if the Angular docs have any interest in talking about this like collaborating with them on that. Also, figuring out where we can put this in web components docs, where we can put this in Polymer docs so people can better understand how to sue all these things together.Ward:           Rob, I can announce right here in front of everybody, and I’m gonna say it now. Yes, Angular 2.0 Docs, I want a piece on this, we gotta work it out. It’ll be there.Rob:             Okay, yeah. I’d love to work on that.Charles:        Alright. Well, this seems like a good place to go to picks. Ward, what are your picks?Ward:           I knew you were gonna say that. I always forget we do this segment. I’m gonna tell you about a book I picked up. I picked it up because the title of the book is Men Explain Things To Me. I’m thinking, “Oh no, this is so like I gotta know,” because this is written by a woman.                     It’s a scading essay about how guys try and tell, at least tell her what they know and what they think she knows. I’m shading my eyes and saying, “I’m sure this is gonna be all about me.” I can’t wait to read the essay. I throw that out there in case any of the rest of you folks out there, men or women, find the title of that essay provocative as I do.Charles:        Okay. I’ve got a quick pick. I have some friends who are pulling together a remote conference next year. I’ve been putting on a number of those, last week I did and also two weeks ago I did Angular Remote Conf. If you missed that, you can still view the videos. Just go to devchat.tv/conferences and just click on Angular Remote Conf.                     Anyway, they’re putting one on and they’re doing it about web components. It’s Web Components Remote Conf. I’ll put a link to that in the show notes. It sounds like they’ve got a bunch of stuff that they’re excited about. Hopefully, they have reached out to Rob but if they haven’t I will tell them that they have to.Rob:             I will be speaking at that event, yes.Charles:        Awesome. Go check it out if you’re interested in this stuff. Heavens, you don’t even have to travel. This sounds like a great option. Rob, what are your picks?Rob:             I’ve been reading the Elon Musk biography by Ashlee Vance. I don’t know if you all saw that today they did their whole Mars colonization announcement, stuff like that. That book is crazy awesome, it’s super inspiring and at the same time demotivating because you’re like, “Wow. This dude is literally superhuman and I will never ever be that awesome.” It’s a really, really, really fun read.                     I’m just gonna go say everyone should go watch Stranger Things if they haven’t yet. That seems like a safe bet. If you haven’t watched Stranger Things yet, you’re still struggling, you gotta go watch that.Charles:        Am I like the only person on this show, including guests, that hasn’t picked that show or watched it?Ward:           I haven’t watched it either but it seems to come up every single show and I’m running out of excuses to dodge it.Charles:        I know. Joe picked it and Jules picked it and Carol picked and Rob has picked it.Ward:           They must all be wrong, Chuck.Charles:        Oh well, maybe I’ll have to go check it out and make sure before I make that pronouncement.Ward:           I’m afraid I’m gonna binge watch it and I’m never gonna sleep.Charles:        I know, right? Tomorrow, John will show up here for Ignite. He’ll text me and I’ll hook it back, I stayed up all night watching Stranger Things. Anyways, it’s a popular pick.                     Once again, you talked about some of the stuff you’re doing but if people wanna follow you on Twitter or something, I don’t think we got that information out to them.Rob:             Yeah. You can follow me on twitter @rob_dodson and you can also check out the shares that I do on YouTube, you can go to youtube.com/chromedevelopers. I’ve got two shows on there. One is called polycast, it’s all about Polymer and web components. Another one that we just launched is called allycast, it is all about accessibility. Super interesting topic. It’s a very fun, meaty engineering topic. I love working on accessibility because some of the problems are really hard and fun to solve. Also, it’s one of those areas that not a lot of developers pay enough attention to. I think that’s mainly because we don’t always have a great understanding of the space and so it’s not super fun to work. But when you know enough about it, it’s very fun to work on. Definitely go check out allycast and hopefully learn a thing or two about accessibility.Charles:        Awesome. We’ll go ahead and wrap this up. Thanks for coming, Rob. It was a fun discussion.Ward:           Thanks Rob, I learned a ton. It’s one of those things that I have parked on my list, gotta learn about it. It was really great for you to come along and tell us about it.Rob:             Thank you.Charles:        Alright, we’ll catch everyone next week.