Live data from Hacker News

Things that suck in AngularJS

lhorie.blogspot.ca

131–140 of 151 posts

Re: Things that suck in AngularJS

#131
post #25
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…

ClojureScript uses Closure.

It uses the closure compiler. Not the closure library.

Re: Things that suck in AngularJS

#132

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.

I've found quite the opposite. Ember docs are very clear, constantly being refined and tweaked, and the core devs are actually willing to take input to improve upon them.

Re: Things that suck in AngularJS

#133
post #12

I agree with most of the things mentioned in the article, but here are a couple of nits, just in case you have that exact problem and look for the fix: $timeout having no $cancelTimeout: that's just called $timeout.cancel(), taking the promise you got out of the initial $timeout call. $.when is called $q in AngularJS, support for promises actually runs deep in the framework. Regarding the difficulty of instantiating…

Hi author here. Thanks for the feedback :)

re: instantiating controllers - services definitely help, but you still have to design and expose APIs to manage the lifecycle of variables from the controllers, and often times (at least for me), there are a lot of cross-concerns and it becomes impractical to have services to deal with each permutation of concern groups (this is especially a problem in more exploratory projects). I should note that in the cases where maintainability suffers the most, I have upwards of 5 core model entities and a dozen other auxiliary ones being manipulated in a single page.

Also, when things need to persist across route changes, then you're pretty much stuck to polluting $rootScope (or worse, $cookie)

re: "Bi-directional data binding should never get you into a loop if you take care to only use the APIs in ngModelController"

Yes, they shouldn't, but under some unexplainable circumstances they do, even when I'm explicitly avoiding all the other undocumented traps (e.g. isolated scope interop, etc). One very big weakness in Angular is internal integration testing. Given enough moving parts, even simple things that should just work start breaking in very strange ways (looking at you, ng-if).

Re: Things that suck in AngularJS

#134
post #106

Earlier quoted context omitted.

Sure, but Backbone does a fraction of what Angular does. And, it's pretty consistent with how most people write JS anyway -- whereas Angular pretty much re-envisioned everything.

You say that like it's a pro but I'm pretty sure it's a con.

It depends on your point of view. Personally I've never been too happy about the state of JS code, so trying something different is absolutely a good thing.

Is Angular the best approach? Is there even such a thing as a best approach? Probably not. Look at the proliferation of server side frameworks. They each have their pros and cons.

I do like that Angular is a real framework, rather than a library that only gets called a framework. It handles all sorts of stuff for you in the same way serverside frameworks tend to do.

Re: Things that suck in AngularJS

#135
post #10

Shameless subreddit promotion: I (and the rest of the members) are trying to submit every single worthwhile AngularJS article to http://www.reddit.com/r/angularjs so that it becomes a solid place to keep up with AngularJS tutorials and guides. So far we've almost doubled the subscriber-base in about 3 months so things are finally starting to snowball a bit in terms of participation.

Why Reddit?

Re: Things that suck in AngularJS

#136

So, a lot of people complain about AngularJS's documentation, not just this article or the comments, but everywhere. Does nobody see the bright 'Improve this doc' button at the top right or something? It's an open source project - instead of complain, contribute! The link immediately opens a github pull request for your convenience and you can edit it in github's own editor. Yeah, you could shift the blame to Google,…

Improving docs is a bit of a chicken and egg problem: someone who's having a hard time with the docs is not going to be able to help improve it.

Re: Things that suck in AngularJS

#137
post #95
post #30

Earlier quoted context omitted.

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

So you're learning a lot more than just AngularJS, then, and attributing the problems you run into along the way to AngularJS. Maybe AngularJS is hard to grasp if you're not already familiar with the DOM, compared to other frameworks. I wouldn't know, to be honest. Your video driver example is not a good comparison, in my opinion. You're comparing developers to users. If a developer triggers a bug in a video driver t…

You understand a lot of people using Linux are developers. That comparison is not so bad. Yesterday I was playing counter strike and an error popped. I did a quick search and I could have fix the file in place but instead I just use built-in feature to fix the error. As a developer, I rather have someone to deal with that problem if I had the choice.

Learning Angular.js internal is not interesting to most of us. Sorry. We are users too. We are developers but we don't want to develop angular.js because we don't have time and we don't have the experience dealing with DOM and browser. I know this sounds harsh but in an open source world developers are users too. Documentation is the the emergency call to developers. IRC is not always helpful and most of the time core developers are not available to talk. Imagine someone from India asking help while East Coast is sleeping.

Here: https://github.com/angular/angular.js/issues/3753

I don't even know where to start. This is quite browser specific.

Re: Things that suck in AngularJS

#138
post #135
post #10

Shameless subreddit promotion: I (and the rest of the members) are trying to submit every single worthwhile AngularJS article to http://www.reddit.com/r/angularjs so that it becomes a solid place to keep up with AngularJS tutorials and guides. So far we've almost doubled the subscriber-base in about 3 months so things are finally starting to snowball a bit in terms of participation.

Why Reddit?

I didn't start that subreddit actually, just became a mod a few months ago. Reddit is easy for these types of things because so many coders are already using it to browse other subreddits. I'd prefer it be its own site entirely but this is working well for now so no need to mess with a good thing.

Re: Things that suck in AngularJS

#140
post #121
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 feel like I spend 90% of my time banging my head against a brick wall. Why do people want to work with a technology like that? Personally I feel that the worst part of programming is when you're stuck trying to decipher the inner workings of an intermediate layer. It's so frustrating and futile, and I'm not learning anything generally useful because mastering arcane workarounds for technology layer X doesn't transl…

I agree. What I'm trying to determine is whether or not it's a rabbit hole going down. Am I using a very powerful tool that's user interface is fine, but takes a little bit of time to learn. Or am I using a very powerful tool that has a user interface that's just bad. I'm honestly not sure - I haven't spent enough time with it to tell.

And yes. A programming language or framework is/has a user interface.

Post reply on HN