WebComponents vs Framework Specific Components
Why generic components are a much better investment
Contents
Introduction
We’ve all seen and used them, we may even have written some ourselves. They seem such a great idea at the time and using them seems to make life easier. I’m talking about Framework Specific Components.
I want to talk about why WebComponents are much better and they should be the first think we look to use and create whenever possible.
What I mean by framework-specific is a component that is written specifically to fit into a framework. So instead of a date picker, you have a jQuery date picker and an Angular date picker and a React date picker and [insert every framework imaginable] data picker.
Of course there is a good reason for it. The framework comes with utilities that are convenient to use and the component author wants to make it easy to consume which usually means creating an API to match the caller - the framework code. That’s the trouble with frameworks.
I’ve done it myself - as part of switching from Angular 2 to Polymer I began by splitting off component pieces and turning them into Polymer elements, reusable components that I could use in both codebases to allow for a gradual migration. It was a great learning experience as well as a productivity boost.
Polymer is a great library and very small and definitely makes it easier for components to be re-used in other frameworks. But I’ve realized more and more lately that some of these components were Polymer based just because it was convenient, not because they really needed to be.
It was especially apparent when I wanted to re-use some pieces to update an older server-rendered site containing Angular 1 code. Do I really want to have to load the Polymer runtime, however small on each page request, if I could avoid it? It’s not just bandwidth remember, it’s all the JavaScript that has to be parsed. It all adds up.
So I’ve taken a fresh look at some of the elements I’ve created along the way - a masonry-like grid layout element, a time-ago relative date element, a ShadowDOM-friendly lazy-image loading element (using IntersectionObserver) and so on. Few of them really needed to directly rely on Polymer, I just tended to consume them from Polymer but I’d fallen into the trap of convenience.
I’ve spent the last couple of days converting some of these elements to be pure WebComponents and it’s been a great experience. All Polymer needs is a HTML element file containing a <script> tag to load the element and they can be dropped into projects with no changes and work as before. I’ve been using them as part of my Polymer 2 app upgrade work.
But now they truly are re-usable and should work in any web framework with no runtime whatsoever other than the platform that is built into the browser (well, as long as the browser is Chrome or Safari - others still need a Polyfill until they catch up with their support which is planned).
The resulting code has always been smaller and lighter and the idea that they don’t rely on any framework is liberating and should extend their life as well. It’s possible that the WebComponent specs might evolve in the future but they already switched from v0 to v1 so the “experiment” phase is over. Browser development tends to be slower and more deliberate than the wild world of JS web frameworks because support for the platform has to live for much longer, possibly decades (part of why the web is such a phenomenally successful platform).
Just think, what happens to all the jQuery, Angular, React or whatever other framework specific component over time? What happens when you decide you’d like to switch frameworks or even just upgrade to a newer version - are they a help or a hindrance? Is it better to have different components for each framework or a single component that can work for all?
WebComponents are simply a better solution to doing ‘components’ because they remove the framework dependency and that is a good thing.
Of course some people are always going to look for a framework-specific version of something and there’s nothing wrong with creating a wrapper or adapter to make consuming an element more convenient within a specific framework. Just think about not making it the only option.
