Things that suck in AngularJS
51–60 of 151 posts
Re: Things that suck in AngularJS
#52Documentation 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…
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
#53Documentation 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.…
Re: Things that suck in AngularJS
#54One 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
#55I 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…
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
#56Angular, 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…
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
#57Earlier 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.
Re: Things that suck in AngularJS
#58Re: Things that suck in AngularJS
#59Where 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.
Re: Things that suck in AngularJS
#60Documentation 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…