Why Web Components Matter — Interview with Taylor Savage, Google’s Polymer Project
Onsen UI 2.0 has just been released and Onsen users often focus on building mobile apps. But Onsen UI provides a full-stack ecosystem for developing beautiful cross-platform apps including web development. No matter your focus, we believe strongly in standards-based open source tools like Web Components. This is a fantastic way to future-proof your development environment as JavaScript development continues to expand from web to mobile platforms.
Google has been doing some interesting work with web components with the Polymer Project. Polymer is an open-source JavaScript library for building web applications using custom components. It’s developed by Google as well as contributors on GitHub. We recently interviewed Taylor Savage (@TaylorTheSavage), product manager for the Polymer Project, to ask more about Polymer, what the latest developments are, and what’s the difference between Polymer and Angular.
Polymer 1.4 came out in March. What are the biggest priorities for Polymer this year?
The transition to the v1 versions of the Custom Elements and Shadow DOM specs marks a huge milestone for web components. All major browser vendors have rallied around these specs, and native support is imminent or already shippping in all major browsers. Polymer’s biggest priority for this year is to provide a bridge for current users to build elements against these new specs. This means the ability to drop the Polyfills and cut out a lot of shimming code inside Polymer, leading to a much lighter and leaner library, and the ability to use modern features like ES6 class syntax to create elements.
Polymer adoption inside Google has grown exponentially — there are thousands of unique elements built with Polymer inside Google. Projects like Youtube Gaming, Chrome, Play Music and more have already shipped production apps using Polymer, and many more are not far behind. We use Polymer for all kinds of different applications and many different ways — it is used for productionized, user-facing apps, for large-scale internal apps, for rapid prototyping and UX explorations, and more. Some build top-to-bottom apps exclusively use Polymer, others integrate Polymer elements with a variety of different internal frameworks. The most common use overall, as you might expect, is to build and share components across large and diverse teams working on many different products, so that we can more quickly and efficiently launch user-facing applications and features.
What’s the difference between Polymer and Angular?
Polymer is a standards-based, lightweight sugaring library on top of the Web Component API’s. It makes it easy to build standalone, encapsulated web components, that you can use piecemeal or build entire applications out of. The Polymer Project is part of the Web Platform team here at Google — its driving hypothesis is that by relying more closely on API’s and standards provided by the web platform itself, you can build more efficient and long-term sustainable applications. Angular is much more a top-to-bottom opinionated way to build applications — a “framework” in the common web developer sense. Of course, it is certainly possible to use Polymer-based web components inside of an Angular-organized application.
Polymer and the Web Components specification are standards-based. Can a standards-based approach succeed? What are the biggest challenges in gaining wider usage?
I would argue that ultimately standards-based approaches are the only ones that can sustainably succeed for the long-term, and relying on standards significantly lowers costs overall. There are numerous advantages to relying on standards-based API’s as the building blocks of applications:
Speed
If the user has a modern browser, the standards-based API’s already exist natively directly on the user’s device. In a mobile world, with slow devices and flaky connections, every byte that you download to the user’s device has a cost — using what’s already there inside the browser is strictly better than having to download a completely separate abstraction layer in order to run your application. Even if relying on an abstraction is necessary, abstractions that just lightly sugar native features can be much smaller and faster than ones that invent brand new patterns out of thin air.
Longevity
The “popular” framework is constantly radically changing, but the underlying platform is consistent. An application built on top of the latest hot framework can be old-news within a year. An application built on top of web standards will have a solid foundation for the long-term.
Sustainability
The engineers who built the original application are rarely the ones supporting it years down the line. By relying on standards, you ensure that the foundational knowledge needed to understand how an application is built is also the foundational knowledge of just the web platform in general. New developers don’t have to learn a specific dialect to be productive — they just need to know about the web platform itself.
Scalability & Interoperability
Especially for large projects and companies, it is important to be able to broadly share resources and approaches. Every team targeting the web platform can target a standards-based approach, and it becomes very easy to share and re-use pieces of code built to a standard. It is impossible to efficiently share resources when the individual teams are using non-interoperable stacks.
Increasing efficiency, for free
Even if a user’s browser doesn’t yet support the standard API’s, more and more users will gain this support over time, as browsers implement the API’s natively. Polyfills can be used in the meantime, but they disappear over time.
There are two big challenges I’ve seen for gaining wider usage.
On the browser vendor side, browser support for new standards can be slow. The standards process can take a long time, and it can be challenging for browser vendors to arrive at consensus, and then to ship support natively. This is where developers can really help out — by demonstrating excitement and use-cases for specific API’s, it can help browser vendors prioritize implementations.
On the developer side, I’ve seen a lot of hesitation to rely on polyfills — bits of code that emulate the standards-based feature that can be optionally loaded in browsers that don’t yet support the feature natively. To some, polyfills seem to be an anathema, some extra overhead that is to be avoided. This is the opposite of how we consider polyfills. We think of relying on a polyfill as essentially like relying on a framework — it provides a set of features that aren’t directly in the browser — except that the need to run a polyfill goes away over time, while a framework dependency will be fundamentally required for every user, forever. It’s always smart to profile and measure the performance impact of relying on a polyfill, but we’ve found that in the vast majority of cases the pro’s far outweigh the con’s, especially given that the goal of polyfills is to ultimately cease to exist.
There are many ways to provide feedback and get involved. One way is to provide feedback to the Polymer project though Github issues, Tweets, and emails. We look for trends in our developer feedback, and work with standards bodies and browser vendors to extract out useful new standards.
You can also get involved directly with standards bodies. The web component standards, for example, are worked on in Github, and you can file issues directly if you’d like to provide an idea or feedback.
