These are not competing technologies. Angular is a framework. Polymer is a library. Let’s skip comparing libraries / frameworks against other libraries / frameworks for a second (polymer or angular or react or meteor or backbone or mustache or express or jquery or dojo or kendo).
Web development is ever-evolving. Being in tune with state of the platform (HTML, HTTP, Javascript, CSS) is critical to helping teams choose what technology (or technologies) are the right fit for particular team/project, to be responsive to paradigm shifts and to stay ahead of the curve (or at least not behind it).
There are a handful game-changing platform changes that have occurred recently. For the purposes of this conversation, let’s touch on just a couple.
-
Custom-Element Specification https://html.spec.whatwg.org/multipage/scripting.html#custom-elements
-
Css style properties and style mixins https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables
A custom-element is simply a re-usable and composable html primitive that you get to create. If custom-elements were supported by the platform 20 years ago, then it is safe to say that the implementation details of :name your favorite ui library: would be completely different. They would be web-components.
Can you tell which of the following are custom-elements?
<md-button class="md-primary">Primary Button</md-button><button data-dojo-type=”DojoButton” data-dojo-props=”label: ‘Primary Button’”></button><paper-button>Primary Button</paper-button><FlatButton label=”Primary Button”></FlatButton>
No? So what are the advantages of a custom-element vs something from a javascript framework or a library?
-
Custom elements work everywhere. No matter what new fancy library comes about, the custom element will work within or without that libarary
-
Custom elements have much smaller dependencies (literally as few as zero). You deliver a smaller payload to the end-user
-
Custom elements have a scoped dom-tree. There are no leaky styles. There is no competition for “unique ids”. If you clicked ‘inspect element’ on any of the elements above it would be very obvious which were custom elements
-
Custom elements have proper life-cycle events (attached, detached, etc)
-
Can mix-and-match components from various authors without including huge libraries for each
-
Huge open-source community of component authors https://customelements.io/
Learn more about webcomponents: http://webcomponents.org/
Simply stated -- Custom properties and style mixins are the unrivaled way to achieve theming through a web app. Without custom-properties and style-mixins, we use a tool like LESS or SASS to achieve theming. Those tools require a build-step. You define properties or mixins somewhere. Then a build step goes through and copies the properties / mixins around to a bunch of places, producing good old fashion static css.
- Sass example…
$my-color: green;
@mixin rounded {
border-radius: 5px;
box-shadow: 0 2px 2px 0 rgba(0, 0, 0, 0.14);
}
.. then somewhere else…
div {
height: 50px;
width: 50px;
background-color: $my-color;
@include rounded;
}
- Native example…
html {
--my-color: green;
--rounded-mixin: {
border-radius: 5px;
box-shadow: 0 2px 2px 0 rgba(0, 0, 0, 0.14);
};
… then somewhere else
div {
height: 50px;
width: 50px;
background-color: var(--my-color);
@apply(--rounded-mixin);
}
They look about the same. What are the differences?
- Sass required a build step (and a dependency)
- Sass copies the properties and mixins around to “N” locations
- Native is.. native
- Native doesn’t copy the properties around… instead “N” locations have pointers to one definition. You ship less bytes
- Native provides RUNTIME access. Using javascript, you can set “my-color” to be purple and every element using that property is now purple.
Webcomponents.js is a small library of polyfills and shims that add support for the aforementioned features to browsers that lack complete support. For the time being, it is utilized by all web-component authors (depending on the browser vendor).
Polymer is a thin abstraction layer whose goal is to make it easier to define custom-elements. Polymer sits on top of actual html, css, and javascript platform specifications. Polymer actually wants itself to play an ever-decreasing footprint in your development (as the native platform matures and gains compliance in all browsers).
Custom elements can be defined via any of the following popular techniques…
- Polymer, google
- X-tag, Mozilla
- Bosonic
- SkateJS
- Vanilla JS (just using the native way w/ support lended by webcomponents.js where needed)
The end result is the same. A slim, reusable, framework-agnostic, declarative html primitive.
It’s worth stating, there is a very common misconception that “Polymer = Material Design”. Polymer is nothing more than what I just described. The CSS used to style an element is up to the author.
See how polymer describes itself: https://www.polymer-project.org/1.0/
Angular is a framework for developing web-apps. Web apps composed by components… you can make (angular-only) “components”… they aren’t natively registered custom-elements. They won’t work outside of an angular application. By contrast, web-components WILL work within an angular application (or a react application).. or without any framework at all.
If webcomponents existed when angular was first developed, how different would a typical angular webapp look? Would we be writing angular components are would we be writing proper custom-elements? Much the space angular was used to fill was to create reusable (within an angular app) “components”. It continues to be used in that way.
See how angular describes itself: https://docs.angularjs.org/guide/introduction
Once the platform offers a primitive that does what the library or framework does, then you should be using the platform. It’s faster. It doesn’t require dependencies. Use the platform. Ignoring the state of the platform is perilous. Many frameworks exist or existed (many are dead and all but gone) because of gaps in the native web platform.
Once you tie yourself to a framework, any framework, as a development platform, leaving the framework is nearly impossible. By contrast, custom elements work with or without a framework and swapping out one custom element for another is relatively painless (I’ve done it on many occasions).
It goes without saying that webapps built using frameworks like Angular will increasingly make use of web components.
There is an ever growing list of google (and non-google) web-apps that are built with polymer. For example… we recently started using SalesForce. SalesForce is built with polymer. Learn about more here: https://github.com/Polymer/polymer/wiki/Who's-using-Polymer%3F
Angular and Polymer are both owned by google. Where better to acquire a pulse on the state of web development than their web-development channel… https://www.youtube.com/user/ChromeDevelopers/playlists
One of those playlists is dedicated to polymer. I’m junkie for learning.. so I know because I watched most of the videos… but polymer (and webcomponents in general) are featured throughout other playlists: A11ycasts, Progressive WebApp Summit 2016, Web and Chrome at I/O 2016, Supercharged with Paul Lewis, Chrome Dev Summit 2015, more…
HTTP 203: Libraries vs Frameworks (S3, Ep6) https://youtu.be/t_pxnrLktNI?list=PLNYkxOF6rcIAKIQFsNbV0JDws_G_bnNo9