AngularJS: The Bad Parts
larseidnes.com
larseidnes.com
No, what I hate about Angular's DI is that it tries to make inferences about the name you give it, instead of the name being an unambiguous identifier. It does this for "convenience" but it just ends up causing problems and making incorrect guesses.
I'm talking about how, for example, if you have a class called WobbleController, you don't inject 'WobbleController', you inject 'Wobble' and Angular just "figures out" the 'Controller' part. Pretty sweet when it works! Wow, you don't have to type 10 characters! (Good luck grepping for it later, though.)
But when it makes a wrong guess it seems impossible to fix. The other thing that sucks about this is that you have to reload your app to see if Angular will actually be able to find the thing you're injecting. This whole thing is supposed to save time, and it just doesn't. It sucks.
Yes - use a minifier that doesn't break Angular code. Asking me to insert repetitive verbiage isn't an acceptable solution.
And like I say, no way to check that you've fixed the problem except reloading your whole app and waiting for it to show you an error, or not.
The DI looks for 'Foo', can't find it so it looks for 'FooProvider', can't find it, and throws an error saying it can't find 'FooProvider'.
edit: This portion of a down thread comment captures my complaint well:
"In a sane framework, errors are meant to direct you to the cause, not simply to announce that something somewhere is written in a way that the framework doesn't like because of complex reason foo."
By the way, Ruby on Rails does tons of this sort of thing, and goes a lot further. It automatically matches your Person class with the People table in your DB.
To me that's infuriating. I get that Javascript isn't Haskell (and I don't even want to go that far into that direction), but the combination of extreme leniency and the remarkable absence of checks is really bad.
Templates shouldn't be throwing exceptions for something like customer.name when customer is null. Angular's rendering tries to do something sane by default in a very common case.
If it really bothers you, you can easily write your own click-log-error directive that writes to the console if the function isn't defined.
Actually thanks to Angular's DI system you can replace the base ng-click with one that does throw an error.
Sure, not rendering a null value is, while I disagree, a possible choice and certainly useful in certain contexts. However the point about objects not ready should IMO be rather fixed by delaying until the object is ready and I'm actually horsing that if possible so that no uninitialised state is visible at any point.
And again, for production mode you mostly don't want exceptions to pop up, but a strict mode for development is useful. Otherwise someone (who? the customers won't notice this way) has to tell me that some values don't show up (yes, modulo testing).
Replacing those handlers is actually a very interesting idea, I'll try and see how that goes.
That being said, it's frontend stuff. The turnaround times are so small that those kinds of bugs are pretty hard to ignore, and very easy to find.
Note: I have used Angular, but don't use it anymore, for other reasons.
There are MANY viable alternatives. No one solution fits all, but some solutions, like Angular, fundamentally suck at everything, because they're terribly designed, and their developers refuse to acknowledge or correct that fact.
In order to answer your off-topic question, which is outside the scope of this article, you'll have to explain in detail all about what your actual requirements and experience and expectations are, and for that you should expect to pay a reasonable hourly rate for an experienced developer to listen to you and give you advice.
If that's what you really want, then good luck finding someone to help you with your problems choosing a decent web framework, but at least you now know that Angular simply doesn't qualify. But if you're just trying to imply that it's not right to criticize Angular without evangelizing an alternative, you're wrong.
That's utter BS. There are lots of very good ideas in Angular. Yes, some of it is not done nice but at the end of the day it's quite a nice framework. Have you even worked with angular?
Also, Angular forces structure on you in ways JQuery doesn't. It makes unit testing viable. I rewrote a javascript slider in Angular, and the code became a lot simpler, shorter and more readable, exactly because of all the stuff Angular abstracts away.
So in comparison with JQuery, the previous best javascript library, Angular has some very clear improvements. How it compares to Ember and Knockout, I have no idea.
But then I tried react and the whole idea of unidirectional event flow made sense, JSX was a little confusing but it was simple to grasp the need and use of it.
Not really. Angular is its own little world of terminology and ideas. I've heard it said that Angular users don't learn JavaScript, they learn Angular.
I really like the acknowledgment that UIs are fundamentally state machines, and React's explicit connection between state and rendering. I do wish they would introduce more featured state transition/events modeling...Something similar to Jake Gordon's javascript-state-machine[1] library would be amazing.
That annoys everybody. It's that way because the JSX attributes map directly onto the DOM attributes which in turn are named that way to avoid ES3 reserved keywords. It's supposed to be less magic/surprising but far more people interact with JSX (e.g. designers) than work with raw DOM manipulation.
The concepts on Angular have nothing to do with JavaScript. The new changes they propose to JavaScript borrow most from Dart, which in the eyes of a JavaScript programmer is an attempt to turn JavaScript into Java.
In Zope, any property could be inherited not just from the parent object, but from the current context; you could invoke the object path "a.b" and b would inherit from b, but if you invoked the object path "a.c.b", b would inherit from c instead. They called this design pattern "acquisition", and seemed rather proud of it until they realized it was the kind of magic that was ultimately too magical for its own good.
The Zope guys tried very hard to eradicate it, and in the process ended up alienating all the developers with the new, non-backwards-compatible version. Funnily enough, there is another Angular parallel to Zope: Just like Zope 3, AngularJS 2.0 is also not backwards-compatible.
Angular's parameter-based dependency injection is coincidentally the same reason Martini [1] is slower than most other Golang web frameworks. Clever, sure, but ultimately a design flaw.
These problems demonstrate how important it is to introduce a good design from the very beginning. You can fix bad code, but bad design is much harder to change.
But I don't really mind anymore for two reasons: I know most of the gotchas now (probably after some loss/whitening of hair), and I haven't used any of the other major frameworks (like ember) to really be able to make an informed comparison.
I don't know if there's a real takeaway here. Maybe "evaluate major contenders even if one is super popular" or "be more vocal when someone tries to blindly railroad in a candidate"?
For example point #4 complains that Angular redefines Constructor to mean something else.
The controller constructor IS a constructor, it constructs an instance of a controller and can request and decorate(or construct) a new scope by injecting $scope.
But the debate aside... the quoted revision is over a year old! (It also hasn't reflected the behaviour of the controller constructor for even longer than that, but that's a separate matter.)
I realize there's the third party AngularUI UI Router project. I'm assuming everyone who uses Angular for any real project uses that.
The issue is resolved simply by using controller as syntax which is recommended in many blogs. Point taken about the pit of dispair though.
The kicker is elimination of these concepts: Controllers, Directive Definition Object, $scope, angular.module, and jqLite
Technically, Angular 1.0 also had its own scripting language too. It's kind of inevitable, since Javascript itself is one of the obstacles to making a better web framework.
That, in my opinion, was one of the most terrible ideas I've ever heard come out of the Angular community. And even worse, they refuse to acknowledge that it's a bad idea. That's a very bad sign indeed.
It's the realisation that this is a fundamentally bad idea that was the real kicker for me.
The more you try to write clearly structured, maintainable Angular, the more it begins to resemble React.
Well, painless at first. Because eventually you run into the limitations. The data binding doesn't scale, a lot of things that are easy to declare (particularly scope variables for directives) are a lot more complex than they initially seem. The article hasn't even scratched the surface on problems with scope in Angular.
And then there's the fact that my templates keep turning everything into strings. Too often, when binding stuff from an outside controller to the isolate scope of a directive, I keep having explicitly to turn all the strings back into numbers.
Still, Angular does a lot of very neat stuff. There are just too many common use cases that the neat stuff doesn't really cover very well.
React's data model is much simpler, at least at a high level. State changes are explicit, and data is immutable. This means that whenever you give a component new props, it can simply do a deep comparison of the data with the previous version and mark the component as dirty if it's changed. (Setting a new state always triggers a re-render, no matter if the data is different or not.) Since data changes only happen explicitly, and flow naturally through component nesting, it doesn't need process a lot of data to figure out what needs to be updated.
The list of dirty components is then processed to produce the virtual DOM, which is then diffed against the real DOM. Doing anything with the real DOM is expensive, whereas the virtual DOM is extremely fast. So is building the virtual DOM; while it's true that a component's render() method needs to build its own tree every time it's called, re-rendering is extremely fast, even if you actually change state near the root of the virtual DOM (which causes a bigger cascade of dirty checks). Current JS engines are capable of creating tens of thousands of objects in just a few milliseconds.
(There are a few of optimization tricks you can use to avoid renders, too. In particular, there is PureRenderMixin, which declares that your component is "pure", meaning that given the same props and state, it will always render the same tree, allowing React to do shallower checks to determine if a render is needed.)
Something similar to this seems to be true for every piece of programming technology that is popular. How did it come to this? Other professions don't go in masses towards the worst solutions, do they?
-Bjarne Stroustrup
Every piece of tech involves design tradeoffs. Most software benefits from network effects -- there are advantages to using what everyone else is using. Because of that people inevitably end up using software with design decisions they disagree with.
It's worse in programming because their are fewer hard design limits. Everything comes down to preference.
That's not to minimize the trouble you get when you first have to learn about scope inheritance, but I think ng-if may be the only completely non-intuitive directive of the framework. (As opposed to something like let's say ng-repeat, where you sort of get the intuition that some care will be needed).
ng-model will auto-create scope variables if they don't exist. That's a handy shortcut.
But if you have two inputs that can auto-create variable you're asking for trouble, and you should probably initialize it on the scope constructor.
Or at the very least, use an ng-init so that you know where it will be created.
It only took me a couple days of fooling around with it before I built something useful with it. The steep learning curve is only if you want to know the how-and-why behind every feature of the framework (which I still am not even close to). Learning 100% of the framework is simply not necessary for certain apps.
It's easy in my opinion, it's quick, and it gets the job done. If I run into any problems, there about a bazillion stack overflow post addressing my issue already.
But eventually you will run into more complex use cases, and the beautiful abstractions of Angular will fall apart. And the problems I run into often only have unanswered questions on Stackoverflow.
To elaborate: invoking the argument "you reduce to the Halting Problem, suxxor!" without some concrete examples of how the practical problem (i.e. ng-min implementation) encounters difficulties is disingenuous. It's not uncommon to be able to cover some very useful space of a real-world problem, skirting "inside" a problem which is theoretically limited by the Halting Problem or similar. Occasionally you hit a limitation in your algorithm and add a special case, further claiming practical territory from The NP-Complete Beast.
In this case, the strict di enforcement that baconner mentioned in this thread provides an escape hatch: if you're using ng-min while having di enforcement enabled, you'll at least get warned if something goes amiss. If so, add your manual DI annotations, maybe file an ng-min bug, and move along.
Since this shortcoming is hard or impossible to overcome completely, case-specific post-processors to help out the minifier sound reasonable to me.
I think your point about the minifier being "broken" is a good one, but the real problem is with AngularJS in my opinion.
This shortcoming is easy and possible to avoid in the first place, totally eliminating the need for case-specific post-processors to help out the minifier.
Some advice: next time you design a framework, how about designing it not to require case-specific post-processors from the start? Then you won't end up with so many shortcomings that are hard or impossible to overcome completely.
I agree that identifier names should not matter for semantics, but it's quite possible to write JS (and other language) programs that do. So, your first sentence is simply incorrect, it is part of the semantics.
So yes, it's not best practices to do this, but it's not exactly "insane". Constraining your design on non-semantic-preserving minifiers is not the answer.
Also: In your last sentence, like in the linked article, it sounds like you and the author are under the belief that framework/api design is easy - and anyone who gets it wrong is an idiot.
I'd say that angulars behavior here is very unexpected, by mapping parameter names to registered controllers, but I'm not sure if the minifier can be said to be incorrect. If javascript has a way to get the names of the parameters, is it then incorrect to assume this can be used? Strictly speaking if you want to conform fully almost nothing can be minified since object==dictionary but you have to draw the line somewhere, maybe parameter names are moving over that line.
When do you think schools teaching JavaScript should instruct their students how to write easily minifiable code? Is that an appropriate topic for JavaScript 101, or is it more of a graduate level thing?
Can you please suggest any good online course where I can learn this important skill that you're suggesting all JavaScript programmers should have?
Has Doug Crockford written a book called "JavaScript: The Minifiable Parts"?
Does Google test job candidates for the ability to write minifiable JavaScript code on the white board during job interviews, by giving them a dry erase marker that's almost run out?
So do you really believe that the insane scoping madness described in the article, and the fact that Angular's new templates breaks HTML syntax making it impossible to edit/validate/transform/generate/consume them with standard off-the-shelf HTML tools, are really not big issues, and dirt-simple two-way binding outweigh those problems, and are impossible to do without causing those other problems in the first place?
Since the order a user fills out text fields on a web page affects the scope in bizarre unexpected ways, shouldn't Angular automatically disable the offending second text field until the first is filled out, and provide tooltips and help text explaining to users why they're disabled, to force users to enter them in the correct order, that will not undermine the intent of the developer? Is that the kind of implicit magic that you expect from your full service front end web development stack, that makes it all worth it in the end?
Personally, I'd rather have a scoping mechanism that's less magical and astonishing, and more deterministic and predictable. And a templating system that doesn't forsake and reject the rich existing ecosystem of HTML and XML tools.
Yes, this is insane. No, they don't do this anymore. But I'm glad I had the opportunity to do this (on somebody else's dime), because it made me really think about latency and on the performance trade-offs you make to get maintainable code. Code size is not free; many devs think it is, and they write really bloated SPAs as a result. And there's also a lot of low-hanging fruit that doesn't require lots of engineer effort but gives appreciable latency benefits.
The digest loop is highly flawed, as the article describes - it is not performant, and requires disabling for many common scenarios.
Worse, and I don't see this mentioned, is that the digest loop is not tied to any notion of lifecycle - you can accidentally keep retriggering it until you bomb out after 10 loops.
Forgetting to set up your eventing fabric is not a great reason to choose a framework. If you forget to hook up the wires, the view doesn't render properly. This is easily debuggable.
Uncaught TypeError: Cannot read property '$$nextSibling' of undefined
By the way, very nice article, and after working with some real time angular apps, the thing that haunt me the most is the number os binds.
People just want more information, and it can hard to explain that we have a limit.
To me, this is already revealing. A critique of a web framework and this is the first impression I get? Not off to a good start. There’s a reason people find it hard to trust a fat nutritionist. I see parallels here.
Lately there has been a lot of negative feedback about AngularJS and I have been interested in the critiques of its shortcomings. For this reason, I gave him the benefit of the doubt, pulled up the article on my computer, and dug in.
His initial complaint about prototypically inherited scope properties (Bad Idea #1) being confusing and "literally impossible" to predict was perplexing to me. He states that he understands a child scope will inherit from its parent scope, yet doesn't explicitly instantiate any object on the parent controller in his example of the so-called problem ( http://jsfiddle.net/1op3L9yo/ ). A child of a parent with no properties inherits nothing from its parent -- this seems obvious. If properties are actually defined on the parent the child will inherit them. Is this not the expected behavior?
The "fix" for his "impossible" scenario, is to make sure you explicitly define the property on the parent.
In his specific example, that would look like this:
$scope.obj = { prop: '' };
( http://jsfiddle.net/355fuxk5/ )
He complains: "Whether or not a new scope is introduced by a directive is up to its implementer. And if a new scope is introduced, it is up to its implementer to decide if it inherits from its parent scope or not."
How is this a bad idea? I like choices in life, don't you?
He talks about dynamic scoping being a terrible thing. I think the alternative, dictating One True Way of doing things, removes flexibility. This would be far worse than the current status quo of leaving it up to the developer. He advocates for removing this choice altogether, but is there NEVER a good use case for this "dynamic scoping"?
He also complains about the digest loop -- how two-way bindings constantly check for changes and impact performance as your number of bindings grow. There is truth to this, but it is easy to write your own directives that only update UI elements when a change occurs. This can easily be achieved in a variety of different ways. (The most universally familiar of which being a simple callback paradigm.)
Building a quality application with angular requires you to think, but I would argue that designing a performant application with ANY framework demands the same thing. You might initially think you get some things for free, but everything has its costs. If you want things to happen automagically, without needing to be explicit about the needs of your specific use case, that'll cost you. Is this not a near universal truth in programming? People fault the framework when, instead, they should be faulting themselves: their own laziness or lack of clarity.
He talks about having a page listing where their UI already had 2000 bindings and how clicking a "load more" button added another 1000 bindings, killing performance. I can't understand why you would possibly have that many bindings... for ANYTHING, unless you're Doing It Wrong. Why would you need any two-way bindings for explicitly appended information? When the user clicks "load more", we know something needs to change. If performance is a concern, why would you ever allow that listing to be automatically updated by checking for changes on every digest cycle? Instead, you can either explicitly update the element when the action is called (no two-way bindings), or use a SINGLE binding for the entire list. 1000 bindings? What could possibly be the justification for that?
Bindings can be drastically reduced and performance dramatically improved if you work to optimize your code and move from prototyping with built in ng-* components, to crafting components explicitly for your needs. I truly believe the standard ng-* components are meant more for prototyping and to serve as an example for how you can accomplish similar things as your write your own application specific code. Not being clear about this is perhaps one of angular's biggest failings.
Does it really surprise any programmer or developer that in order to achieve high performance in your application, you must architect explicitly for your use case?
To put it another way, in order to make a great application, you need to understand what is happening under the hood. If you're using components that you don't fully understand, that end up running a bunch of unnecessary operations, is that the framework's fault, or your own?
Is it really the role of the framework to do your development for you? You can either have things happen automagically, or have things be performant, but not both. This is reasonable and beyond logical, I think.
He critiques the language used in the documentation to explain controllers and hangs his hat on what he feels is the misuse of the word "constructor". His contention is that this is incorrect because the controller functions are being applied to an existing scope, not being instantiated in the traditional sense. Yet, and he even admits this, he is critiquing documentation that is over a year old. The current docs do a better job of clarifying what's actually happening. How is this a fair critique of a framework? Cherry picking year old documentation... this just seems silly, and as someone else said, disingenuous. Nothing is perfect, especially out of the gate, especially in open source -- I think we all know that.
His further complaints in this section employ the same strategy -- he takes segments from the documentation out of context and explains why they don't make sense. He even says that their use of the term "syntactic sugar" to describe the many options for creating components (services, factories, providers) is incorrect because, in his mind, "syntactic sugar" would imply a direct syntax modification to JavaScript or implementation of a custom language parser. Really?
Let's see what Wikipedia has to say on the subject:
"In computer science, syntactic sugar is syntax within a programming language that is designed to make things easier to read or to express. It makes the language "sweeter" for human use: things can be expressed more clearly, more concisely, or in an alternative style that some may prefer." (http://en.wikipedia.org/wiki/Syntactic_sugar)
Soooo, for example, angular's service and factory being abstractions over the provider implementation? When you don't need the full power of a provider using these higher level functions makes it more concise, easier to use, and "sweeter"... sounds like syntactic sugar to me, unless we're just being pedantic for the sake of it.
He says, "Angular seems to strive to make things as complicated as possible." I would argue that this simply isn't true, is shortsighted, and borderline insulting to the intelligence and efforts of angular's core team. I believe AngularJS is opinionated but it strives to make things as flexible as possible and as a result some inherent complexity exists.
In my (almost) 2 years of working with the framework, this is what I’ve found: AngularJS is extremely flexible. Its built in components are great for quick prototyping and its underlying structure provides an excellent FRAMEWORK for creating more purpose built, application specific, code. In my experience, angular is there when you want it to be and quickly gets out of your way when you don't need it. This is a robust framework. It is built for rapid prototyping and creating complex, performant applications (when properly executed). It is not baby's first framework.
How many times have we heard the old adage that, with most things in life, you get out what you put in. This is doubly true for angular (and development as a whole, I would speculate). If you're willing to put in the work, AngularJS can be a phenomenal tool in your arsenal. It can also be great for getting a prototype together, but one must understand, that a prototype is just that. Using ng-* components everywhere and expecting everything to work out optimally is just not going to happen. Did you REALLY think it would?
To pull a quote from his last paragraph:
"... many people like to recommend projects they haven’t used in any depth, because the idea of knowing what the next big thing is feels good. The result is that people choose frameworks largely based on advice from people who don’t know what they’re talking about."
The irony here is palpable. Change "recommend" to "criticize" and "knowing" to "condemning" and I almost needn't say more (he says, 8000 words later).
Of course putting enough time on a framework can pay off once you've mastered the tool and know all the caveats. The problem is that if you weigh the pros vs the cons objectively, the cons are not something you can scoff at. Angular has a lot of complexity that is difficult to reason about, and there are a lot of traps along the way to mastery (speaking from experience seeing co-workers shoot their own feet).
For me, the biggest problem is that it throws some seriously useless errors (e.g. race-condition infdig on a route redirect). In a sane framework, errors are meant to direct you to the cause, not simply to announce that something somewhere is written in a way that the framework doesn't like because of complex reason foo. This can be a serious showstopper if you are more than a single developer working on the codebase and even more so if the rest of the team touching the codebase isn't made of Angular superstars (which is often the case).
Usually stated by people who feel the need to comment in the thread about an article covering a subject they've already read about; just to point out they don't want to read about the subject again. It's like a driving need to spread their negativity towards discussing anything more than once.
Bad Idea #2: can be avoided using gulp. If you are minifying, you should be using gulp anyway, so it’s just a matter of adding a plugin to take care of that
Bad Idea #3: this is true, and you have to take care of it for large-scale applications to prevent performance breakdowns. Since angular 1.3 there are one-time bindings as well.
Bad Idea #4: This sounds like nitpicking from a JS purist
Bad Idea #5: I agree that this stuff is unnecessarily complicated
so yeah… there are many ways that you can break Angular :p learning curve is definitely steep.. and there are plenty of edge-cases that will bite you. Despite all that, it’s pretty powerful at what it does, once you get around it…