Preface - Developing Web Components (2015)

Developing Web Components (2015)


Why We Wrote This Book

Web development has not stopped evolving since I stumbled into the field over 13 years ago. If anything, the rate at which it is evolving is increasing. If you take a look at the investment that Google has made in Polymer and web components, it is probably safe to bet that web components will play a large role in web development in the near future as browsers implement more support for them. There are still some issues that need to be addressed, such as search engine optimization (SEO) concerns, but I do not think web components are going away, and I don’t think this is bad. The introduction of web components (or a similar standard for extending, packaging, encapsulating, and importing discrete UI components) is long overdue in web development. Even if you do not put all your stock in web components—for example, lifting back the curtain and seeing how the Great Oz accomplishes his UI wizardry, making an element draggable—they can be very useful.

Glenn Vanderburg said, “Developers should always understand one layer of abstraction below their everyday work.” I agree with this statement, and I would argue that widget libraries, jQuery plugins, and even jQuery are the levels of abstraction at which most frontend engineers operate on a daily basis. The level just below that consists of the DOM manipulations these libraries perform, and the DOM and its native APIs. Understanding precisely what these libraries are doing will enable you to write more efficient code on a daily basis and prepare you for the great awakening.

Inevitably, there will come a time when one of these libraries does not fit nicely into the use case with which your product manager or information architect has gifted you—at which point, you either sink or swim. I for one would have preferred to have some swimming lessons before my day arrived, but I was not that fortunate.

I was tasked with making a fixed-width portal product fluid-width, and all of the portlets resizable. Sounds easy, right? I was informed that this had been attempted more than once before, and that previous developers had failed and said it was impossible. Well, that was encouraging. On top of this, Internet Explorer 9 had just hit the market, and due to technical debt we were running three different versions of jQuery and two different versions of jQuery UI, none of which worked well with IE9. So, before I could even start the resizing work I had to move to a single version of jQuery and jQuery UI that played nicely with IE9. You might think that moving to a single version of each library would be a simple process, but I quickly realized why we had accumulated the massive technical debt. We were running a myriad of jQuery plugins ranging from bad to awful in quality and old to ancient in web time. In addition to breaking our code, the upgrade broke the majority of these plugins. This required upgrading and patching several plugins, and replacing others. This in turn involved an intimate knowledge of the DOM, which I did not have. I console logged, reverse engineered, and consumed Stack Overflow until I had solved every problem. This was all before I could even get started on the column resizing and portlet changes.

Next, I got some ridiculous requirement that the portlet column resizing had to look precisely like a mock that had already been approved. It also had to behave just as the approved specification described. There was not a plugin in existence that would meet these requirements. Marvelous. I got to write my own.

Once I had that spaghetti code written, I had to make all the portlets and every widget resizable. All of these events had to be timed properly, and nothing could spill out of containers while resizing. setTimeout and I began a love affair that still continues to this day.

If you can relate to this story, then you likely have your own. If so, like me, you probably hacked something together that was a hodgepodge of Stack Overflow responses and miscellaneous jQuery plugins held together by some glue code you wrote that have 100 different branches to account for all the anomalies that occurred due to your lack of understanding. I have been there, and it is not fun. This experience is why I wrote this book.

In addition to not drowning, there are some other benefits to understanding how the lower-level parts of UI components function:

§ It allows you to define an API that makes sense to you—jQuery plugins are not everyone’s cup of tea.

§ It gives you full control over the entire stack, which makes debugging easier and allows you to decide at what layer a change should occur.

§ It allows you to decide which features are important and to limit your footprint in cases where file size is of great concern (e.g., mobile applications).

§ It allows you to make optimizations that fit your applications and use cases.

Lastly, I think that it is every frontend engineer’s job to understand the DOM and vanilla JavaScript. This understanding, and the ability to design solutions, is what sets frontend engineers apart from frontend developers.

What This Book Is

The primary goal of this book is to provide the foundational knowledge required to develop and deploy web components. It is intended to be an introduction and to inspire, not to be an exhaustive resource on the subject matter. This foundational knowledge has been divided into four parts, preceded by a general introduction to web components and the areas we will tackle in this book. Each of these sections and their chapters will build upon a working code example.

Part I, UI Core Concepts

The first part covers core concepts such as cloning nodes, rendering layers, stacking contexts, and z-index that are necessary for understanding how to properly position, drag, and resize elements. These concepts are often misunderstood or only partially understood, which can lead to poor design decisions and implementations. These poor decisions can have a significant impact on the performance and maintainability of your code. If you already have a firm grasp on these concepts, then feel free to skip ahead to Part II.


The base class component and the dialog component that are used throughout the rest of the book are introduced in Part I. If you skip ahead and later decide that you would like to learn about the design and implementation details, then refer back to Chapter 2.

Part II, Building Our UI

The second part provides an introduction to concepts and patterns that are typically abstracted away from day-to-day frontend development by libraries such as Dojo, jQuery UI, Kendo UI, and Twitter Bootstrap. These concepts and patterns are used to implement UI components that you probably work with on a daily basis as a front-end engineer. The benefits that these abstractions and UI components provide cannot be understated. I highly recommend leveraging a base library such as jQuery UI that provides good life cycles, extension points, and access to utility functions and helper classes. If you need a more lightweight foundation you can explore using jQuery++, which provides APIs for dragging, dropping, resizing, etc. in a single 162 KB file. It also allows you to cherry-pick features, further reducing the file size.

A practical application of these concepts and patterns is illustrated by the continuation of the dialog component that was introduced in Part I.

If you are already familiar with these patterns or you would prefer to dive right into the meat of web components, then start with Part III.

Part III, Building HTML5 Web Components

The third section provides an introduction to web components as defined by the World Wide Web Consortium (W3C) and implemented by browsers. This section takes the working example built in and and converts it into a fully functioning web component.

Part IV, Testing, Building, and Deploying Components with Polymer

The fourth section covers how Google’s Polymer bridges the web component implementation gaps in today’s browsers and provides convenient APIs for creating extendable web components. It then guides you through converting your web component from Part III into a Polymer component. Finally, it shows how to package and deploy the raw web component and the Polymerized version using different package managers.

What This Book Isn’t

The intent of this book is not to be the definitive guide for developing web components across the entire spectrum of devices used to access the Internet. That would be an impossible endeavor, for two key reasons.

First, the capabilities of the browser have increased significantly in recent years, and the Internet has transformed from a document delivery mechanism into a quasi application platform. This transformation has made the browser a much more robust and feature-rich platform than I ever imagined possible back when I was using tables to lay out pages and testing them in Netscape 4. There are now many new techniques for achieving what would have been spectacular feats of JavaScript pixel pushing using CSS alone. These native features continuously evolve, but are adopted at differing rates by browser vendors. Implementation varies across browsers as well, because browser vendors base their implementations on their own interpretations of the W3C specifications. These features are very relevant to web component development, but this brave new browser world is a book topic in its own right. Inclusion of this level of detail is out of scope. While it is very relevant, it is not required for web component development.

Secondly, the number of device types and vendors—smartphones, tablets, phablets, etc.—has increased significantly over the past five years. This proliferation of new devices and manufacturers has reintroduced limitations that we assumed were issues of the past: limited processing power, limited memory, smaller form factors, poor network connectivity, etc. This influx of new devices has impacted web development in interesting ways, and introduced new concepts such as responsive design and adaptive design. They have also introduced new interaction patterns, such as the touch event and gestures. All the devices have their own sets of quirks. The new and expanding mobile market is a field of its own within the web development world, though, and too deep a topic to include here.

Trying to account for these complexities and others in web development when authoring a book of this nature is simply not feasible. The book would be larger than The Art of Computer Programming and out of date before the first chapter was complete.


In addition to issues relating to the number of devices on the market and varying device capabilities, it is equally import to note that the W3C Web Components specification is a working specification. As a result, information contained in this book will likely become dated and require the publication of new editions as the specification is finalized. A best effort will be made to follow the specification as closely as possible.

Conventions Used in This Book

The following typographical conventions are used in this book:


Indicates new terms, URLs, email addresses, filenames, and file extensions.

Constant width

Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.

Constant width bold

Shows commands or other text that should be typed literally by the user.

Constant width italic

Shows text that should be replaced with user-supplied values or by values determined by context.


This icon signifies a tip or suggestion.


This icon signifies a general note.


This icon indicates a warning or caution.