[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.