As many developers have likely heard, Web components are the next big thing in the developer world. And now that a complete Web components implementation landed in Chrome 36, users finally have a much more stable, unprefixed, unflagged version to try and test out. Unfortunately, even this solution will not allow for easy-to-implement components for production applications... at least not yet.
If the above hasn't scared developers away (and it shouldn't!), there are several issues to be aware of when using Web components in production. And yes, there are also several key tips provided to help solve them.
One of the biggest reasons that many developers have avoided Web components is the lack of browser support. Although Web components have now landed in Chrome 36, they really only have partial support in Firefox, and they are not present in Safari or IE. Since cross-browser support won't be possible for a significant amount of time, a user could try using a polyfill as a long-term fix for outside of Chrome.
Also of note, the Polymer team maintains a complete set of polyfills collectively known as "The Platform," but although Polymer's official documentation makes it seem like getting cross-browser Web components support is as easy as including webcomponents.js, things aren't quite that simple.
Although developers tend to think of all polyfills as just another polyfill, the complexity of the implementations can vary widely depending on the technology being polyfilled. For example, APIs that are syntactic sugar for existing APIs tend to be the easiest to implement. However, APIs that add entirely new behavior, or that include CSS syntax changes, tend to be more difficult to write. Some technologies are harder to polyfill than others but why is this relevant?
Well, as it turns out, polyfilling Web components is the king of all polyfilling challenges. Simply put, writing a Web components polyfill is absurdly difficult, and the inherit complexity has non-trivial implications on the viability of using Web components polyfills in production.
Coding efforts to leverage Web components In JavaScript are extremely complex. The Web components specification aims to give hooks into browser internals, so it makes sense that it's nearly impossible to replicate that functionality in JavaScript. Given this, the job the Google did with the platform polyfills is extraordinary.
But, given that Google has already done the hard work, why should a user care about how difficult it was? Because the complexity has several adverse effects on the feasibility of using these polyfills in production. Let's look at each of these issues in turn.
The first issue is Polymer's polyfills do not support all the functionality that Web components offer (most notably shadow DOM). Take for example, the 38-block of regular expressions, below, where this is the case (most notably shadow DOM). According to the source, "The intention here is to support only the styling features which can be relatively simply implemented. The goal is to allow users to avoid the most obvious pitfalls and do so without compromising performance significantly."
Although some disagree with Google's interpretation of "relatively simple," people understand the sentiment here, as truly polyfill-ing all of shadow DOM would require rewriting CSS in JavaScript, and even Google agrees that goes too far. From a developer's perspective the problem is that it's hard to know what will and what won't work.
The next issue is sheer file size. As of version 0.3.3, the platform polyfills comprise 151K of JavaScript, 44K gzipped. If a user chooses to use Polymer on top of the polyfills, they can add another 66K, 20K gzipped. For comparison, people complain incessantly about the size of jQuery, which is 29K gzipped.
Polymer does do a good job of separating the polyfills into separate modules so a user can pick and choose the ones he or she needs, but in practice almost no one actually does that (the one exception being Mozilla's X-Tags library).
Beyond the overhead of shipping the polyfills across the network, there's also the time it takes for the browser to parse and interpret the JavaScript code, which is a known performance bottleneck on mobile devices.
One performance issue worth specifically noting here - because many have stumbled across this - is the numerous requests generated by HTML imports. The idea behind HTML imports is great: a single .html file that contains everything he or she may need. As such, it's relatively common to see an HTML import that depends on several other resources, each of which must be resolved over HTTP.
In browsers that support HTML imports natively, the browser can resolve these resources using parallel connections - this works great in Chrome, but in all other browsers when HTML imports aren't natively supported, polyfills must resort to queued up XHRs.
The good news is that as some tooling is emerging to aide with the performance issues like vulcanize, a build tool from the Polymer team specifically for HTML imports. One can pass Vulcanize an HTML file and it outputs that HTML file with all HTML imports inlined, including deep dependencies.
To summarize, here are a few recommendations that would help encourage the adoption of Web components:
Web components without any polyfills perform great in Chrome 36+; it's the polyfilling that causes the issues.
99 percent of published Web components rely on Polymer, which relies on platform.js, which means always downloading 66K of gzipped JavaScript. jQuery doesn't get a free pass for 29K, so Polymer shouldn't get one for 66K.
Overall, Polymer could be better about micromanaging its dependencies and documenting how to do that in third-party components. Shadow DOM is easily the biggest and most complex Web components polyfill, and many components don't even need it - yet, 99 percent of them are downloading and parsing it.
If the Polymer team expects people to use Web components in real apps, then they should start benchmarking the polyfills in the browsers developers need to support, especially mobile ones.
Web components and Polymer are exciting technologies that may fundamentally change the way developers develop Web applications, but like all "new" solutions, the large performance gap between browsers that support the technologies natively (aka Chrome 36+) and those that don't (aka every other browser) will prove difficult for most developers to use Web components until they're implemented everywhere, and there's no way of knowing how long that will be.
All that being said, Web components are here to stay and developers should feel encouraged to use, play and develop with these tools. Challenges are part of the development "game" and together, developers can help advance the sophistication of such a groundbreaking technology.