
Angular 2 Core - tilt
https://docs.google.com/presentation/d/1XQP0_NTzCUcFweauLlkZpbbhNVYbYy156oD--KLmXsk/
======
davidholmesnyc
I feel that Angular changes too much in HTML to be considered useful for long
term projects.The new syntax is also disturbing. My ideal MVC for front end
utilizes regular javascript and html tags. At most just add data-ang-click=""
something like that instead of "(click)" the latter isn't even valid HTML.
Sometimes I think Angular is mainly popular because it's supported by Google.
If any regular developer made these drastic changes in HTML with non valid
tags and attributes people would not be happy with that project.

I know Angular has a lot of community support and I have built some side
projects in Angular but I feel now too bloated with having their own standards
instead of following normal HTML standards. That's just my 2 cents on it and
i'm sure there are a ton of reason to use Angular but I just don't know if I
can continue supporting a project that makes so many drastic changes to a
standard. I don't want to make it sound like I have Angular hate here but i'm
a big vanilla fan and it seems in order to build anything useful in Angular
you have to throw out vanilla and use Angular's way even if vanilla is better.
On most projects handlebars and correct proper design patterns in code is
enough to keep HTML out of javascript and keep basic organization.

~~~
nobleach
> Sometimes I think Angular is mainly popular because it's supported by
> Google. If any regular developer made these drastic changes in HTML with non
> valid tags and attributes people would not be happy with that project.

This is a pretty interesting statement and I want to give it more thought.
I've used Angular on plenty of projects and admittedly, It's felt a bit dirty
to go back to spaghetti DOM that we worked for years to get rid of. All the
books were saying to separate logic from our views. Now we're calling it
declarative and it's acceptable again. I've been yelled at by other developers
as if I should just forget the past few years and just get in line with what's
currently the new hotness. Fine, I'm totally okay with embracing whatever is
new and hot. But not just because it came from the same people that gave us
Wave, Gears, GWT, etc. Let's not get involved in hero worship. All of those
technologies had great ideas, yet were (overall) marked as failures. I'd love
to have seen this same proposal come from some random Susan/Joe on their
GitHub and see if it had been laughed off the stage for the same reasons I
mentioned earlier.

~~~
andybak
> All the books were saying to separate logic from our views

It doesn't matter what the books say. Or rather - you've got to understand the
reason for the advice - not just learn to follow the advice.

Programming abounds with maxims. However you can't capture a complex truth
with a glib catchphrase. Everyone is trying to achieve the same ends - ease of
development without sacrificing maintainability (to give a very simple
example).

Catch-phrases such as "separate your logic from your views" was meant in a
specific context. If you etch it in granite and pass it on to future
generations it won't always embody the practical truth it was meant to convey.

So - we should remember the catch phrases but understand their context - and
therefore we might hope to understand the more subtle and less easily stated
truth behind the one-liners.

~~~
Joeri
Exactly. There is almost no advice in programming which applies to all
situations. The trick is knowing when not to follow the advice, and that
cannot be explained in a one-liner.

Or, as the tao of programming says:

There once was a Master Programmer who wrote unstructured programs. A novice
programmer, seeking to imitate him, also began to write unstructured programs.
When the novice asked the Master to evaluate his progress, the Master
criticized him for writing unstructured programs, saying, "What is appropriate
for the Master is not appropriate for the novice. You must understand Tao
before transcending structure."

------
Cthulhu_
I want to be excited, but at the moment there's just so much new and unknown
stuff I'm seeing that I'm just not sure. I don't like the new template syntax;
html attributes with parentheses and whatnot just look non-standard and I
don't really see why they did all that. I really need to dig into the design
documentation and find out the whys behind all of these new features.

ES6 is also new, of course; when I first saw Angular 2.0 code, I didn't like
it - mostly due to DI, which instead of a single argument in a simple
function, now consisted of three different statements to have one service
injected, which just feels non-DRY.

~~~
EugeneOZ
I disagree. New syntax actually gives much more for compatibility with other
technologies and IDE integration. Also clean visual difference between events
and properties - big thing. Not valid HTML... Well, not so high price.

~~~
acjohnson55
That's a fair point. Being able to differentiate complex directives from
attributes greatly helps separate the concerns visually.

------
zak_mc_kracken
Even though this is still called "Angular", this new version has barely any
resemblance with the previous one, it's really a totally new framework.

It's a bit sad to think that all this knowledge I have of Angular 1 is now
obsolete but I'm excited to dive into this new framework. If it's half
revolutionary as Angular 1 was, it's going to be a pretty interesting time.

~~~
mcbutterbunz
I have to agree. Will there be backwards compatibility? If not, upgrading to
angular 2 is going to require so much work and we'll probably end up switching
frameworks. This could end up like Python 2 & 3.

~~~
dodyg
It is not an upgrade if your old stuffs stop working. Man, 1.0 used to mean
something.

~~~
baddox
What did 1.0 used to mean? I thought that major version upgrades typically
mean that backwards-incompatible API changes have been made.

~~~
dodyg
It used to mean that it is stable and it will carry on working as far as it
can to the future major versions or until it is end of line of the product.

So I can understand if Angular 1.0 stopped working on Angular 4.0 or 5.0.
Breaking apps just on one major revision number is really a bad way to manage
frameworks.

~~~
jacquesm
It's what killed Drupal for me (and many others). Frameworks should provide
for either a porting tool or backwards compatibility between major versions.
Otherwise you alienate the people that trusted your in the first place.

------
realusername
I'm quite disappointed by this presentation, I see only new syntax everywhere
for approximately zero benefit.

There is not even any mention to the Object.observe integration which would be
the most exiting feature to improve Angular apps.

Angular looks and feels now like a Java framework, with ugly decorators and
bloated APIs, that's really sad...

~~~
kuni-toko-tachi
Agree 100%. Things like dependency injectors have no real place in JavaScript,
where programmatic wiring and modules already solve the problem in an
idiomatic way. Angulars modules factories services etc are absurd and attempt
to reinvent what the language naturally provides.

~~~
nilliams
>> where programmatic wiring and modules already solve the problem in an
idiomatic way

Can't agree with that. Not sure what you mean by 'programmatic wiring' as it
sounds vague, but certainly modules do not solve the same problem that DI
solves.

Modules, (assuming you mean stuff you require() or equivalent), provide
module-level dependencies but do not provide object instances. For example, if
an instance of House requires a Door it is not enough to just require('Door').
You still have to do the equivalent of `new Door()` in your House module to
get an instance. By doing so within the House module you just tightly coupled
House to Door (your House now knows how to create Doors).

DI allows you to provide an object with object instances it depends on without
tightly coupling said object to those dependencies (pass a Door instance into
a House instance, advantage being you can pass in any type of Door and House
doesn't need to care - thanks polymorphism)!

I'm not sure that's a great explanation, but it's worth trying every now and
then right?

You seem to be making the argument that the language provides alternatives,
and it's true that in dynamic languages you can eschew some of the benefits of
DI by doing monkey patching instead (e.g. to mock out an object's 'tightly
coupled' dependencies during testing), but to myself and many OOP proponents
DI leads to cleaner design and simpler tests.

~~~
kyllo
_For example, if an instance of House requires a Door it is not enough to just
require( 'Door'). You still have to do the equivalent of `new Door()` in your
House module to get an instance. By doing so within the House module you just
tightly coupled House to Door (your House now knows how to create Doors)._

So what? What is so bad about House and Door being "tightly coupled"? Here's a
House constructor that can take any kind of Door instance:

    
    
        function House(door){
            this.door = door;
        }
    

This is JavaScript, let's stop trying to make it into Java.

~~~
nilliams
What you just wrote as a code example _is_ Dependency Injection, it's just
manual dependency injection as opposed to using an IOC container or any of the
mechanisms Angular provides.

I am very much in favour of the approach you posted. That's exactly how I
write my code (I don't currently use Angular), but yep ... that's DI. As James
Shore said _' Dependency Injection is a 25-dollar term for a 5-cent concept'._
[1].

What you show in that code example is what in my head I call "poor man's DI"
or ... "passing stuff in" but it's actually my favourite kind as it
demonstrates the fundamental idea and is easy to explain to people - as soon
as you start talking about IOC and service providers things start to get
murkier. I think that's definitely where Angular is losing some people. You
can get a long way with the basic "poor man's" approach.

[1] [http://www.jamesshore.com/Blog/Dependency-Injection-
Demystif...](http://www.jamesshore.com/Blog/Dependency-Injection-
Demystified.html)

~~~
coldtea
> _When I realized it was "passing stuff in" I wanted to shout, I have done
> that for years!_

Well, it's the "automatic" part that is important, not just the DI.

~~~
kyllo
So the setter gets called automatically, but now you have to store the object
names as strings or in an XML file. How is that better?

~~~
coldtea
Loose coopling?

~~~
kyllo
Well, now the different classes inside your application are more loosely
coupled, but your business logic is more tightly coupled to a DI framework.

------
pedalpete
I'm not sure I've seen a framework with such a drastic API change,
particularly such a young API. I find that very threatening. Having spent a
considerable amount of time learning and working with Angular.js, not only
does this appear to be massively breaking changes, but it would also break 3rd
party directives which has been a great benefit to building the Angular
community.

This makes me think that Angular didn't think through their API for the 1.0
release. I would have thought Angular could have been written to improve the
performance where needed without such drastic changes to the framework.

~~~
Bahamut
It has been talked about for almost a year that Angular 2.0 is going to be
bringing such breaking changes. 2.0 is going to require complete app rebuilds
_if_ you want to migrate to 2.0.

The good news is that if your code is clean, a migration shouldn't be too
painful. The danger comes when you have unmodular code that sticks everything
on $rootScope (for example).

~~~
pedalpete
Except in a modular app, I should be able to upgrade module-x to Angular2
without having it break the entire app. With this change I have to re-write
every module in my app.

We've been looking at React at work over the last week, and were considering
moving some of our angular directives to react. Now there is a larger case for
building a complete app in Flux.

------
tracker1
I am literally working on a new project, starting to code the front end as of
a day ago... I using Flux+React (nearstack.io, plug) around the Yahoo
implementation of Flux's model. The down side, is this will be how things are
for the next 3-5 years for the life of the site/application.

Angular 2 looks really cool... they seem to be embracing the shadow-dom
concepts (like polymer) as well as es6-style import directives and expansion.
I still think I made the right decision, but this is really cool and looks to
be something that can work really well on current/next-gen browsers, but maybe
not so well on currently supported browsers such as limited support for IE8 in
my case :-(

I've been saying for a while that React/Flux is probably the best solution
today for web applications, and that something similar to Polymer would be the
best option in 3-5 years. I'll be watching this with great anticipation as
Angular 2 actually changes most of my complaints about the framework today,
and is really something that will come to work well.

Though, I'm not sure if they have or plan on a server-side component to
handling server rendering, which is a huge part of why I went with React+Flux.

\-- adding to my post --

More Info: [http://ng-learn.org/2014/03/AngularJS-2-Status-
Preview/](http://ng-learn.org/2014/03/AngularJS-2-Status-Preview/)

Looks like they are indeed using Traceur as a migration path, and embracing
many ES6 features. Not sure how they will go with Promises, or if they'll wind
up going down the generator path. There's definately some interesting reading
and watching for the next year or two on this. Also, really curious where
Polymer is heading in the light of this as well.

~~~
bsimpson
FWIW, React will be in ES6 (with native classes and imports) before they tag
1.0. In fact, React 0.12 has some breaking changes to prepare for that
transition.

~~~
tracker1
Interesting... though not surprising... Honestly, I'm not a big fan of class
hierarchy in JS. It tends to weight things down imho more than it helps. I'm
generally in favor of decorating against object literals, which has some
overhead, but less so than deep inheritance chains.

------
gasping
Angular 1 developers should see this as an opportunity to abandon Angular and
move on to React.

React is by far and away the best the market has to offer right now. From my
perspective client-side applications are a solved problem thanks to React.

~~~
purpletoned
Not to mention, it's much simpler than Angular. You can get upto speed with
React in 2 or 3 days. Once you make the shift to specifying single states for
your interactions and letting React rebuild the DOM on changes, you'll never
go back to anything else.

~~~
Bahamut
I disagree (about never going back) - I spent some time playing around with
React (I authored [https://github.com/wesleycho/angular-
react](https://github.com/wesleycho/angular-react) ), and I found the lack of
a framework for application development to be a massive void. Code
organization and modularity is becoming an increasingly important problem with
JS as more logic is happening in the client and more components need to be
modular for fast changing requirements. Neither Angular or Flux quite solves
this, but Angular provides more useful tools for managing an application.

Angular has a void with the lack of a useful enough eventing solution - $scope
eventing has specific use cases, but you don't want to use it as a general
event bus, mainly due to performance. This is important for Angular since you
don't want to couple modules together with hardcoded state keys that you may
want to alter in different applications.

Flux does offer a way around the eventing problem at a lower level within
React components, but on a higher level, there is no application level of
control - you have to construct exactly the control you want, which while
liberating, also is an easy way to create a hole in architecture when
designing an application if you're not careful. Angular exposes that problem
directly in many ways (for example handling transitions between two urls in
the application), as well as forces thinking about module dependencies with
dependency injection.

HTML mixed in with JS via JSX is also an abomination, that originally made me
want to run far away from React when I first looked at it. I'm not a huge fan
of it still, but it's not an extremely terrible thing as long as you keep
higher level templates slim, which React forces you to do in order not to have
huge chunks of HTML mixed in with complex JS...although I'm sure there are
developers out there who do it anyway (just like there are plenty of Angular
developers who will toss plenty of jQuery in an Angular controller).

~~~
purpletoned
> Angular has a void with the lack of a useful enough eventing solution -
> $scope eventing ...

I've found that using a publish/subscribe system for communicating between
components makes them more loosely coupled and modular. In most cases, the
components I've written are naturally somewhat slightly coupled so I just pass
around functions as props from parent to child components.

> HTML mixed in with JS via JSX is also an abomination ...

Totally agree. I use the default React.DOM elements instead. I find them more
transparent and easy to read, and manipulation of these are much easier using
the map, filter, folds etc.

~~~
Bahamut
> I've found that using a publish/subscribe system for communicating between
> components makes them more loosely coupled and modular. In most cases, the
> components I've written are naturally somewhat slightly coupled so I just
> pass around functions as props from parent to child components.

I agree - my company is going to open source an event machine for Angular
sometime in the next couple of months which should address this hole.

> Totally agree. I use the default React.DOM elements instead. I find them
> more transparent and easy to read, and manipulation of these are much easier
> using the map, filter, folds etc.

Unfortunately it doesn't seem like React documented React.DOM :( . I would
rather just use HTML, but I would rather have it in a separate file. Perhaps a
build tool for grunt/gulp where you can register keys with the path to the
template being the value, and the tool converts the value into the React.DOM
elements would be a good idea.

~~~
spicyj
> Unfortunately it doesn't seem like React documented React.DOM :(

React.DOM.div(), etc. are part of React's public API -- if we didn't document
them, that's a mistake.

~~~
Bahamut
At the least, I cannot find any mention of the specifics anywhere on the main
GitHub page - this is the best that I can tell:
[http://facebook.github.io/react/docs/top-level-
api.html#reac...](http://facebook.github.io/react/docs/top-level-
api.html#react.dom) . I do know the recommendation is to use JSX, and I can
see why, but more visibility of the API would be better.

Edit: As a note, I did find out how it worked by doing source code diving two
months ago.

------
skore
To everybody trying to make this into a tech fight about Angular vs.
React/whatever, I've been repeating this like a mantra and even mentioned it
in a talk on javascript once[0]:

You can argue about the minor details of the tech stack till you turn green
and blue, but Angular wins because it succeeds in the only metric that really
counts.

jQuery: (for reference)

    
    
        5,656 commits
        7 branches
        122 releases
        199 contributors
    

React:

    
    
        3,003 commits
        10 branches
        18 releases
        226 contributors
    

Ember:

    
    
        7,490 commits
        35 branches
        90 releases
        412 contributors
    

Angular:

    
    
        5,988 commits
        12 branches
        111 releases
        1,044 contributors <---
    

I have made a bet on Angular two years ago and the reason was: They understand
how to herd cats. They get community right and at the end of the day, that's
the only thing that really counts (no matter how much nerds like to pretend
that it doesn't and it's all about technological purity or what have you).

I am absolutely confident that they are making good calls and the way they
have handled the transition periods so far (and the way they are going about
these new "big" changes) only increases my confidence.

I would be very surprised if in a few years, Angular wasn't on the same level
of "you can basically assume that it's loaded" as jQuery is.

[0]
[https://www.flickr.com/photos/valanx/14136669418/in/set-7215...](https://www.flickr.com/photos/valanx/14136669418/in/set-72157644551467698)

~~~
mateuszf
React is just newer. Give it some time.

~~~
robert_tweed
Indeed. If number of contributors is the only metric that counts then, since
React has more contributors than jQuery, I guess that means we shouldn't bet
on jQuery. Nobody's gonna be using that fly-by-night project in a year!

~~~
skore
That's why I wrote "for reference". jQuery, of course, is a different kind of
library.

A proper argument would be: jQuery has about three times the contributors that
mootools has. If I had to decide between mootools and jQuery, I'd pick the
second because of that metric alone, yes. (And this is how the market ended up
playing out.)

Angular (born Jan 2010) has 2.5 times the number of contributors of ember
(born Apr 2011), 5 times of React (born May 2013). I'm not just trying to find
a reason to dismiss React and I do realize that it is still young. From a
business standpoint, though, the choice couldn't possibly be any clearer.

I do agree that React has gathered a sizable crowd in a short time and it's
definitely on my list of projects that I keep an eye on. But it's simply too
young to warrant the same kind of investment that I have personally made into
Angular.

~~~
mateuszf
> But it's simply too young to warrant the same kind of investment that I have
> personally made into Angular.

Sure .. it makes sense. Though one of the main selling points of React is that
it's dead easy.

------
emilis_info
Guys, relax and stop whining. You are probably wrong about what is going to
happen with Angular, because you underestimate how massive Angular has become.

I recently began searching for a new JavaScript job. I don't like Angular at
all and I am skipping all positions that mention it. I have to skip ~90% of
all ads. Think of it – 90% of companies that are expanding their web
development use Angular.

So, even if this change will kill Angular, it will probably take years. It has
become too big to fail.

If you like Angular, get excited about it. Look at how .NET or Java guys
accept everything coming from Microsoft or Oracle. You are in a similar ship
now. No one got fired for choosing Angular. No one will.

~~~
colinramsay
Is this right? I can't believe for a millisecond that 90% of all new JS jobs
relate to Angular, it's a horrible and overblown framework with a high barrier
to entry. Were you looking at a particular subset of jobs, a particular
industry or in a particular location?

~~~
Jgrubb
> it's a horrible and overblown framework with a high barrier to entry

Listen, if _I_ can figure it out and get lots and lots of work done with it,
it's neither horrible nor overblown and the barrier of entry was there but I
got over it. By all means, keep ignoring it, but drop the shtick where you
know better than thousands and thousands of us out here building things with
it.

~~~
nawitus
>if I can figure it out and get lots and lots of work done with it, it's
neither horrible nor overblown

That's a weird argument. Just because you think it's not horrible or overblown
doesn't really mean much. That's just an opinion.

I've worked full-time with AnguarJS over a year, and I know it pretty well.
It's easily better than jQuery spaghetti code, and probably better than most
data-binding frameworks. It has lots of issues, though. From bad documentation
and performance to the mess of $scope.$apply/digest loop and a lot of moderate
design problems.

Anyway, the biggest problem is the boat. AngularJS is really trying to "eat"
other libraries and actually doesn't try to be modular. A data-binding/MVC
framework shouldn't invent it's own module system, and recently it's own
_programming language_. Apparently Google is trying to kill of jQuery too and
substitute their own system. And they want to reinvent everything as AngularJS
modules instead of "plain" JavaScript code that can be used across multiple
frameworks.

What I'd like to see in AngularJS 2 is a tiny core which does data-binding
without $scope.$apply, is fast and modular and could be used with a wide range
of other frameworks. What I don't want to do is start writing AngularJS
modules with AtScript and using their forced(?) ES6 classes.

~~~
Bahamut
Angular 2 definitely aims to be more modular - the Angular team acknowledges
the problem that it isn't modular enough itself. Stuff like di.js,
watchtower.js, zone.js, etc. are all built with modularity in mind & are
framework agnostic. I think once Angular hits 2.0 and it becomes highly
modular, we are going to see a boom in development productivity. Some of what
is currently in Angular is unique for JavaScript, such as the change listener
pattern and dependency injection. These are things that we'd like to take
advantage of with other libraries. Combining stuff like di.js with React
sounds very appetizing to me.

In addition, it would appear that we would be able to use these libraries with
Node.js as well.

I can only see this being a good thing.

------
marknutter
It's sad to see a post on HN specifically devoted to Angular utterly devolve
into framework flame wars. If the title were "Why Angular 2 will be better
than React" I could understand, but this is just a sneak preview of features
to come. Can we please just choose the tools we prefer and build stuff instead
of nursing our insecurities about the choices we've made?

~~~
personZ
As someone at the inflection point of choosing a single-page framework, I find
these "flamewars" incredibly useful. Further I find the notion that this is
evidence of insecurity itself evidence of insecurity -- why feel threatened
that people discuss alternatives and merits/detriments?

When new language features of C# or other languages (e.g. Go) are brought up
on here, inevitably those features and benefits will be contrast against other
languages. _And they should_. Because we aren't hammers and everything isn't a
nail, and even if we happen to use tool A today, we usually have the capacity
to move to tool B tomorrow if it made sense.

~~~
watty
Surely you don't really find "off topic" complaints an insecurity. This
article is about Angular 2.0, I would expect to read about thoughts/pros/cons
about Angular 2.0 when reading the comments.

It's similar to reading comments on a Halo (Xbox) post on Reddit. Over half
the comments are flame wars about PS4 > Xbox. There have been many "framework
vs. framework" potss already on HN, let's keep the flamewars contained.

~~~
joshkpeterson
No, sometimes you don't really know what something is without holding it up to
a yardstick. Flamewars are annoying, but this isn't a flamewar.

Carry on.

------
inglor
The problem I see with this is that it's very different from Angular 1 to the
point people using Angular would have to learn it all over again.

Breaking how the framework looks this drastically is both very brave and very
risky. Especially since from discussions with Angular core (and as you can see
from the presentation) - Angular 2.0 relies heavily on ES6 features and syntax
which are not yet supported in any browser and worse - are not known by most
web developers anyway.

~~~
cageface
Agreed. This looks almost like a complete rewrite, which seems like a good
thing because IMO Angular 1 is overly complex. But it does make me wonder if I
should bother to really learn Angular 1 at all. The main thing pushing me
towards Angular has been the size of the community but if they're wiping the
slate then I might just go with React after all.

~~~
tracker1
Angular has some huge support and momentum behind it... there has also been a
lot of job postings around it as well. That said, I couldn't get past some of
my issues with it, and that server rendering (shared code) was not really a
good option there... The issues with dependency injection is another issue,
and testing pretty much requires a browser.

These are the reasons I'm using flux/react now. I'm really looking forward to
following the development of Angular 2 now, and may just be my tool of choice
for new development in a couple years.

------
joeevans1000
I think it's hilarious how javascript frameworks are beginning to resemble
java frameworks. This new release is really starting to look like Spring,
including annotations. The increasingly complex DI is also looking like
Spring.

~~~
hippich
original author came from Java server-side background I believe, that probably
explains why you see similarities.

------
swalsh
There have been so many binding frameworks, with a few varieties of approach.
It has always been clear that it's "experimental". But it's been a few years
now, and the mature(er) frameworks are focusing themselves.

This is a good thing! I'm glad they're learning, and willing to make it
better. In my career I've gone from ASP -> PHP -> ASP.NET Web Forms -> ASP.NET
MVC -> Angular/knockout/react. We're developers, if you can't flow with change
you should move on to one of the more established engineering disciplines.

~~~
dodyg
It's not about you, the developers. You can easily move on and jump from
frameworks to frameworks.

Your clients or employers suddenly have to worry about one extra thing because
their newly developed applications/systems suddenly become 'out of date'
simply because the crazy churn in on JavaScript frameworks API.

It is not a good thing. We are invalidating people's investments, time and
money for no good reason.

~~~
swalsh
Honestly, that's why you don't develop a new production system in a framework
that's just a few years old. I had a coworker suggest using Angular on our
main product that pays our bills. My reply was, it looks great... i'm excited
about it, but I think we should use it on less critical systems until it
matures. There's too many unknowns. There's no reason every new platform you
develop needs to be using literally the latest tech. Actually, there's really
good reasons not to.

~~~
zghst
Too many unknowns is way too broad of a reason when it comes to JS. JS is
already the language of unknowns. It really depends on the framework, timing
of things, people behind it. Angular is by Google, but also Google is pushing
Web Components at the same time, which can integrate with Angular 2, but it
challenges it as well. Also with Angular 2's goals being known for a long
time, anyone could tell that ES6 would be a dramatic wave of change to the
framework.

With JS, all the frameworks and libraries out there are just a few years old.
Angular is about 5 years old, but Google doesn't even use Angular in their
sites, which should be extremely telling (along with the complexity learning
and figuring out the API). In fact I think Google isn't even planning on
Angular on any Google sites in the future. They are waiting until Web
Components are finalized.

With React, it is apparently mature enough, it is used on Facebook (1 billion
users), Instagram (a child company of Facebook, like Youtube for Google), Khan
Academy, Github (github issue viewer), AirBnB, CloudFlare, and a lot more:

[https://github.com/facebook/react/wiki/Sites-Using-
React](https://github.com/facebook/react/wiki/Sites-Using-React)

In the JS world, there's a lot of reason to keep moving forward with tech.
Sure it doesn't have to be the latest and greatest, but since JS is such a
"poor" language, a lot of these newer tools, features, framework, and
libraries help build more professional, quality code. Shying away from newer
tech (again not the latest and greatest, but away from tech that improves
quality of code) highlights obstinance and ignorance about the technology
behind it, as well as how little someone understands the industry today.

~~~
Bahamut
Google does use Angular on many sites in production - the number is somewhere
over 120 according to their metrics last I heard. They even use it for static
pages - I noticed that the older Google Nexus pages were done in Angular. They
prominently tout using Angular for DoubleClick, among other sites. It is also
used widely internally.

Angular is also used by a formidable set of companies in production -
Microsoft, Google, Apple, VMware, Netflix, MSNBC, Bloomberg, Washington Post,
USA Today, US News & World Report, Amazon, Udacity, Cisco, and countless
others. I have heard of it being used in the financial sector quite a bit as
well. The prevalance of Angular and the strong support by Google is far more
telling.

~~~
dodyg
I will challenge that 'strong support by Google'. Angular.js 2.0 is an
abandonment of Angular.js.

------
Wintamute
Every large opinionated framework is "overblown" (aka "scary") until you
actually take the time to learn it and code a few large non-trivial projects
with it. I've learnt more MVC frameworks than you can shake a stick at and
Angular is hands down one of the best. Once you're comfortable with it you can
fly and code things so quickly and cleanly, and it scales well into complex
apps too. Angular is largely designed the way it is to promote small,
encapsulated, testable components. But if you're not practising TDD, or don't
test your code at all, (which I suspect is the case for many of the
framework's detractors) then it possibly is somewhat over architected - by all
means pick a simpler framework, but don't knock it from a position of
ignorance.

~~~
trumbitta2
TBH, I'm both amazed by the power and simplicity of Angular && mad at how
difficult and unpredictable is to unit test services that use promises and/or
depend on other services.

~~~
Wintamute
You can fully mock out those services and pass them into the component under
test. Those mocks could return an immediately succeeding (or failing) promise
for example. Hey presto, no uncertainty or weird promise handling code in your
tests.

------
IkmoIkmo
Ouch, just spent this month learning Angular... And now 'RIP angular.module,
controllers, $scope' etc.

Does anyone have some idea about when this launches and when it can be sort of
considered stable for building apps beyond mere prototyping? Curious about the
timeframe :) Thanks

~~~
purpletoned
> Ouch, just spent this month learning Angular

I've found that no knowledge I've gained from learning
technology/framework/language etc has ever gone to waste.

Somewhere down the line, the insights gained previously come in really handy
or even make something that I thought wasn't possible, realizable.

------
grose
Took some digging but I found a video:
[https://www.youtube.com/watch?v=S8fE-w2DL8U#t=54m12s](https://www.youtube.com/watch?v=S8fE-w2DL8U#t=54m12s)

Edit: They took it down, sorry :\

~~~
mrwnmonm
This video is private.

------
adamors
This looks like a completely new framework, version 1.0.

I don't think I'll use Angular for any new projects, they basically flushed
every library and documentation (1st and 3rd party) down the drain.

------
spir
As somebody with little experience writing web applications, having just used
ember for a my last project, these Angular 2 Core highlights seem way behind
ember.

------
allworknoplay
I knew there was a reason I put off learning angular.

~~~
clubhi
I'm not so sure. I think it will take about 5 years for angular 1.x to lose
momentum.

------
andrewstuart
Intresting, but WHY are these approaches better. Is that adequately explained?

~~~
swalsh
I think this is the problem with posting slides, and not a video. For most
presentations slides are bullet points. It's like ordering a cheese burger
without the burger.

------
dandv
From
[http://jaxenter.com/angular-2-0-112094.html](http://jaxenter.com/angular-2-0-112094.html):

> _the framework will be “drastically different looking”, meaning users will
> need to get to grips with a new kind of architecture. It’s also been
> confirmed that there will be no migration path from Angular 1.X to 2.0._

> _Currently Angular is aiming for a release by the end of 2015 – but early
> 2016 seems more realistic given the drastic changes that are planned._

This essentially makes investing in Angular pointless, when there are far more
capable and easier to learn frameworks out there - Meteor primarily, and also
Derby.js, though it's got about 1/10th of the momentum of Meteor, which
launched 1.0 two days ago, and had 20k GitHub stars without backing from some
giant company. BTW, Meteor never broke compatibility with earlier releases in
such drastic ways as Angular will.

------
vayarajesh
It took a lot of time for me to get the hang of AngularJS 1.x and now
AngularJS 2 seems very promising but shifting along with the new syntax,
programming logic is really painful..

They should provide a path to easily shift programmers thinking from 1.x to 2
(hopefully it is already in their roadmap)

~~~
vanadium
IIRC, in the larger Google Doc cache of their Core documentation for Angular
2.x, they've stated in the manifesto of sorts that, well, that "easy shift"
may just not be possible. Primarily when it comes to migrating existing
applications.

~~~
vayarajesh
Although I am looking forward to the Angular 2.x mainly to see what it has in
store in terms of performance.. i had had faced performance issues with
Angular regularly

------
sproutkey
1\. For developers, change is usually a good thing in regards to our careers.
If you aren't learning and growing, it's not Angular that will go away, it's
you.

2\. They are following the [http://semver.org](http://semver.org) definition
of a major version change perfectly fine "MAJOR version when you make
incompatible API changes".

3\. If anyone is bothered by the complete shift, fork Angular at version 1.3
and maintain it yourself. That's the joy of open source. You might even be a
hero to many other developers.

------
tschellenbach
I tried both EmberJS and Angular. To me it seems Ember is years ahead, the
main advantages:

\- clean model abstraction, which prevents soo much boilerplate \- clean
templates \- components, partials, great re usability

~~~
danieltrembath
I've built one significant project in Ember, and three in Angular (multi-month
projects with a small team; requiring maintenance for the next 3-4 years; <
$100k USD).

Ember 'feels' so much more right to me. I really enjoyed working with it and
it reminded me of the desktop frameworks I used to work with. It's not without
it's faults, but what is.

But sadly Ember just doesn't seem to be holding it's head up in the ongoing
swell of JS frameworks. I think that is a great pity. But time goes on and
they'll all be forgotten in a few years.

~~~
danieltrembath
"its"

------
AndrewDucker
Is there anywhere with further detail on this?

(Because it looks fascinating, but I'd like to see some detailed documentation
and examples on how it's going to work.)

~~~
inglor
Yes, if you go to the AngularJS GitHub it's full of design documents and
debates about 2.0, for example - here is 2.0 change detection for the data
binding:
[https://github.com/angular/watchtower.js/](https://github.com/angular/watchtower.js/)

It's not proper documentation but debates and design documents but it's all
there.

Of course - not to forget
[https://github.com/angular/Angular2.design](https://github.com/angular/Angular2.design)

------
Ironballs
I don't know exactly how many of the Durandal & Angular convergence[1]
features made it into Angular 2.0, but it looks like lazy module loading and a
better component syntax did, which is fantastic

[1] [http://angularjs.blogspot.fi/2014/04/angular-and-durandal-
co...](http://angularjs.blogspot.fi/2014/04/angular-and-durandal-
converge.html).

------
desireco42
I love how they use attributes, I've been impressed by attribute modules for
CSS. The only thing I am surprised, I would think that this would include
significant overhead, yet you claim it is way faster. Most likely previous
scanning of the dom was even slower.

I think this is excellent use of attributes and good way to refactor things.
What others pointed out, this is different framework :)

------
stardrive
Great to see HTML5 growing so rapidly during the past few years! That said,
I'm not a huge fan of frameworks, they do not work so well except for basic
pattern apps. When you have an app worth building you consider very carefully
what foundation stones to use. I ended upright on my feet and happily dancing
using React as one of the stones.

------
joeevans1000
Can anyone suggest which practices can be added to the use of 1.3* to ease the
transition to 2.0? For instance, if I start using grunt-ng-annotate or gulp-
ng-annotate now, will that help ease the transition? If it would, I'd be
curious what other things I could do to make the switch less abrupt.

~~~
Bahamut
I think the biggest win would be to start using ES6 and getting used to using
the import/export syntax.

------
marani
New syntax is ok, quite cool actually, but I'd rather see more improvement on
things like route, high performance repeat. Hope they bring some goodness from
Angular 2 to Angular 1x as well. Also, not sure how the old directive/plugin
ecosystem would fit in, is there any rewrite needed?

------
EGreg
In your face Angular fans, who said that all the angular stuff was the best
way. They scrapped most of it!

------
ChicagoDave
After looking at the doc, my first reaction is that all HTML should be schema
compliant. Using non-standard HTML in the constructs will screw up a lot of
tooling and validation.

It's also safe to say this is just too big of a change without public
commentary. Way too big.

------
ChrisCinelli
I understand wanting to appeal to the same user base and tell that it was
develop by the same team. It's a brand decision. Nevertheless Angular 2
"deserve" a completely new name. It has no resemblance of Angular 1.x. Welcome
to a new framework.

------
kvirani
Nothing surprising or disappointing here in my opinion. It was my
understanding from day 1 that ng was Google's experiment and attempt in
transforming and mutating HTML into a language for web apps instead of web
sites.

------
toblender
Is this for real? Is this the official direction for AngularJS 2?

Seems like a very big leap considering people are just getting use to the way
AngularJS 1 works ($scopes etc).

------
dodyg
This is what is shit with JavaScript frameworks, no respect to backward
compatibility. Imagine if these kind of API churning happens in C++ or other
languages.

~~~
binocarlos
I'm sat right now coding a bunch of new stuff in angular 1.2 - it was feeling
sweet until I read this - now it feels old and outdated. Time to just ignore
the massive race to reinvent the framework and just get some stuff done I
think.

------
TheMagicHorsey
What does Angular win you beyond what you get in Web Components? I haven't
used Angular, so this is curiosity, not a challenge being issued.

------
joeyspn
I'm now wondering what will happen to other projects that have placed a huge
bet in Angular 1.x, like the Ionic Framework for example...

------
omarelamri
Is he using TypeScript or ECMAScript 6? Also, is it just me, to does this seem
like a completely different framework than Angular 1?

~~~
novaleaf
Typescript is ECMAScript6, with additional (typing) features.

I'd venture it's ecmascript 6 being used, as Google suffers NIH syndrome too..

~~~
omarelamri
Yeah, it definitely is EcmaScript 6. They've added the "class" and
"constructor" keywords. Typescript is very mush modeled after EcmaScript 6
anyways, so technically it can be both. But I'm sure it's EcmaScript6, because
that's what Angular 2 is written in.

~~~
joshkpeterson
See the post about Google's AtScript that was on HN yesterday.

~~~
omarelamri
So is this basically TypeScript with annotations and types available at
runtime?

------
novaleaf
is there a video of this? viewing these slides is like reading every-other
page of a book :(

------
calinet6
So... upgrade path is nonexistent?

Looks like it's great if you're starting from scratch though!

------
finalight
time to find another framework to work with

or best is, just scrape client side MVC framework, and fallback to server MVC
framework

------
donsw
bye bye angular. need new framework due to 2.0 if I have to rewrite then I
might as well look at others.

------
hellbanTHIS
Is this just a proposal or something?

------
taskstrike
This is a change for the far worse, someone branch this please and maintain a
backward compatible branch with the same syntax.

