What do you want to learn?
Skip to main content
HTML5 Web Component Fundamentals
by Cory House
Learn how to use the Shadow DOM, Custom Elements, Templates, and Imports to create reusable web components.
Resume CourseBookmarkAdd to Channel
Table of contents
Five Problems, One Solution
Hi, and welcome to HTML5 Web Component Fundamentals. I'm Cory House with Pluralsight. You can reach me on my blog at bitnative.com or catch me on Twitter: @housecor. Today's web developers have some big problems, and that's why I'm really excited to bring you this course on HTML5 Web Components. I believe web components are going to radically improve the way that we write applications today. So what sorts of problems am I talking about? Let's walk through five specific problems that web developers face today.
Problem 1: Undescriptive Markup
The first problem is most of our markup isn't descriptive, it's highly generic. Just look at the source of Gmail. Note the divs nested more than a dozen layers deep. Using the developer tools it's really obvious when you look at the layers of nesting, html, body, then div div, div, div, div, div. I could go on, but div soup is the problem. Divs mean nothing, all they say is this element is a block. And Gmail isn't alone with having a sea of divs in its markup. Twitter is the same story. As you can see, there are least nine layers of divs in the markup for Twitter. Wouldn't it be nice if this markup were more descriptive and less generic? One last example, check out StackOverflow, again, div soup, but do note that StackOverflow has done a great job of at least providing useful IDs and class names on different elements. This certainly helps the maintenance programmer navigate the markup, but it's still composed of deeply nested divs at least nine layers deep. You've likely heard about the importance of the semantic web over the years. Semantics is the study of meaning in language, and the semantic web is important because it helps convey the meaning of your content. The generic div tag conveys no meaning about what lies inside.
Problem 2: Style Conflicts
Have you ever had a plan to take family pictures, and you have this vision of well-behaved children and proper coordinating outfits, and as developers, we have the same dreams of creating clean, professional-looking components with a polished style. We want things to look crisp and for things to flow. And then you go pull in the giant centralized application style sheet, and ah, what happened, that's not at all what I envisioned. When everyone is free to do their own thing, style clashes are a real risk. So problem #2 is styling conflicts. Today's HTML5 components struggle with avoiding CSS conflicts. We envision cohesive styles like this, but if we're not really careful, we may end up with this. Other people's styles end up ruining our vision, and because there's no way to encapsulate styles for a given component, there's no way to ensure that other styles on the page won't accidentally break the styling of any components that we use or write ourselves. So, we're forced to bloat our CSS and markup with very specific selectors or even resort to the use of hacks like !important to ensure our styles are applied as expected. The bottom line is, we have no guarantee that other styles won't accidentally conflict with ours, so we have to be extremely specific when writing styles and markup for useable components. This adds unfortunate bloat to our markup and our style sheets.
Problem 3: No Native Templates
Problem 4: No Bundling
Problem 5: No Standard
The Solution: Web Components
I'll warn you, these technologies aren't yet supported in all major browsers at the time of this recording, so throughout this course I suggest using Google Chrome to test out the components that we create. Google took a leading role in the Web Component spec, so Chrome was the first browser to boast full native support for Web Components. While other browsers may have caught up with Chrome by the time you're viewing this course, I suggest using the latest version of Chrome throughout this course to assure that the demos we're walking through work for you. To keep track of the latest status of Web Components support, check out Jon Rimmer's website at this URL. As you can see, at the time of this recording all of the four core pillars of Web Components are fully specified and supported natively in both Chrome and Opera, and they can be polyfilled for use in all modern browsers using the webcomponents.js polyfill library. We'll discuss this polyfill library briefly in module 7. As you can see on this chart, the webcomponents.js polyfill adds support for all four of the core Web Component technologies to today's modern browsers. In addition, there are interesting libraries that make it easier and faster to create web components like Polymer and X-Tag. But before you learn these libraries, it's important to learn the native specification that we're exploring throughout this course first. I'll use an analogy to help explain why.
Why Learn Web Components First?
Selecting a Level of Abstraction
So before we dive in, let's consider what level of abstraction makes sense when creating Web Components. My short answer, any level, low level to entire app, yes, you can encapsulate an entire application into a web component, and that component could of course be composed of many smaller components. So imagine you created a billing system application. You could create a component that encapsulates the entire application if you like. Since it's a billing application, perhaps you'd decide to prefix all your custom element names with the word bill. So you could call the component that delivers the application, bill-app, and that component could compose together more granular components that handle smaller pieces of the app, maybe bill-header and bill-body, and that header might be composed of a navigation bar and an avatar of the currently logged in user, you get the idea. Now you certainly aren't obligated to make your entire app into a single component. You might simply find Web Components useful for creating very small reusable components, like search inputs, tab navigation, or other small reusable pieces of interface. There's no right answer here, but think carefully about the level of abstraction that is useful for your project. When you start thinking about the web as a nested set of components, it starts to really change the way you write your markup and compose your pages. Here's an Author page, oh, it just happens to be mine, nice, okay. So what components do we see here? Well, there's a header across the top, and that header is really helping integrate two separate sites, Pluralsight and Digital Tutors, so this could be an integration-header element. Jumping down here to the list of courses, each of these could be a Pluralsight course-listing component, and that component might have attributes like Course Level, Date, and Rating. Of course, some of these components are complicated and would warrant their own component. You can imagine the Pluralsight star-rating component could be composed within a Pluralsight course-listing component, and this entire page could be wrapped up as an author-page component. You could just set an author attribute on the author-page component, and it would make the call to retrieve the information that you need. It's, of course, not required, but this is just an example of how high-level you could go if desired. And since you can compose components within components, deep nesting is a practical option to consider.
The Dawn of the Democratic Web
In summary, I believe Web Components will democratically grow the web from the bottom up. We're moving control over the future of the web from a small group of people who work within standards bodies like the W3C and the Web Hypertext Application Technology Working Group, and instead empowering every developer to create ever more powerful components for building the web. Web Components get around the bottleneck of waiting for standards organizations by giving web developers the power to introduce new declarative elements. We're going to see communities rally around components, and major existing component vendors like Telerik and ComponentOne are likely to release Web Component based versions of their existing components. In this new world, GitStars and downloads will measure interest in specific components, and will likely be considered by standards bodies for determining which components should be considered for becoming native HTML elements in future versions of the HTML specification. And since standards bodies will consider the interest in existing web components when deciding which elements should be added, future web browsers are likely to provide native alternatives to components that become very popular. Web Components will create a rich feedback loop, where standards bodies regularly consider which of the most popular web components should become native element. This should produce a bright future where web application developers enjoy ever more powerful solutions with less boiler-plate configuration and complexity.
Summary: Why Web Components?
So bottom line, why Web Components? Well, Web Components will make our markup easier to read, navigate, and understand. It will help replace generic tags like divs and spans with higher level and more descriptive markup that's easier to navigate and maintain. We'll no longer have to start from the beginning on each new project. We can easily leverage components created during previous projects, and reach out to the community to leverage existing components as well. Web Components honor the Unix philosophy. They emphasize building simple, clear, modular, and extendable code that can be easily maintained and re-purposed by developers that aren't the initial creators. When bugs are found in our components, it'll be easier to replace and upgrade the code, since it'll be properly bundled, encapsulated, and centralized. And since we're more likely to share and reuse each other's components in the future, more developers will use each line of code, which should help reduce the number of bugs that are in our components. And since HTML Imports make it so easy to import a bundle of dependencies, we're less likely to struggle with integration problems on our projects. We'll simply add a single line to the top of our file, and get everything we need to run the component on our page. Finally, the API for interacting with the components that we create will be much clearer than today's compromised solutions. The components will feel native, which should greatly reduce the learning curve when picking up new components that you haven't seen before. As we're about to see, HTML5 Web Components usher in a new exciting era in web development. They're going to dramatically change the way that we build web apps, and I believe Web Components mark the biggest change in a web developer's fundamental toolset since around 2005 when the term AJAX was coined. And yes, I know that's an audacious statement. The componentized web is going to radically increase the speed of innovation and web development by empowering us to create and share ever more robust components to build rich web applications. Web Components removes standards organizations as a bottleneck to innovation, by empowering individuals to create the tags that they need today. It's a bright future, so let's get rolling.
Hi, I'm Cory House with BitNative Consulting and in this module on HTML5 Web Components, we'll discuss the first of four core new technologies for building web components, and that's Templates. Templates aren't a new concept. You're almost certainly already using a templating solution today to build web applications, and in this module we'll quickly discuss the existing templating strategies on both the client and the server. Then we'll explore the new HTML5 Template tag and see how it finally provides a formal, inert, and standards-based approach to storing reusable snippets of markup on the client. We'll review examples of activating templates, injecting data into templates, and also learn how to handle nested templates. So, there you go, that's the Template for this module. I'd like to apologize, that was an awful pun, I should probably cut that. Okay, let's get rolling. I'm sure you already understand what templates are. They're a way to define a preset format for reuse, and all sorts of server-side technologies offer a template-like solution. HAML is popular if you're in Ruby or PHP. If you're in ASP.NET MVC, then the Razor View Engine is a popular templating option. Python developers are likely familiar with Django, and Node developers often use Jade. The point is, there's a huge number of server-side solutions for templating. These days it's becoming increasingly common to render the UI on the client, but up until now the web has offered no standardized support for defining templates that are parsed on the browser. As we discussed in the introduction, today we have simple and elegant ways to reference assets that help us build web apps. We use the