

All About Angular 2.0 (2014) - nfriedly
http://eisenbergeffect.bluespire.com/all-about-angular-2-0/

======
_mtr
And 11 days later...

> Several months ago the general direction of Angular 2.0 began to change in
> critical ways. I found myself fundamentally at odds with certain aspects of
> the proposed design. Still, I tried to keep an open mind and explore the
> various possibilities. Unfortunately, I haven't been satisfied with how
> things have progressed since then. At this point, there are too many
> irreconcilable differences. The Angular that's being built is not the
> Angular I signed up to work on

[http://eisenbergeffect.bluespire.com/leaving-
angular](http://eisenbergeffect.bluespire.com/leaving-angular)

~~~
serve_yay
See, I find this reaction to Angular understandable, but in some ways it
should apply more towards the current version than the upcoming one. I think
people should be unhappier with the pile of junk that they currently have to
deal with, than the fact that a bunch of it is going to change or go away.

It looks like the new version does away with some unnecessary concepts
(Angular itself has way too many concepts to deal with IMO) and adopts
upcoming standards like module syntax. (The AtScript stuff does seem like sort
of a nightmare, though apparently only contributors need to worry about it.)

I hated the time I spent with Angular 1.x and the whole thing strikes me a as
a complex and painful way to build applications. But the new stuff seems like
a slight course-correction if you want to build apps in that way.

~~~
marknutter
> I hated the time I spent with Angular 1.x and the whole thing strikes me a
> as a complex and painful way to build applications.

This comment baffles me. Not your cup of tea, sure, that I can understand, but
complex and painful? Angular, Ember, Backbone, React, etc. are all so vastly
superior to hacking together jQuery spaghetti code with imperative DOM
manipulation I can't understand how anybody wouldn't be elated with the
productivity gains they get from any of the modern frameworks, regardless of
their syntax preferences.

~~~
serve_yay
Who said anything about jQuery or Backbone?

About the complexity part, I am referring to the number of concepts one must
be familiar with in order to produce a working Angular app. I mean read TFA:
part of it breaks down the three varieties of directives you need to know in
order to do a thing.

And it's all like this, just a constant array of made-up concepts you have to
digest in order to make something happen in the DOM. It's such a pain in the
butt, and you constantly keep running into it -- whenever you need to output a
URL to the view, you get to go hunting for the docs for $sce and figure out
your exact use case just so you can spit out the damn URL.

~~~
marknutter
> Who said anything about jQuery or Backbone?

Well, if you're not using jQuery or Backbone at the very least to build SPA's,
then that just adds weight to my argument.

> About the complexity part, I am referring to the number of concepts one must
> be familiar with in order to produce a working Angular app. I mean read TFA:
> part of it breaks down the three varieties of directives you need to know in
> order to do a thing.

I agree wholeheartedly that Angular has far too many bizarrely named concepts
(transclusion being the worst offender), but if you don't put pressure on
yourself to learn a framework inside-out in order to use it then you can save
yourself a lot of initial pain. Simply using Angular's templating and two-way
binding system and nothing more (no directives, services, etc) saves you from
having to write an incredible amount of boilerplate DOM manipulation code. As
you start to learn more about the different features Angular offers you will
agree that most of them were necessary evolutions of the framework. Because it
evolved over time, it has become a bit bloated as frameworks often do so the
rewrite should be a welcome change.

> whenever you need to output a URL to the view, you get to go hunting for the
> docs for $sce and figure out your exact use case just so you can spit out
> the damn URL.

This is a built in security measure that you can easily override by providing
a blacklist of URLs. Unless you're keen on coming up with your own
sanitization logic, $sce is a very nice feature.

------
jeswin
I don't think Angular can be fixed, without throwing out everything in 1.x.

What's wrong:

1\. UIs are complex. Angular tries to solve this by attaching a lot of
programming capability into its templating language. That makes the template
itself very complex, which is the situation with Angular right now. Instead of
injecting some programming capability into html-like templating, a better way
would be to insert templating into a full programming language. Example, JSX.

2\. One of the great things about the evolving JS ecosystem (as seen in say,
the npm registry) is that components and libraries are tiny, and usually they
do only one thing. While there are a few disadvantages to this, it also gives
incredible flexibility. From my experience it reduces risk (because components
are smaller and better understood) and makes it possible to adopt newer
ideas/tech faster (because you could incrementally add small components).
Angular on the other hand, tried to do too much.

3\. Frameworks should enable users to re-use what they already know, instead
of making them go through dozens of pages of documentation. Learning Angular
takes as much time as learning JavaScript. We should encourage libraries which
take advantage of what programmers already know, so that they can spend time
working on features instead of learning the framework.

~~~
Bahamut
The general idea behind directives is still there in 2.0. JSX does come with
one fatal flaw in order to accomplish what it does - it requires extra build
tooling from the get go, which makes it that much more difficult for junior
developers to pick it up, along with the assault of other technologies, code
structure, and paradigms they have to pick up at the same time. The beauty of
the declarative direction of Angular is that it still is just regular old
HTML.

I do agree with #2, and it is a large part of why Angular is changing so
drastically with 2.0 - part of this can be evidenced in 1.x with components
being split into official optional modules (ngRoute, ngSanitize, ngAnimate,
ngTouch, etc.).

I somewhat agree with #3 - I feel like in order to properly use any framework,
there is no way around combing through documentation and the source code. I
have found that true with most libraries I have used. Angular's documentation
at least has the benefit of being very thorough compared to most at least. I
do disagree that libraries should only use what programmers already know
though - we should be pursuing how to best foster productivity in the long
term, and sometimes this means exploring new patterns.

~~~
colinramsay
I _think_ JSX can be used by doing nothing more than including the JSX
transformer via a script tag.

~~~
Bahamut
You're correct, but it is not recommended to use that in production.

~~~
TheAceOfHearts
Of course not, but if you're working in a small development environment it's
great :P.

------
marknutter
I'm really hoping this thread doesn't devolve into a framework flame war, but
those who are interested in angular or currently using it would find this post
very interesting. It clarifies a lot of the reasons why the Angular team felt
that they needed to do a complete rewrite instead of incrementally improving
1.x and it also outlines a lot of the exciting new features they hope to
include in 2.0. I personally appreciate their dedication to the web components
specification and a desire to seamlessly co-exist with it. Atscript
illuminated a lot of interesting programming concepts I'm not personally
familiar with as a front-end developer and I'm intrigued by them. Definitely
worth a read if you have time, Rob Eisenberg has a very extensive
understanding of Angular.

------
trainwrecks
sorry I just have to vent a little... I feel like I got wrecked twice jumping
on the GWT and then the Angular train. I am not sure if I have the energy to
jump on the Angular 2.0 train and get wreck once more... Any advice would be
helpful.

~~~
pjmlp
Never jump to framework flavour of the month until it gets mentioned in
Requests For Proposals by customers.

There is a reason we old timers are usually sceptic of new
frameworks/languages.

~~~
needusername
I have seen several large enterprise organizations build important
applications in AngularJS. The kind of applications that you don't want to
rewrite the UI in 2 years. In fact I know of one that will start in a few
months. I would not be surprised if AngularJS was in the RFP.

These days I just stay away from those projects and watch them burn.

~~~
pjmlp
Yes I can imagine that. 2014 was the first time we got AngularJS on a RFP.

Then again, I am glad the project is now gone, given the direction AngularJS
is going.

------
pavlov
_When AngularJS was first created, almost five years ago, it was not
originally intended for developers. It was a tool targeted more at designers
who needed to quickly build persistent HTML forms._

I guess this confirms it -- Angular really is the modern Visual Basic.

------
RivieraKid
I haven't read the article (I never used Angular), any idea how does it
compare to React? Does it use the one-way-only data-binding powered by shadow
DOM?

~~~
marknutter
It really only makes sense to compare React to Angular's Directives because
they are both trying to simplify the process of creating isolated, reusable
components with data binding built in. In fact, they both use in-memory
representations of the DOM to track model changes, although they differ in the
actual mechanisms for doing so. Angular uses "dirty-checking" which basically
tracks whether or not a model has changed in any way from its previous value
and it does this on a loop. It's very simple and inexpensive but can start to
perform poorly when dealing with large lists of items (in the tens of
thousands). React also has an in memory representation of the DOM they call
the "virtual DOM" (not to be confused with Web Components' "shadow DOM") and
differs from Angular in the way it employs its diffing algorithms to
efficiently and surgically respond to only the elements that need to change
when a model is updated. It performs better than Angular when dealing with
very large collections of items but I believe Angular is as performant or
better than React in the small case.

React also enforces certain restrictions by default when it comes to mutating
data. While Angular encourages "two-way binding" where data can be changed by
two different sources (e.g. the controller and the user changing the input
field), React encourages a strict policy of one-way data passing. It is
possible to restrict Angular directives to function exactly like React
components, however, if you subscribe to React's core philosophies about data
handling. For large applications, though, React applications get messy as they
need to pass data down a very long tree of nested components. They wrote the
"Flux" pattern to address this concern, but it really ends up looking like yet
another version of MVC (although I like it, personally).

Where React and Angular differ dramatically is in how they handle templating.
Angular's philosophy from the start was to embrace HTML and a declarative
programming style. They believe HTML should be embraced and extended using
"Directives" which is very much in-line with the philosophies behind the
coming Web Components standard. React's team, on the other hand, challenges
long-held assumptions about web development like not including markup in your
code, opting instead for a framework that not only encourages it, but requires
it. This is a controversial aspect of React, but it makes sense when you
actually try it. Some logic is better written imperatively (like if
statements, map/reduce, etc.) and it's nice having everything required to
render the component in one file. It does, however, require a compilation step
unless you use their imperative DOM manipulation library so in that respect
Angular is far easier to get up and running with (which is part of its
dramatic success).

In my mind, the only aspect where React really has a clear advantage is the
ability to run server-side, which allows you to pre-render components before
sending them to the client. This solves a variety of SEO and time-to-render
issues single-page web applications often struggle with. The only caveat is
that single-page apps don't typically need to be SEO friendly (like gmail or
google docs, for instance) so it remains to be seen how important this
differentiator really is. The React team admits it was really a happy side-
effect of the virtual DOM and not really the main reason they built it, but
it's compelling nonetheless.

One last thing I'll mention is that currently it's a very difficult time to
pick a horse in front-end development world. All signs point to Web Components
becoming the next big thing, but React has made a lot of people question
whether or not that's the correct approach. React has not made it a stated
goal of theirs to align with the Web Components specifications like the Ember
and Angular teams have. I can't say whether this is incredibly wise or
foolish, but again, it's compelling.

edit:

I forgot to answer your original question directly:

> Does it use the one-way-only data-binding powered by shadow DOM

It allows for both the use of one-way binding and two-way binding, which React
actually does too (although React's core team discourages using two-way
binding). Neither is powered by shadow DOM so I'll assume you meant virtual
DOM. I kind of answered this above but to re-iterate, both frameworks build up
virtual representations of the DOM in memory to better serve data-diffing, but
they both chose different mechanisms for doing said diffing which is outside
the scope of this post but definitely interesting to learn about. The
important point to take away is that you can restrict Angular directives to
function exactly the same as React components, the only functional difference
being the diffing algorithms under the hood and the templating systems used.

~~~
RivieraKid
Thanks for the detailed answer. So I guess you prefer Angular? On HN, it seems
that almost everyone that has tried React really likes it.

~~~
marknutter
I'm actually not sure what I prefer, to be honest. I am hoping web components
show up in IE and Safari soon so we can start using them but for now I'm not
sure which tech to fully invest in. The good news is they are all awesome in
their own unique ways and it's sometimes easy to lose sight of that with all
the flame wars.

------
ttrashh
Rob is a brilliant guy. We've used his WPF/Silverlight mvvm framework for
years. Our consulting company uses durandal.js for current projects. It looks
like Durandal v2 is now called Aurelia. I have high hopes for it, he knows how
to write a framework.

[https://github.com/aurelia](https://github.com/aurelia)

------
andrewstuart2
I'm glad to see official Google support confirmed, but I wasn't too worried
about that. It's an open source project, always available on github at any
version, and if Windows XP can survive this long without those provisions,
then I'm sure Angular 1.x will be last a long time.

I think the one thing that I would change for Angular 2.0 is the project name.
With so many of the framework elements being killed, and the whole thing
rewritten from scratch on a different language (AtScript, compiled to JS),
with a different API, with different paradigms, the name "Angular" and the
expected meaning it's built up to all developers involved doesn't apply
anymore.

I will soon need to update my resume to say that I'm experienced in Angular
1.x. I'll need to ask people developing projects built on Angular, "But which
version do you use?" I'd say the same gripes apply to Python 2 vs Python 3.

I don't want to go all Romeo and Juliet on the name here, but maybe there's
room for a semver 2.1 that specifies the hitherto-unspecified contracts you
can expect to be upheld if a project keeps the same name.

~~~
cheriot
Keeping the name succinctly describes how 1.x will stop adding new features
and the team behind it is building 2.0. It's a good move if the community
stays with them.

------
Nekorosu
The Angular's level of complexity looks overwhelming. I feel like it creates
more problems than it solves. I do hope I'm wrong, the man-hours put into it
are not in vain and there is a good niche for this framework.

------
sidcool
Very very comprehensive article.

