

Have the Angular Team lost their marbles? - emeraldd
http://blog.dantup.com/2014/10/have-the-angular-team-lost-their-marbles/

======
paulddraper
"Of everyone, Google should know how hard it is to maintain large web apps"

They do.

Google doesn't use Angular for Gmail, Docs, Sheets, Calendar, Maps, or
Google+. They use Closure Tools
([https://developers.google.com/closure/](https://developers.google.com/closure/)),
which has a much longer history, and is geared towards truly large web apps.

As far as I know, only DoubleClick uses Angular.

~~~
StevePerkins
I have no idea why Closure doesn't get more publicity. You never hear about it
on Reddit/Slashdot/HN, but in the real world it's the foundation for virtually
EVERYTHING Google does on the client-side, save for a handful of things still
using GWT. Like GWT... Closure has been around awhile, has gentle-to-
nonexistant migration issues, and will be around for at least a decade to
come. Unlike GWT, and virtually everything else Google does... Closure is pure
JavaScript, rather than a trans-compiling mess that tries (and fails) to
replace JavaScript.

In client-side land, it's like there's inverse relationship between "blog
chatter" and "real-world use in large projects". The tools that get all the
attention are only used for personal tinkering, or by startups that mostly
won't exist in a few years. Over the past several years, if something seems
popular then that's a sign it's probably a children's toy for which you
shouldn't stick your neck out within your company.

~~~
aikah
The closure-compiler is written in java. Here is your problem.

~~~
StevePerkins
If you don't mind my asking, what do you mean by this? If you're doing non-
trivial client-side development, then you are probably already managing the
details of your building/minification/testing through Grunt or something like
it anyway. Does the issue boil down to, "Needing a Node.js installation on my
laptop to do client-side development is fine... but having a JVM installed on
my laptop sucks because ermahgerd-old-people-enterprise-uncool"?

~~~
aikah
Dont shoot the messenger,i'm just explaining you why the js community doesnt
give a damn about all these closure tools written in java.

------
ludicast
I like angular and I think some of the changes (better DI for one) are good.

AtScript makes sense in one way. I already tend to use browserify to pre-parse
custom annotations. That way I can "macro-expand" injections and controllers
and stuff like that to do some rails-esque magic. So what looks like commented
coffeescript lets me have nearly empty files following CoC a la ember & rails.

This gives me enough benefits that I'm sold with invading the framework with a
new language (or adopting those advantages within coffeescript etc.).

The changes to the view are a little disturbing though. I've found jade, slim
and the like to be okay parsing my regular angular code. But adding these
special characters to attribute names are probably going to break a lot of
html preprocessors.

------
orclev
One of my friends had an interesting thought concerning the new syntax. He
suggested the changes from the old syntax are based primarily around making it
nearly impossible to work with jquery. E.G. how do you even make a jquery
selector for something like "(click)="?

~~~
sanderjd
It seems pretty crazy to me to want to do that. If you need to select that
element, why not give it an id or a class? Angular attributes should be
considered to be purely directions to the templating system.

~~~
orclev
Right, that's the way you're supposed to use angular, but some people are
lazy/bad/whatever and do crazy things with jquery either out of ignorance or
because that's the way they're used to doing it. The thought was that they
made this change to explicitly try to break people of the habit of falling
back on a quick jquery hack rather than taking the time to do it right. This
is of course pure speculation, I don't know if that's the reason behind the
change or not, I just thought it was an interesting concept if that was in
fact the reasoning behind it.

------
Bahamut
My thoughts on 2.0 so far - most of 2.0 seems pretty good. I can deal with
AtScript, since it seems like we are forced into transpiling from ES6 to ES5
anyway. It is dirty that this means we don't quite have clean standalone JS
libraries that is as easy to use as an ES6 import. The gains of DI with
something like di.js instead of repetitious annoying conventions that pollutes
code design is worth it I think.

The one thing I don't like is the new HTML templating. I want valid HTML - the
one thing that gave Angular a leg up over other frameworks in my eyes is that
the templates were purely HTML. If I wanted to migrate to another framework,
it would be much easier to do so from Angular since the templates were pure
HTML, so the CSS would still be valid. It seems like we are forced into a sort
of templating system similar to JSX (note: this is a guess on my part - I know
the Angular team admires React for the performance of the virtual DOM). This
type of complexity makes it harder for newer developers to get into frontend
application development, and it makes me concerned from a management
standpoint.

I think the main complaint in the article about enterprise support is bleh
though. Very few frontend developers want to support enterprise these days due
to how fast the frontend world is evolving. Due to this fast pace, it's
important to modernize until the ecosystem is as mature as it needs to be. The
complaint seems to ring hollow since it seems that the author doesn't want to
have to devote the amount of resources as it takes to develop web
applications. More of the complexity has shifted to the frontend, and so it
takes more on the frontend to meet the same expectations (and less on the
backend, or focused on more high level tasks)

~~~
kylecordes
The valid HTML that is where I have the hardest time swallowing the new stuff.
From teaching classes to big-company teams in the process of adopting
AngularJS, I can tell you, many of them really like the fact that AngularJS
templates are HTML, look like HTML, are accepted by all manner of tools as
HTML, etc.

Re: Enterprises, lots of big companies are adopting AngularJS. Front-end
developers who work there are therefore using it, and will end up responsible
for supporting angular-based systems for years to come.

------
aikah
I dont mind changes,frankly.That's that AtScript thing that bothers me,a
lot.So basically they are developping angularjs 2.0 with a new language. But
i'm not interested in AtScript, i wouldnt use angularjs if it was written in
typescript/coffeescript/clojurescript whatever.Because i want to actually be
able to read the source code,in js.

I think what happened is,the dev team saw React,they liked it,decided they
wanted their own React,since React uses JSX which isnt javascript,and here we
are.

But again,it's opensource, people will fork the framework if they feel Google
is f*cking things up.

------
buckbova
If we had to rewrite our largest angular app to be 2.0 it would be a
considerable effort, but the way things go by 2017 it'll probably be rewritten
anyway. It's gone from .NET controls, to jquery soup, and now angular. The
service structure and the database remain only mildly altered in all that
time.

I'm starting a new project soon and using angular. And it'll still be working
for years to come.

When 2.0 comes out I'll treat it as a different brand new framework and make a
judgement call on if we use that or pick a whole new architecture.

------
marknutter
If anyone who does front end development can't accept the fact that the tools
and technologies they use are going to change dramatically every few years
then they should probably move further down the stack or onto native
platforms. Don't choose frameworks like Angular or Ember because you want to
"set it and forget it". Choose them because they make you productive _now_. If
your angular app works now, it will likely work years from now. If it causes
you a great deal of stress to keep up with the latest tech, then don't bother
keeping up with the latest tech. Continue using angular 1.3 or jquery or
whatever it is you're personally most productive with. The sky is not falling,
and the only constant in web development is change.

~~~
d2p
That's fine if your app is a toy you can rewrite in 6 months.

If you have a huge number of products that span millions of lines of code and
took over 10 years to write and you're trying to pick a tech stack you can use
across them all; this isn't going to fly.

~~~
kylecordes
Moreover, many people who have been choosing AngularJS have been doing so
because they believe that by coming from Google it stands a much better chance
than numerous competing solutions of surviving and being updated for years to
come. That is still probably true, but if it turns out to be true in the sense
that you can keep using AngularJS but need to substantially rewrite your
project every couple of years to keep up with radical changes, the value
proposition is lessened considerably.

------
Alex3917
If you write code in Angular 1.3 today, I really see no reason why it wouldn't
still run in ten years. As for the lack of bug fixes, if a front end bug
doesn't break your app within the first three years, I don't see how it's
going to suddenly become a show stopper.

~~~
d2p
Having had to fix many bugs in libraries that failed in newer browsers, I
disagree. Things get deprecated; new browsers stop supporting them. My current
project is full of abandoned JS libraries, and we spend a lot of time patching
them up.

