A year ago, I was on a quest to eliminate our usage of PolymerElement and replace it with LitElement or Vanilla via HTMLElement (oddly the year before that it was moving from Polymer 1.x to 3.x). This year, at about the same time, we're now gutting all references to the @polymer series of elements that helped us get to where we are today.

What started with a simple thread pull of "I'll just remove all our usage of paper-button" kicked my OCD into overdrive and now has us on the edge of replacing every reference. I'm currently in the process of eliminating iron-ajax and paper-dialog (dialog will take the longest). We've got a long road ahead and this is just in our core element group for now (legacy apps will be a mix of upgrade or just leave it be, HAXcms will move a bit slower in theme layer).

I wanted to kick off a series about the quest to remove these pieces because it illustrates one of the more powerful aspects of web components - Progressive decoupling. But not the kind you might be thinking of. In this instance, I'm referencing the decoupling, one piece at a time, from an old library, element or way of thinking.

Web components offers us an abstraction or pointer to the guts of a file to replace the contents of something on the page. When viewed this way, the browser and endpoint application no longer cares what's in the element, just that it has a definition.

This sees us through the following pattern in our life-cycle

• 2017: Debate really hard about the name of something. Land on the need for a tag called video-player to handle all our video needs
• 2018: launch the tag using Polymer 1.0 and the HTML Import spec (which is now defunct). Roll this out into all our applications, in twig and other template engines, CMSs, etc.
• 2019: Replace all Polymer 1.0 with Polymer 3.0 + the actual JS modules spec for building a web components application. Our end points didn't change, just how they got fed the definition.
• 2020: Replace all paper-checkbox, paper-slider, paper-progress, iron-icon, etc tags with our own versions or vanillaJS input elements. No end point changes, no application changes, just the interns of the video-player tag.

In all 3 years of this life cycle example, we've shipped an identical designed player yet the guts and how it got there changed. This seems subtle, but we have the video-player on a CDN now with a single line integration to implement (read more about it here). That means we can sustainably update definitions across all of our properties without a good understanding of the places they are deploys.

In the series to follow I'll talk about different elements along the way and how we got rid of iron / paper tags while simultaneously improving our usage conventions. This will be a mix of video and writing and code examples. Enjoy!