
Angular 2.0 - callmevlad
http://blog.angularjs.org/2014/03/angular-20.html
======
jeswin
AngularJS has a J2EE mindset. Where libraries grow to become as hard to learn
as programming languages themselves. It does not make semantic sense to me
anymore.

Here is an example from the site:

    
    
      <div>
          Length (float):
          <input type="text" ng-model="length" name="length" smart-float />
          {{length}}<br />
          <span ng-show="form.length.$error.float">
            This is not a valid float number!</span>
        </div>
    

How semantic is ng-show="form.length.$error.float? smart-float sounds like
C++. If programming languages worked like this, we wouldn't have built many
apps. The problem is that some frameworks assume that everything should be
done with using configuration. What ends up happening is that the
configuration (and conventions) becomes its own language. This is a waste of
time in the long term; library conventions are not a portable skill set.

Some things are just better off with plain JS and simple HTML. FB/Instagram's
React is a much better approach to building HTML UIs; you get readable JS and
HTML instead of configuration mess.

~~~
stuaxo
This is true. AngularJS is much better than what we had before, it is kind of
large and monolithic.

The cycle probably goes thusly:

Large monolithic framework comes and shows everyone a new way of doing things
(Angular/Django).

People think it is too large and monolithic, so make microframeworks
(Flask/Whatever comes after Angular).

The next step will be a kind of happy medium.

~~~
AznHisoka
I never understood how JQuery and JS were just dumped the past 3-4 years in
favor of all thse complex frameworks like AngularJS, Ember, etc... is there
something these frameworks can do that JQuery can't? Can they make fancy
single page apps and JQuery can't? I need to be enlightened.

Or is it simply ppl need to exercise their mental creativity?

~~~
Hovertruck
"I never understood how JQuery and JS were just dumped the past 3-4 years in
favor of all thse complex frameworks like AngularJS, Ember, etc..."

Well, you can't have Angular without JS so we'll focus on the point of jQuery
here.

jQuery does a few things really well – so well that Angular itself uses jQuery
(or jqLite by default). angular.element(selector) returns a jQuery object.

Angular also does a few things well. Code reusability and testability are much
easier to achieve with Angular, in my opinion. Features like data-binding also
help to reduce boilerplate code.

~~~
ulisesrmzroche
Ok, cool. if Angular returns a jQuery object then its proof that it uses
jQuery quite extensively. So does Ember.

~~~
bmm6o
There was a similar discussion last week. What I said then was that a lot of
the things you would use jQuery for have a different solution in Angular:
[https://news.ycombinator.com/item?id=7396016](https://news.ycombinator.com/item?id=7396016).

------
kristiandupont
I have multiple friends who are very excited about Angular and one who is very
excited about Knockout, so I am convinced that they are getting something
right.

I am personally much more attracted to the reactive style of Meteor's Blaze or
ReactJS. It seems much easier for me to reason about, but maybe this has
something to do with my background in video games which means that a render-
loop seems really natural to me.

I don't have enough real world experience with the former to make a comparison
so I'd love to hear from someone who is able to properly compare the two
styles what the real pros and cons are.

~~~
davedx
I've worked on one large project with Angular, and a couple of medium sized
ones in Meteor (using the original UI system) and am working on a POC project
with ReactJS at the moment.

I think Angular is better for "slightly more traditional" webapps such as
dashboards. Its directives are nice for building small custom widgets, and the
thin model wrappers $http and $resource can be useful (though I'm looking
forward to what they add to these in v2.0). Data-binding is very
straightforward and easy to understand.

I've built a couple of projects in Meteor, and I'm still a fan, though I've
yet to have a real use case for the realtime (pub/sub) stuff: I'm still making
straightforward webapps that would probably be just as easy (if not easier) to
build in Angular or Backbone. The reason I'm using Meteor is more for
productivity than for reactive realtime: I love that I get Mongo, a watched
asset pipeline and a bunch of other stuff for free. I love being able to
share/move code around easily between the client and server.

Sometimes the reactivity in Meteor can be quite subtle and difficult to get
your head around, and I wish I was just using straightforward webservices
instead; other times it's a productivity booster and keeps things simpler.

ReactJS is a really nice concise view library, with some extra stuff that
Facebook put in that I'm not sure should really be in there (e.g. the
synthetic events) and should maybe be a module instead (an approach I'm _very_
happy to see Angular taking). ReactJS does for views and templates what Meteor
does for client-server. It's also got its share of subtleties and gotchas
though.

I'm also from a video games background and am also tending to favour Meteor
and ReactJS. But I do think the extra power of these technologies brings an
extra set of complexity and things to watch out for. But then Angular has
transclusions, so......

~~~
ianstormtaylor
Big +1 to Facebook breaking down React into smaller parts that are reusable.
Makes it hard to point out where there are weaknesses in the library with the
"all or nothing" system of dependencies.

------
tectonic
"All code in Angular 2 is already being written in ES6. As ES6 doesn’t run in
browsers today, we’re using the Traceur compiler to generate the nice ES5 that
runs everywhere. We’re working with the Traceur team to build support for a
few extensions like annotations and assertions."

That's pretty cool.

~~~
josteink
While "cool" and "clever" and any other half-positive adjective you like, it
does mean things will literally be _hell_ to debug until native ES6 support is
available in current browsers.

I thought the internals of Angular already had a reputation for being pretty
horrible and indecipherable already. I doubt this will improve on any of that
criticism.

~~~
EGreg
Really? Do you mean it's just super optimized and advanced, or coded badly? I
kind of always assumed that famous libraries built by a team of open source
geniuses would be super tight and tested for major errors and performance
inefficiencies.

No snark, I really did think this. Of course, Wordpress and Drupal do seem to
have a lot of crazy architectural decisions that made maintenance difficult,
so maybe I am just completely off.

Here are two JS files from a framework that I've written myself over the past
few years, for my own use. Is the angular source code pretty much like this,
or much more optimized?

[https://github.com/EGreg/Q/blob/master/platform/plugins/Q/we...](https://github.com/EGreg/Q/blob/master/platform/plugins/Q/web/js/Q.js)

[https://github.com/EGreg/Q/blob/master/platform/plugins/Stre...](https://github.com/EGreg/Q/blob/master/platform/plugins/Streams/web/js/Streams.js)

~~~
egeozcan
It seems that they go as far as creating their own benchmark tool to optimize
their performance[1]. They also seem to have a logging tool in the works just
to expose the stuff going on under the hood[2].

[1]:
[https://docs.google.com/file/d/0BwftRCZoTFiyRzhnVml3dlRiR1A5...](https://docs.google.com/file/d/0BwftRCZoTFiyRzhnVml3dlRiR1A5NEVscEl0UVlXZlNIRktZ/edit)

[2]:
[https://github.com/angular/diary.js](https://github.com/angular/diary.js)

------
tijs
Unless they plan to release this 4-5 years from now isn't it a bit optimistic
to release something intended to be used in production for IE11 only? For most
real-world applications it's kind of nice to be able to support anything with
a browser share over 1-2%, with this requirement it places Angular squarely in
the 'startups for the tech crowd'-only world.

~~~
nostrademons
The intention is to use it with Traceur, which is an ES6->JS transpiler that
works right now. It's like writing a framework in CoffeeScript or dart2js -
users shouldn't care about the implementation language, the ultimate binary is
just a blob of JS that works on browsers - except that the source code will
eventually run natively in the browser.

~~~
maga
Just to clarify, even Traceur has a hard time supporting browsers before IE10.
Though I agree that it is not an issue here.

~~~
MertsA
FYI, your last post on the Nvidia post is dead.

------
pavlov
Dependency Injection -- the heroin of abstraction junkies.

~~~
marknutter
This doesn't really add anything to the discussion. You should elaborate.

------
anton-107
> Dependency Injection is still a key differentiator between Angular and other
> client side frameworks

Why not just take Require.JS and use it as a dependency injector, like any
other client-side frameworks allow you to do?

IMO Angular is trying too hard to be everything, while it is now de facto a
template system with an excellent support of custom directives and two-way
data-binding.

For example, Angular could be a good choice for a View layer of an app built
on top of Backbone, since it moves away from opinionating the View layer. But
it's just too much fuss happening around this templating system in Angular.

~~~
lern_too_spel
Require.JS is a service locator. It's not an inversion of control dependency
injector. You can swap in a different service locator for your tests, but it's
messier than just directly passing in different dependencies for your tests.

~~~
camus2
RequireJS is not a service locator,it's a module loader. It doesnt instanciate
anything.AngularJS DI IS a service locator, not a dependency injection
container.

~~~
lern_too_spel
You're confused. A service locator doesn't have to instantiate anything.

Angular's injector, like Guice's injector is a service locator. Because the
normal way to use AngularJS is to simply list your dependencies instead of
requesting what you want from an injector instance, it is an IOC DI framework.

------
richbradshaw
Back last year, (May 2013) Miško said:

"We're in early stages of designing Angular 2.0, but some of our goals are:

\- Angular will use the underlying web platform features available to it (e.g.
Node.bind, template integration, Custom Elements, etc...)

\- Web Components (Polymer, Ember, or any other framework/library) will work
seamlessly within Angular apps and directives.

\- Components written in Angular will export to Web Components (to be used by
Polymer, Ember, or any other framework/library) .

We're working actively with the MDV, Web Components, and Polymer teams to make
sure that our approaches remain compatible as all these projects evolve (and
they will still evolve).

\-- Misko & the Angular team" ([https://groups.google.com/forum/#!msg/polymer-
dev/4RSYaKmbtE...](https://groups.google.com/forum/#!msg/polymer-
dev/4RSYaKmbtEk/uYnY3900wpIJ))

Does anyone know if the focus on Web Components is still there?

~~~
gravity13
First thing I looked for myself, this doc is titled "Polymer Notes"
[https://docs.google.com/document/d/16O2Im1ekfdJ4FU8FBbVRYGjq...](https://docs.google.com/document/d/16O2Im1ekfdJ4FU8FBbVRYGjqsXjmcV3tYFg1vyfhYC8/edit)
\- sounds like team Angular and team Polymer aren't exactly on the same page
quite yet.

------
Kiro
The new DI looks confusing. The old way is super simple to understand. You
inject the location provider and call it. In the new way however I don't
understand what's going on at all.

Where can I find a simple example?

~~~
quest88
[https://github.com/angular/di.js/blob/master/example/kitchen...](https://github.com/angular/di.js/blob/master/example/kitchen-
di/fridge.js)

Seems pretty simple, imo.

~~~
Kiro
I don't understand how that correlates to the current DI.

How do I rewrite the following using the new DI system?

    
    
      function MyCtrl($http, Base64) {
      	$http.get('http://www.example.com').success(function (data) {
      		console.log(Base64.decode(data));
      	});
      }

~~~
nateabele

      import {Http} from 'angularjs/http';
      import {Base64} from './base64';
    
      @Inject(Http)
      @Inject(Base64)
      export class MyCtrl {
        constructor(Http, Base64) {
          Http.get('http://www.example.com').success(function (data) {
            console.log(Base64.decode(data));
          });
        }
      }
    

Not too bad, right?

~~~
Cthulhu_
I don't like it at all; the Http and Base64 imports require three tokens /
lines to import, while the existing DI just needed one. RequireJS requires two
(array entry, callback parameter).

I'll stick to ES 5 / Angular 1.2 if we're required to write this much
boilerplate to achieve the same thing.

------
Osiris
I was at ng-conf back in January and there were some great presentations on a
lot of these topics, such as the new DI model. I'll have to pull out my notes.

It's great to see a framework team take a fundamentally new approach. Many
frameworks get stuck in a mindset while other frameworks pop around them with
new and more innovative approaches.

Good luck to the Angular team.

------
iSnow
ES6 support with ES5 fallback, I am stoked.

As to the mobile-first changes, we'll see - I have some reservations on using
Angular on lower specced mobiles, for the $watch()-cycle seems to me huge
drain on batteries. But since the Angular guys know what they are doing, I am
looking forward to nothing but goodness.

Why not just include restangular as one of the resource modules if they decide
to go all-out modular?

I am hoping for multiple ngIncludes and a bit easier development of
directives, other than that, keep up the good work, guys :)

~~~
filipedeschamps
Using heavy javascript computation in low performant mobiles, isn't the same
as playing Playstation 4 games on a Playstation 3?

You will need to go Playstation 3 native for performance, otherwise, you will
not be able to do much computation.

------
opendomain
Should this be marked as Angular 2.0 BETA? The docs say that it is not done
yet.

Also, the docs say that they do not know when they will be done. While I can
understand that we may not know problem that arise, it is a pet peeve of mine
that I never have a an idea when Drupal 8 will be released. I know that open
source contributions are hard to track, we have to estimate (guess) when our
projects will be done in our work, so why can we not do it for the projects we
love?

~~~
rdtsc
Yeah this a bit is misleading, title gives the impression this is a release
announcement, instead it is more of blueprint of "how we plan to do it".

------
johne20
+1 to "Integration with authentication and authorization". This is needed on
95% of apps or more, nice to know it hopefully will be supported.

oh, and don't forget better documentation :)

------
orandolabs
Unfortunately, Angular 2.0 sounds like a project killer. Let's abandon the
huge effort put in by the community, and build this shiny new framework with
all the latest and greatest (and currently unsupported) tools. Let's support
everything we can possibly foresee, and make the ultimate framework that will
never need improvement. That is until Angular 3.0, when we'll need to support
ES8...

Rewriting a successful framework with no backward support is suicide. Please
read this link before continuing on this path:
[http://www.joelonsoftware.com/articles/fog0000000069.html](http://www.joelonsoftware.com/articles/fog0000000069.html).
Another informative example is Perl 6. The 'rewrite' killed Perl. Microsoft
also did this time after time, forcing developers to constantly rewrite their
applications instead of spending time writing new products. Even Python 3,
with it's limited incompatibilities, had a very negative effect on the
community: [https://programmers.stackexchange.com/questions/63859/why-
do...](https://programmers.stackexchange.com/questions/63859/why-do-people-
hesitate-to-use-python-3).

Why should I bother supporting Angular 2.0, since 2 years from now the
developers are going to get bored and want Angular 3.0? The community is NOT
going to take the time to rewrite all their code to scratch your itch. My time
is very limited, and I need to be selective where I use it. I love Angular,
but there is zero chance I will rewrite any of my code for Angular 2.0. It's
not going to happen. I'm quite certain that my sentiments are shared by other
developers who have put in far more time and effort than I have.

My strong advice is to fix and optimize what you have. If there are areas that
need rewriting or rearchitecting, then do it, but leave a clear upgrade path
and don't break existing apps where possible. Sorry, but that's how software
works.

You have a ground breaking, beautifully designed framework. Please don't
destroy it because it's not perfect. Nothing is.

Can someone at Google please talk some sense into the developers running this
project?

------
uptown
I realize this is a basic question, but how does synchronization between the
client and server work with Angular? I understand the concept of data-binding
once you've retrieved the data to a data-structure on the client-side, thus
causing that data to update the view in the DOM, but what triggers a client-
side update when your server-side data changes? Do you need to poll a REST
service to check for changes? Does the server push the change to the client
side? Say there's no client-action triggering an update? What causes the new
server-data to get pushed to the client?

~~~
candybar
AngularJS is not a server-side framework and therefore it is agnostic on that
question. You can do it however you like and you can even create directives
that keep the client model synchronized with server-side, but it doesn't come
out of the box.

~~~
uptown
So if you want to poll a service periodically, you can do that ... or if you
want to use a websocket and just leave a pipe open to refresh your client-side
model ... you can do that too? Got it. Thanks.

~~~
yoshokatana
Yep. The $http service in angular core basically does your standard Http stuff
(with some nifty additions like caching and promises), but people have built
services to do sockets, sails, handle server-side events, etc.

------
CmonDev
The actual important stuff:

"Simplify the directive API

Integrate with other component frameworks using web standards

Improve performance

Allow tools like IDEs to analyze and validate templates"

------
thoradam
They mention annotations, presumably type annotations? Is that actually a part
of ES6? I can't find any mention of it.

------
nailer
Would love to see Angular 2's ES6 use promote some of the 'inline async' you
can do with ES6 generators.

~~~
hcentelles
I really want to hear more on that from the angular team. Generators and
modules are my favorite ES6 features right now.

------
ajanuary
OT if you're going to insist on double spacing HTML, use "&nbps; " and not "
&nbsp;" otherwise you'll have a ragged left margin like the OP.

------
jimktrains2
An yet another simple text blog that is 100%, completely, utterly broken an
useless without JavaScript enable. There isn't even any compelling feature.
Besides the sliding out mention there is _no_ reason JavaScript even needs to
be on this page.

I don't get why BlogSpot an so many other sites require javascript to o
absolutely nothing of value just to see the site. It's maddening and
appalling.

~~~
mantrax2
It's maddening and appalling to you because you deliberately disabled an
essential part of the web platform on your browser. Your problem, not theirs.

~~~
jimktrains2
What about the blind who use screen readers or braille displays? Why should
the page become so bloated that I can't read simple text simply?

~~~
mendelk
This is not an endorsement (or not) for blogs that rely on JS, but apparently
98.6% of screenreader users have javascript enabled.[0]

[0]
[http://webaim.org/projects/screenreadersurvey4/](http://webaim.org/projects/screenreadersurvey4/)

~~~
jimktrains2
Doesn't mean that it's makes for a pleasant or useful experience. Viz
[http://hanselminutes.com/413/im-a-blind-software-
technician-...](http://hanselminutes.com/413/im-a-blind-software-technician-
ask-me-anything-with-katherine-moss) from a sibling comment of yours.

Also, I'm surprised I got downvoted for saying that we should be considering
the disabled when making decisions on how to structure a blog. I know
accessibility isn't _cool_ but it's the right thing to do, especially for a
text-based site, like a blog.

(PS: mendelk, I'm not accusing you of downvoting me)

------
kclay
The new DI system looks promising, looks like they are trying to make a JS
version of Guice which I love in java. The whole thing of using annotations in
javascript seems a bit out of place though especially when ide/text don't
support them. Also the logging framework, seems they are making sure that they
cover some "enterprise" concerns.

------
kmkemp
It's pretty bizarre that people keep saying AngularJS is "large and
monolithic" when it, in fact, is modular.

------
ap22213
All I really need are client-side templates and awesome DOM binding.

What's the current best options?

~~~
sergiotapia
Backbone.JS, it's exceptionally bare bones, but hey it's YOUR code. You don't
have to memorize an entire framework like Angular.

Pick up a Backbone book and in two weeks your dangerous enough to use it. A
month, you're in the groove. 6 months: Angul-who?

~~~
mushishi
If you are going to use Backbone for the first time in a big project, beware
that you don't end up with low-level code that is duplicated in different
flavours all over the place.

When you have implemented features enough to notice that it takes too many
steps to make new views that resemble old ones, ease off from feature
building, and make proper custom abstractions suitable for that particular
project.

Also check out Backbone extension: Marionette for modularizing and backbone-
documentmodel for non-linear forms.

------
jbeja
I will stick with jqueRy for now, i don't need this yet.

------
beefydude
The focus on mobile web development is key here.

~~~
orky56
That's what bothers me. AngularJS is not going to be a big enough step (time
will tell) for native apps to suddenly disappear and for everyone to go web
app. They should have continued focus on a desktop-first approach since that's
where they can really shine. What I see here with this announcement is that
they are optimizing for the limited resources of the mobile device rather than
the more powerful applications and usage patterns that we see on desktops.

------
johnny635
They are getting rid of the config phase!!!

