As someone actively rolling their own JavaScript framework (more as a learning exercise than for anything else), I second the opinion that AngularJS is uniquely hard/blackboxed compared to other JavaScript frameworks (which I frequently refer to in order to guide my own efforts).
For instance Backbone is pretty much what would happen (give or take) if all the JavaScript books on how to program OOP and MV* got together and build a JS framework. It's not fancy, it's not "magic", but it is very approachable in terms of advanced standard/best/popular JavaScript programming practices.
AngularJS left all that stuff behind and built their own little world. It might even be a great world, but on the surface or to the implementation-level developer has little to do with "regular" advanced JavaScript programming techniques/patterns.
To me it's a bit like the JavaScript version of Drupal, which gives you a ton out of the box, but is just it's own whole world of conventions etc, that has little do with anything seen outside of itself.
Wow, this could not be further from the truth. Angular is much more similar to Rails than Drupal. Like Rails, it magically takes care of some of the more routine and annoying parts of front-end development like DOM manipulation and testing, but beyond that you're just writing javascript without having to worry about making sure your views are being updated. To extend the analogy I would compare Backbone to Sinatra. It's much smaller, allows the developer to make more choices, but takes care of less details.
So if you prefer Sinatra over Rails, you'll probably prefer Backbone over Angular or Ember. If you like all the magic Rails has to offer, you're probably going to feel right at home with Angular. But comparing Angular to Drupal is ridiculous.
Actually, I would compare AngularJS to Node's Express or Ruby's Sinatra. Because by and large it's actually a set of highly reusable and composable blocks that make very few assumptions about what you're trying to do (aside from something vaguely DOM related). It's a fairly pure look at the MVVM metaphor and does not even assume you're trying to do CRUD or RPC or whatever. Heck, you're not even tied to using client-side routing.
Please don't compare it to Express. Express is a beautifully simple, and clean framework that strives to always have the least magic possible. You can see that goal reflected in the simplicity of its documentation as well. You can build on top of it with any other node modules you want exactly because it doesn't make strict assumptions about your code. If you were to compare Express to any front-end framework it would be Backbone.
Angular is not simple in any since of the word. (Especially if we're talking about its documentation.) And it's components are only reusable inside the Angular bubble.
I really don't think it's accurate at all. Can you qualify it in any way?
For me, Drupal sucks for developers because you're configuring a bunch of objects to try to build a system but you're a) at the mercy of the initial design and b) going to run into hook soup hell, especially once a couple of plugins are installed.
Angular is nothing like that. You have a few classes of things you'll create. They're all well thought our and have very specific uses. None of them constrain you in any way, all the code inside is yours.
I don't get the comparison. I would never touch Drupal again however you would have to produce a very convincing argument to move me off Angular.
Backbone source is insanly easy to read , and it's short. Angular's on the other hand ... but that's the price to pay for it's features.
I would not call Angular magic. Basically there is a "loop", the digest cycle , whereas in Backbone you would add Backbone components to your code.
AngularJS creator worked at Adobe on Flex , and Adobe in fact attempted to create a "AngularJS" for non developers bundled with Dreamweaver ( Spry framework , but databinding was only one way).
I like AngularJS but since i dont do form centric apps ( more reactive documents with a lot of animations,svg or canvas) i went with Ractive + Backbone. Ractive is easier to learn and to use.
But AngularJS is pretty RAD when you have a lot of forms ( an admin panel ,etc ...), and provides a big testing plateform too.
> To me it's a bit like the JavaScript version of Drupal
hmm yeah maybe , drupal hooks are a bit like backbone directives in spirit.
I'm wondering why you would prefer angular for a form-centric app?
I've used angular and rivets.js + backbone with success, my preference being angular but Ractive looks like a way to get awesome templating and databinding without committing the entire app to a single monolithic framework.
It also seems that server side rendering is more reachable with it's mustachy roots.
Ractive creator here - yes, Ractive runs in Node. You create an instance similarly to on the client (ractive = new Ractive({ template: myTemplate, data: myData }) - obviously you don't specify a container element), then use ractive.renderHTML() to get the result.
We've been using it at https://starthq.com for about 6 months and I have to agree. Angular is so hard that even the core committers sometimes struggle to keep it together.
IE8 is a second class citizen in Angular and Angular UI, so some things that should work, don't. We've spent a fair amount of time patching it up and trying to get our patches merged into master. Here's a list of things we fixed: https://gist.github.com/olegp/f564ad1a17cadf269d44
Hard as hell? Nothing to be proud of. Main reason that keeps me from buying into the Angular hype is that apparently even after a year of practice in production, no one knows what the hell is going on.
The force multiplication for most cases is intense. If you're doing something that looks like something lots of people do, then you're going to have a good time. That's the same deal with Rails.
Typically, the issues that people talk about surround the fact that in Angular, the one right way to do stuff hasn't been discovered yet. The fact that the way that Angular works is a pretty fundamental change from the way that webpages have worked for most of their history means that there isn't really much to go on. The patterns are still being discovered.
The situation isn't helped by the fact that lots of people dove into the ecosystem and started writing blog posts about how do do things with Angular.js without first learning why just using a directive to apply jQuery plugins is probably not the right approach.
Generally speaking, the problem is not that it's hard to think of a way to accomplish what you want, it's that it's hard to figure out what the Angular way is (usually because there is not one way, yet).
Have they fixed the tutorial yet? Last time I checked, you couldn't even get through the second (third?) step without running into instructions you can't complete (they changed the testing framework & it won't run with the data they've given you).
For me, that's a big sign of the overall quality & attention to detail on a project. For something as big as Angular, with the sort of backing it has, it gives me the feeling that it's not a community-driven open source project but an industry project where a few big players are sharing their code.
I see AngularJS as a general purpose framework, conceptually, similar to .NET, JVM, Node.js, although limited in scope to front-end web development.
What I mean is that there's still room for someone to build another framework on top of AngularJS, with common features such as authentication, authorization, breadcrumbs, rich controls (grids, combos, autocomplete), etc.
I also find it harder to grasp than other frameworks like ASP.NET, RoR, Django, probably because you have to do so many things from scratch and because it introduces many concepts not commonly found on your typical MVC framework.
For me, even though it's PHP, ProcessWire consistently models data in a human way. I've put the out-the-box backend CMS in front of people that interact with computers very little and they instantly "get it". All data is simply a node in a hierarchy, and is easily movable and editable. I don't understand why more frameworks don't copy this basic structure.
If you watch "The mother of all demos"[1] the structure is almost visually 95% the same.
I look at Angular and it's looks complicated - the article is about how complicated it is. Surely we should be striving for tools the everyday man can pick up and play with?
> I don't understand why more frameworks don't copy this basic structure.
Lots of problem domains are difficult to model as trees because often, a node can be logically assigned to multiple parents, but the tree model requires it be physically assigned to only one.
Recently I bought a prepaid SIM card for a trip I am making to the USA.
In my bookkeeping system, I could enter it either as a transaction against the "Telephone & Internet" expense account, or I could enter it against "International Travel". What I can't do, because trees require mutual exclusion, is enter it under both. That breaks the model.
If instead Renaissance accountants had understood sets and relations, I might be able to log it against both and then derive whichever view of the data was necessary.
And that's the problem with hierarchical data. It privileges one and only one view of the problem domain. As soon as you need some other view, you are in trouble. If your project management system organises by project, then getting per-staff reports is now much harder. If your class hierarchy views A->B as the natural order of creation, what happens when you come up with cases where C->A but not C->B? You can't: you have to introduce complicated workarounds.
Hierarchies are simple to understand on their face. But they quickly come apart when faced with the real world and ad hoc queries about the state of the real world.
Sets and relations are indeed the most richest metamodel but most of the time a dag (directly acyclic graph) is enough : object can be connected to many parents but it keeps most the hierarchical organisation, which is easier to model.
What can be modelled as a graph can be modelled as sets and relations and vice versa; they're both equally powerful. But just as any two Turing-complete languages are equally powerful, the discussion doesn't end there.
It's still the same problem: you have mixed the logical model and physical structure of your data together. You are privileging one view of the data over all other views.
I consider switching to a full graph model a complicated workaround for the limitations of trees. You now introduce new and exciting paradoxes and you will need to litter your code with special cases (B means C, but only when A is not an ancestor, otherwise it means D). Ask C++ programmers about the joys of multiple inheritance.
In some cases the logical model is a graph and in those cases you should absolutely model it as a graph. But modelling all problems as a graph is inadvisable.
Node is a run-time for JavaScript, much like what is available in the Chrome console. Its usage is very similar to that of a command-line python interpreter / REPL.
Angular is a front-end framework for organizing large JavaScript projects. It requires a JavaScript run-time (such as a browser).
Auth is easy as cake on top of angular http interceptors.
The non-existant widget story is where work needs to be done. Plus Google need to fix their Github issues/feature request faster. Have an option for company to pay for it, hahaha.
It also has this weird retro stuff like dynamic scopes and reactive programming. It's also really slow, because it implements reactive programming with dirty checking.
Its called declarative user interfaces. Angular is not yet another technology if you've programmed in Silverlight or WPF.
Its one of the standard ways of developing WINDOWS applications. One example of declarative UI is HTML and CSS. You never write any "HOW TO LOGIC" when you are "printing" buttons, textboxs etc. on browsers. You just say <button> and there you go, you've a button there. You say <button class="red"> and lo and behold your button turns red. In that way you don't care "how" to print UI elements, you just focus WHAT YOU WANT TO DO rather HOW YOU WILL DO IT.
Declarative UI makes overall application highly testable and maintainable. You don't think how to "print" things on screen (write tons of binding code). Writing tests for the UI specific code is not only hard but messy. Without strong test-ability you can't scale your app without pains.
There is a reason why Google adopted this approach because world has learned the "best way" for building UIs. Google has probably half a decade of experience of building Google Web Toolkit. Right now Google Web Toolkit GWT has lot of similar concepts to AngularJS. Microsoft has probably 20 years experience of building UI framworks. Right now WP8 and WPF are all declarative UIs. In near future you'll see almost every UI framework across all devices technology will employ more or less the same concepts as AngularJS has now.
AngularJS is solving the testability & maintainability problem of large scale Javascript apps.
1) The first example is a template/view. It is reactively updated automatically when the values referenced are updated. It maps to markup on the page. The second example is a basic control structure that does nothing.
2)
<span ng-bind="foo == bar ? '...' : '...'"></span>
Yeah, I'm not saying that Angular literally replaces javascript "if" syntax with SGML syntax.
However, it does fit in with a long line of tools whose premise is "Normal programming with normal control flow is an insufficient tool for the unique problems of ${DOMAIN}. We need to create a new programming model with its own syntax and exotic control flow to make things easier."
The appearance of the "if-statement-in-markup" (or "if-statement-in-flowchart-diagrams", etc.) is to me a sure sign of a certain kind of misguided system.
I work as a javascript programmer, so I'm trying to do my small part to stem the tide of crapware before it makes my job less pleasant (too late in the case of angular).
I feel that as a js programmer you probably owe it to yourself to understand this space better. These frameworks are coming in fast because they're very powerful - and they're here to stay. Looking at your example definitely feels like you don't really understand how to use angular. Obviously it's your choice to make, but calling it crapware without really getting it, when it's going to directly effect your job is doing an injustice to nobody but yourself.
It's posts like yours that caused me to originally dismiss Angular out of hand and waste time with other frameworks until I came back around and took a better look at it.
Please reconsider whatever it is you think you're doing, it's seriously not helping anyone.
It's better because you get nice stuff like two way binding which your js won't give you. Also, building templates in html is definitely nicer and more expressive than doing it in js. That specific example doesn't look great - but it's probably not the best way of doing it either.
On the performance - it's going to be slower than doing everything in specifically optimised code, but it's almost certainly not going to be a problem. My project has a million+ objects in js once the interface loads and I have watches on a big chunk of that data and the interface is still snappy. Granted, there are bits where I have to be careful to make it snappy, but that's life. Development time is so much faster I wouldn't make the tradeoff for the world now.
He didn't mention other frameworks - but how JS doesn't give you two-way bindings. Which it doesn't. Your second point is about Handlebars, which isn't even mentioned in the comment you replied to.
My parent suggests two way binding requires manually annotating the DOM, implying that it's an Angular-exclusive feature.
Furthermore, those who don't like annotation aren't writing JavaScript views, they're writing HTML templates and annotating them with some JS, which means the parent offers a false dichotomy.
Incorrect. I was saying that the joke example presented didn't in anyway show the difference in power that Angular gives you over raw js - nothing at all about Angular exclusivity.
Word. I think we can all agree that EVERY framework is far better than plain old JS; the comparison is so nonsensical to me that I assumed you couldn't possibly be making it. Seems good!
The only reason to ng-switch/ng-switch-when is because you have to bind to DOM nodes (Angular decided they do the views this way) and you can't have DOM subtrees (those `{ ... }` branches in your `if ... else ...`) without elements.
I take it you haven't worked with angular that much. You can put as much code in your controllers as you like if you don't like decorating your views like in your example.
AngularJS is a level of abstraction above the old JQuery and Backbone style of app. It frees the developer from worrying about the tedious details of updating the DOM. For example, a typical old style app would do something like this:
function updateCheckoutButton(cart) {
if (cart.length === 0) {
$('#checkoutButton').addClass('light-blue');
$('#checkoutButton').prop('disabled', true);
else {
$('#checkoutButton').addClass('dark-blue');
$('#checkoutButton').prop('disabled', false);
}
}
1) Code reduction - The C language was invented to be an abstraction above assembly. Assembly code has a lot of low level details of moving values from registers, adding them, etc. The C language abstracts that away. In a similar way, AngularJS abstracts away the low level details of DOM manipulation.
2) Data binding - In the first example, it's important that updateCheckoutButton() is called wherever it's necessary for it to be called. Otherwise bugs could appear when the button is not updating when it should. AngularJS simplifies this to just listening for changes in the scope. It's possible to achieve the same thing using events, but again that's a lot of low level details of managing events and event propagation.
3) Declarative UI - <button id="checkoutButton"></button> tells me nothing about how this button behaves. The AngularJS example is immediately obvious on the button's behavior.
4) Unit testing - I can write a unit test to ensure that the value of scope.isCartEmpty is updating correctly. This test can be pure JS without any DOM support. It's much harder to test the DOM manipulation code style.
Angular reminds me a lot of enterprise java. Lots of its own conventions, inversion of control and lots of magic.
That being said, I love working with it. It's definitely cumbersome feeling at times though. Despite that, I like the idea of self contained modules, the html binding, and all of the semantics that go with it.
It's definitely an acquired taste though. There are many things that you can do with it that you probably can't take to other javascript frameworks though.
Ironically why I like it, as bloated and silly as the technologies are, it's what I cut my teeth on (let's just say my first boss was a former IBM guy)
I worked in web dev 3 years ago, then I moved to WPF. Recently, the place I was at decided to try some web development. Being the only guy with experience in it, i landed the project.
It is blowing my mind, how in 3 years the environment is so different. I'm sure these things existed on the fringes, but its very mainstream now.
When I left, JQuery was the in thing, it was pretty rad. Today i'm doing MVC, unit testing, and code coverage WITH JAVASCRIPT!
it isn't that hard... it's actually simpler than Ember to grok.
it is the right thing to learn right now anyhow, as the concepts naturally leads to web components, which will probably be the future of app development (cue polymer http://www.polymer-project.org/).
Angular's dependency injection is literally magic. Someone who has never used javascript before would probably have the advantage over a seasoned js-pro when reading the code.
That said; once I realised what it is doing, I quite like it and it has led to some of the cleanest client-side code I've written.
As you say - once you know what's going on it's not that magical at all. It literally looks at the text source for you function definition and injects the arguments you ask for. Certainly, when I first looked at it I felt the docs didn't explain that little nugget so you sort of wonder how your arguments are injected. More of a doc problem than an obfuscation issue, I think.
I think this depends on a developer's background before using AngularJS. I've used Spring (Java DI framework) for a while and AngularJS DI was easy to understand. However, the first time I was introduced to the DI concept, it took a while for me to understand it. Some of the complaints about the difficulty of AngularJS DI could be because for some JS developers it's the first time they've been introduced to the concept.
Am I the only one making AngularJS apps without writing a single test? The examples given are usually "test that this custom math function is doing what it should" but how often do you have those in a real app?
Are you saying you test in other platforms, just not AngularJS? Or is your question actually about the value of automated testing of code in general?
A strong point in AngularJS's favour when a bunch of my coworkers were evaluating different frameworks was that it was designed with testing in mind: dependency injection as a pervasive feature is huge for us, because that's what we've been doing on the server side (C#) for a long time. Angular seems to be encouraging its users to modularise code more, and that's a good thing.
We have fairly comprehensive test coverage of our JS code, this is pretty easy if you take the happy default path of Karma and Jasmine. From my point of view, we've always had comprehensive server side testing, now that a lot of logic has shifted to the client and sits on top of a much lighter-weight API on the backend. All that JS code needs to be tested.
Apart from lower level unit testing, we also have integration tests which drive real browsers through our apps. This is pretty important to make sure the whole thing including the server side code works together properly. These gain immense value as the project grows in size and complexity.
Barely ever, especially if you use JS as a functional language. I've seen most people setup the testing suite, but dealing with async is far too fiddly right now and thus tests/ is mostly boilerplate.
Not that you shouldn't be testing your JS, but that the tooling gets in the way of shipping code.
we should form a support group -- i too feel guilty about our lack of test coverage. but honestly, i dont think its much of a problem. we know from user feedback that none of our big issues are bugs in our Angular code.
We're using AngularJS for the second time on a project, and it's great. While I found the basics easy to pick up, some of my team struggled a bit more (but they've also spent less time doing heavy client-side JS development).
The biggest problem AngularJS has is documentation. Some of it is missing, some of it is poorly explained, all of it should have examples. The developer guide and API reference both need a rework/rewrite. I think the team should focus on this after this major 1.2 release.
What comes out of poor documentation is that best practices are not immediately obvious, because if you're trying to guess things from just the API and just picking a random way to achieve your end result, chances are you're going to do it wrong. This has been identified at https://github.com/angular-ui/community/issues/1 so hopefully it's going to get better.
The major thing which I think almost everyone gets wrong at first are the relationships between templates, scopes, controllers, services and your actual data. If you get this wrong you'll either end up writing a bunch of tricky workaround code, having memory leaks or subtle data binding bugs.
Let met tell you why angular is hard. It is because most of us are not familiarized with the concepts. The docs are hard to read and some stuff is buried deep within the language, but once you understand the concepts it's very easy to get started. We have introduced angular here and are using it in several production apps, and everyone is very happy. We had one team member learning it in a week (granted, he could learn very fast because he could ask someone when he had doubts), and already wrote 2 or 3 apps in the next weeks. An he isn't a "javascript" guy.
In fact, most or all of angular concepts can be found elsewhere in other frameworks such as spring/guice(IoC), any decent ORM (dirty checking, "digest cycles"), WPF (directives/code-behind,declarative, whatever you want to call it), etc.
Although I feel that its source code is hard to read sometimes, I'm happy to let the framework do its magic and allow me to write apps without getting in the way. I can write modular components and test them with the angular/grunt/karma combo. If I need tabs, modal or whatever I can pull some libs and get it working quickly. If size/speed's a serious concern, I'll write my own lib/directive/etc.
I decided not to go with AngularJS, mainly because I want to reuse as much client side logic as possible in future native apps and Angular seemed very tightly coupled to browser apps and the DOM. With Backbone find it easier to separate the UI specific code so that I can swap it out and control native UI elements instead, running the js in a hidden WebView. Anyone tell me if I'm wrong.
Angular makes front-end development much more like native development because it gives you true MVC. Meaning, the views are automatically updated based on the current value of the models. In an Angular controller, you really don't care or even know about the view other than the fact that you're sharing scope with it. The controller just makes sure the models are in the correct state and the view handles the rest automatically, perfectly decoupled.
In my experience, this is much closer to how native development works. In an iOS app, you have your view controllers which are responsible for responding to user input and making sure the models are in the right state. The views just automatically update themselves based on those models, much like Angular. So if you're writing your Angular apps correctly, they should be very similar to your native apps.
genuely curious : how do you manage to keep your views automaticcaly synchronized with the model in IOS ? It seems that your controller's in charge of the two-way data binding, and that it is clearly NOT automatic... contrary to angular.
With ember you will understand the right way to build an ember app from day 1 and it will take you 2 days to build a working 1st app. With Angular you will use it for a year, still have no idea how to build an Angular app the right way, but somehow your app will be done in 1 day instead of 2.
I have learned and used both within the last few months with the most up to date versions of both and I settled on Angular for our CRUD business applications.
Angular is more mature, well thought out, better supported, much better documented, is logically consistent throughout, supports the concepts of MVC properly (unit testing is a breeze), much easier to use with REST backends I could go on and on.
There simply is no comparison.
Ember, even after the major changes recently, feels like someone's idea of how MVC should be done without consulting any existing standards or ideas about MVC or REST or any related technology and just throwing in things without thinking them through.
Angular feels far more trustworthy and serious to me than Ember by many orders of magnitude.
Neither though are even close the level of documentation and support and widespread relevant reference apps as I was used to in the .net world (for example), but Angular is the more solid choice in my opinion.
I would recommend Angular over Ember at this point in time unreservedly for making actual applications versus websites.
really it seems like other people argue the other way, I only know Angular and prefer it over Ember but I have legit heard that same argument coming from Ember "Gurus"
While everyone's needs and background are undoubtedly different I'm coming at this from the perspective of developing business software that is used globally for over two decades now and I have a pretty good handle on most technology in this area.
I invested a decent amount of time now in both Ember and Angular (also Meteor) writing a proof of concept app for the next major release of our business software.
Frankly most of the negative comments I've seen here either way are low on actual knowledge and high on axe grinding and emotional reactions.
It's interesting when you see a post here that is in your domain of expertise and then see the reactions to it. It really makes you wonder about all the other stuff that you might not know so much about and how much you can trust what people post about those topics.
I found Angular to be almost trivial (even more trivial than, say, Ember, due to being more explicit), except for a bit messily structured documentation and the constant need to monkey patch or duplicate some internals to make them do the right thing (like removing broken sanitization with ng-bind-html, etc.)
Can you read and understand AngularJS source code? can you explain in detail how does the digest cycle works ? and how datas are updated during this cycle ? if yes congratulation , if not , stop saying AngularJS is trivial ,it is not, past the exemples on the homepage. Doesnt mean it's a bad thing , but let's call things "trivial" when they are not.
Bingo. That is kind of my benchmark of "should I use this?". If code is too arcane and hard to understand (especially when docs a slightly lacking) I usually pass it up.
It could reflect on my density and stupidity (can't read code too well) but so far I've had good track record.
I tried understanding and learning Angular.js but got lost in directives, dollar-sign prefixed identifiers, services and other custom terminology.
One way to make sense of it is to look at the source, and that was pretty painful.
Anyway so far it fails my smell test so I'll pass it up. Maybe later will revisit.
Very good point. The terminology is exactly the thing that's (in my opinion) is weird with Angular.
When I had a first glance on it, I didn't really get it. Only after several hours reading the docs and experimenting with code I got what they were talking about things became somehow clear (lots of aha-moments "ahh, the service is just a fancy name for an angular-managed singleton, now I see...").
Scope.$digest is 100SLOC long, about a half of which are variable declarations, closing brackets and comments. I think, anyone capable of reading and comprehending normal non-obfuscated JS code should be able to understand what's going on within an hour at worst.
This is certainly not a trivial part of the code (tree traversal is a bit obscure, they even have comment that it is; it probably could be much nicer if JS would really had graph handling in the standard library), but certainly not "hard as hell", it's more likely "if you need to understand this (as if something goes wrong or works in an unexpected manner), you have to spend some time to get how internals actually work".
I have seen the code that is very hard (if not nearly impossible) to understand without some special knowledge. Angular, in my opinion, is not even remotely close.
The thing is that if you've ever built anything significant in JS, you're going to have a couple war stories and 'easy' is the last thing that you'd call the stuff.
Obviously, I had such stories where I had spent many hours doing what I wanted in a manner I wanted it to do. For example, I had problems with content transclusion and had to dig relatively deep into the source code to figure why I'm not getting what I believe I should. Software without bugs is nearly non-existent, and Angular is still not very mature in some aspects.
But in overall, Angular is very easy - after you spend a day or two toying around, groking the terminology and core concepts. Way easier (in my opinion) than, say, Sproutcore (which I found too complicated to my tastes to invest time learning).
I think drdaeman meant trivial to use / learn. Like Google search, an incredibly complicated system that's trivial to operate. (Also I sometimes read the AngularJS source when I'm stuck reading the documentation, to be fair it's pretty easy to grok, I submitted my first little pull request a couple of hours after getting an idea.)
Yesterday on ng-torronto meetup I saw picture with graph of AngularJS learning steps - it was like up-n-down function and I absolutely agree :) Many times I felt "it's hardest thing" but after understanding all these things looks pretty simple and powerful. Last most challenging issue was with recursive directive (tree) - it took 2 days, but I understand directives much better and other issues looks trivial now :) But I think it was not last puzzle :)
In my current web app I have a lot of work with collections, and each change should be reflected on UI - without directives and bindings it would be hell. With AngularJS even code is clean.
I love angular.. I use it more and more every week.
Ironically, angular speeds up lots of things, but also makes me unproductive in others. Yeah, the end resulting code is usually shorter and cleaner. But I waste so much time with hard-to-understand errors that it's often not time wisely invested so far.
Still, I use it and as I become more proficient with it I expect these random hard to find errors to slowly disappear. (Hey, if one time in my life I was good enough to parse C++ template error messages, I can do it for angular ;-)
"Hard". All of egghead takes maybe 3 hours to go through. And then you're done. The the price of 1 lecture you're maybe 85% of the way there to angular use.
Angular is certainly a platform. I'm usually skeptical about platforms like this, but after using it for a while there are enough wins to justify the weirdness.
When I read things like this coming from experienced smart engineers a little voice in my head starts yelling "incidental complexity." When I see engineers who are building web applications discussing the nuances of type theory and the complexity of Javascript frameworks I wonder how much time they have left to solve the actual problems their users have.
AngularJS is more powerful than any other Javascript framework. That's reason enough to use it, unless the application you need to write requires more than Angular offers.
I'm still not convinced that forcing the client-side to build DOM elements is the right way to go; especially in the mobile sector where CPU cycles are at a premium.
For instance Backbone is pretty much what would happen (give or take) if all the JavaScript books on how to program OOP and MV* got together and build a JS framework. It's not fancy, it's not "magic", but it is very approachable in terms of advanced standard/best/popular JavaScript programming practices.
AngularJS left all that stuff behind and built their own little world. It might even be a great world, but on the surface or to the implementation-level developer has little to do with "regular" advanced JavaScript programming techniques/patterns.
To me it's a bit like the JavaScript version of Drupal, which gives you a ton out of the box, but is just it's own whole world of conventions etc, that has little do with anything seen outside of itself.