Chapter 1. Introduction
Oh, good, you’re here! Welcome! We hope you’re in for a fun ride. If you’re the type of person who skips the prefaces of books, we need to go over something real quick: this book is set up in a way that takes you through basic widget creation from a jQuery background and then translates that knowledge and understanding first into the world of web components, and then into that of Polymerized web components (web components created using the Polymer framework).
Web components are on the bleeding edge, barely supported in the most modern of modern browsers, and we have a fair way to go before people start falling into generally accepted best practices. The Polymer group is leading the way, with Mozilla having its own spin, and individuals in the community are adding in their own opinions as web components start being adopted in real-world applications.
In this environment, we felt that the greatest tool that we could put in the hands of developers interested in web components was an understanding of how to develop facets of the user interface (UI) in a reusable manner that can also translate directly to web components if (and when) you decide to use them.
What Are Web Components?
What does that even mean?
Well, if given the task of implementing a
<p> tag just describes a set of styles and then maybe write a
<div> with some inline style, or maybe a
p class that groups paragraph styles together.
Now how would you implement, say, a
<select> tag and its constituent list of
Further down that same path, how would you implement the
<video> tag? This starts getting dicier and dicier, and these are the types of problems that web components technologies seek to solve. They don’t go all the way, but they give developers a standard way to encapsulate, protect, and package these concepts.
Even if you don’t think web components are the bee’s knees (which they are, to the extent to which a bee’s knees could possibly make web development a lot more satisfying and exciting), the constituent technologies are all independently useful and will undoubtedly find their way into frameworks like Angular and Ember, so they are worth being aware of and understanding.
What’s intriguing about web components is that the bulk of it is maddeningly obvious. Two years after you buy into web components whole hog, you will look back at the twenty-aughts as this primitive time filled with Neanderlithic frameworks and “best practices” that involved putting whole string templates in
<script> tags. When recalling this era of development to your grandchildren, they will look at you with skepticism and ask disbelievingly, “Gramps, did you really not have native templates in your DOM or are you just yanking our chains?”
And you’ll say: “It’s true, sweet Becca and little Johnny—now go play with your robots and don’t touch my space bike.”
Following is a rundown of some of the key areas we’ll be exploring in this book.
HTML templates are the simple embodiment of a templatized, inert Document Object Model (DOM) that can be stamped out and reused over and over again. Before the
<template> tag, there existed any number of ways that you could reuse HTML. You could write your own functions that created and populated DOM nodes directly via DOM methods, you could retrieve text stored in the DOM via
innerHTML and run that through a template engine, you could “precompile” templates in the build phase and send template functions, or you could choose some other equally uncomfortable method.
Now it’s all over. There is one way to write reusable HTML. Its usage can certainly differ, but one thing’s for sure: you’re going to be writing your templates and partials in
<template> tags from now on.
The HTML import is another foolishly simple concept that accommodates a single interaction point for independent bundles to be loaded by. What has already been done for
<style> tags has now been done for HTML itself. The bonus, on top of what was done for scripts and styles, is that the imported HTML can then infinitely link to all its own dependencies in the same formats that already exist. This will allow a developer to include miniature applications and all their dependencies with a single
@include, instead of tracking everything down and including all the sources or links directly.
Finally! There now exists a standard way of generating custom elements across framework, platform, and all other boundaries. The core of HTML, the single element, is now open to everyone. The custom element API is incredibly trivial, and it’s meant to be. This is the first step to building HTML into what our apps have always wanted to be. This is about far more than simply creating new textual tags; it’s opening up a strict API touchpoint that everyone is inherently familiar with. It’s a contract that is already agreed upon, tolerated, and enjoyed by every web developer that exists.
The Shadow DOM
The shadow DOM is the secret sauce to web components. Each other technology on its own provides value that is obvious and appreciated, but the shadow DOM is the icing on the web component waffle. It finally provides a way for us to isolate portions of the DOM for true protection from styling, access, and modification via common means. For anyone who has ever tried to build reusable UIs, this is a welcome change that could nearly bring a tear to the eye of the most jaded developer.
Combining each of these things, we have the ability to generate custom elements, generating their own subtrees that are isolated from the parent DOM, all importable via a single tag!
If we sound excited, it’s because development with web components is like breathing fresh air after being in a coal mine for two decades. Like standing up after 50 pounds of weight have been removed from your back. It’s a freedom that is welcome and genuinely exciting.
Why Web Components?
The Web is in a transitional state, and has been for quite some time. It was originally designed to view documents—that’s why the applications we use to sift through its contents are called browsers! Since its inception, though, the Web has been slowly morphing into an application platform, radically transforming the software development landscape. It has never been easier to release a new version of an application: a developer pushes code changes or new assets to a server, and the end user refreshes the page (as someone once said, a page refresh is the “compile” of web development). Unfortunately, the browser has not kept pace with this revolution, forcing developers to come up with clever solutions to make the Web more of an application platform.
Module loaders such as Require.JS have also helped greatly, providing more structure by supplying the equivalent (and more) of the missing
If you step back and look objectively at the current state of web development, it is really a giant hack—but that has been changing in recent years.
The fact that it is a hack, in a sense, is not altogether bad. It has provided a sense of freedom that other platforms and languages lack. Irritating as it can be at times, it’s hard to imagine developing in a more restrictive environment.
The emergence of HTML5 and newer APIs is evidence of a great attempt at turning the Web into a real application platform. However, it is still missing some important features that are in most other application platforms.
For instance, the Web is not extensible. You cannot create new types of elements or extend existing ones, and there are no imports or methods for encapsulating components. Enter web components.
What if you could create a dialog component simply by importing the resource and declaring meaningful markup?
>Ending is better than mending.
/>The more stitches, the less riches.
That would be a huge improvement in terms of readability over the current standard:
<!-- based on http://jqueryui.com/dialog/ -->
>Ending is better than mending.
/>The more stitches, the less riches.
This is not to say that current widget libraries do not have anything to offer or that their patterns are flawed. In fact, they are still quite relevant given the current browser support for web components. Additionally, the web components specification alone is not a panacea for creating rich user interfaces. A dialog component would still be driven by the same code as a dialog widget. However, the dialog component would wrap the widget code in a simplified, standardized, native interface with a convenient method for including its dependencies.
While this might not sound like a vast improvement, the ability to extend, abstract, import, and encapsulate natively will make the development of web applications much easier. It will allow developers to create reusable elements with standard life cycles that can be imported by any application. This standardization will form an implicit contract between the elements and the application, making the creation and management of interfaces a much smoother process.