zz: Is Angular 2.0 Worth It# Programming - 葵花宝典
S*t
1 楼
Is Angular 2.0 Worth It
Author: Torgeir Helgevold
Published: Sat Sep 05 2015
I have over the past months spent quite a bit of time working with Angular 2
.0 by writing sample components and going through the Angular 2.0 source
code. At this point I have decided to write down some of my thoughts around
my experiences with Angular 2.0. Keep in mind, these are just my own
personal experiences, so I am very interested in hearing from other
developers who might have totally different views on this.
Similar concepts
As I have stated before, I really like some of the new conventions in
Angular 2.0. However, what gets me is how similar Angular 1.x and Angular 2.
0 are if you trim it down to just concepts – ignoring syntax differences. I
am starting to see this as a red flag and I question if it's ultimately the
right approach to create a new framework with the same concepts repackaged
and delivered with the promise “that it's better this time”.
I want to emphasize that my issue is not primarily with the new breaking
syntax since converting syntax is not really a hard problem with the right
editor. My issue is more with the Angular team's decision to create a brand
new framework where they have to redo everything – even the things they did
right the first time around. In my mind the biggest disadvantage of going
with a fresh start is a huge delay in their time to market. We are already
seeing new frameworks like Aurelia and React (with supporting patterns),
emerging as very viable alternatives to Angular 2.0.
Most developers think of Angular 1.x and Angular 2.0 as two completely
different frameworks and the reactions I see are mixed. Some are frustrated
that there is no proposed release date for Angular 2.0. This begs the
question if it even makes sense to start with Angular 1.x and move to
Angular 2.0 later. The latest news with a promise of a less painful
migration route, with Angular 1.x and Angular 2.0 coexisting in the same
application, likely makes this a viable solution though.
I am not trying to discount the new features and conventions in Angular 2.0.
I fully support most of them, but my argument is that it should have been
introduced incrementally in the Angular 1.x codebase. Features of Angular 1.
x that are considered bad practices should be deprecated as part of this
effort. This is a practice we're already seeing when it comes to promise
methods like success and error which are headed for deprecation.
Different concepts
One might argue that some of the new features like bindings and change
tracking break the conceptual parity between Angular 1.x and Angular 2.0.
This is ok since you could have included meta in the bindings to opt in to
one-way, two-way or one-time bindings. WPF in .Net is an example of a
framework that went in this direction. I have argued from the very beginning
that one-time, for performance reasons, should be default. However, I
understand that this ship has sailed. Some disagree with me here, but my
argument is that one should opt into change tracking where it's needed,
instead of opting out where it's not needed.
Conceptual parity explained
I realize it might not be clear what I mean when I say the concepts are so
similar between Angular 1.x and Angular 2.0. I think the rich API surface in
Angular 1.x hides this a bit since you have to write your Angular 1.x code
a certain way to see the similarity. My argument is that the similarity is
really striking if you write Angular 1.x directives with “controllerAs”
style controllers – consumed by the directive. Not everyone realizes this,
but new features like bindToController and controllerAs have made the
interaction between the directive portion and the controller seamless. It
also gives you that sought after Angular 2.0 component feel. I have done a
more in depth comparison in the following article.
I like the new direction of using TypeScript for Angular 2.0, but I also
think it may make the two frameworks seem more different than they really
are. After all you could be writing Angular 1.x in TypeScript as well.
Perhaps a comparison of Angular 1.x and Angular 2.0, both in TypeScript,
would make them seem even more similar.
New Concepts
As with all new major versions there are a ton of new improvements in
Angular 2.0. Some of the exciting new features include components decoupled
from the runtime environment. This will likely give us some of the same
benefits we see out of React where you can map a component to completely
different underlying platforms (server, mobile and browser). Another big one
for large applications is native built in support for lazy loading. In
Angular 1.x we have to rely on third party libraries like ocLazyLoad to
achieve this. That said, these new features don't seem to break with my
previous argument that this could have been released incrementally as a
natural evolution of the 1.x line.
Going forward
Despite my criticism I am still certain that the final Angular 2.0 product
will eventually be a success. As I stated earlier, my complaint is not with
the breaking changes, but rather with how they are delivered. I personally
would have tried to evolve the exiting framework rather than via a clean
slate that adds months, maybe years, to the release timeline.
Anyway, this was just my take on this. I would really like to hear from
other developers on this topic and learn different perspectives. My views
are for the most part a result of working with Angular 2.0 in my Angular 2.0
repo on Github. Check out my live demo here if you are interested.
If you liked this article, share it with your friends. I also invite you to
follow me on twitter at
Author: Torgeir Helgevold
Published: Sat Sep 05 2015
I have over the past months spent quite a bit of time working with Angular 2
.0 by writing sample components and going through the Angular 2.0 source
code. At this point I have decided to write down some of my thoughts around
my experiences with Angular 2.0. Keep in mind, these are just my own
personal experiences, so I am very interested in hearing from other
developers who might have totally different views on this.
Similar concepts
As I have stated before, I really like some of the new conventions in
Angular 2.0. However, what gets me is how similar Angular 1.x and Angular 2.
0 are if you trim it down to just concepts – ignoring syntax differences. I
am starting to see this as a red flag and I question if it's ultimately the
right approach to create a new framework with the same concepts repackaged
and delivered with the promise “that it's better this time”.
I want to emphasize that my issue is not primarily with the new breaking
syntax since converting syntax is not really a hard problem with the right
editor. My issue is more with the Angular team's decision to create a brand
new framework where they have to redo everything – even the things they did
right the first time around. In my mind the biggest disadvantage of going
with a fresh start is a huge delay in their time to market. We are already
seeing new frameworks like Aurelia and React (with supporting patterns),
emerging as very viable alternatives to Angular 2.0.
Most developers think of Angular 1.x and Angular 2.0 as two completely
different frameworks and the reactions I see are mixed. Some are frustrated
that there is no proposed release date for Angular 2.0. This begs the
question if it even makes sense to start with Angular 1.x and move to
Angular 2.0 later. The latest news with a promise of a less painful
migration route, with Angular 1.x and Angular 2.0 coexisting in the same
application, likely makes this a viable solution though.
I am not trying to discount the new features and conventions in Angular 2.0.
I fully support most of them, but my argument is that it should have been
introduced incrementally in the Angular 1.x codebase. Features of Angular 1.
x that are considered bad practices should be deprecated as part of this
effort. This is a practice we're already seeing when it comes to promise
methods like success and error which are headed for deprecation.
Different concepts
One might argue that some of the new features like bindings and change
tracking break the conceptual parity between Angular 1.x and Angular 2.0.
This is ok since you could have included meta in the bindings to opt in to
one-way, two-way or one-time bindings. WPF in .Net is an example of a
framework that went in this direction. I have argued from the very beginning
that one-time, for performance reasons, should be default. However, I
understand that this ship has sailed. Some disagree with me here, but my
argument is that one should opt into change tracking where it's needed,
instead of opting out where it's not needed.
Conceptual parity explained
I realize it might not be clear what I mean when I say the concepts are so
similar between Angular 1.x and Angular 2.0. I think the rich API surface in
Angular 1.x hides this a bit since you have to write your Angular 1.x code
a certain way to see the similarity. My argument is that the similarity is
really striking if you write Angular 1.x directives with “controllerAs”
style controllers – consumed by the directive. Not everyone realizes this,
but new features like bindToController and controllerAs have made the
interaction between the directive portion and the controller seamless. It
also gives you that sought after Angular 2.0 component feel. I have done a
more in depth comparison in the following article.
I like the new direction of using TypeScript for Angular 2.0, but I also
think it may make the two frameworks seem more different than they really
are. After all you could be writing Angular 1.x in TypeScript as well.
Perhaps a comparison of Angular 1.x and Angular 2.0, both in TypeScript,
would make them seem even more similar.
New Concepts
As with all new major versions there are a ton of new improvements in
Angular 2.0. Some of the exciting new features include components decoupled
from the runtime environment. This will likely give us some of the same
benefits we see out of React where you can map a component to completely
different underlying platforms (server, mobile and browser). Another big one
for large applications is native built in support for lazy loading. In
Angular 1.x we have to rely on third party libraries like ocLazyLoad to
achieve this. That said, these new features don't seem to break with my
previous argument that this could have been released incrementally as a
natural evolution of the 1.x line.
Going forward
Despite my criticism I am still certain that the final Angular 2.0 product
will eventually be a success. As I stated earlier, my complaint is not with
the breaking changes, but rather with how they are delivered. I personally
would have tried to evolve the exiting framework rather than via a clean
slate that adds months, maybe years, to the release timeline.
Anyway, this was just my take on this. I would really like to hear from
other developers on this topic and learn different perspectives. My views
are for the most part a result of working with Angular 2.0 in my Angular 2.0
repo on Github. Check out my live demo here if you are interested.
If you liked this article, share it with your friends. I also invite you to
follow me on twitter at