[_mtr]

And 11 days later...

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

http://eisenbergeffect.bluespire.com/leaving-angular

[serve_yay]

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

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

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

[marknutter]

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

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

[serve_yay]

Who said anything about jQuery or Backbone?

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

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

[marknutter]

> Who said anything about jQuery or Backbone?

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

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

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

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

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

[cmdkeen]

In my (albeit limited) experience with Angular the level of complexity is much greater than say using something like Knockout for data binding only. Not everyone wants to build an SPA and make use of $http. Also not everyone is currently hacking together jQuery. There never seems to be community chat, or posts, from people who have migrated from another framework/library to Angular, it's always people mashing together jQuery who are held up as the target audience. That should really tell you something...

[sanderjd]

Data point: I moved from a relatively big Backbone project (utilizing some of the higher-level libraries that inevitably were built on top of it) to a bigger Angular project. I liked Backbone more, because it is simpler to reason about and much easier to debug, but I believe we build things much faster with Angular. I decry a lot of the same design in Angular that others do, but I can't argue with its productivity.

I think the productivity for me comes from two places: 1. Emphasis on isolated and reusable view components. You can certainly do this in Backbone, but I never felt like I had a satisfying pattern for it. 2. Automatic data binding in the "push" direction. That is, the direction of updating the view based on changes. I think the full bidirectional binding complicates things. I find that I have far more sinks for changes than sources, so being explicit at the sources would not be burdensome.

From my initial reading tinkering, using something like ReactJS as the view layer in a Backbone (or perhaps even plain JS) app may very well speak to both of those points.

[cmdkeen]

Certainly at ng-europe AtScript was being touted as the way you should be writing Angular 2.0

As a massive fan of Typescript I'm not convinced it is actually that much of a problem. But when you see the JS you have to write to achieve what AtScript produces it's going to be pretty painful for someone who wants to stick with JS.

[kofalt]

Yikes.

> What I am saying is that it is no longer fundamentally the same thing I was originally hired to help build nor is it compatible with my vision for the future.

I've heard elsewhere that 2.0 will be an entirely unrelated framework which will be still called Angular for no good reason.

Dismissing this opinion as a troll is no longer productive after the above commentary by an Angular developer.

[cheriot]

In that Angular 1.x has been iterative changes and 2.0 is a completely new architecture and code base, it's not a rumor. The angular team has been saying that since the original announcement.

[justinzollars]

he should create a fork

[Kiro]

He has Durandal.

http://durandaljs.com/

[dang]

Discussed at https://news.ycombinator.com/item?id=8619789.

[cheriot]

Keep in mind this guy's reasons for leaving. He's focused on his own vision for his own framework (Durandaljs).

[ep103]

Any time I've ever left a job because of a project, all that time spent working on a broken product has left me with tons of time to figure out how I would do it on my own.

[cheriot]

The guy's framework existed before he joined Angular, he announced that they were merging, and then he changed his mind. Your analogy doesn't quite fit.

I'm skeptical of several things, but so far trusting that team has gone well for me.