Live data from Hacker News

Things that suck in AngularJS

lhorie.blogspot.ca

51–60 of 151 posts

Re: Things that suck in AngularJS

#52
post #15

Documentation is by far the worst part of Angular. I spent 90% of my time Googling and 10% writing code. (Hey, maybe that's Google's plan -- ramp up traffic to search. Synergy!) AngularUI is confusing, mostly undocumented and often behind Angular. Splitting ngRoute/ngAnimate into their own files is an odd choice, although I assume the former is so they can replace it with the superior ui-router. Which also is weird.…

> Google has the chance to build the new framework that will run the web in 2-3 years. Much like Rails a few years ago. Angular is an amazing framework. It seems like they just don't care. People use to say that about ExtJS a few years ago , then BackboneJS, etc ... There will never be one framework to rule them all , like Rails never ruled server-side developpment, Rails influenced other frameworks. Likewise Angular…

The problem with Closure is that it really sucks for small projects. It was built for large products with hundreds of developers and millions of users; many of the library features (eg. static typing; dependency management; compilation; CSS renaming; namespacing & scoping; full component libraries) are absolutely invaluable for that use case, but don't get you much when you're just prototyping a few ideas. I don't think Google's webapps could run on any framework but Closure, but when I and many of my coworkers want to do a quick prototype, we reach for JQuery or Angular. Or even just native DOM APIs.

All big projects have to start out as small projects first, and so most small projects. If a small project uses a framework that's great for big projects, they're paying all the overhead for that up-front, which puts them at a disadvantage in the marketplace. I could see Closure being quite useful for rewrites, but once a dev is in charge of rewriting a project with dozens of devs and hundreds of thousands of users, he probably doesn't have time to blog about the latest JS framework.

Re: Things that suck in AngularJS

#53

Documentation is by far the worst part of Angular. I spent 90% of my time Googling and 10% writing code. (Hey, maybe that's Google's plan -- ramp up traffic to search. Synergy!) AngularUI is confusing, mostly undocumented and often behind Angular. Splitting ngRoute/ngAnimate into their own files is an odd choice, although I assume the former is so they can replace it with the superior ui-router. Which also is weird.…

Personally, I skipped the docs and went straight to the API guide. Reading that had me only Googling for edge cases, such as scope changes within ng-repeat.

Re: Things that suck in AngularJS

#54
Angular, when it feels right, makes me incredibly productive, but I feel like I spend 90% of my time banging my head against a brick wall.

One of the single biggest usability features of anything is giving things appropriate names. The "other half" of Karlton's law is well in effect here. Angular fails miserably at this task. And that makes reading documentation, as well as maintaining enough context in my head to be productive nearly impossible.

From a documentation standpoint, the documentation focuses on "this is how this function works internally" rather than "this is how you use it to produce results".

I want to like Angular. So much of it feels right, and technically it seems excellent. It really is a usability nightmare, though.

Re: Things that suck in AngularJS

#55
post #36

I found Angular to be overly complex and couldn't imagine training a team to learn to use it in reasonable time. That's the scariest part of adopting Angular for me. How would other coworkers adapt to the API and how long would it take for them to use it? The documentation was o.k at best, but I find that isn't the core issue. If you take a look at http://docs.angularjs.org/guide/concepts , it takes a very long time…

I disagree. I very like how the learning curve of angular follows my simple to complex application features. What I mean is that it's very easy to get started and hack you way through something that work, even if it's not 100% angular best practices. I.e. putting jquery code in your controller. As you become better and better, you start to have a better understanding of how angular works and your code improves similarly. I think this is an amazing quality for a framework. It reminds me how fun it was with jquery to get started even if the code was terrible, and then improve from it as you learn.

For a newcomer to an angular project, they can simply read the html and have a pretty damn good idea of what's happening. You don't have to start writing directives and play with transclusion right away.

Re: Things that suck in AngularJS

#56
post #54

Angular, when it feels right, makes me incredibly productive, but I feel like I spend 90% of my time banging my head against a brick wall. One of the single biggest usability features of anything is giving things appropriate names. The "other half" of Karlton's law is well in effect here. Angular fails miserably at this task. And that makes reading documentation, as well as maintaining enough context in my head to be…

I agree with you that it's frustrating at time. Especially when angular does magic stuff that you're just supposed to know. Like fuck with your existing links and stop existing forms from working.

And sometimes, real easy things are so complicated.. For instance, try to make a form post on the current page. (Hint: If you don't have action="", then the form doesn't post. But, by default, no action usually means submit to current page.) (Hint2: Probably more a hack than a real solution, but I've just used an onclient event on the submit button to manually post the form..)

Re: Things that suck in AngularJS

#57
post #42

Earlier quoted context omitted.

Maybe my understanding is wrong, but closure (and closurescript) are compiled languages. Angular is a UI framework, so comparing them is apples to oranges. And I think the Angular community would be thrilled if it had even close to the kind of documentation that Rails has. You are correct, no one framework will rule them all, but there are examples of OS projects that have good docs (like jQuery and Rails) that can b…

You may be thinking of Clojure and ClojureScript — with a J. It's confusing naming, but those are different, and are not Google products. In this thread, we're talking about Google's Closure (with an S) Library. Google also makes a Closure (with an S) Compiler, but it's more of an optimizer — it "compiles" from JavaScript to optimized JavaScript.

further adding to the confusion, clojurescript targets closure compatible code

Re: Things that suck in AngularJS

#59

Where are the Angular devs? Are they not paying attention? I would expect at least ONE contributor to see this article and take in the feedback, offer advice, make corrections.

This article actual shows that the author doesn't really get the framework, although I suppose he's blaming it on the doc...

Re: Things that suck in AngularJS

#60

Documentation is by far the worst part of Angular. I spent 90% of my time Googling and 10% writing code. (Hey, maybe that's Google's plan -- ramp up traffic to search. Synergy!) AngularUI is confusing, mostly undocumented and often behind Angular. Splitting ngRoute/ngAnimate into their own files is an odd choice, although I assume the former is so they can replace it with the superior ui-router. Which also is weird.…

I don't think Google created Angular, but rather a Google employee. I'd imagine if Google fully backed Angular, the syntax/design would've been much cleaner. Angular with a fresh boot would be something I'd hope for, they just keep adding things on top of it to keep BC as much as possible which is why it feels so dirty at times. I too get (extremely) frustrated with Angular at times for all the points mentioned by OP…

Angular used to be its own startup. The founders were acquhired by Google.
Post reply on HN