Web Components with Cory House | Episode 9

On this episode Cory House and I discuss the exciting new Web Components standard including the Shadow DOM, templates, custom elements, and imports.

To subscribe to the podcast, please use the links below:

Click Here to Subscribe via iTunes
Click Here to Subscribe via RSS (non-iTunes feed)

Craig McKeachie: [0:00] On this episode Cory House and I discuss the exciting new Web Components standard including the Shadow DOM, templates, custom elements, and imports.

[0:09] [music]

[0:20] Welcome to the “The Front End Developer Cast,” the podcast that helps developers be awesome at building ambitious web applications. Whether you are a JavaScript Ninja or just getting started. I’m your host Craig McKeachie.

[0:30] Hi everyone. My interview today is with Cory House, let’s get right into it. Hi, today I’m here at CodeMash, I’m lucky to have Cory House here with me. Cory is a Microsoft MVP, C# an ASP Insider, Outlier developer, expert, you may have been to his blog at bitnative.com. Cory, welcome to the show.

Cory House: [0:52] Thanks for having me. Glad to be here.

Craig: [0:55] Anything else I missed there about yourself?

Cory: [0:56] Oh, no. That’s sounds like enough platitude, sir. I can live with that.

Craig: [1:00] Great. You may have done some of Cory’s training on the Pluralsight, as well, if you have Pluralsight subscription. He has several courses out there. What are some of the courses about? I forget.

Cory: [1:10] There’s a course on clean code, called “Writing Code for Humans.” I have one on “Real World Architecture and Dot Net,” which is about being more pragmatic and comparing really simple to more complex, and when each makes sense.

[1:23] Then, I have an odd one called, “Becoming an Outlier,” which is about creating an exceptional career in software development, really setting yourself apart.

Craig: [1:30] I’ve seen your talk on that, here at Cobasa, last year, a really good talk, a packed room. People were sitting all over the floor and everything like that.

Cory: [1:38] It’s a great problem to have. That was a lot of fun.

Craig: [1:41] Speaking of that, today, I have you on the show to talk about web components. I went to your web components talk, this year, and the same problem. The room was very crowded. We were talking about it’s a great future technology, but I didn’t think that many people would be ready for it.

Cory: [1:58] Yeah, and frankly neither did I. It’s wonderful to see. I’m excited about it, and that’s why I’m speaking about it. I feel like, as a web developer, this is as big a story as anything that’s happened, probably since Ajax.

[2:11] This could, fundamentally, change the way that we compose and build our applications, and, finally, take all this fragmentation that we’re seeing, and get us all on a nice standardized, more reusable path. It’d be wonderful to see this all play out as well as it appears like it might.

Craig: [2:28] Exactly. Let’s backtrack a little bit, and talk about what are web components. For the people who’ve maybe seen an article or two online, let’s unpeel that a little bit.

Cory: [2:39] The easiest way to think about web components is, you’re probably writing components today, somehow. Maybe you’re using jQuery UI, and using MIME as a starting point. Maybe you’re using Angular and their directives.

[2:51] Maybe you’re using Knockout and their components, Ember and their components. I could go on. There are all these different ways to write these little reusable pieces that we slap into our web application.

[3:01] Wouldn’t it will be nice if we had a standardized way to do so and that is what it should…Components are about and the standard defines 400 technologies that all work together.

[3:12] To give us reusable components. We have templates we have HTML5 imports have the Shadow DOM and we have a fourth that I am forgetting. Offhand, which is…

Craig: [3:27] The pieces of imports Shadow DOM, HTML5…

Cory: [3:29] Of course custom elements.

Craig: [3:30] Custom elements?

Cory: [3:31] Yes, which is maybe the most important because Custom elements are something, that lot of people are already doing today…

Craig: [3:40] Each one of those if you don’t mind, which one you want to tackle first…

Cory: [3:42] Lets talk about Custom elements, because this is a story that lot of people are doing now, angular directives are interesting, at least in one piece. Because now we end up solving the DIV soup that we see in our code…Are reusable pieces of logic is that now when we look at our source code.

[4:00] Its more semantic. It describes what inside a lot better than all these DIVs that we see every ware. All the source code…Source almost any web application, and all you see is DIV, DIV, DIV, DIV, DIV…It is clear that our current market is doing a great job of letting us describe what is inside.

[4:22] DIV is a generic container and it’s useful but it’s, it should be used as a last resort, if we had something more descriptive, that would be preferable. That what custom elements are all about. Instead of waiting around for standards bodies to continue to add new semantic tags.

[4:39] We can do that whenever we want to now, and not just that, we go well beyond because maybe for instance, I have some data structure that is really useful just for my app, just for me. Why don’t create a tag just for that?

[4:54] Maybe, I’m creating a component for Pluralsight website site and I could create a Pluralsight-component tag and in time I put that on the page, then this component renders out the whole comment form, verything I need right there I can configure it.

[5:09] It gives a lot of power and does not require anybody to write a lot of code once it is done you put on the page like any other HTML tag.

Craig: [5:16] I could picture you while talking about so I can read what you are saying so instead of DIV soup may be a tab tag with the represent of DIV, possible to UL’s might have the real world. You might be able to throat tab tag on there with tab inside of it or something…

Cory: [5:34] The contrast tabs in the New World could literally have a tab tag, although to back up a bit, you have to hyphen in it, that part of the rules for custom elements, they have to have a hyphen in the name, but you could call it whatever you like.

[5:49] Maybe if we’re creating a tabbing structure for Pluralsight, it would be Pluralsight-tabs and then that would have its own mark- up inside. The beauty of that is now it’s really conveying what’s inside and makes your mark-up easier to read and you have this nice reasonable component.

Craig: [6:05] Why do you think they put the hyphens in there? I can guess, but I was curious what you thought.

Cory: [6:09] The hyphens are a really big deal because they are a message to the browser, that says hey this is a custom element, so treat it differently. Without a hyphen, then it is considered an unknown element, so the browser treats that differently. We probably won’t have time to get into the details here.

[6:26] But there’s styling that goes on and some new selectors that end up paying attention to any tags that contain a hyphen in it. This is all part of the standard, so that hyphen tells the browser a lot of important things about how it should treat that tag.

Craig: [6:41] That’s interesting that you explain it that way because I was thinking well they probably they did so they made sure people named things with a namespace and accordingly. This also gives the browser a big advantage, in terms of processing.

Cory: [6:54] It does. It’s also a future proofing scenario because, as you know, no HTML tags today have hyphens in them and there’s no plans to do so in the future. This assures that as new HTML tags come out they’re not going to collide with any of your custom elements.

Craig: [7:09] Not to belabor this too much more, but did you say you could have a tag that doesn’t have a hyphen that’s a base tag for other tags in your talk or is that not? Do they all need hyphens, like if you’re inheriting from something?

Cory: [7:20] There we go, yeah. You can extend native elements. I create a super button, for instance the way that I would instantiate that once it is created would be to put in a regular button tag and then use the is attribute.

[7:32] The value for that attribute could be super button, if that’s what I decided to call it, for instance. That’s a way to take the native behavior, native semantics of a button tag, for instance, and then add extra things to it.

[7:44] Maybe, my super button would always alert the browser and do something really annoying. Who knows what you can do with it? The point is taking that basic behavior and extending it.

Craig: [7:57] Which ones tackle on Shadow DOM, good candidate or is…

Cory: [8:00] …I love the Shadow DOM. It sounds mysterious. I feel like we should hide it behind a little bit more, keep them in suspense.

Craig: [8:06] I remember you talking about the light versus the dark DOM. I love that. Tell me people about that.

Cory: [8:12] That’s hard because the DOM that we know today, now we need to refer to as the light DOM because we have this new concept called the Shadow DOM. When we’re working with custom elements and we’re working with HTML5 web components.

[8:27] The Shadow DOM encapsulates a DOM subtree and that sounds pretty jargony. Effectively, it is this way to encapsulate and namespace a section of your DOM to keep the concerns separated from the rest of the page. What’s awesome about this is once you get this chunk of mark-up encapsulated.

[8:51] Then you can do things like style it in a really simple way. For instance, if this web component had an h1 tag in it, I could style it and say this h1, I want it to have a size of X, size 14 point. Any other h1 tags on the page wouldn’t be impacted by that because it’s encapsulated within this Shadow DOM.

[9:13] Each Shadow DOM has its own scope, so it’s not impacting others along the way. This is a beautiful thing because you think about all the places that you write really specific selectors trying to avoid colliding with someone else and now that we have this encapsulation, it’s beautiful.

[9:30] Now, everything gets really simple because I need to write the selector to do what I want here and I don’t have to worry about the rest of the page and the implications.

Craig: [9:38] If I take a component that someone’s written or web component someone’s written, I put it into a page. It could be in the middle of quite a mess of CSS and it won’t get stomped on, unless I’ve specifically gone to that level of specificity in my selector.

[9:55] The new set of selectors I noticed you talked about and I was excited about that because a lot of people explain the allure of oh gosh this thing’s encapsulated.

[10:05] That’s awesome, but I’m like wait I want to style that to be consistent with my website. I’m glad it’s encapsulated, but can I get in there? That’s what I’m wondering.

Cory: [10:16] Yeah. That’s what surprised me because I looked at the Shadow DOM as this vault. There was no way. It was heavily protected and no one else would get to it. Then, I came to realize well that’s not the case.

[10:28] The way the Shadow DOM works is you can always pierce the Shadow DOM using certain selectors and so there’s a new set of CSS selectors, which are hard to describe over audio. There is the deep selector, which lets you traverse any level of shadow roots and provide styles.

[10:46] There’s another way that you can define a pseudo selector and then define styles for that first level of Shadow DOM.

[10:54] What I am getting at is that you can nest Shadow DOMs and then decide whether you want to hit the first one or hit all of those nested Shadow DOMs. There is a lot of complexity here.

Craig: [11:03] When you were talking about that, it reminded me of your demo that you said “If this demo doesn’t blow your mind, you might as well leave because this is the best I have got,” which got quite a response from the crowd

Cory: [laughs] [11:14]

Craig: [11:16] Talk about that demo. That is useful for people.

Cory: [11:17] What was interesting is the Shadow DOM is there today. We are all using it and we don’t even know it. Browser vendors have been using this tactic for quite a while now. If you have used a video tag or you have used input with a type of date, those use a Shadow DOM behind the scenes.

[11:33] What I showed in the session is if you instantiate a video tag and then you inspect it using Chrome developer tools, at first all you are going to see is the video tag. But you can go into Settings and you can tell Chrome “Hey, show the Shadow DOM to me.”

[11:48] Once you do that all of a sudden you can expand and see all of the mark-up that creates that video tag. You can see all the DIVs that sit inside it. It is still…

Craig: [laughs] [11:58] The DIVs are back.

Cory: [11:59] Yeah, the DIVs are back. We are not losing the DIVs, it is we are encapsulating them. That is pretty cool because now the mark -up reads really clean and all that complexity is hidden away for the author of the component. That is powerful.

[12:14] What you also see is within that video tag that the video tag references an input with a type of range which also has its own Shadow DOM inside. That is where we are nesting components and we are nesting shadow roots and they each have their own separate scoping.

Craig: [12:31] Yeah, that is very insightful to know that components with a Shadow DOM can be nested inside of each other. I train on Angular a lot and people write directives.

[12:41] It is interesting when people realize their directives can get a lot simpler if they use other Angular directives inside their directives. It is the same thing, position story.

Cory: [12:50] Yeah.

Craig: [12:51] That is great. Let’s talk about imports. How about that?

Cory: [12:54] OK. Imports are awesome because they wrap this whole story up. They give us an easy way to deliver components. Remember when we are writing components they are HTML, JavaScript and CSS, same old tactic we have been using all along. We have some new APIs to define all of this.

[13:09] What happens right now is, say you want to create a component and use bootstrap, you are going to end up using about five different things. You are going to need to reference JQuery, reference Bootstrap. You’ll need to reference your own CSS and your own JavaScript.

[13:25] You’ll have to get those in the right order, too. Order does matter. Scripts are parsed from top to bottom. What happens today is that people are very specific about their documentation, saying “OK, here is how you use this ad hoc component that I created.”

[13:42] This is often the case with, say, a JQuery plugin, for instance. The same thing often happens in a proprietary way with what…UI or JQuery UI, Ext JS, whatever it may be. The beauty of HTML5 imports is you say on a single line, “I want to import this HTML file.”

[14:00] That HTML file contains all that complexity. That HTML file can have all the different script references that are necessary. It can have the different links to the style sheets that are required. All of that is in a nice little bundle.

Craig: [14:13] That is awesome, to bring a component in, one import and then declare the tag, is your story.

Cory: [14:19] Yeah, it is beautiful, nice and declarative and you can look at the top of your file and see what you are using.

Craig: [14:26] I don’t know about you but in the past, when I have to bring in a JQuery UI component I am like “Well, how do I want to do the folder structure,” and spending a half an hour trying to decide where I want to put things and my file structure and stuff. This is nice.

Cory: [14:37] Sure.

Craig: [14:37] You put that one file somewhere and you are good to go.

Cory: [14:40] Exactly. I am interested to see how many people embrace Bower when they are working with web components because Bower is really handy as a package manager for the web and pulling this stuff down. Bower helps make the process of getting the assets better.

[14:57] But it still doesn’t answer that question of me adding the references in the page. That is where HTML5 imports will be really handy. Yes, use Bower to get it. But then when you reference it, the nice thing is it will be a single line in your HTML.

Craig: [15:10] Right. Haven’t you heard? Bower is out now. [laughs]

Cory: [laughs] [15:12] Oh no. It wouldn’t surprise me.

Craig: [laughs] [15:15] Honestly, I have heard some people putting things in MPM. But we all know the downside to that. We could talk about it. I thought that was funny because…

Cory: [15:23] We could now have a rabbit trail here in this conversation. I agree…

Craig: [15:26] We should not go there. [laughs] What do we got left here, templates? Is that what I remember now?

Cory: [15:32] Templates is the final piece. Templates are really interesting because today we get this done, but we get it done in, again, proprietary ways. That seems to be the theme with our conversation today. We are going “Yes, what we are doing today works.

[15:45] But the standards-based way would be really nice to get in the future.” Templates are utilizing a new tag, which, not surprisingly, is the template tag. Anything you put within the template tag is inert. That means it doesn’t run at all. You don’t see anything there.

[16:02] I could put some JavaScript inside and say alert, and you would not see that alert run. Nothing would happen. I could put mark-up inside, put images inside and you wouldn’t see anything on the page. It is sitting there waiting to be utilized, waiting to be…

Craig: [16:16] It is like going back to high school chemistry here, it is inert. You used the word, I-N-E-R-T.

Cory: [laughs] [16:20] Yes.

Craig: [16:21] I am trying to clarify here.

Cory: [16:21] That is correct.

Craig: [16:22] That is awesome, that is awesome. That is a great way to describe it. Yeah, I saw that in your demo. You put a script tag in there, it doesn’t run.

Cory: [16:29] Yeah.

Craig: [16:30] Which is a security measure, I assume, right?

Cory: [16:31] It is not just a security measure. To me, it is semantically what you would expect. If it is called a template then I wouldn’t want it to ever render to the page by default. I want to write some code that utilizes it as a resource. It is a resource sitting there.

[16:49] Today we do this. We will slap some mark-up within a script tag. Or we will take a DIV and we will style it off the page or set its display to none and then we will strip that mark-up out at some point and put it on the page.

[17:01] That works. In fact, a lot of the frameworks that are pretty popular today use some similar approaches, hiding things in comments, whatever it may be. It does work. But the nice thing about templates is the browser is finally giving us this standards based way to say “Hey, don’t display this.”

Craig: [17:18] Right.

Cory: [17:19] Semantically it makes a lot of sense, too. Now when I read the mark-up it is really clear.

Craig: [17:23] Right. Of all the things people are debating about with JavaScript NEC frameworks, one thing they are not debating about is “We need templating and we need templates,” right?

Cory: [17:31] Yes.

Craig: [17:31] This is a clearly established thing.

Cory: [17:34] For sure.

Craig: [17:34] Like components. Talk about can we use these today, browser compatibility and so forth.

Cory: [17:43] This is where things get serious.

Craig: [laughs] [17:44]

Cory: [17:46] If you are lucky enough to be supporting only Chrome and Opera then all of this that we have discussed you can use today. The standards are set and they are supported in those browsers. Firefox still has some issues. But it looks like it won’t be very long until it is on the bandwagon, too.

Craig: [18:02] OK.

Cory: [18:03] The sad story, drumroll please, is IE. It is going to take some time. IE, at the moment, it looks as though what we are discussing may not make IE 12.

Craig: [18:14] That is surprising, isn’t it?

Cory: [18:15] Yeah.

Craig: [18:17] Shocking.

Cory: [18:17] It is coming. It looks like, if you look out on IE’s site, they have more or less committed to adding these features. There has been a huge number of votes. Everybody is really excited about HTML5s web components based on the feedback that we are seeing out on forums.

[18:31] And people voting for new features in IE. I would be very surprised if it is not added in, if not IE 12, perhaps there is some an update to it. That is my best guess at the moment.

[18:43] That said, you don’t have to have native support. There are poly-fills out here that give you the goodness of a lot of what we have described. Webcomponents.js is the name of the poly-fill. I believe it rolls back to IE 10.

Craig: [18:56] OK.

Cory: [18:57] It gives you most of the goodness that we talk about here with some interesting quirks. If you’re familiar with “Polymer,” that’s a project from Google that was formerly the poly-filling library of choice but now.

[19:12] They’ve taken the poly-fill piece and they’ve pulled it out and called it, “webcomponent.js.” It’s a separate project now. Anybody can use it. You don’t need to use Polymer to enjoy it. That is the story if you want to do so.

[19:24] The real question is, “Given where we are right now, does it make sense to use that over all this other really popular options like Knockout, Ember, Angular and Backbone?” That’s a really tough call.

[19:38] To me, even as somebody that’s really excited about this right now, I would probably lean toward one of those because they are great frameworks that work today across browser.

[19:46] But if you’re somebody that’s fortunate about to be able to write against Chrome or maybe you’re doing some mobile development and you only work in modern versions of the mobile browsers, then you might find that this works pretty well.

[20:01] I can say off the top of my head how all the mobile browser support is at the moment. I haven’t checked that. That’s revving pretty quickly. Now, mobile is ahead of the curve of these things, so we might find that that’s the story that helps move these standards forward first.

Craig: [20:14] Yeah, and we’re soon be to a world of all “evergreen” browsers. You won’t be more than a few more years until…I’m probably exaggerating by that statement but soon, we’ll have all browsers that are auto-updating and then this stuff is going to come really fast at us.

Cory: [20:30] I can’t wait. Yeah, I love that. Right now, things are revving very quickly but that’s going to be a whole new level of excitement when we get there. I’m also excited to see what happens with “Spartan.”

[20:39] I’m a little unclear what Microsoft is doing there. It sounds like it’s using the same engine but if we see Spartan as the default browser in Windows 10, that could really start to change things.

[20:50] That could really help move people over to the full evergreen browser stack because IE is at the moment, I believe the last hold out on the whole auto-updating movement.

Craig: [21:01] That’s interesting. One thing I wanted to breakdown a little bit more that was confusing me and you started to explain it there is the whole, it used to be Polymer and then I know is “X- Tags,” which is a competing thing like a healthy competition to Polymer.

[21:15] But Polymer had in it some amount of code that then got pulled out into the URL’s now web…

Cory: [21:22] …Webcomponents.js is the name of the poly-fill.

Craig: [21:25] OK. It’s literally on a separate site now like “webcomponents.com” or something like that.

Cory: [21:30] It’s out on GitHub is the project. It’s an open source project but it is, as far as I can tell, still developed primarily by Google. I don’t know if they’ve taken many poor request on the outside.

Craig: [21:41] Correct me if I’m wrong here, so Polymer and X-Tags are comparable things and one is by…

Cory: [21:47] …Yeah, Polymer is from Google and then X-Tag is from Mozilla.

Craig: [21:51] We know good ideas come from competitions so they’re trying to create a healthy ecosystem of components in two different worlds so that the different ideas can be brought to the world. Is the idea is that?

Cory: [22:03] Yeah. I would say they have two core goals. One is to make writing Web Components easier, so they take the standard and then add some syntactic sugar on top of it so that you can do some things that the standard doesn’t currently allow you to do.

Craig: [22:16] What’s an example of some syntactic sugar that you’ve seen and maybe I’m getting too deep here?

Cory: [22:20] One thing you can do with Polymer is you could reference external style sheet within a template. That’s not part of the standard spec but that’s something that Polymer allows you to do.

[22:33] They poly-fill in that. I shouldn’t say “poly-fill” but they give you that behavior even though it’s not part of the standard.

Craig: [22:38] You can also declaratively create an element with Polymer, which you can’t do with the native HTML5 specification. This is where things get a little tricky and my…

[22:48] [cross-talk]

Cory: [22:49] …Code when you say “declaratively,” right?

Craig: [22:50] Within mark-up. Yes, I could create a tag right there within mark-up using Polymer.

Cory: [22:56] Oh, interesting.

Craig: [22:57] Yeah, and this can get confusing. Order of operations is really important and I recommend first thing you should is learn the standards and understand those. Once you understand those standards.

[23:09] Then it will be easier to see how Polymer and X-Tag take those standards and start to add some interesting things on top of it. But if you do it in the other order, you’ll probably going to find yourself confused in the same way as if you learned jQuery and then try to learn JavaScript.

Cory: [23:23] Yes, which we all did, right?

Craig: [23:24] Yeah.

[23:25] [laughter]

Craig: [23:26] Was it common story, yeah?

Cory: [23:27] Indeed.

Craig: [23:29] I feel like when I went to Polymer site though, beyond the making extending Web Components, there was maybe a start of a component library there. Is that something that’s happening?

Cory: [23:41] Yeah, absolutely. There are component libraries for native HTML5 Web Components out there like “Component Kitchen” and the other site slips my mind.

Craig: [23:50] That’s fine. I’ll put it on the “Show Notes.”

[23:52] [cross-talk]

Cory: [23:53] Thank you. Also, you see Google out there and Mozilla trying to create reusable components using their libraries. There are Polymer elements. There’s the paper elements that are really interesting that Google announced a while back at “Google I/O.”

[24:06] There’s a lot of unique components also from Mozilla. That’s a nice way to really showcase what you can do. They’ve done a great job of really wowing people, where you can put a simple tag on a page and get really rich behavior.

Craig: [24:20] These all sounds great. Besides the fact that maybe not quite ready to use today but we should be learning about it because it’s going to change the world of web development.

[24:29] What are some downsides? What are some things about Web Components that you feel like they’re still trying to figure out?

Cory: [24:35] The biggest problem to me right now is if I have a bunch of component on the page and they all have third-party dependencies, things get really hairy. If people are creating their components and they depend on third-party libraries like jQuery, for instance.

[24:51] And I have three different components I want to use that require different versions of jQuery, I can’t use them together. For that matter, if I tried to, then we’d end up loading three different versions of jQuery at the same time which is going to cause issues.

[25:04] For the same matter, even if they used the same version, there’s this other conversation of “I need to use the exact same reference at the exact same URL.” Because if I don’t, then it’s going to end up pulling down two versions because one was from this domain and one was from this domain.

[25:21] This remains to be seen how we solve this. My opinion is if you’re writing a web component that you want other people to use, eliminate the third-party dependencies.

[25:30] I feel like the need for jQuery when you’re working with Web Components should be pretty minimal. You’re already working with really modern browsers that have pretty consistent APIs already set up. They honor the specifications well, so that should greatly reduce your need for third-party libraries.

[25:48] If you are given the option between two components that do more or less the same thing and one of them doesn’t bring along this heavy third-party dependency, which one should you pick? It’s a pretty easy choice, right?

Craig: [26:00] Right.

Cory: [26:01] Then you don’t have to worry about those conflicts. That’s the biggest concern right now.

Craig: [26:05] One thing I really struggle with because I’m so much in this JavaScript framework world, the Angulars and the Embers and the Backbones of the world.

[26:13] I’m trying to imagine particularly with Angular and Ember with the two-way data binding and who knows what things like react, whether that will stay around but how these components are going to play within a framework like that.

[26:26] I’m guessing maybe it’s going to take a new version. I know Google is working on that but I wonder what you’re thoughts are around that.

Cory: [26:33] It’s interesting because you’re already seeing these frameworks trying to move more toward the standard and do little things to honor it.

[26:40] If you’re familiar with Knockout components, the most recent version, when they added components, they were careful to put dashes in the component names in their examples. Now, they didn’t have to do that because it really doesn’t matter.

[26:53] But it was their way of helping move people toward the standard. You’re going to see increasingly, Ember isn’t a framework that I’m particularly familiar with, but I’m seeing a lot of interest there and I’m trying to take pieces of specification and use those in Ember components.

[27:11] What’s going to likely happen at some point down the road is these popular frameworks wound up being really a layer over the top of the standards. They will all honor the standard underneath but they will add their own goodness on top of that.

[27:28] That’s really to some degree, that’s exactly what Polymer is doing today. It so happens that Polymer isn’t solving all of the other interesting problems that Angular does, so Angular remains the real focus and probably the most practical option that Google is offering at the moment.

[27:43] It is interesting that they have both sitting side by side and I speculate that probably Angular too will end up swallowing up most of what is currently happening in Polymer and somehow morphing them together. It’s hard to have a clear picture of what that would look like right now.

Craig: [28:00] I’d see it’s very difficult for me as well to rationalize that but I do think, Web Components, they’re going to be part of the standard. It’s coming so they’re going to have to play in that world, which is great.

[28:13] You’ve mentioned at the end of your talk that you’re obviously very knowledgeable about this. You finished a course on “Pluralsight” about it?

Cory: [28:21] Just did. It’s supposed to publish any day now and it’s called “HTML5 Web Component Fundamentals.”

Craig: [28:26] If you’ve got a Pluralsight subscription, go check out that course. I’m sure it’s going to be awesome if you’ve checked out Cory’s courses before. Thanks for coming on the show today.

Cory: [28:34] Thanks for having me. This was fun.

[28:36] [music]

Craig: [28:38] Thanks for listening of the “Front-end Developer Podcast.” Please subscribe of the podcast by going to the iTunes Store on your phone or desktop then search in for “Front-end” or via RSS by going to “frontendcast.com,” where you also find Show Notes and a full transcript of each episode.

[28:52] You can also signup for my free “Angular JS, Backbone and Ember” crash course. All of them solve the same problem, so why not learn them together. See you next time.

[29:02] [music]

The post Web Components with Cory House | Episode 9 appeared first on Funny Ant.