Before you read

On last Thursday I had the gorgeous possibility to try out Angular 2 at work, and I started as usually with the simplest tutorial on their page: Angular 5 minutes Quickstart.

It took me a bit more (ehm… way more) than 5 minutes but once I was done I could move to the next one: the Heroes tutorial!

This is also just my first contact with Angular 2, so take it cum grano salis like if your coworker were informing you about something he tried yesterday for the first time.


Almost everything is now a component and in order to let Angular know how to use it they implemented decorators which take as input a metadata object (actually a plain JS object)

Although it allows us to identify at a first glance all the components’ properties, these decorators can become quite verbose. On the other hand we can move those metadata out of our classes which in Angular 1 were definitely too verbose and cluttered.


Each Angular component can bring its own styles as a string or as an array of files to imported, just declaring it in the property styles  or styleUrls of the metadata object.

When we assign styles to a component they get scoped at runtime within that specific component: our styles will then only apply to our AppComponent and won’t bleed over the outer HTML. This is a great feature since allows for a true composition of basic blocks without caring about what the component does to the styles.

In order to achieve such a result, Angular will modify the styles adding a unique element’s attribute to all the nodes of the the tree and to the css itself.

Scoped CSS in Angular 2

Scoped CSS in Angular 2

In the tutorial it is all done at run time and this is something which scares me a bit, since there might be some overhead in terms of code and DOM access.

A downside to take into account is that the urls must be declared relative to the root: there’s no need to say that I lost a bit of time following the 404  I got while running the exercise.

The syntax

I was surprised to find such a weird and different syntax:

Basically we have a different symbols and parenthesis based on the attribute’s function:

  •  is used to mark directives which physically modify the DOM tree
  • () are used to enclose an event, called a template statement
  • [] are used to enclose a template statement which is evaluated
  • [()] to explicitely ask for two way data binding
  • ….?

It took me a while to understand and I also had to check the Template syntax. It’s simply too difficult.

Errors management

It truly improved as you can see from the screenshot:

Angular 2 stacktrace

Angular 2 stacktrace

The stacktrace is verbose and allows for good debugging.


Angular 2 still requires explicit declarations for directives and providers: though instead of arrays of strings we eventually can use array of objects which is less error prone. Nonetheless I was astonished when I read about providers shadowing: the injected provider can indeed be instantiated more than once if declared as a dependency.

Let’s see an example:

In the providers field we declare the dependency over ROUTER_PROVIDERS and HeroService. If we now have a different component declaring the same dependencies, it will get a different instance of those.

While for stateless providers is just a matter of overhead, can you imagine how difficult could be debugging a statefull provider?

There’s though a third way to break it: declaring the dependencies per module is the same as using the decorator per component.

As per Angular docs:

Notice that we supply the HTTP_PROVIDERS in an array as the second parameter to the bootstrap method. This has the same effect the providers array in @Component metadata.

So far I see difficult to truly integrate components built by different teams and based on a common library if there’s such a limit: the only way to avoid those errors is to always declare dependencies at top level and share across the teams the same setup.

The Routing

Guess what? The routing of the new framework is already deprecated.

It uses a decorator for the application which takes an array of states:

In the example it is quite easy and straightforward to use, but I was figuring out whether is it possibile to split up the configuration across modules. The idea to have again to declare all my pages in one file is not compatible with a modular architecture, and I could do that with the UI-Router.

For sure this topic deserves a post for itself.

The Reactive part

As I saw that Angular’s http is exposing Observables I was at the same time surprised and delighted: really they did go for streams rather than promises?

They moved from the MVC/MVW like patterns towards a more reactive one, promoting one way data transformations and message passing in the form of streams (if you ever tried out ELM you know how it works) with RxJS.

On the other hand, I was disappointed to see that in order to transform an Observable into a Promise they chose to go with side effects:

Just import that library and the Observable becomes automagically a Promise. Frankly I don’t like this approach being promoted in an official tutorial.



I didn’t (yet) try to use Angular 2 to build up a real web application so my conclusions can be shallow: I like the way they reduced the boilerplate and the idea that we have no more controllers and directives but actual components.

I also appreciate the fact that a scope, and namely a rootScope, doesn’t exist anymore and therefore can’t be used by the nth developer to “add a feature”.

Another thing I really like is the event oriented approach to let the components communicate: instead of adding listeners on the scope is more clean to be able to fill in the gaps of the component with the desired behaviour, processing streams and reacting to events.

Last but not least the styles’ automatic scoping is simply amazing.


What I really don’t like is that you see the framework all around the code: you are not writing Javascript anymore, but Angular. The templates’ syntax is also weird and leads to cluttered HTML.

The dependencies management is also still too weak, easy to break and difficult to debug: too many ways to declare them and the fact that a component could can get a different instance of the provider is scary.

The need, again, of side-effects: import a library for the sake of modifying at run time another library is really dangerous and also hard to maintain.

Also although I appreciate the new architecture based on Observables, it is a pity that they didn’t go completely in that direction as the model is still mutable directly from the view instead of using messages, and the messages themselves are mutable.

Last but not least Angular is always presented with TypeScript, even if they say that is fully compatible with Javascript. The problem is that you could hire developers with not JS experience and teach them write TypeScript, and they will be able to work on your application.