Over a million developers have joined DZone.

Embracing the Future With AngularJS 2.0, Web Components, and ag-Grid

DZone's Guide to

Embracing the Future With AngularJS 2.0, Web Components, and ag-Grid

ag-Grid is now available in so many flavors, it will be applicable whichever way the community goes.

· Web Dev Zone ·
Free Resource

Read this guide to learn everything you need to know about RPA, and how it can help you manage and automate your processes.

The first release of ag-Grid (www.ag-grid.com) broke the ‘usual thinking’ for AngularJS developers. It provided a high performance grid to the AngularJS community, but it didn’t use AngularJS underneath the hood. Instead it used AngularJS where appropriate, and then native Javascript and DOM manipulation at all other times. A wolf-fast grid in AngularJS clothing! This approach was novel, building a bridge between native Javascript and AngularJS without the client AngularJS application realising it was using a non-AngularJS component.

AngularJS 1.x had some shortcomings, which is understandable given its evolutionary development. What AngularJS is being used for today is probably beyond the intentions of Misko when he wrote those first lines of code, which is probably why the guys at Google decided to do a complete redesign for Angular 2. One of the shortcomings that particularly bothered me was the closed nature of the platform: AngularJS applications could not seamlessly use non-AngularJS components. For AngularJS to use a non-AngularJS component, it had to wrap the component with AngularJS code. This led to a sea of non-functional components whose only purpose was to wrap non-AngularJS components – a component wrapping a component.

In ag-Grid, this wrapping code is done for you, thus the AngularJS application had no idea it was talking to a non-AngularJS component.

AngularJS 2 turns this problem right around. Rather than having a closed system for modularising AngularJS applications, AngularJS 2’s foundations lie on the emerging Web Components standard. What this means is that AngularJS will be able to directly use, without any wrapper coding, any component written as a Web Component. That is easy to understand - when I first heard it I understood technically what it meant - but it took me some time to really appreciate the implications of what it meant.

Having spent a considerable time considering the above I have come to the following logical conclusions:

  • Right now AngularJS 1.x has a large following. It is probable that a large majority of that following will migrate onto AngularJS 2 when it is ready.
  • This migration of followers will start hunting for Web Components to include in their AngularJS applications.
  • Web Components will receive a significant wave of interest from these followers.
  • Web Component developers will not have to worry that it’s AngularJS 2 is their client, no wrapper code will be needed. This is what's called a framework-agnostic model for Web Components.
  • The sea of non-functional wrapper components for AngularJS 1.x will have no role in the new AngularJS 2 & Web Components world and will be washed away.
  • Some reusable components will be better suited to AngularJS 2 over Web Components. Components that solve business functions to be reused within an organisation probably fit here.
  • Some reusable components will be better suited to Web Components over AngularJS 2 Components. Low level UI widgets (date pickers, grids etc) probably fit here.
  • Low level components that are currently implemented in AngularJS 1.x probably won’t have a place in the new world as Web Components framework-agnostic pattern will be favored. These will also wash away.

This is excellent news for Web Component developers, regardless of whether you are an AngularJS advocate or not. This added surge of interest will provide Web Components with additional traction.

So in the future, when AngularJS 2 is out, it will bring more choice. Component developers will have the choice to provide Web Components that work with AngularJS as well as with other platforms. AngularJS developers will have wider choice when selecting components for their application, not being restricted with ‘only AngularJS’ components. The binding between application technology choice and component technology choice will dissolve. The AngularJS 1.x components that came into existence as a result of it's dependency shortcoming will disappear.

So where does this leave components like ag-Grid? ag-Grid has worked with AngularJS 1.x and native Javascript since version 1. Version 2 has extended to AngularJS 2 and Web Components (these are two separate things, one depends on AngularJS 2, one depends on Web Components, however an AngularJS 2 application can talk to both). The positioning of ag-Grid, to support this new technology choice, was evolutionary. Google and the Web Components community laid the breadcrumbs. Now that ag-Grid is available in all these flavors, it will be applicable whichever way the community goes.

I guess ag-Grid has thrown some breadcrumbs too, by supporting the multiple choices, with the anticipation of seeing what sticks.

Get the senior executive’s handbook of important trends, tips, and strategies to compete and win in the digital economy.

angularjs ,javascript ,web components ,html 5 ,polymer ,angularjs 2

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}