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.
Things that suck in AngularJS
131–140 of 151 posts
Re: Things that suck in AngularJS
#132If you think angular docs are bad , you should try ember. Ember is so frustrating. All answers on SO are out of date or wrong.
Re: Things that suck in AngularJS
#133I 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…
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
#134Earlier 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.
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
#135Shameless 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.
Re: Things that suck in AngularJS
#136So, 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,…
Re: Things that suck in AngularJS
#137Earlier 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…
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
#138Shameless 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
#139If you think angular docs are bad , you should try ember. Ember is so frustrating. All answers on SO are out of date or wrong.
Re: Things that suck in AngularJS
#140Angular, 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…
And yes. A programming language or framework is/has a user interface.