Jun 3 2016

Will Google Angular2 survive to Google own Polymer?

Category: JavaScript | TypeScriptFrancesco @ 00:56

A couples of weeks ago Google presented Polymer features at I/O 2016. In a few words Polymer is about Web Components. Web Components (also known as Custom Elements) are part of the Html and Dom specifications. They are a way of encapsulating both JavaScript, Html templates and Styles within reusable components. Everything is inside the component is not accessible from the external world. So for instance, component internal styles and JavaScript do not affect the remainder of the Web Page. Custom elements are associated with custom Html tags,so the developer may use them, by simply writing the custom tag. Since custom tags may contain other Html inside them Web Components may be nested. So for instance, you may define a “grid” custom element that may contain custom row or column templates inside of it..

At moment browser support for Web Components is limited basically to Opera and Chrome, but there are hundreds of polyfills that simulate them.

Polymer furnishes both:

  • A polyfill for browser not supporting Web Components
  • A complete set of already implemented components
  • Various tools to help you build web component based applications.

Angular team declared that they will end up adopting Polymer Web Components inside Angular. Since there is an overlap between Web Components and Angular custom elements, it appears that most of Angular UI logics will end up being completely substituted by Polymer Web Components.

This transition will be driven by the support provided also by other Browser to Web Components. In fact, with native browser support Web Components will over-perform slower simulated Angular UI constructs.

To say the truth, also polyfilled Web Components are faster than their equivalent Angular constructs, because normally Angular2 must visit the whole Model behind the page to perform changes detection each time an event occurs!

Thus for instance if you change a value in a grid with 10.000 items, it must check all all 10.000 items looking for changes that might affect the DOM. Luckily, if you use either Immutable objects or observables it is able to restrict changes detection just to the path within the overall page Model that contains the changed property. Please refer to this article for more details on Angular changes detection,and on how immutable objects and observables help the process.

However, this means you can’t use plain JavaScript objects as they are returned by the server, but you have to copy them into ad-hoc designed objects before binding them to the DOM .This was the main criticism moved by Angular sustainer against knockout.js, because of knockout.js usage of observables!

But why Angular1  started with plain JavaScript object and then moved toward immutable objects and observable? Simple! They hoped they might have improved performance thanks to the browser support of the forthcoming Object.observe api!

For the ones that never heard about Object.observe, changes in standard plain JavaScript objects should have automatically caused notifications to functions registered with Object.observe. Unluckily, Angular performance when using Object.observe was unacceptable! In a few words the reason of this unacceptable performance was the too many notifications coming from modified objects. In fact each event may cause a chain reaction of object modifications which in turn causes an unacceptable number of notifications being sent to  the Angular changes detection engine.

Similar problems with other software caused the removal of the Object.observe api from Chrome and  other browsers, and their consequent removal form the initial “standard” proposal.

Summing up, after this bad experience Angular team was forced to move to other techniques to improve performance, i.e.: immutable objects and observables.

So, from one side we have an UI based  on Polymer that has the following advantages:

  1. Based on a W3C standard
  2. Efficient, because in a short time all main browsers should support natively Web Components
  3. Modular, easily integrable with other frameworks, and not opinionated, since Polymer components are not tied to Polymer,but are completely independent chunks of software you may use in any application.The only constraint is that a polyfill be provided for browser not supporting Web Components yet. However, this constraint is going to be removed in a short time since Web Components will be soon implemented by all major browsers.

On the other side we have Angular:

  1. A complete framework, containing everything is needed to develop a client-techniques based Web Application, from User Interface  to client-server communication, and Dependency Injection. However, it is opinionated and quite difficult to integrate with other frameworks.
  2. Slow as compared to native Web Components and with no hope to overcome this gap.
  3. Forces the usage of Observables and/or Immutable objects in performance critique applications. True,that the usage of Immutable objects is expected to grow (give a look to this post for a quick introduction to JavaScript Immutable objects), but being forced to use them, for sure, makes life more difficult to developers in any case. Moreover, the immutable objects  paradigm doesn’t fit all situations,and for sure is not adequate for complex big business objects.

We might expect that with the increasing native support for Web Components Angular will be forced to integrate Polymer style web components,  till an almost complete substitution of its User Interface. Now the point is, is it worth using Angular once its UI stuffs have been substituted with another framework?

For sure a lot of people will continue using it, since it will continue being a “glue” that keeps together various client-side technologies, offering everything is needed to implement a client-based application. It will continue being attractive for companies that need its developers be guided by the “pre-defined style”  of an opinionated framework: a kind of guarantee all developers conform to a common universally accepted “standard”.

However, a lot of freelancers and company with a stronger “governance” of their teams, or company was strength is flexibility, will prefer implementing their applications by assembling modules from different authors/frameworks. Thus choosing each time the tools the more adequate to their current needs: say Polymer for UI,but tools from different authors for client/server communication and routing. In fact notwithstanding  the need of some companies for a complete  omni-comprehensive framework the community is preferring always more self-contained modules easy to assemble with other technologies.

Anyway while its difficult to forecast in detail the future of Angular, for sure it’s worth to start learning Polymer, and/or similar Web Component based frameworks like for instance React.js!

Have fun with Web Components!


Tags: , , , ,