This looks like a good resource. But number 28 is wrong:
> Always have a ‘.’ in your ng-models which insures
prototypal inheritance.
That isn't what that does. The egghead.io Angular videos also get this wrong. I really think that the vast majority of Angular programmers don't really understand how its scoping works. I've ranted about this before [1], it's just ridiculously complex.
Some scopes inherit prototypically from their parents, and others don't, and you can't tell or affect it from the markup. The dot just means you're referring to a property of an object on the scope. If the object is somewhere in the scope inheritance chain, two directives attached at different points in that chain can share data by pointing to the object. If the object isn't there, what the name points to is actually non-deterministic. Ng-model silently creates it, and the point in the chain at which it creates it depends on which directive wanted to write to the property, which might depend on the order in which the user interacts with the different elements on the page.
> Whatever the reason is for Angulars popularity, it isn’t that it’s a great framework.
Anything that makes programmers productive is a great tool. Angular 1.x definitely makes teams productive. It's one of the first web framework that comes with a specific testing framework. The clear separation between the DOM and the business logic makes apps more testable. And I could go for hours. Angular helps developers write complex apps faster and better.
Sure it isn't perfect, but show me something better with all the features AngularJs has.
AngularJS didn't became popular because it was from Google, a simple proof is the closure widget library nobody uses outside google. AngularJS became popular because it was obviously superior in term of developer experience.
Now your point about ng-model and scopes is valid.But it's not a angular problem, it's a javascript issue.Ultimately to understand angular you need to understand how javascript works, which many develpers don't.
Instead of saying "this thing is bad", Educate them. But I guess sensationalism drives more clicks.
I got tons of both hate and love for that blog post. One of the few criticisms that I can accept is the "The problems are real, but don't matter that much." view. I don't agree, but I suppose people can have different experiences there.
Any 'sensationalism' comes from legitimate anger with the framework, after having spent over a year working with it on a large project.
> Now your point about ng-model and scopes is valid.But it's not a angular problem, it's a javascript issue.
This I don't agree with. Yes, JavaScript has prototypical inheritance between objects, but certainly not between scopes. It has lexical scoping like everyone else. The decision to have scopes be objects that (sometimes, not always) inherit from one another, is entirely on Angular. So is the decision to have ng-model silently create objects on this scope.
Most people don't understand directives, so they resort to a pub/sub communication model that makes the web page unable to scale when you have too much items that are binded/coupled on a page.
No optimizations are possible for an exponentially resource greedy problem.
>Anything that makes programmers productive is a great tool. Angular 1.x definitely makes teams productive.
Definately? Based on what? The teams i've seen and projects i've been on that use Angular take much longer and end up with slow, buggier code.
>Sure it isn't perfect, but show me something better with all the features AngularJs has.
Meteor, Ember, React, Qooxdoo, Extjs, Backbone, etc... pretty much every other framework. Most of them don't specify a half-baked programming language hiding in data attributes in your dom-nodes.
>AngularJS became popular because it was obviously superior in term of developer experience
That is a lie. Angular seems to attract back-end programmers who have been moved to the front-end because it uses design patterns that are more common to back-end development. Find me a single Angular fan, that has actual job experience with at least two other SPA frameworks.
>Instead of saying "this thing is bad", Educate them. But I guess sensationalism drives more clicks.
You are misrepresenting his blog post, mostly out of spite.
Here's a more generic complaint: doing control-flow by annotating dom-nodes dom just means you lose proper debugging, refactoring, scoping and not to forget: hurts performance (since dom reads are much too expensive).
Angular is one of the worst executions of a fundamentally flawed approach. The only people defending it are those who are not familiar with _any other alternative_.
Well you didn't disprove my assertion (I was obviously talking about front end frameworks) by citing a front end framework that came with an extensive testing framework. So why on earth are you saying something without backing it with facts?
> But it was definitely helped that it was so heavily promoted by Google
I started using AngularJS in 2011 it had 0 promotion from Google. It wasn't even a Google product at that time.
> Again...what? JavaScript doesn't have `ng-model`...Angular does. It's an Angular problem through and through.
No the problem is that Javascript doesn't have pointer variables,therefore when using variables in a scope you need to use object properties and not objects directly if you want to refer to it in the outer scope. It has nothing to do with angular but everything to do with the way Javascript works.
>Well you didn't disprove my assertion (I was obviously talking about front end frameworks) by citing a front end framework that came with an extensive testing framework. So why on earth are you saying something without backing it with facts?
Let me help settle which of you two is the liar then.
Ember comes with tooling for unit-tests and so does Qooxdoo (which also includes Selinium support out of the box).
And that's just two of three i'm familiar with.
>No the problem is that Javascript doesn't have pointer variables
There you go: pass-by-reference semantics (i.e. pointer variable)
var flow = function( init ){
return function( v ){
if( v !== undefined ) init = v;
return init;
}
}
> It has nothing to do with angular but everything to do with the way Javascript works.
No, it has to do with the ad-hoc programming language shoehorned into dom-nodes. Javascript has lexical scoping, Angular does not, because its control-flow lives in your dom. It also doesn't have encapsulation or proper step-debugging this way. But none of that has anything to do with Javascript. If all that logic lived in a .js file lexical scoping would be possible and recommended.
It's got some good information on some pieces of angular that more people should have a better understanding of, yes. However, trying to absorb that information through the shouting and sensational ranting is almost impossible.
This same article could have been written by a level-headed coder who understands the complexity of making a widely distributed browser frameworks and it would have been called "5 Angular Idiosyncrasies" or "Tricky Angular Patterns".
But no, sensationalism sells and loud, strident claims win the day. Why have humility and get less clicks when you can write a scathing takedown using strawman arguments and style yourself the next Crockford?
Your points are entirely valid criticisms, but your language and attitude make you sound like a blowhard trying to prove something or a shill promoting a competing framework with negative press.
FWIW, my tone in that article is exactly the tone I would have if you got me started on this in a real life conversation. If I sound like a blowhard, at least I'm an authentic blowhard, it's not some act I put on for the clicks.
The tone comes from being legitimately angry at these flaws in Angular, but also from having to discover them myself, instead of reading about them on someone else's blog. The various JavaScript frameworks affect hundreds of thousands of developers every day, and choosing the wrong one can cost companies a lot of money. I really think that as a profession we'd make progress faster if more people wrote angry blog posts about things that are bad.
I appreciate a human, conversational approach to technical information and applaud you for your blog's tone. If you were writing for a professional news site it might be inappropriate but as a post on your own blog, you're entitled to whatever writing style you want.
Then lets be sure not to have any real-life conversations, though I do appreciate you being authentic about it.
I agree 100% with the idea that it's better when people know about potential pitfalls before making big decisions and I hate how much marketing is involved in promoting frameworks. Read any of my comments on a Meteor post and you'll see similar anger and points to those you made about Angular.
However, anger is over-rated as a communication tool and is automatically limiting your receptive audience. I use is without thinking and shoot myself in the foot all the time, like in my comments about Meteor. But comments are comments and easy to publish without re-reading to consider how the intended recipient will take your words.
Not so with blog posts, when considering your audience you should consider whether people who are turned off by blowhard advice are going to respond how you want. Or do you only care about reaching those people who like to be yelled at, or are already angry with you (and thus a part of a choir you are preaching to)?
I see there are others willing to express appreciation for your tone, I will not. The question is, because I don't agree with your tone, am I the one who misses out on what you (and other blowhards) have to say, or are you the one who misses out on the positive responses of everyone who feels the same as me?
Also, consider how much of what you opine on regarding patterns and standards or whatever isn't naively influencing those new coders you're trying to save with your bluster. Here is a relevant article from the homepage today, does it resonate at all?
Sheesh, I never got into angular because the "DI by parameter name" thing seriously bugged me but had no idea that the variable scoping in models could depend on the order that the inputs are used! How can people live with that?
Interesting article, although I feel that some of your time may have been better spent submitting the changes you felt (like for documentation) as pull requests to help make it better, rather than just ripping on it.
I love working with angular, but the intense competition from other technologies combined with the overall negativity towards it has turned me off. The long term future of angular seems very uncertain.
I suspect Google would gain a huge amount of goodwill if they backed down and announced: "You know, we'll rename the incompatible redesign as AngularNext 0.1 and use it to develop cutting-edge ideas. Then we'll bring the best of those into the mainstream Angular over time without breaking compatibility."
They could call the rebooted compatible Angular 2.0 "Harmony".
The Angular team is not going to do backwards compatibility with Angular 1.x with 2.0 at all - they're going to help with migration some with the router, but the api are fully incompatible.
FWIW, Angular 2 is awesome to work with, even in its alpha form. Productivity with it should be immensely improved compared to 1.x.
You should spend some time watching some of the videos about Angular 2.0 from ng-conf, and you may see that there is much less reason for the opinion you have stated. The core team and some of the other presenters really laid out both a migration path going forward as well as the advantages Angular v2.0 will bring, and why they couldn't just do it on top of Angular 1.x.
I wouldn't call this a cheatsheet in the same sense of the emacs/vims ones which list mostly keyboard mapping shortcuts. This is more of an abbreviated overview of the framework, complete with sample code demonstrating the patterns.
You are right, I should not compare apple and orange: you can edit text, play soduku, do syntax highlighting easily, search/replace with regexp in vim, while in angular JS you can only do slow, unusable data bindings. So comparing the 14pages of angular sheet is way too much of a disgrace for vim or emacs.
Btw, I use kate that need NO cheatsheets, because mastering an editor does not make me a better coder...
EDIT: ok I also use vim, emacs, joe, nano, ultraedit, gedit, visualstudio, netbeans, eclipse, nvi, simpletext, texmate, sublime ... whatever the guy paying me want me to use even if it is stupid.
> 24. Wherever possible, use AngularJS versions of JavaScript functionality. So instead of setInterval, use the $interval service....It becomes easier to mock them or write unit tests
I've always been very against these angular versions of basic js functions because it requires everyone on the team to learn them and it puts you even deeper into the angular lock in swamp, hindering you from eventually changing your view-framework in the future. Any takes on this?
I like the data binding of angular but try to restrict angular coming in contact with "core" code. As example we hardly write any services, we just use them to hold an instance of plain js-classes that can easily be reused in non angular projects.
Services such as $interval or $timeout are very simple - $http is also a fairly simple service to replace too. I don't really view it as much of an issue when it comes to lock in or migration, there are usually far more perilous pitfalls when it comes to lack of being able to migrate, such as bad app architecture or hacks.
I agree with you. It doesn't matter how thin the wrappers are or whether they preserve the API, the problem is all code is supposed to call them.
It's no problem to call $timeout in your Controller code or whatever, but what if you want to require a module that uses `setTimeout`? Either the module has to have some way of passing in the timeout function it should call, or you'd have to have a shim that monkey patches it or something.
Services like $timeout and $interval are basically just thin wrappers around their vanilla JS relatives(setTimeout and setInterval), there are more examples like this.
The APIs look identical, some with a little added functionality - but the primary reason for the AngularJS wrappers is that they'll automatically call $scope.$apply() for you, so that you don't have to do it yourself.
I would avoid investing too much in UI Router. As soon as the new Angular 2 router is available, it should be used for Angular 1.x projects as well to support migration to Angular 2 in the future.
I am getting enough energy kick from my angular day job on pretty intimate level :) Also, it serves me as a collection of "gotchas" to point to new devs.
> Always have a ‘.’ in your ng-models which insures prototypal inheritance.
That isn't what that does. The egghead.io Angular videos also get this wrong. I really think that the vast majority of Angular programmers don't really understand how its scoping works. I've ranted about this before [1], it's just ridiculously complex.
Some scopes inherit prototypically from their parents, and others don't, and you can't tell or affect it from the markup. The dot just means you're referring to a property of an object on the scope. If the object is somewhere in the scope inheritance chain, two directives attached at different points in that chain can share data by pointing to the object. If the object isn't there, what the name points to is actually non-deterministic. Ng-model silently creates it, and the point in the chain at which it creates it depends on which directive wanted to write to the property, which might depend on the order in which the user interacts with the different elements on the page.
[1]: http://larseidnes.com/2014/11/05/angularjs-the-bad-parts/