
Angular 2 Final Released - mikeryan52
https://angular.io/
======
EugeneOZ
I use Angular 2 in production since November 19, 2015 (alpha.46). Currently
I've built 3 web apps (40, 60 and 20 components each), 3 mobile apps (with
Ionic 2) and my employer have plans for more apps.

Breaking changes during alpha stage were expected, so I didn't have issues
with it.

Most positive things I want to highlight:

1\. Components are encapsulated and truly reusable (and without dependencies
hell).

2\. You don't need any "bridges" anymore to use 3-rd party JS libraries inside
your Angular app. Nothing need to be "angularized" \- twbs, D3, all just works
out of the box. Maybe it's even most important part for me.

3\. Idea of `(events)` and `[attributes]` is awesome, works really effective
and makes code much more easy to read.

4\. Performance is great.

5\. Community is friendly and have a lot of fun and patience, even to newbies.

6\. TypeScript gives a lot of bonuses with zero price - you don't need to
learn anything (you can just rename js to ts and it will work) and additions
to JS are simple and powerful.

7\. Cool abilities like AOT-compilation, server-side rendering and tree-
shaking.

Congrats to the all devs who are using Angular, congrats to the Angular team!
:)

~~~
NhanH
Any chance you can do a quick cons review too? Specifically comparing to the
weakness of Angular 1 like bloated complexities, issue with custom directives
or scope life-cycle.

~~~
Nemcue
Cons:

1\. Typescript. If your team isn't familiar with it it's not trivial to get
everyone on board. The up-front cost can absolutely be worth it in the long
run, but there's some friction in the day-to-day work with managing type
definition files and looking up esoteric lint-errors from the Typescript
compiler.

2\. RXJS. Canonical NG2 should use Observables, and rxjs is not a trivial
library to learn the ins and outs of. Add to that that there's no clean way of
doing testing with Observables at the moment (integrating with the rxjs
testing schedulers is very finicky). This is doubly true if you're using ngrx
(which you probably should).

3\. Template language. I'm one of those who don't think it's a very good idea
to bring a new DSL into html. I'd much rather do it the React-way of bringing
HTML into JS instead of relying on a very complex compiler to do magic behind
the scenes. This becomes a bit better with the template pre-compilation, but
it's still new syntax that you need to learn and keep in mind. Some of which
is not intuitive nor well documented (i.e. how pipes and parentheses work
together).

4\. It feels unfinished. This is to be expected since it's just on it's
initial release, but the sharp edges do show up quite a lot. For example we
very often have to do manual subscription and unsubscription of Observables in
Components. This feeling also goes for quite a few of the community addons,
such as the browser-extension. While I absolutely applaud their efforts, it's
far from reaching the quality of e.g. the Ember-Inspector.

5\. Sub-par debugging experience. When you get any errors there's a mile long
stack trace filled with rxjs and zone.js garble, making it very hard to
actually figure out what's going on. When there actually are custom error-
messages they are not very informative, with you having to fundamentally grok
how parts of NG2 works to even come close to understanding why it's not
working (getting this a lot with the change detection).

6\. Lack of documentation. I tried to stay very far away from Angular 1 since
I found its documentation to be very low quality (probably a symptom of
Angular 1 being poorly engineered as well). The NG2 docs are definitely
better, but I feel like my mental model for reasoning about how things work
was still very weak when I had finished going through the docs. There's some
really huge gaps in there (testing) and a lot of the really complicated stuff
that you will stumble over is only really documented in semi-old blog posts.

~~~
NikhilVerma
It's very strange to me, any one of the cons from 3-6 will make me avoid a
framework. Do you think the pros of the framework outweigh these serious cons?

~~~
Nemcue
At the moment? No, I don't think so.

To be brutally honest I think the only reason why this is on HN frontpage is
because of its name. It's quite telling that they kept the name despite it
being a totally different beast with (imho) an entirely different audience. No
way they'd get this much support from the webdev community otherwise.

However I do see the potential, and one should not forget that this is just
the first version, straight out of the oven.

Give it some time and I'm sure it will improve.

~~~
emodendroket
It kind stinks because they iced the growth of angular 1 when they announced
it.

------
gkoberger
As someone who uses Angular 1 currently but would pick React for their next
project, I'd love to see a list of reasons why I should use Angular 2 over
React.

If nothing else, Angular just stranded all their developers, while React has a
huge head start on mindshare/plugins/tutorials/etc.

~~~
jasonkester
I recently started a new front-end-heavy project and ended up just using
Angular 1 instead of React. The decider for me was the amount of tooling that
React needs you to have in place just to get up and running.

React expects you to do your development on some flavor of Unix, and really
doesn't have a sane plan for Windows, so you lose VS.NET and its huge
productivity gains. And it needs tools upon tools upon tools to set up,
whateverify, transpile and pack the files you write into something that can
display in a browser. Again, this all seems to want to run from a Unix command
line.

I want to edit some HTML and Javascript, then reload the browser and see my
changes. Angular isn't perfect, but at least it lets me do my thing without
adding a bunch of extra hoops.

~~~
lacker
_And it needs tools upon tools upon tools to set up, whateverify, transpile
and pack the files you write into something that can display in a browser._

I think this was true six months ago but now there is create-react-app. You
might want to try it out - you won't need to whateverify your code, you just
need that one tool. Also it works on Windows.

[https://github.com/facebookincubator/create-react-
app](https://github.com/facebookincubator/create-react-app)

 _I want to edit some HTML and Javascript, then reload the browser and see my
changes._

With create-react-app the browser will know you've made a change, and reload
for you ;-)

~~~
jasonkester
_npm install -g create-react-app_

The fun thing watching the new world of Javascript is that overtooling is so
built in to everything that nobody even realizes how many tools they're using.
You can't even install this thing until you have the standard pile of
javascript tooling in place. And it never occurred to them to even mention how
to get said pile set up.

Once set up, this still uses all the same stuff. It just removes a few steps
to produce the Big Red Button you press to run it all.

~~~
BigJono
This is the problem I have with all these "easy" setups and boilerplate
projects. It doesn't matter how you set up your project, unless you do it
wrong, it all comes down to a one liner in the end. All these things do is
hide the complexity from you with the goal of being able to "get up and
running quick", which I find fairly pointless for projects that are of a
significant enough size that you're considering using React or Angular for
them. You're much better off learning all the tools and understanding how your
project works.

But then again, the thing about the overtooling is: I can't find anything in
my React stack that is unnecessary or can be removed. And really, all it is is
React, Redux and Webpack. I think the complexity of front-end Javascript
development is blown a little bit out of proportion.

~~~
dismantlethesun
Ah well rather than being uncessary, theres' alternatives for all of those
options.

React could be replaced with Preact or Inferno.

Redux could be replaced with MobX or RxJS.

Webpack could be replaced with JSPM.

------
petilon
I evaluated React and Angular 2 several months ago and picked React. Some of
the issues I found in Angular 2:

The HTML template in Angular 2 is stored in a string. This has several
disadvantages:

1\. Editors can't do syntax coloring.

2\. Editors can't do auto-indenting.

3\. Editors can't offer "intellisense" suggestions.

4\. Editors can't match tags.

You embed variables in this template string like this:
'<div>{{hero.name}}</div>'.

This means:

1\. Compilers can't find typos or find syntax errors at compile time.

2\. If you make a typo in the variable name you don't get a compile-time or
run-time error, instead the value is simply not displayed!

3\. Tools can't refactor (i.e., rename) variables embedded inside the
template.

4\. No intellisense for the embedded expressions.

You have to learn weird syntax such as ngFor whereas in React you just use a
JavaScript for loop.

In React you embed HTML inside the TypeScript and VisualStudio treats both the
HTML and the TypeScript as first-class citizens. You get compile-time checks
and intellisense for both the HTML and the TypeScript code! You can even put
breakpoint inside the template and step through loops whereas in Angular you
can't step through an ngFor.

Note that some of the above may have changed since I last looked at Angular 2.

~~~
dvdcxn
>The HTML template in Angular 2 is stored in a string. This has several
disadvantages

This is patently false. Just use "templateUrl" instead of "template". This
allows you to specify a file instead.

This is the way I always did it in angular 1 as well. I don't really
understand why style guides & general practice recommend embedding html in the
javascript though. It's horrible.

~~~
bcherny
If you're using TypeScript + templateUrl, you won't get static checking of
templates. With React + TypeScript, you will.

~~~
marpstar
This is literally the only thing in our Angular2 setup that I'm really
missing. Besides that, I've really enjoyed working with it (by way of Ionic 2)

------
electrotype
Serious question : Why are SPA frameworks so popular these days? When someone
asks "What should I use for web development?", It's now all about
React/Angular/Ember/etc.

But when I look at how are built the sites I like and visit frequently, I'd
say 95% of them are not SPA, they are classic sites where the server generate
each page (sometimes with one or two Ajax requests)!

The Single Page pattern is great for desktop-like applications such as Gmail,
it's obvious. But otherwise, I don't know... I think I still prefere the
"feel" of classic websites.

~~~
TelmoMenezes
What's with the "serious question", "genuine question", etc? Mostly I see this
mannerism prefacing questions that could not reasonably be taken as a joke or
provocation.

Serious question: are people so touchy these days that you have to assure them
that you are not being hostile before even saying something?

~~~
akst
Someone having a different point of view online isn't that radical of a
concept. Especially considering how easy it is to misinterpret the tone of
someone's remark online. It just shows you're going out of your way to clarify
your interested in a genuine discussion.

~~~
TelmoMenezes
Fair enough.

For me it has the opposite effect, it makes everything sound less genuine. But
hey, I'm just some guy, if people like it...

I find unnecessary clichéd phrases very annoying (e.g "going forward"). Maybe
I'm alone in this. It's not because of pretentiousness or language puritanism,
it's that it makes me feel that I'm reading something created by corporate PR
or some other soulless entity with ulterior motives. My rule of thumb: if you
have nothing creative to add, just be simple.

------
Yhippa
Front end development is crazy these days. I remember on my road to learning
Java EE banging my head on the wall trying to put together things like
dependency management with Maven, ORM's, and all sorts of arcane concepts and
patterns. It took me a long time to get to that point but now it seems all too
familiar.

As someone coming up to speed with frameworks like React and Angular 2 it
feels like that all over again.

~~~
jacobsenscott
That's Conway's law for you. All three frameworks were built by meglogcorp,
and they all feel exactly the same.

It is funny that after the Rails driven success web devs had moving away from
J2EE they are falling right back into the same traps - ultra complex bloated
frameworks built on a terrible language.

~~~
choward
Javascript is definitely a terrible language, but it is the only language for
the web unless you consider languages that transpile to javascript. Are you
suggesting not using a javascript framework, using a transpiled language
instead of javascript, not writing any front end code at all, or doing
something ridiculous like turbolinks?

~~~
calsy
Why would you consider JS to be a terrible language? It's not a requirement to
use a framework to code in JS.

~~~
jomamaxx
"Why would you consider JS to be a terrible language? "

JS is kind of a 'bad language' because:

1) It's missing some pretty important things. Try to determine if a value is a
number. Seriously. Look into that mess. Or anything else. Doing simple type-
checking is crazy, and we basically are resigned to 'best practices' \- which
is crazy.

2) Prototype chaining is a neat idea and has some merits - but in reality it
makes things super-duper complicated. Ask 10 JS devs how it works and get 21
answers. That is bad.

3) Almost nothing is built in. You need to use a lot of 3rd party libs to do
common things.

4) There is no such thing as 'JS' \- ever browser, every version - you get
completely different implementations. Maybe we can't blame 'JS' \- but
pragmatically, this means JS is a problem.

A minor issue is issues with packaging, encapsulation and scale, which is also
a function of loose typing. When JS programs get complex, they get unruly, and
you wish you might be able to do things in an OO language at that point.

JS is really light, and that has advantages - and I think it's the best
language for a lot of async things - and UI's are inherently async - so that's
good.

In 5-8 years JS might be 'stabilized' in terms of libs or de-facto standards
and it will grow.

To anyone who's programmed in other, more established languages, I think it's
clear JS has some weirdness that doesn't need to be there.

But I like it.

~~~
Klathmon
1) Isn't it just (!isNaN(num) && isFinite(num))? I know that's pretty far from
intuitive, but it's not as bad as you made it sound. That being said, i'd love
an `isNumber` function at some point...

2) I felt the same way for a while, but recently I was working on something
where I ended up really "abusing" the prototype system, and when you actually
spend the time to learn it, it's not that bad! It's different, that's for
sure, but it's not bad.

I like to think sometimes that if javascript came before C, would we still
call many of these things "bad"? Would we call javascript's equality table
"weird", or would it be C's that was the weird one? Would C be the star in a
talk labeled 'Wat' where they laugh at the absurdity of 'a' == 97? So much of
the stuff that people complain about in JS is because they have expectations
from other languages. Sometimes those expectations are a good thing, but other
times they are just different, and taking the time to actually learn how and
why it's different can make you a much better programmer.

3) I genuinely like this about JS. There is no "one true way". The language is
free to evolve, change, get new features, get new functionality, and easily
"polyfill" old browsers outside of the release cycle. And that's important in
JS because there is no one "authority". Keeping the stdlib small means that
it's easier for new implementations to crop up, and it leaves the "niceties"
to be developed by libraries. It's what allows libraries like ramada and
lodash to be so powerful. They wouldn't be where they are today if the stdlib
was more opinionated/complete.

4) But again I kind of like this. It does often make things more difficult,
but at the same time it improves the ecosystem. I honestly believe that the
fact that there are competing implementations is pretty much the only reason
javascript (and in some ways, all dynamic languages) are as fast as they are
today! Not only that but the fact that there are multiple competing
implementations keeps most devs "honest". For the most part I don't need to
worry about someone writing code that will run on version X on platform Y. I
don't need to worry that the next "update" will require us to spend a week
cleaning up removed functionality. It does lead to a lot of "crap"
accumulating in the language, but over time that crap can and will be removed.
JS is a fluid, constantly-evolving language, and because of that you tend
target a point in time, not a "release", and the impressively awesome
backwards compatibility means that while your older code might look outdated,
it's not going to suddenly stop working.

I do agree that complex JS programs need much more tooling to be manageable,
but it's working out very well in my experience. It's just different.

~~~
jomamaxx
"1) Isn't it just (!isNaN(num) && isFinite(num))? I know that's pretty far
from intuitive, but it's not as bad as you made it sound. That being said, i'd
love an `isNumber` function at some point..."

You just proved my point!

A) Even if you are correct - it's _terrible_. This is completely ridiculous
that there's no basic check for _extremely common_ and mundane type-checking.
Moreover, it's the same issue for other types!

B) Worse: you're wrong.

isNaN('100') = false isFinite('100') = true

The string '100' would pass your check as a Number :)

Underscore uses:

"toString.call(number) === '[object ' \+ Number + ']';"

So noodle on that for a while: I'm assuming you're an experienced JS
programmer _and you can 't test to see if something is a number_! Embarrassed?
It's ok. 9/10 JS programmers would get it wrong. I had to look it up! Which is
my point - it's really bad!

2) Prototyping is not bad because it's prototyping - it's bad because it's
really confusing. Point: nobody has - or will 'borrow' this idea form JS.
Again - almost zero JS devs really understand how it works.

3) Again I disagree. There definitely should be a 'true way' for the most
common operations. There should only be one 'true way' to test to see if
something is a Number (!) - and for basic things like string operations - 'one
true way' is better. For so, so many reasons.

4) "For the most part I don't need to worry about someone writing code that
will run on version X on platform Y" \- sure you do. You cannot use 'const' or
'let' in Safari/iOS. You can in Chrome. That's just the tip of the iceberg.
There are dozens of such mismatches - and it's a fragmentation nightmare.

Now - I agree with your point about 'competing versions' hey, that's great.
But they are 'not the same platform' \- which is totally destructive.

~~~
abaco
FFS read the code before spouting random stuff.

(!isNaN('100') && isFinite('100'))

Negation (!) before isNaN()

~~~
Klathmon
he's right...

(!isNaN('100') && isFinite('100')) === true

My check would treat '100' as a number, so if i did something like this it
would break unexpectedly:

    
    
        var num = '100'
        if ((!isNaN(num) && isFinite(num)) === true) {
          console.log(num + 10)
        }
    

You'll get "10010" printed to the console.

~~~
abaco
Well that's because this is checking if a value may be a valid number. It's
not safely converting the value to a number. That's done after a parseFloat()

~~~
jomamaxx
You guys make my point for me.

There's no way on earth we'd be arguing about such a ridiculously trivial
thing for most other languages.

Nobody should have to look any of this up.

Yeah, we work around it ... but it drives me crazy. :)

------
pramttl
I have been using Angular 2 for 3 months now and so far have loved it (except
for the breaking changes in RC series and updating each time). Glad 2.0.0 is
here. Here are the few things I loved, amongst other interesting features:

1\. Typescript awesomeness: You can write plain JS or give type hints in
Typescript. Typescript is awesome, because it is a superset of Javascript and
compiles to Javascript. (Typescript > ES6 > ES5)

2\. Modular code: It is is much easier to manage Angular code as it grows
(compared to AngularJS). Components could be made independently and reused
within other components using component interaction [1] (@Input, @Output)

3\. Template Directives: .html template directives are available unlike
ReactJS. A ReactJS vs Angular2 blog post online [1] argued that that putting
HTML in Javascript is better than putting Javascript in HTML. I'd argue that
template directives like ngFor, ngIf, etc are much simpler to understand.
Also, it is easier to collaborate with a designer/half-developer who knows
some html/scss and doesn't know Javascript than working in ReactJS where every
collaborator has to know JS. This way, it is also easier for someone to
gradually learn the framework. For me, template directives are a big win. If
someone wants to construct templates with plain JS, that is still possible in
Angular.

4\. @angular/router is better than AngularJS routing and we don't have to use
a 3rd party library (like ui-router was more popular in AngularJS than the
angularjs router)

One thing that I have found annoying is that: UI libraries for Angular.
Example: material2 (currently at alpha.8) [3] are not complete yet and lack
several useful components. This can be a problem if you are looking to quickly
build a complete, good looking UI. Hopefully, now with Angular 2.0.0 out;
Angular team could focus on quicker development of material2, so we have all
the AngularJS Material UI goodness with Angular.

[1] [https://angular.io/docs/ts/latest/cookbook/component-
communi...](https://angular.io/docs/ts/latest/cookbook/component-
communication.html) [2] [https://medium.freecodecamp.com/angular-2-versus-
react-there...](https://medium.freecodecamp.com/angular-2-versus-react-there-
will-be-blood-66595faafd51) [3]
[https://github.com/angular/material2](https://github.com/angular/material2)

~~~
xeromal
We've been using Angular 2 for about 6 months now. Having things deprecate
several times like the routing engine was annoying but that's the cost of
being on the cutting edge. The side benefit is that we learned a lot about the
inner workings of Angular.

I agree with your annoyance with the UI libaries. It's been a PITA just to
find a working datepicker. We eventually rolled our own starting with the
source of an abandoned date picker project. Haha.

~~~
Bahamut
There is a working datepicker here: [https://ng-
bootstrap.github.io/#/components/datepicker](https://ng-
bootstrap.github.io/#/components/datepicker)

Source code here: [https://github.com/ng-bootstrap/ng-
bootstrap/tree/master/src...](https://github.com/ng-bootstrap/ng-
bootstrap/tree/master/src/datepicker)

Be aware, it is not perfect atm, especially around validation, but it is
pretty much the only datepicker out there for ng2 in the open source world
(not even Angular Material 2 has one).

~~~
jeddf
Angular Material 1 only got its date picker in Oct last year (0.11.2). Oh how
we celebrated!

~~~
nikon
Have been making use of this component. This issue[0] regarding supporting
floating labels is quite sad really.

[0]
[https://github.com/angular/material/issues/4233](https://github.com/angular/material/issues/4233)

------
joshschreuder
There's more info on future plans here:
[https://angularjs.blogspot.com.au/2016/09/angular2-final.htm...](https://angularjs.blogspot.com.au/2016/09/angular2-final.html)

Specifically:

    
    
      > Bug fixes and non-breaking features for APIs marked as stable
      > More guides and live examples specific to your use cases
      > More work on animations
      > Angular Material 2
      > Moving WebWorkers out of experimental
      > More features and more languages for Angular Universal
      > Even more speed and payload size improvements
    

And immediately:

    
    
      > Semantic Versioning

~~~
Lx1oG-AWb6h_ZG0
Ha! I foolishly thought that when ng2 hit RC, it actually meant things would
be stable. Keeping up with the ridiculous amount of breaking changes (the
router, for example) through the RC versions was a horrible experience.

~~~
xeromal
Hahaha. No shit. Stackoverflow would be like "You are using the wrong router.
Use version x." Then someone said "No, version x is deprecated as of last
night. Use version z. They skipped y after abandoning that too."

------
_alexander_
As see I on github there are lot of issues -
[https://github.com/angular/angular/milestone/58](https://github.com/angular/angular/milestone/58)
for final release., however they released it. These issues are not important?
Who can clarify?

------
DigitalSea
Rob Eisenberg and his nimble team beat Angular 2 to the punch all the way back
in July when Aurelia final was released. Before considering Angular,
considering checking out [http://aurelia.io](http://aurelia.io) \- easier to
learn, no third party dependencies and great support. I applaud the Angular
team for sticking it out, but I am afraid they released far too late to
compete with the likes of React, Vue and so on.

~~~
oneshoe
I now have several Aurelia apps in production. I've also created an app in
Angular (v1), and another using Ionic (v1) - which was great. But, I can't
express how well Rob and his team executed on this project. Documentation
_could_ be a little better in a couple areas but this is a place where they've
done extremely well also (contradiction I know - but, for example the cheat
sheets are amazing and documentation is complete on most things but there are
some classes that are still not documented well enough). If you want to
develop in Aurelia - just the community on Gitter - they are extremely
responsive and very helpful.

~~~
stephenhuey
The documentation has been improving since January, and I expect there to be
plenty more in a short time because for over half a year they were focused
more on getting from beta to a full release. But even with the cheat sheets it
felt like there was plenty to get work done because the complexity isn't so
high with Aurelia - less to get confused about! And I agree about the Gitter
channel being very friendly.

------
kensign
Before you consider Angular 2, do yourself a favor and check out
[http://aurelia.io](http://aurelia.io).

Compare the differences and consider the trade offs with complexity vs
simplicity. It's worth a consideration.

~~~
stephenhuey
Please! The more of you that join us in Aurelia the better it will be, and I
think the Angular community will benefit as well because at least they would
become aware of some more best practices they could use to improve Angular.

------
georgefrick
As a developer who didn't care for Angular 1.x and strongly argued in favor of
a simple approach for years (Backbone, etc).

I've been using Angular 2 in a major enterprise project since RC1. Even with
some of the headaches between RC releases; all of the reasoning behind those
changes is technically sound.

It's easy to write components and wire everything, and even small things like
async validators are fluid and easy to implement.

I'm loving it, and while the entire build system is still a bit of a dumpster
fire; we're doing great on things like testing, code coverage; etc.

There are a lot of problems with lazy developers hoping a blog will tell them
how to do every little thing. The source code is on Github. If you can't get
something working right; maybe go read the source code of the classes you are
interacting with. I've found 99% of the time now that simply reading through
the code gives me not only the transparency needed, but a clear path to a
better solution. Kudos to them on the new forms; they're awesome.

~~~
Bahamut
One thing that is hugely helpful that many developers don't do is read the
tests for the library they use - in particular with Angular, reading the tests
in the Angular codebase actually assist greatly in how to use a feature.

------
KyoChunho
It's a fantastic framework and I'm looking forward to building a ton of cool
stuff with it.

Though next week's announcement...

 _Angular 2.0.1 RC 1_

It's Change Log will read:

    
    
      * Routing has been rebuilt.. all previous versions not compatible
    
      * We decided to rename the NgModule decorator to NgYouMAD?
    
      * All Internet tutorials no longer work... Good Luck relearning!

------
wcarss
Is there a definitive angular versus react versus ember (or others)
pros/cons/community status page out there somewhere?

~~~
swalsh
You know what, these religious debates need a war to settle the question.
Let's get 3 of the best teams for each stack, have them build the same 4 apps
that cover a few of the most common scenarios... and let's see who's solution
is done the fastest, is most maintainable, and has the best performance.

~~~
davidw
Emacs, of course.

------
mgadams3
AngularClass's free project-based course on Angular 2 by Scott Moss has been
pretty popular in the release candidate stage with 10k students so far. Will
be getting updates with official release changes soon.

[http://courses.angularclass.com/p/angular-2-fundamentals](http://courses.angularclass.com/p/angular-2-fundamentals)

------
sturmeh
Can't wait for Angular 3!

------
jcadam
Never used Angular. I was considering it for one project, but the uncertainty
around the whole Angular 1/2 thing made it too risky, so I stuck with what I
knew at the time (Backbone/Marionette).

Tried Ember.js more recently, didn't much care for it. I think I'm just not a
fan of large frameworks.

Now mithril.js ([http://mithril.js.org/](http://mithril.js.org/)) has finally
lured me away from Backbone :)

------
WA
Right now, I'm considering which works best for me. Requirements: App for
Android & iPhone plus Web-based app. The most complex part is a Graph with
interactions (such as highlighting a specific value). It should feel snappy,
although I don't make heavy use of neither gestures nor OS-related features.

Ionic 2 + Angular 2 seem to be the best choice, since I can basically write
the app once and release for all three platforms.

 _React Native_ has the downside that _React_ and _React Native_ are two
different things. Be aware that there is no such thing as _React Native for
the web_. There's something in development right now, but nothing stable.

 _Truly native_ : I can't support three platforms as a single developer and I
don't feel like outsourcing it.

I'll go with Ionic 2 + Angular 2, although Ionic 2 still has quite a few bugs.
For example, the _zoom_ attribute on <ion-scroll> doesn't work – which is
critical for my app.

Sure, there are hacks and this reminds me on the discussion from the other
day:
[https://news.ycombinator.com/item?id=12477190](https://news.ycombinator.com/item?id=12477190)

Yes, it's all very hacky. But there's really no alternative I guess.

~~~
rubber_duck
Check out nativescript, it's TS/angular 2 equivalent to React Native.

------
scotchio
Shameless plug: Free Getting Started Video Course on Scotch.io

Getting Started with Angular 2

[https://school.scotch.io/getting-started-with-
angular-2](https://school.scotch.io/getting-started-with-angular-2)

------
sergiotapia
Question for Angular devs: Why would I use Angular 2 and risk being left in
the wind like Google did with Angular 1?

~~~
jbigelow76
Why would you use any open source codebase and risk being left in the wind by
the maintainers of said codebase?

~~~
sergiotapia
Faith. Google has already broken that faith with 1.0, why do I renew the
faith?

------
mshenfield
Found this pretty helpful in grasping differences between angular 1 and 2.

[https://angular.io/docs/ts/latest/cookbook/a1-a2-quick-
refer...](https://angular.io/docs/ts/latest/cookbook/a1-a2-quick-
reference.html)

------
cubef
I've been developing a large web app with ng2 and Dart since april, no
framework is perfect, but this combo is a joy to work with.

Did ng1 and react with JS before, react was more enjoyable but in the end it
just doesn't compare.

Anyway, great to see the release :)

------
boxctim
"Loved by Millions" might be overstating things a bit

~~~
arc_of_descent
Classic sales talk, huh?

Devs must be in the thousands, but the users of their apps might figure in the
millions :)

~~~
h1d
Users don't necessarily love the underlying framework being used though.

~~~
softawre
This just in: billions love javascript!

------
nsxwolf
I'd be interested to hear people's experiences with running Angular 1 and 2
side by side in the same application for the purposes of incrementally
migrating an Angular 1 codebase.

------
omouse
I heard that a particular company, Rangle, worked on AngularJS2 and from what
I've heard of them they're an MVP/dev-agency so it isn't surprising to see
some of the complaints here about broken backwards compatibility and bad
documentation around testing.

Seems few people know how to steward a free/open source software project that
has lasted over 5 yrs.

~~~
Bahamut
Rangle only created an Angular 2 successor to Batarang. They had nothing to do
with core Angular 2 development.

Angular 2 in beta/rc was in many ways rapid iteration on top of
experimentation to get the core APIs & developer experience right. They have
finally reached a stability point where they feel completely comfortable with
the framework they have ended up with as a result, thus the formal release of
2.0.

If you've actually paid attention to the development cycle of Angular 2, it
was very fast - it turns out that Google moves much faster than most shops,
which was seen in full display during alpha/beta/rc. However, that goes with
the territory there, and the versioning did not lie. It is now following
semver though, so we shouldn't be hearing of these problems anymore.

------
chrisballinger
I expected angular.io to be a flashy example Angular 2 SPA and was
disappointed when I realized it was just a regular old static HTML website. I
guess most of the content is more suited for a static site. At least the
search bar on the docs page looks like it has some Angular going on. Also it
would be neat if the docs had dynamic examples instead of screenshots.

~~~
unknowingone
But can it compete with this?

[https://react-bootstrap.github.io/components.html](https://react-
bootstrap.github.io/components.html)

~~~
Bahamut
I think ultimately ng-bootstrap* ([https://ng-
bootstrap.github.io/](https://ng-bootstrap.github.io/)) will be better, but
I'm biased. API signature looks much better than shoehorning everything into
components that don't belong there - we have a lot of work to go though, so it
currently is still a work in progress.

* I am a part of the UI Bootstrap/ng-bootstrap team - we worked on ng-bootstrap starting back in last August/September and have the benefit of two of our team members currently working on the Angular team.

~~~
winstonewert
Could you elaborate on what you mean by "shoehorning everything into
components that don't belong there"?

~~~
Bahamut
There seems to be a lot of advocacy for tossing everything into the component
tree in the React ecosystem - recently I got linked to a snide remark by Ryan
Florence on Twitter implicitly arguing for putting everything in the component
tree, including constructs that should have a better separation such as
routing (which the tweet appeared to be a reference to).

Some services don't belong in JSX though - this is why you have the idea of
stores in Flux/Redux/etc. Some data doesn't make sense to couple to the
component hierarchy - doing so makes it very easy to create dependencies on
the component tree, which decreases modularity, as well as has perf
ramifications by increasing the DOM elements that get rendered unnecessarily
by React. Some examples are data models, routing, and interactions with non-
element DOM api (window.location, XHR, etc.). This also has a side-effect of
increasing difficulty of testing what generally should be vanilla constructs
not tied to various frameworks/libraries unnecessarily.

~~~
winstonewert
I can see the objection to putting routing information (and similar) in the
component tree.

But you were talking about bootstrap components which obviously do belong in
the component tree, so I'm confused by your response.

~~~
Bahamut
Not everything is a component - as I pointed out in another response below, a
modal is one clear example where you want an imperative API.

------
chillypenguin
I wonder what "Final" even means in this context. Google has already admitted
that the Angular team uses the term "Release Candidate" to mean something
completely different to how every other software company in the universe
understands it. (Listen to Adventures in Angular podcast, episode 105.)

A very rocky road ahead, methinks.

------
ergo14
It is interesting how people are debating here, angular this, react that...

Yet there is Polymer that just works, has a great ecosystem, awesome material
design support and is a breeze to work with (+ its fast too).

Right now there was 2.0 announcement and new version really supports easy
migration path unlike Angular 2.x.

~~~
adamors
Does anybody actually use Polymer? Frontend jobs are mostly either Angular or
React related.

~~~
ergo14
Ofcourse, tons of "enterprises", ING, Comcast, Salesforce, IBM, General
Electric, Electronic Arts, (Slack?) and Google (obviously).

There are also tons of components to pick from, someone is obviously building
them. We are rewriting parts of RhodeCode UI in polymer right now and everyone
is very happy about how that goes.

There are plenty of job offerings on polymer job channel and in the wild.

It just seems that HN folks are ignoring anything that is not called
Angular/React because its not hyped enough :)

------
SonicSoul
congrats to ng-team!

funny i just spent an hour yesterday upgrading to 3.0.0-rc.7

I see their quick start has been updated to use the final.
[https://angular.io/docs/ts/latest/quickstart.html](https://angular.io/docs/ts/latest/quickstart.html)
<= great way to get started.

agree with other comments that RxJS is a tough library to learn but I love
that they used it instead of re-inventing that wheel. It is incredibly
powerful and solves a lot of asynchronous programming problems. you can see
all of the methods visualized with marbles here:
[http://rxmarbles.com/](http://rxmarbles.com/)

~~~
jffry
Surely you know that 3.0.0-rc.7 was deprecated in favor of 3.0.0-rc386, right?

:-p

------
julenx
Announcement URL
[http://angularjs.blogspot.ch/2016/09/angular2-final.html](http://angularjs.blogspot.ch/2016/09/angular2-final.html)

------
waltero
Nice, played around with Angular 1 and 2 - Angular2 with its use of components
reminded me of making front-ends with the Apache Wicket framework some time
ago.

This might appeal to java full stack/backend engineers that need to once in
while show case a nice and shiny GUI. It my experience, the combo of Angular
with Bootstrap/Font awesome works just fine for that.

Very positive to have static typing through TypeScript as well. But also here
I am quite biased for I never liked the concept that 'everything is just a
var' ;)

------
stevehiehn
Yes!!, I was starting to get nervous I jumped the gun using it at work!

------
dschiptsov
How many hundreds of npm dependencies in the default install?

Is Leftpad included?

~~~
renke1
Why does it matter?

~~~
rajangdavis
[http://www.haneycodes.net/npm-left-pad-have-we-forgotten-
how...](http://www.haneycodes.net/npm-left-pad-have-we-forgotten-how-to-
program/)

TL;DR: Left Pad is a NPM package that was removed by it's author in protest.
Apparently, a ton of other packages broke as it was a major dependency across
the NPM ecosystem.

------
awjr
Looking at
[https://github.com/angular/angular/milestones](https://github.com/angular/angular/milestones)
I was slightly surprised to see 30 outstanding issues. Reading the
announcement they have been careful to bring semver into the mix. This should
speed up release as well as start bringing through some of the 2.1 stuff
quicker.

------
jiggly_piff
I dont understand why they claim you can make native mobile apps with angular2
ionic and native are two very different things

~~~
jbigelow76
Nativescript [1] allow for fully native (no native webview wrapper) apps being
built with Angular 2 on top of Nativescript.

1\. [https://www.nativescript.org/](https://www.nativescript.org/)

~~~
DonHopkins
I'd love to hear the experiences and opinions of anyone who knows about
building iOS and Android apps with NativeScript and Angular 2 [1], or who has
used NativeScript [2] itself, please.

NativeScript has a JavaScript<=>Java bridge on Android, and a
JavaScript<=>Objective C bridge on iOS, like a cross platform version of
Apple's ObjC bridge used in OS/X JavaScript for Automation [3] [4] [5] (but
AFAIK Apple's ObjC bridge is apparently not available for developers to use as
a framework, nor on iOS, nor of course on Android).

Unlike React Native's JavaScript engine, it runs in the UI thread, using V8 on
Android and JavaScriptCore on iOS, and you can call all the platform specific
APIs directly, subclass and implement Java classes and Objective C classes and
protocols, call methods and functions, and pass objects back and forth, write
your own plugins in TypeScript, JavaScript, Java, Objective C, etc.

[1] [http://docs.nativescript.org/angular/tutorial/ng-
chapter-0](http://docs.nativescript.org/angular/tutorial/ng-chapter-0)

[2] [https://www.nativescript.org/](https://www.nativescript.org/)

[3]
[https://developer.apple.com/library/content/releasenotes/Int...](https://developer.apple.com/library/content/releasenotes/InterapplicationCommunication/RN-
JavaScriptForAutomation/Articles/Introduction.html)

[4] [http://tylergaw.com/articles/building-osx-apps-with-
js](http://tylergaw.com/articles/building-osx-apps-with-js)

[5] [http://developer.telerik.com/featured/javascript-os-x-
automa...](http://developer.telerik.com/featured/javascript-os-x-automation-
example/)

------
rukenshia
So I have never used Angular before but work with Vue. Looking at the
tutorial, why is there the syntax of [(ngModel)] (equivalent would be v-model
for me) and _ngFor_ = (v-for)? Why are they different? It looks kind of
unnecessary to me. I would really appreciate if someone explained it.

~~~
zygimantasdev
[()] indicates two-way binding. If you curious you can read more in docs [1],
while ngFor is just an attribute directive which changes DOM [2]

[1] - [https://angular.io/docs/ts/latest/guide/template-
syntax.html...](https://angular.io/docs/ts/latest/guide/template-
syntax.html#!#two-way-binding-with-ngmodel) [2] -
[https://angular.io/docs/ts/latest/guide/attribute-
directives...](https://angular.io/docs/ts/latest/guide/attribute-
directives.html)

------
kabes
Look at the weekly meeting notes: [http://g.co/ng/weekly-
notes](http://g.co/ng/weekly-notes) . So 3 days ago they were talking about an
rc7 to test out and now all of the sudden we've got a final?

------
nagarjun
How does the Angular CLI compare to the Ember CLI? Also, how does Angular 2
compare to Ember 2.8?

~~~
szines
Angular CLI is actually Ember CLI under the hood.

You cannot really compare these frameworks because Ember is far ahead of all.
Super stable, matured, adopted the best practices, huge addon ecosystem,
brilliant community, easy to learn, great documentation. Quite an obvious abd
best choice. Life and development is just super easy and fast with Ember.

------
doczoidberg
Nodody mentioned angular universal here. I think it's a big win to prerender
the SPA on the server. It's faster, more mobile friendly and pages can be
indexed by search engines.

IDEs have to implement better support for NG2 but this will come over time.

~~~
j_jochem
As far as I know, Google does index SPAs that are only rendered in the
browser.

~~~
doczoidberg
Google does not index my ng2 site without prerendering.

There will be always limits for search engines on interpreting js.

~~~
j_jochem
That's interesting. I previously researched this with regard to React apps,
and the tenor was that server-side rendering was no longer required in order
to get indexed by Google.

Google itself has this to say:

[https://webmasters.googleblog.com/2014/05/understanding-
web-...](https://webmasters.googleblog.com/2014/05/understanding-web-pages-
better.html)

Have you tried to figure out the cause using Search Console?

~~~
Bahamut
I have also encountered an Angular 1 app in the wild that was indexed by
Google, but there are limits to the ability of their crawler - it apparently
didn't follow through to other pages.

------
nbevans
At first I read this article title as "Angular 2 Finally Released" :)

------
partycoder
Angular's module syntax, while it makes sense, it's just easiest way to get
version control merge conflicts. Even easier than import statements... since
these can be put into oneliners.

------
alabamamike
Thanks and congrats to the Angular2 team! We've been building on the release
candidates since March, and we're happy to see the breaking changes come to an
end.

------
huuu
Is there a way to download Angular2 as Javascript file? Last time I checked I
had to install loads of software just to start a Angular project.

~~~
pramttl
You can still use the old way of using <script src=..>. See index.html in the
following plunkr (sample angular app):
[http://embed.plnkr.co/xTyGA7Klq8Mta2T1yANh/](http://embed.plnkr.co/xTyGA7Klq8Mta2T1yANh/)

------
rochak
Was waiting for its final release. Recently built an app using it and the
documentation kept changing. Found it hard to keep up.

------
thewhitetulip
Can anyone guide me about writing angularJS apps with Go backend? So far, I
have not been able to find a good source to learn it.

~~~
dfsegoat
FWIW as someone who struggled early on with the "How do i use angular with
<other technology that i work with>?" question.

It's important to IMMEDIATELY understand that the backend should not matter -
so long as it returns JSON (or even XML i suppose) which AngularJS 1.x can
consume with $http or $resource (or ng 2.x equivalent).

This is an advantageous pattern in my opinion because the front-end angular
application is totally decoupled from the backend (we have separate code repos
- and even separate developers) - you can keep the backend as Go, or PHP, or
Python - or even a static JSON file with something like jsonserver. So long as
the JSON is formatted appropriately and API does what angular expects -
angular does not care!

~~~
thewhitetulip
This is great advice! What do you think about routing? angular has it's own
router, so can Go have. What to choose?

~~~
DCoder
You don't choose between those two routers, they are not replacements for each
other.

At the risk of stating the obvious, the Angular router handles routing for the
Angular frontend, the Go router handles routing for the Go backend (the
initial page load, the AJAX calls made from Angular to get data...).

~~~
thewhitetulip
Thanks!

------
xuwupeng2000
I am on the boat of Angular 1. I really want to move to React cuz I don't want
to learn TypecScript.

~~~
alxhub
Even if you use React, you should try Typescript. Totally worth it.

~~~
morsmodr
+1 Billion minimum for this comment

------
leshow
the website is barely functional for me, the anchor links in the documentation
don't even work.

------
martyn80
The angular website itself still uses 1.4.8?

I can't find a benchmark or size comparision somewhere.

------
gravypod
I like that they are selling the fact they have good ide support.

------
morsmodr
frameworkFatigue++

------
kingofhawks
Congratulations!

