Implementing Component Architectures - Comparing Polymer with React, Angular, Vue, Ember, Aurelia

May 11, 2017 0 Comments by

How do Web Components stack up to popular libraries and frameworks in use today? Taylor Savage speaks to the products built with Polymer in the Polymer Summit Keynote. How does this compare to other types of solutions in the wild?

What is a Component?

A component should be a stand-a-lone piece, that can be dropped into almost anywhere, to reuse some kind of functionality. Components were popularized in Angular 1.x with directives. The HTML5 spec said we could use custom elements, this was really interesting. But these custom elements couldn't do anything for the users, this was aimed at improving semantics for developers. Developers created Angular Directives, that enabled implementers to use what looked like HTML tags, into the markup, and achieve custom functionality. That which was componentized into a simple tag.

A simple example: <stock-ticker/>

To create this functionality the developer needed three things: HTML, CSS, and JavaScript. This ended up in a lot of code, and so technology innovators set out to come up with ways to tackle this challenge. Some thought: what if the browser could handle this natively? In the spirit of Cordova and hybrid apps, polyfill this functionality in hopes that we can just pull it out someday in the distant future and everything will just work. Others worked within the current limitations to provide the best solutions for today and tomorrow's application developers. Embrace JavaScript to handle this. You can embed HTML and CSS within the script, or use either of these as external files. Implementation details are left to the developer. The verdict is out: define reusable parts of your application as configurable components. How you do this, is up to you.

You can choose to use a framework, you could roll your own with a collection of micro libraries, or you could roll your own from scratch. The overarching methodologies in implementing a framework fundamentally revolve around three primary concepts.

  • Model/View (Angular, Backbone)
  • Reactive/Functional (Angular 2, Vue, Cycle.js)
  • Virtual DOM (React, Preact, Inferno)

Web Components

When developing only for browsers with shadow DOM support, WCs facilitate rapid development. If you have to support all browsers, then you may spend time having to figure out why things don't work. It is not possible to step into, through, or over code that is executed directly by the browser. This means you have to resort to a lot of trial and error. When you prepare your code for production, you will need to vulcanize. This is putting together the HTML and CSS into a single file, and all of your JS into another file. A lot of times we are thinking about code splitting, HTTP2, and ES6 imports. Putting everything into a single markup file and js file, won't give you a lot of options. Adopting Polymer means you will be using Bower. The number of Bower users is dwindling.

  • Model/View (Polymer)
  • Reactive/Functional (SkateJS)
  • Virtual DOM (Riot)

there are many other libs, these are just the ones I find interesting.

Principles of Component Architectures

  • One-way dataflow
  • Stateful and stateless components
  • Split rendering engine
  • Component inputs and outputs
  • Pre-compiling


Angular 2 and React — Just-in-Time and Ahead-of-Time compilers. With JiT and AoT


Tag cloud