AngularJS has been instrumental in changing the way I develop web applications. From building imperative views where both business logic and user interaction live, to separate controllers and directives that handle both requirements respectively. From sharing components through jQuery plugins, the usual common denominator, to sharing components through declarative HTML. From reacting to model changes through events, to wiring up the HTML to react to model changes. The list goes on.
This post is intended for:
- AngularJS developers
- Developers that enjoy learning about new web technologies
As a pragmatist, I have dabbled with CoffeeScript in a number of projects. It provides a cleaner syntax, a few useful abstractions (assignment destructuring, list comprehensions, etc.), but there isn’t anything ground breaking about it.
Legacy browsers are still important for businesses that need to support them. This should not, however, discourage us from looking to the future with optimism. There are some really cool stuff that will become commonplace sooner rather than later.
Where is this all heading
There are far more users of AngularJS than AngularDart. This is not a bad thing, just a fact. I can’t say for certain whether I’ll be developing something in AngularDart five years from now. I can say with a much greater certainty that I will be developing something in ES6/7, using web components, and whatever cool, new web technology we’ll have in the future.
This is where I think the real value of AngularDart comes in. The way we are developing applications in AngularJS 1.x is not where the web is moving towards. Web components will become the new common denominator. There are already projects like Polymer and Mozilla Brick that leverage this new power of the web. The powerful, but slightly confusing AngularJS 1.x directives will be gone, and we’ll be left with much cleaner Controllers, Directives, and Components.
AngularDart and AngularJS 2.0
I mentioned controllers, directives, and components. The first two will be familiar to any AngularJS developers, but components are completely new to AngularDart. Here are the use cases for each of them.
- Controllers contain business logic and do not do any DOM manipulations.
- Directives are used to introduce new behaviour to existing HTML in a declarative fashion.
- Components are used for custom elements and uses the shadow DOM – think web components.
The nice thing about AngularDart is that the API for all three are essentially the same.
The main difference here is that each one is decorated with a different annotation (
@NgComponent). Another difference is that controllers and components create a new scope, whereas directives
selector option is a CSS selector to match elements in the DOM. This greatly simplifies the existing directive
API which uses a combination of the name and
This allows us to build our application using an unified API, rather than having to build controllers and directives in completely different manners.
More importantly, AngularJS 2.0 is drawing a lot of inspiration from AngularDart, and many of the APIs will be changed in the future to mimic the same ones in AngularDart. Now is as good a time as any to familiarize yourself with these changes if you are already using AngularJS.
This is just the tip of the iceberg of AngularDart. Other major changes/additions are Zones
and the DI framework. With zones developers will no longer need to call
scope.$apply(), which I am sure will make everyone very happy.
A little bit more on zones
Okay, zones are amazing. From the Dart API Reference:
A Zone represents the asynchronous version of a dynamic extent. Asynchronous callbacks are executed in the zone they have been queued in.
What it means, basically, is that async operations that pushes execution to the next tick (in the run loop) will still
take place in the same “zone.” This way, Angular will be able to digest any bound value changes without you calling
For example, in the current AngularJS this code will present a problem.
To fix it, we must call
scope.$apply() within the function passed to
With zones, however, Angular will be able to detect these changes because the
setTimeout call occur within the same zone.
More on web components
Back to components. Can we all agree that web components are awesome? Imagine a future where we can all share our custom elements no matter which MV* framework we are using.
The fundamental difference in building web components versus AngularJS directives or jQuery plugins is that they allow us to encapsulate HTML and CSS in a way that is not currently possible. This prevents leaky abstractions where we need to understand the underlying markup and styling in order to use a component.
For example, say we want to include slideshow in our application. If you use a jQuery plugin, you will have to construct the HTML in a way that the plugin understands.
Here we need to include the right classes in order for the plugin to pick up the correct element to instantiate the carousel, controls, and apply styling.
Now take a look at a hypothetical custom element.
The second HTML is much cleaner, and as a bonus we wouldn’t need to include extra stylesheets because the CSS is encapsulated with the component.
This is the way AngularDart components work, and in the future probably AngularJS as well. Moreover, we should be able to use components that are not built in Angular.
I think it’s worthwhile to learn AngularDart now, even if you don’t plan on moving any projects to it. There are major API overhauls and changes to the framework that will eventually come to AngularJS.
Just as AngularJS changed my way of developing web applications, so will AngularDart help us, once again, rethink the way we build and structure our applications.