Web components enjoy large-scale usage today. From YouTube to GitHub and many other major organizations, its safe to say theyve made their way into commonplace frontend development practices.

That wasnt always the case. After all, web components had to start somewhere. And web development can be particularly picky with what succeeds and what doesnt.

So then, how did web components succeed? What was their path to broad adoption? And what are the origins behind the APIs used for modern web components?

Lets walk through a short history of web components and the related ecosystem to answer these questions.

2010: The Early Days of MVC in JS

While the concept of Model View Controller, also commonly called MVC, has been around for some time, in JavaScript itself it failed to take hold early on.

However, in 2010, there was an explosion around MVC and its related cousin: Model View View-Controller (MVVC) ). This explosion came courtesy of a slew of new frameworks that launched only a few months apart from one-another.

Knockout was one of the first to introduce strict MVC patterns inside of JavaScript in July 2010. Knockout supported observable-based UI binding. Here, you could declare a Model, and bind data from said model directly to your HTML.

<!-- Demo of KnockoutJS --><table class="mails" data-bind="with: chosenFolderData">    <thead><tr><th>Subject</th></tr></thead>    <tbody data-bind="foreach: mails">        <tr><td data-bind="text: subject"></td></tr>    </tbody></table><script>function WebmailViewModel() {    // Data    var self = this;    self.chosenFolderData = ko.observable();    $.get('/mail', { folder: 'Inbox'}, self.chosenFolderData)};ko.applyBindings(new WebmailViewModel());</script>

While this works great for UI binding, it lacks the componentization aspect weve come to expect from modern frameworks.

This was improved in the ecosystem when Backbone saw its first release in October 2010. It introduced a View, similar to what we might expect a component to be like today.

var DocumentRow = Backbone.View.extend({  tagName: "li",  className: "document-row",  events: {    "click .icon":          "open",    "click .button.edit":   "openEditDialog",    "click .button.delete": "destroy"  },  initialize: function() {    this.listenTo(this.model, "change", this.render);  },  render: function() {    ...  }});

Here, we can see that we can now bind events, classes, and more to a single tag. This aligns better with the types of components wed see in, say, React or Lit.

But thats not all we saw in October that year. We also saw the initial release of Angular.js only 10 days after Backbones release.

Here, we can see that it introduced a concept of controllers into the document, similar to the Models of Knockout. It allowed two-way bindings from UI to data and back.

<div ng-controller="TodoListController as todoList">  <ul>    <li ng-repeat="todo in todoList.todos">{{todo.text}}</li>  </ul>  <form ng-submit="todoList.addTodo()">    <input      type="text"      ng-model="todoList.todoText"    />    <input class="btn-primary" type="submit" value="add" />  </form></div><script>  angular    .module("todoApp", [])    .controller("TodoListController", function () {      var todoList = this;      todoList.todos = [        { text: "learn AngularJS" },        { text: "build an AngularJS app" },      ];      todoList.addTodo = function () {        todoList.todos.push({ text: todoList.todoText });        todoList.todoText = "";      };    });</script>

While Angular was the last of the three mentioned here, it had a huge impact. It was the first time Google released a JavaScript-based MVC based library into the wild.

Not only did they build the library, they used it to build Googles Feedback tool - which powers almost all of Googles products today. This represented a shift from their prior Java-based Google Web Toolkit (GWT) that was widely used before.

Later, with the , the team that was working on the migration of the DoubleClick platform for Google decided to use Angular.js as well.

2011: A Glimmer in W3C Standards Eye

With Angular.js continuing to grow within Google, its no surprise that they continued researching in-JavaScript HTML bindings.

On this topic, Alex Russel - then a Senior Staff Engineer at Google, working on the web platform team - gave a talk at the Fronteers conference.

In this talk, he introduces a host of libraries that allow building custom elements with experimental new APIs.

<script>class Comment extends HTMLElement {  constructor(attrs = {}) {    super(attrs);    this.textContent = attrs.text || lorem;    this.shadow = new ShadowRoot(this);    this.buildUI();  }  buildUI() { ... }}HTMLElement.register('x-comment', Comment);var c = new Comment("Howdy, pardner!");document.body.appendChild(c);</script><x-comment>...</x-comment>

Here, he utilized the TraceUR compiler (a precursor to Babel) to add classes (remember, class wouldnt land in JavaScript stable until ES6 in 2015) to build a new custom element.

This combined with their new MDV library in order to create a similar development environment to what we have in browser APIs today.

Its important to note that at this stage, nothing was formalized inside of a specification - It was all experimental libraries acting as playgrounds for APIs.

That would change soon after.

2013: Things Start Heating Up

In early 2013 the Google team created a Working Draft of a specification for Custom Elements. Alongside similar working drafts for Shadow DOM APIs, they were colloquially called Custom Elements v0.

With Google Chromes release in 2008, they had the ability to quickly implement these non-standard APIs into Chrome in order to allow application developers to utilize them before specification stabilization.

One such example of this was Polymer, which was a component library based on v0 APIs to provide two-way UI binding using MVC. Its initial alpha release was announced in early 2013, alongside the specifications.

At Google Dev Summit 2013, they walked through its capabilities and how it was able to run in other browsers by utilizing polyfills.

Facebook, not one to be outdone on the technical engineering front, introduced React into public in 2013

While Polymer went deeper into the MVC route, React relied more heavily on unidirectionality in order to avoid state mutations.

2016 & 2017: Formative Years

While only the year prior, Polymer 1.0 was released with the usage of v0 custom element spec, 2016 saw the release of the custom element v1 specification.

This new version of the specification was not backwards compatible, and as a result required a shift to the new version of the specification in order to function properly. Polyfills were continued to be used as a stop-gate for browsers that didnt have a v0 implementation.

While v1 was already implemented into Chrome in late 2016, it wasnt until 2017 with the release of Polymer 2.0 that it would be adopted back into the library that helped draft the specification.

Because of this, while YouTubes new Polymer rewrite theoretically was a huge step towards the usage of web components, it posed a problem. Browsers like Firefox without a v0 implementation were forced to continue to use Polyfills, which are slower than native implementations.

2018 and Beyond: Maturity

2018 is where Web Components really found their foothold.

For a start, Mozilla implemented the v1 specification APIs into their stable release of Firefox, complete with dedicated devtools. Finally, developers could use all of the web components APIs in their app, cross-browser, and without any concern for non-Chrome performance.

On top of that, Reacts unidirectionality seemed to have won over the Polymer team. The Polymer team announced that it would migrate away from bidirectional binding and towards a one-way bound LitElement

That LitElement would then turn into a dedicated framework called Lit, developed to replace Polymer as its successor, that would hit v1 in 2019 and v2 in 2021.

Timeline

Whew! Thats a lot to take in. Lets see it all from a thousand foot view:

• 2010:

  • Knockout.js released
  • Backbone.js alpha released
  • Angular.js made open-source

• 2011:

  • MDV (Polymer predecessor) introduced at a conference

• 2013:

  • Working draft spec for Web Components (v0) released
  • Polymer (Googles web component framework) announced
  • React open-sourced

• 2015:

  • Polymer 1.0 released

• 2016:

  • Custom elements v1 spec released
  • YouTube rewritten in Polymer

• 2017:

  • Polymer 2.0 released

• 2018:

  • Polymer announces start of migration to LitElement
  • Firefox enables web components (Polyfills no longer needed)

• 2019:

  • Lit framework 1.0 released

• 2021

  • Lit 2.0 released

Conclusion

In the past 10 years weve seen massive changes to the web development ecosystem. No more is this more apparent than the development and continued growth of web components.

Hopefully this should put any future learnings about web components and framework comparisons into perspective.

Weve waited a long time to see many of these ideas fully standardized into the web platform, and, now that theyre here, theyre helping accelerate growth of many platforms.

Want to learn how to build them yourself?

We have articles about how to build web components without a framework as well as using Googles Lit framework.