Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things that suck in AngularJS

lhorie.blogspot.ca

Post reply on HN
Print view View original

21–30 of 151 posts

Re: Things that suck in AngularJS

#21

Post by paultannenbaum »

camus2 wrote: post #15
gkoberger wrote: post #4

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…

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 be used as comparisons when evaluating a framework.

Re: Things that suck in AngularJS

#22

Post by gbadman »

This is a good set of arguments explaining some challenging corners of AngularJS.

It is true that when you start getting into the realm of edge cases, substantial knowledge of the framework's internals is required to put together a solution that is consistent with the 'zen of Angular'.

The author argues that some of the challenges introduced by Angular's $apply lifecycle and its approach to two-way bindings make it a challenge to use in certain circumstances. I would rephrase that and say that Angular's state-tracking and two-way binding solution is a very elegant hack to a very complex problem, considering limitations imposed by javascript, css and html. Angular proposes a set of integrated solutions that allow developers to avoid a substantial amount of boilerplate (and complex boilerplate, at that) for synchronizing state and the view. As with every other framework, it is not appropriate for every problem.

That being said, I continue to use and love Angular in a complex app with quite a few moving parts. I migrated from Backbone.js about a year ago and never looked back.

/x-post from Reddit: http://www.reddit.com/r/javascript/comments/1pdzbz/things_th...

Re: Things that suck in AngularJS

#23

Post by camus2 »

general_failure wrote: post #14

If you think angular docs are bad , you should try ember. Ember is so frustrating. All answers on SO are out of date or wrong.

Ember creators cleary did not know where they were heading when they began writing it.

AngularJS was influenced by Flex and Spry( the creator worked at Adobe ) from the start, and still is.

Re: Things that suck in AngularJS

#24

Post by erikpukinskis »

famo wrote: post #18
psychometry wrote: post #5

Earlier quoted context omitted.

Is there a Javascript MVC framework that actually has good documentation, guides, and code samples? I've been working with Ember.js, but it's incredibly frustrating trying to learn a framework whose documentation is incomplete. The other problem I've found is that docs, tutorials, and Stack Overflow posts that are even six months old are often completely useless when troubleshooting bugs in Ember.js or even learning…

I started with Ember about a year ago and the getting started docs were pretty terrible. It took a lot of experimentation and frustration before I was comfortable developing with it. Eventually I became familiar with the framework and the API docs are quite in-depth, not really great for a beginner though. After about four Ember projects I can now prototype a large app (using something like Bootstrap) in a day or so,…

My experience pretty much parallels yours. These frameworks are at the cutting edge. Only a handful of big apps have been made with Ember or Angular, and so the core teams are constantly bumping up against weaknesses in their designs which can only be addressed by making changes that break apps.

From reading the Ember discussion lists I get the strong sense that the core team is willing to make difficult breaks, but that they really try to only do it when it's absolutely necessary for the long-term robustness of the platform. A lot of thought seems to go into which problems are getting solved now, which are put off til later, and which interfaces get torn out and rewritten.

I just spent several weeks upgrading my app from the earlier Ember RCs to Ember 1.0 and the latest Ember-data, and while quite painful, I feel good about it because I don't think the core team made those changes lightly. My sense is they are looking out for us.

Re: Things that suck in AngularJS

#25

Post by pron »

camus2 wrote: post #15
gkoberger wrote: post #4

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…

ClojureScript uses Closure.

Re: Things that suck in AngularJS

#26

Post by camus2 »

paultannenbaum wrote: post #21
camus2 wrote: post #15

Earlier quoted context omitted.

> 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…

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…

I'm talking about the closure library, it's a javascript library written by google :

https://developers.google.com/closure/library/

All google Saas apps use this lib.

Re: Things that suck in AngularJS

#27

Post by kosinus »

gkoberger wrote: post #4

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.…

If you're really spending 90% on Google, and 10% writing code, then you're doing it wrong.

At least a good 30% of your time should involve reading code. In any framework.

That said, AngularJS' code is magic in places. The magic is contained within small modules, or at least as small as those can get for what they're supposed to do.

But documentation is only enough to get you started. In any framework.

(And in my experience, proprietary frameworks and APIs always involve lots of email back and forth.)

Re: Things that suck in AngularJS

#28

Post by louthy »

> I consider myself to be a reasonably good js developer, but the internals of AngularJS are overwhelmingly non-approachable.

Same here. I'm just getting up to speed with Angular. I spent the past weekend developing a web-app to manage our internal test-process. I like it a lot, I managed to create an incredibly complex and interactive web-app in two days.

Well, I say I like it a lot, I like the idea a lot: data driven mark-up, separation of concerns, etc.

However when it goes wrong it's incredibly difficult to step through the Angular code to work out what on earth is the cause of the issue.

It took me several hours of poking around trying to get this tree-view directive to work:

http://ngmodules.org/modules/angular.treeview

First to try and work out why the directive wasn't being initialised, then why the parameters were coming through with different names of the properties compared to what the original source expected (ngTreeModel rather than treeModel for example). Then, why on the inner elements of the tree the properties coming through were named as expected!

So exasperated I head over to the documentation for directives, and, yeah, horrible... incredibly dry and terse.

I never quite got to the bottom of the issue, and have deferred working it out until I know Angular a bit more (var treeId = attrs.ngTreeId || attrs.treeId).

But I can't deny that this thing is incredibly powerful, so I think it's worth persevering with. But yeah, some better docs and up-to-date examples would be very, very welcome.

EDIT:

I remember reading this a few months back. Now I get it...

http://www.bennadel.com/blog/2439-My-Experience-With-Angular...

Re: Things that suck in AngularJS

#29

Post by gkoberger »

kosinus wrote: post #27
gkoberger wrote: post #4

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.…

If you're really spending 90% on Google, and 10% writing code, then you're doing it wrong. At least a good 30% of your time should involve reading code. In any framework. That said, AngularJS' code is magic in places. The magic is contained within small modules, or at least as small as those can get for what they're supposed to do. But documentation is only enough to get you started. In any framework. (And in my expe…

I was of course generalizing -- by "Googling", I meant everything from reading StackOverflow to browsing GitHub to looking at the docs.

That being said, I'm not quite sure where that 30% figure comes from. Whose code am I reading? Why am I reading it?

Angular isn't your run-of-the-mill framework. They've reimagined almost everything. That's fine (and for the most part, I like what they've done) -- but documentation is incredibly important.

Re: Things that suck in AngularJS

#30

Post by yeukhon »

kosinus wrote: post #27
gkoberger wrote: post #4

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.…

If you're really spending 90% on Google, and 10% writing code, then you're doing it wrong. At least a good 30% of your time should involve reading code. In any framework. That said, AngularJS' code is magic in places. The magic is contained within small modules, or at least as small as those can get for what they're supposed to do. But documentation is only enough to get you started. In any framework. (And in my expe…

> At least a good 30% of your time should involve reading code. In any framework.

Understand that not every developer has a good knowledge of these frameworks. Understanding the DOM, browser-specific JS stuff are not piece of cake. Hence documentation is super crucial to have.

This is like asking every developers to read Linux kernel video driver when their video driver crashed.

Post reply on HN