Corbin is a senior developer with a passion for helping others. 💜
They're focused on ensuring that learning is open and fun. 🦄
They blog, livestream, code, and more to reach those goals to help others! 💅

Corbin Crutchley


This is a series about web components. I did the most research I could on topic and I hope you enjoy it as much as I did
to write about it!

Worth mentioning that I wrote on behalf of and while under the employment of [CoderPad](https://coderpad.io) and I'd love to thank them
for allowing me to spend time on this.


Learn the history of web components, alongside how to use them with both Lit and Vanilla JavaScript.

Web components enjoy large-scale usage today. From YouTube to GitHub and many other major organizations, it’s safe to say they’ve made their way into commonplace frontend development practices. 

That wasn’t always the case. After all, web components had to start somewhere. And web development can be particularly picky with what succeeds and what doesn’t.

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?

Let’s 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](https://en.wikipedia.org/wiki/Model–view–controller), 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 it’s 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](https://github.com/knockout/knockout/releases/tag/v1.0.0). Knockout supported observable-based UI binding. Here, you could declare a Model, and bind data from said model directly to your HTML.

```html

<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>
```

![A list of emails based on their subjects](./knockout_demo.png)

While this works great for UI binding, it lacks the componentization aspect we’ve come to expect from modern frameworks.

------

This was improved in the ecosystem when [Backbone saw its first release in October 2010](https://github.com/jashkenas/backbone/releases/tag/0.1.0). It introduced a `[View](https://backbonejs.org/#View-extend)`, similar to what we might expect a component to be like today.

```javascript
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 we’d see in, say, React or Lit.

------

But that’s not all we saw in October that year. We also saw the [initial release of Angular.js](https://github.com/angular/angular.js/releases/tag/v0.9.0) only 10 days after Backbone’s release.

Here, we can see that it introduced a concept of controllers into the document, similar to the `Model`s of Knockout. It allowed two-way bindings from UI to data and back.

```html
<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 Google’s Feedback tool](https://www.youtube.com/watch?v=r1A1VR0ibIQ) - which powers almost all of Google’s products today. This represented a shift from their prior Java-based “[Google Web Toolkit” (GWT)](http://www.gwtproject.org/) that was widely used before.

Later, with the [acquisition of DoubleClick](https://www.nytimes.com/2007/04/14/technology/14DoubleClick.html), the team that was working on the [migration of the DoubleClick platform for Google decided to use Angular.js as well](https://www.youtube.com/watch?v=r1A1VR0ibIQ).

# 2011: A Glimmer in W3C Standard’s Eye

With Angular.js continuing to grow within Google, it’s 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](https://fronteers.nl/congres/2011/sessions/web-components-and-model-driven-views-alex-russell).

In this talk, he introduces a host of libraries that allow building custom elements with experimental new APIs.

```html
<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](https://web.archive.org/web/20210311050620/https://github.com/google/traceur-compiler) (a precursor to Babel) to add classes (remember, [`class` wouldn’t land in JavaScript stable until ES6 in 2015](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes)) to build a new “custom element”.

This combined with their [new MDV library](https://web.archive.org/web/20110509081454/http://code.google.com/p/mdv) in order to create a similar development environment to what we have in browser APIs today. 

It’s 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](https://web.archive.org/web/20130608123733/http://www.w3.org/TR/custom-elements/). Alongside similar working drafts for Shadow DOM APIs, they were colloquially called “[Custom Elements v0](https://www.html5rocks.com/en/tutorials/webcomponents/customelements/)”.

With [Google Chrome’s release in 2008](https://googleblog.blogspot.com/2008/09/fresh-take-on-browser.html), 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.](https://web.archive.org/web/20130515211406/http://www.polymer-project.org/) It’s initial alpha release was announced in early 2013, alongside the specifications.

At [Google Dev Summit 2013, they walked through its capabilities ](https://www.youtube.com/watch?v=DH1vTVkqCDQ)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](https://www.youtube.com/watch?v=GW0rj4sNH2w)

While Polymer went deeper into the MVC route, [React relied more heavily on unidirectionality](https://coderpad.io/blog/master-react-unidirectional-data-flow/) 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](https://web.archive.org/web/20161030051600/http://w3c.github.io/webcomponents/spec/custom/).


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 didn’t have a v0 implementation.

While [v1 was already implemented into Chrome in late 2016](https://web.archive.org/web/20161101052413/http://caniuse.com/#feat=custom-elementsv1), it wasn’t 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 [YouTube’s new Polymer rewrite](https://blog.youtube/news-and-events/a-sneak-peek-at-youtubes-new-look-and/) 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](https://web.archive.org/web/20180724154806/https://twitter.com/cpeterso/status/1021626510296285185), 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](https://www.mozilla.org/en-US/firefox/63.0/releasenotes/), 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, React’s 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`](https://www.polymer-project.org/blog/2018-05-02-roadmap-update#libraries)

That `LitElement` would then turn into a dedicated framework called “[Lit](https://coderpad.io/blog/web-components-101-lit-framework/)”, developed to replace Polymer as its successor, that would hit [v1 in 2019](https://github.com/lit/lit/releases/tag/v1.0.0) and [v2 in 2021](https://github.com/lit/lit/releases/tag/lit%402.0.0).

# Timeline

Whew! That’s a lot to take in. Let’s see it all from a thousand foot view:

- 2010: 
  - [Knockout.js released](https://github.com/knockout/knockout/releases/tag/v1.0.0)
  - [Backbone.js alpha released](https://github.com/jashkenas/backbone/releases/tag/0.1.0)
  - [Angular.js made open-source](https://web.archive.org/web/20100413141437/http://getangular.com/)

- 2011:
  - [MDV (Polymer predecessor) introduced at a conference](https://fronteers.nl/congres/2011/sessions/web-components-and-model-driven-views-alex-russell)

- 2013:
  - [Working draft spec for Web Components (v0) released](https://web.archive.org/web/20130608123733/http://www.w3.org/TR/custom-elements/)
  - [Polymer (Google’s web component framework) announced](https://www.youtube.com/watch?v=DH1vTVkqCDQ)
  - [React open-sourced](https://www.youtube.com/watch?v=GW0rj4sNH2w)

- 2015:
  - [Polymer 1.0 released](https://web.archive.org/web/20150814004009/https://www.polymer-project.org/1.0/)

- 2016:
  - [Custom elements v1 spec released](https://web.archive.org/web/20161030051600/http://w3c.github.io/webcomponents/spec/custom/)
  - [YouTube rewritten in Polymer](https://blog.youtube/news-and-events/a-sneak-peek-at-youtubes-new-look-and/)
- 2017:
  - [Polymer 2.0 released](https://github.com/Polymer/polymer/releases/tag/v2.0.0)

- 2018:
  - [Polymer announces start of migration to “LitElement”](https://www.polymer-project.org/blog/2018-05-02-roadmap-update#libraries)
  - [Firefox enables web components (Polyfills no longer needed)](https://www.mozilla.org/en-US/firefox/63.0/releasenotes/)

- 2019:
  - [Lit framework 1.0 released](https://github.com/lit/lit/releases/tag/v1.0.0)

- 2021
  - [Lit 2.0 released](https://github.com/lit/lit/releases/tag/lit%402.0.0)

# Conclusion

In the past 10 years we’ve 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](https://coderpad.io/blog/web-components-101-framework-comparison/) into perspective.

We’ve waited a long time to see many of these ideas fully standardized into the web platform, and, now that they’re here, they’re 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](https://coderpad.io/blog/intro-to-web-components-vanilla-js/) as well as using [Google’s Lit framework](https://coderpad.io/blog/web-components-101-lit-framework/).

Web components have had a long history to get where they are today. Let's look back to see where they came from & their immense growth!

Web Components 101: History

One of the ways web components differs from a framework is that it works right in the browser. Here's how to build them from scratch.

Web Components 101: Vanilla JS

Google pushed for web components, sure, but they didn't stop there. They also went on to make an amazing framework to help build them: Lit!

Web Components 101: Lit Framework


Alright alright, I know for a lot of the last article seemed like a big ad for Lit. That said, I promise I’m not unable to see the advantages of other frameworks. Lit is a tool in a web developer’s toolbox. Like any tool, it has its pros and cons: times when it’s the right tool for the job, and other times when it’s less so.

That said, I’d argue that using an existing framework is more often the better tool for the job than vanilla web components. 

To showcase this, let’s walk through some of these frameworks and compare and contrast them to home-growing web components.

# Pros and Cons of Vanilla Web Components

While web frameworks are the hot new jazz - it’s not like we couldn’t make web applications before them. With the advent of W3C standardized web components (without Lit), doing so today is better than it’s ever been.

Here are some pros and cons of Vanilla JavaScript web components:

<table class="wp-block-table">     <tbody>         <tr>             <th>                 Pros             </th>             <th>                 Cons             </th>         </tr>         <tr>             <td>                 <ul>                     <li><span>No framework knowledge required</span></li>                     <li><span>Less reliance on framework</span></li>                 </ul>                 <ul>                     <li><span>Maintenance</span></li>                     <li><span>Bugs</span></li>                     <li><span>Security issues</span></li>                 </ul>                 <ul>                     <li><span>Smaller “hello world” size</span></li>                     <li><span>More control over render behavior</span></li>                 </ul>             </td>             <td>                 <ul>                     <li><span>Re-rendering un-needed elements is slow</span></li>                     <li><span>Handling event passing is tricky</span></li>                     <li><span>Creating elements can be overly verbose</span></li>                     <li><span>Binding to props requires element query</span></li>                     <li><span>You’ll end up building Lit, anyway</span></li>                 </ul>             </td>         </tr>     </tbody> </table>

To the vanilla way of doing things’ credit, there’s a bit of catharsis knowing that you’re relying on a smaller pool of upstream resources. There’s also a lessened likelihood of some bad push to NPM from someone on the Lit team breaking your build.

Likewise - for smaller apps - you’re likely to end up with a smaller output bundle. That’s a huge win!

For smaller applications where performance is critical, or simply for the instances where you need to be as close to the DOM as possible, vanilla web components can be the way to go.

That said, it’s not all roses. After all, this series has already demonstrated that things like event passing and prop binding are verbose compared to Lit. Plus, things may not be as good as they seem when it comes to performance.

## Incremental Rendering


On top of the aforementioned issues with avoiding a framework like Lit, something we haven’t talked about much is incremental rendering. A great example of this would come into play if we had an array of items we wanted to render, and weren’t using Lit. 

Every time we needed to add a single item to that list, our `innerHTML` trick would end up constructing a new element for every single item in the list. What’s worse is that every subelement would render as well!

This means that if you have an element like this:

```html
<li><a href=”https://example.com”><div class=”flex p-12 bg-yellow”><span>Go to this location</span></div></a></li>
<li><a href=”https://example.com”><div class=”flex p-12 bg-yellow”><span>Go to this location</span></div></a></li>
```

And only needed to update the text for a single item in the list, you’d end up creating 4 more elements for the item you wanted to update… On top of recreating the 5 nodes (including the [Text Node](https://developer.mozilla.org/en-US/docs/Web/API/Text)) for every other item in the list.

## Building Your Own Framework

As a result of the downsides mentioned, many that choose to utilize vanilla web components often end up bootstrapping their own home-grown version of Lit.

Here’s the problem with that: You’ll end up writing Lit yourself, sure, but with none of the upsides of an existing framework.

This is the problem with diving headlong into vanilla web components on their own. Even in our small examples in the article dedicated to vanilla web components, we emulated many of the patterns found within Lit. Take this code from the article:

```html
<script>
  class MyComponent extends HTMLElement {
    todos = [];

    connectedCallback() {
      this.render();
    }
   
    // This function can be accessed in element query to set internal data externally
    setTodos(todos) {
      this.todos = todos;
      this.clear();
      this.render();
    }

    clear() {
      for (const child of this.children) {
        child.remove();
      }
    }
   
    render() {
      this.clear();
   
      // Do logic
    }
   
  }

  customElements.define('my-component', MyComponent);
</script>
<script>  class MyComponent extends HTMLElement {    todos = [];     connectedCallback() {      this.render();    }       // This function can be accessed in element query to set internal data externally    setTodos(todos) {      this.todos = todos;      this.clear();      this.render();    }     clear() {      for (const child of this.children) {        child.remove();      }    }       render() {      this.clear();         // Do logic    }     }   customElements.define('my-component', MyComponent);</script>
```

Here, we’re writing our own `clear` logic, handling dynamic value updates, and more.

The obvious problem is that we’d then have to copy and paste most of this logic in many components in our app. But let’s say that we were dedicated to this choice, and broke it out into a class that we could then extend.

Heck, let’s even add in some getters and setters to make managing state easier:

```html
<script>
  // Base.js
  class OurBaseComponent extends HTMLElement {
    connectedCallback() {
      this.doRender();
    }

    createState(obj) {
        return Object.keys(obj).reduce((prev, key) => {
            // This introduces bugs
            prev["_" + key] = obj[key];
            prev[key] = {
                get: () => prev["_" + key],
                set: (val) => this.changeData(() => prev["_" + key] = val);
            }
        }, {})
    }
   
    changeData(callback) {
      callback();
      this.clear();
      this.doRender();
    }

    clear() {
      for (const child of this.children) {
        child.remove();
      }
    }
   
    doRender(callback) {
      this.clear();
      callback();
    }   
  }
</script>
<script>  // Base.js  class OurBaseComponent extends HTMLElement {    connectedCallback() {      this.doRender();    }     createState(obj) {        return Object.keys(obj).reduce((prev, key) => {            // This introduces bugs            prev["_" + key] = obj[key];            prev[key] = {                get: () => prev["_" + key],                set: (val) => this.changeData(() => prev["_" + key] = val);            }        }, {})    }       changeData(callback) {      callback();      this.clear();      this.doRender();    }     clear() {      for (const child of this.children) {        child.remove();      }    }       doRender(callback) {      this.clear();      callback();    }     }</script>
```

Now our usage should look fairly simple!

```html
<script>
  // MainFile.js
  class MyComponent extends OurBaseComponent {
    state = createState({todos: []});

    render() {
        this.doRender(() => {
            this.innerHTML = `<h1>You have ${this.state.todos.length} todos</h1>`
        })
    }
  }

  customElements.define('my-component', MyComponent);
</script>
<script>  // MainFile.js  class MyComponent extends OurBaseComponent {    state = createState({todos: []});     render() {        this.doRender(() => {            this.innerHTML = `<h1>You have ${this.state.todos.length} todos</h1>`        })    }  }   customElements.define('my-component', MyComponent);</script>
```

That’s only 13 lines to declare a UI component!

Only now you have a bug with namespace collision of state with underscores, your `doRender` doesn’t handle async functions, and you still have many of the downsides listed below!

You could work on fixing these, but ultimately, you’ve created a basis of what Lit looks like today, but now you’re starting at square one. No ecosystem on your side, no upstream maintainers to lean on.

# Pros and Cons of Lit Framework

With the downsides (and upsides) of vanilla web components in mind, let’s compare the pros and cons of what building components using Lit looks like:

<table class="wp-block-table">     <tbody>         <tr>             <th>                 Pros             </th>             <th>                 Cons             </th>         </tr>         <tr>             <td>                 <ul>                     <li><span>Faster re-renders* that are automatically                             handled</span></li>                     <li><span>More consolidated UI/logic</span></li>                     <li><span>More advanced tools after mastery</span></li>                     <li><span>Smaller footprint than other frameworks</span></li>                 </ul>             </td>             <td>                 <ul>                     <li><span>Framework knowledge required</span></li>                     <li><span>Future breaking changes</span></li>                     <li><span>Not as widely known/used as other frameworks (Vue,                             React, Angular)</span></li>                 </ul>                 <p><span></span></p>             </td>         </tr>     </tbody> </table>

While there is some overlap between this list of pros and cons and the one for avoiding Lit in favor of home-growing, there’s a few other items here.

Namely, this table highlights the fact that Lit isn’t the only framework for building web components. There’s huge alternatives like React, Vue, and Angular. These ecosystems have wider adoption and knowledge than Lit, which may make training a team to use Lit more difficult.

However, Lit has a key advantage over them, ignoring being able to output to web components for a moment - we’ll come back to that.


Even compared to other frameworks, Lit is uniquely lightweight.

Compare the bundle sizes of Vue - a lightweight framework in it’s own right - compared to Lit.

![Lit weighs in at 16.3 kilobytes while Vue weighs in at 91.9 kilobytes](./bundlephobia.png)

While tree shaking will drastically reduce the bundle size of Vue for smaller applications, Lit will still likely win out for a simple component system.

# Other Frameworks 

Lit framework isn’t alone in being able to output to web components, however. In recent years, other frameworks have explored and implemented various methods of writing code for a framework that outputs to web components.


For example, the following frameworks have official support for creating web components without changing implementation code:

- [Vue](https://v3.vuejs.org/guide/web-components.html#definecustomelement)
- [Angular](https://angular.io/guide/elements)
- [Preact](https://github.com/preactjs/preact-custom-element)

Vue 3, in particular, has made massive strides in improving the web component development experience for their users.

What’s more is that these tools tend to have significantly larger ecosystems. Take Vue for example.

Want the ability to change pages easily? [Vue Router](https://router.vuejs.org/)

Want a global store solution? [Vuex
](https://vuex.vuejs.org/)Prefer similar class based components? [Vue Class Component Library](https://class-component.vuejs.org/)

Prebuilt UI components? [Ant Design](https://www.antdv.com/docs/vue/introduce/)

While some ecosystem tools might exist in Lit, they certainly don’t have the same breadth.

That’s not to say it’s all good in the general web component ecosystem. Some frameworks, like React, [have issues with Web Component interop](https://custom-elements-everywhere.com/), that may impact your ability to merge those tools together.

# Why Web Components?

You may be asking - if you’re going to use a framework like Vue or React anyway, why even bother with web components? Couldn’t you instead write an app in one of those frameworks, without utilizing web components?

You absolutely can, and to be honest - this is how most apps that use these frameworks are built.

But web components play a special role in companies that have multiple different projects: Consolidation.

Let’s say that you work for BigCorp - the biggest corporation in Corpville.

BigCorp has dozens and dozens of full-scale applications, and not all of them are using the same frontend framework. This might sound irresponsible of BigCorp’s system architects, but in reality, sometimes a framework is better geared towards specific applications. Additionally, maybe some of the apps were part of an acquisition or merger that brought them into the company.

After all, the user doesn’t care (or often, know) about what framework a tool is built with. You know what a user does care about? The fact that each app in a collection all have vastly different UIs and buttons.

![Two different apps, each with different text cutoff points in their button's text](./two_apps.png)

While this is clearly a bug, if both codebases implement the buttons on their own, you’ll inevitably end up with these types of problems; this being on top of the work-hours your teams have to spend redoing one-another’s work for their respective frameworks.

And that’s all ignoring how difficult it can be to get designers to have consistency between different project’s design components - like buttons.

Web Components solve this problem.

If you build a shared component system that exports web components, you can then use the same codebase across multiple frameworks.

Once the code is written and exported into web components, it’s trivial to utilize these new web components in your application. Like, it can be a [single line of code trivial.](https://v3.vuejs.org/guide/web-components.html#tips-for-a-vue-custom-elements-library)

From this point, you’re able to make sure the logic and styling of these components are made consistent between applications - even if different frameworks.

# Conclusion

While web components have had a long time in the oven, they came out swinging! And while Lit isn’t the only one at the table, they’ve certainly found a strong foothold in capabilities.

Lit’s lightweightness, paired with web component’s abilities to integrate between multiple frameworks is an incredible one-two punch that makes it a strong candidate for any shared component system.

What’s more, the ability to transfer knowledge from other frameworks makes it an easy tool to place in your toolbox for usage either now or in the future.

Regardless; whether you’re using Vue, React, Angular, Lit, Vanilla Web Components, or anything else, we wish you happy engineering!


While web components can be used standalone, they're paired best with a framework. With that in mind, which is the best and why?

Web Components 101

Chapter Listing:

Web Components 101: History

Web Components 101: Vanilla JS

Web Components 101: Lit Framework

Web Components 101: Framework Comparison