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. Like jQuery, it seems like the UI portion is just off on their own doing what they want.
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.
Angular needs someone versed in developer usability to take control of the public facing Angular stuff and give it a complete overhaul. Right now, it's the result of hundreds of people haphazardly making changes.
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 will , and something better than Angular will come by.
> Angular needs someone versed in developer usability to take control of the public facing Angular stuff and give it a complete overhaul. Right now, it's the result of hundreds of people haphazardly making changes.
that's how most open-source projects work. Angular is not a Google library, Google already has closure , which is neat and scales(ie great performance,unlike Angular), Gmail is built on top of it , but strangely nobody else but google is using it...
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.
There are definitely overlapping concerns, but they've dogfooded Angular for both the YouTube TV portal as well as their DoubleClick site, and so I don't think it's just for external purposes.
From my point of view, it's just the next logical step after GWT and Closure. The annotations are baked into the language's syntax, you get the usual JS-like development cycle (save -> F5), and Java/C#-like tooling.
TS is somewhat similar. CS, however, isn't. CS doesn't offer any tooling advantages over JS.
> looks strikingly like Angular at times
Heh. There is also a Dart version of Angular:
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.
All google Saas apps use this lib.
- It requires a running JVM to compile it all down (not a bad thing).
- Can take upwards of a second to compile depending on code base size and compression setting (even if the JVM is warm).
- Kills all ability to debug. Looks like "a.call().call()" etc.
That said, ClojureScript has been fun to work with, but IMO, Google Closure as dependency thwarts a lot of people looking to try it out like they might try CoffeeScript or TypeScript.
Here's an example for the kids at home.
Perhaps they still haven't solved the SEO problem of GWT internally, and so only things that don't need SEO-features like control panels, dashboards (but ironically, the google groups forums too) are in GWT.
I don't think the SEO nature of GWT is fundamentally different from Closure or Angular.
I used GWT for a while and it would be great for enterprise and large teams. The static typing which I usually love/insist on though, does seem pretty cumbersome for something as simple as a web page. I've switched to scala play for the back end and lots of tiny angular 'apps' on the front, and it's so much faster to develop for.
http://www.google.com/fonts <-- loads fast for me. In fact, i think GWT apps can do loading in such an optimized way that hand coding js will only beat it if the programmer is very very careful about it.
(ps, i have no affiliation with google, i just don't like mistunderstood tech to suffer…)
But i m pretty sure GWT was created as a result of the research/code written for closure (which, even tho it was opensourced after GWT, existed before GWT in some form or another).
AngualrJS was a side project of Misko, who was working at Google on the DoubleClick team, until he bet he could rewrite DoubleClick in 1 or 2 (can't remember) weeks using his framework and cut down on the LOC/code complexity. He eventually did and they decided to go full time on the framework. They discussed this at the start of their Google IO presetation.
Notice the "Copyright 2009 - Angular / BRAT Tech. LLC" at the bottom of the page.
IIRC, They had a plan to provide a paid or freemium server-side counterpart. edit: freemium, see the first revision of getangular.com, there's a pricing tab which disappeared later on.
update 2: they were not acquired, they abandoned the startup because it did not get enough traction. The framework lived on, though.
AngularJS was originally developed in 2009 by Miško Hevery and Adam Abrons as the software behind an online JSON storage service, that would have been priced by the megabyte, for easy-to-make applications for the enterprise. This venture was located at the web domain "GetAngular.com", and had a few subscribers, before the two decided to abandon the business idea and release Angular as an open-source library.
Abrons left the project, but Hevery, who works at Google, continues to develop and maintain the library with fellow Google employees Igor Minár and Vojta Jína.
Any thoughts on why the whitewash? Maybe to get better traction as being a 100% google skunkwork?
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 its basic features.
It seems Angular suffers from the same complaints I have about Ember.js. Those of us who really need to just "get things done" might be better suited by a mature, well-documented framework, but does one actually exist?
Frameworks are all the same in that they are great at getting you to about 80% of what you need REALLY fast. The next 10% takes some investigation but its doable.
But that last 10%. Its like pulling teeth. You're working for the framework rather than it working for you. In my experience, all of the time gains you realize from using a framework early on are lost (and then some) trying to get it to do that last 10% that you need.
Now, lest you think I'm a complete framework hater; they have their place. They're great at prototyping, for example. But never again will I build an entire project on one. I have little interest in being a glorified glue stick, piecing framework code together. How boring.
I should add that I make heavy use of libraries like jQuery and Underscore. They're libraries, not frameworks. Take what you need with them yet still reasonably lightweight. Frameworks are bloated, tightly-coupled, poorly documented monstrosities in my opinion.
I do consider some frameworks to be exceptions though. Express is called a framework but it looks more like a library for HTTP handling to me. Most npm packages behave like libraries - maybe that's why I like using Node.js so much. Also CSS "frameworks" like Bootstrap aren't in the same league. They've never caused me the type of frustration I've had with frameworks like RoR or Angular. Bootstrap is actually a library of UI widgets. They can call it a "framework" but I don't consider it to be one.
I'm pretty good, but I'm apparently not good enough, because I find myself consistently learning things from frameworks. I certainly am familiar with the Last Ten Percent you're talking of. But I also know that for every 10% that I have to pull teeth to get, there are many many things that work well because the platform team did a great job and drew on a depth of experience and expertise that I just don't have yet.
DHH built a lot of Ruby apps before he built Rails, and by using Rails I can draw on his experience. As a solo founder that's worth a lot to me. And even now, when I've largely moved on from Rails I still draw on things I learned from studying that framework. And the frameworks I use now are equal distillations of very deep experience.
You're perhaps a more experienced developer than I am, or just better suited to the job.
A much better way to learn is to go write your own framework. Then you're forced to encounter the pitfalls and overcome them through research, trial-and-error, and interacting with the community.
But continuing to use a framework is just a crutch in my opinion. At some point not only are you not learning anything but, as I mentioned before, all you're really doing is gluing framework code/modules together. You're actively doing yourself a disservice and letting your skills atrophy by relying on such a crutch.
One thing about frameworks that I find interesting is; how many were used to develop Unix? None. Because there weren't any back then. And now its in billions of devices worldwide.
I did this myself. It was crap. Fun to write, and I learned a lot from it. But still, monolithic, poorly documented, tightly-coupled crap and even I don't use it anymore.
Everything which was simple about the web up until now, Angular transformed into horrible, black voodoo magic which either just worked or didn't at all.
If that's what "re-envisioned everything" is all about, consider me out.
That's what radical re-envisionings always look like. Anything that fits easily into your toolbelt is an incremental improvement. That's what the word "radical" means.
The promise is that after doing some hard work to learn new data structures you will be more powerful, but it's certainly your right to be skeptical of that.
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.
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.
From what I understand, big Ember projects have turned out well for Ember devs - I can confidently say that I feel the same way about big Angular apps. I have built several big ones, including an online assessment platform (frontend by myself) and an online assessment platform/management system (with a team of ~10, 3 of us on frontend).
From my experience, the Angular team has thought things out on a high level, which I greatly appreciate. They are big consumers of their own product, as Angular is used quite a bit with Google's own sites - here is an example of an Angular app, with Angular being used to implement parallax scrolling (and probably more): http://www.google.com/nexus/7/
It claims to be adding MVC support in the next release.
However, Angular UI is a totally separate set of projects that is not run by the Angular team at all. Not sure why you're giving them a hard time about it.
And this is something I was unaware of until now, a "Contributor License Agreement" is required for a pull-request to be accepted. Sheesh, that's kind of a PITA...
At the last London AngularJS meetup it was mentioned that the team have 'pull request parties' where they try to merge or close as many contributions as they can, but more of them just keep coming ... good problem to have I guess, but they are aware of it and trying to address it.
It's one of those nasty problems, like the influence of money on politics, or gerrymandering, where the people best able to fix it are the ones least likely to think it's a problem.
The current docs have come a long way from their previous state - I recommend people try taking a look at them now. The developer guide & API docs have gotten huge improvements within the past month! I think the only things that are really left is to recommend some best practices with examples and more examples in the API section.
And yea, Angular UI is awesome.
Not to be a cynic but I'd rather not have more Google-controlled software take over yet another part of the internet.
The internet managed just fine without Google before, and I'm sure it will manage fine without Google in the future.
Right now Google dominates almost everything, so whenever I'm given a choice between something made/controlled by Google and anything else, I will go almost instinctively go with the "anything else"-option just to provide some counter-balance.
Google is scary as shit these days and can do pretty much whatever they want without consequences, and I just don't want to be part of making that worse.
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.)
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.
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 through some specific OpenGL calls, he will certainly try to develop an understanding.
(The bad part about video drivers is that the maintainers of proprietary ones are hard to reach. But Valve is doing it, I guess because they have contacts.)
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.
I don't even know where to start. This is quite browser specific.
I strongly urge you to learn and understand the tools you are using. It's what makes all the difference between a good developer and a great developer.
There's nothing wrong with the issue you reported. Nobody is asking you to send patches. (Though that would be nice.) But you've already added a small test case, so that's excellent.
There are always things you can do to get a better understanding. For example, take AngularJS out of the equation. Turns out, you can add options to a select element and everything's fine. Only once you set the select value, does Firefox flip the highlighted item.
I use Django on the server side, the documentation is superb (compared to Angular's). I hardly ever need to dig inside the code, unless I want to do something quite special.
I have a good idea of how the framework works, what pieces fit together where, but I never feel the need to go in and read the code for it.
And what about proprietary software? I am sure there are plenty of frameworks where you can't get to look at the code.
I also do a good amount of work with the Twitter and Facebook APIs, and in my spare time work on a fairly complex Cocoa project. Working with all of these is a whole lot of poking at interfaces until they do what I want. These all have tons of documentation, but they'll never be pleasant for me to work with.
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.
The 30% figure is a wild guess, and may sound a bit large, but I certainly spend a lot of time reading other people's code. Or even rereading my own code.
Docs can be improved, absolutely, but there's no framework where I didn't feel that way about documentation. I don't think I've worked with any framework for more than an hour without looking at its code.
$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.
Bi-directional data binding should never get you into a loop if you take care to only use the APIs in ngModelController. If you managed to trigger a loop, you're probably using the wrong API - loops are something that can happen in bi-directional data binding, but it's not a given.
This is not to say the author is wrong, as said above, I agree with most of his points.
I think Angular's complexity can be daunting without someone who can help set you back on the right path when you're stumped. We (the regular denizens on IRC) do a pretty good job in #angularjs on Freenode helping people out when we can, but it's obviously whenever people can spare the time to answer questions. I am constantly helping people at work grasp how to think the Angular way, and it has resulted in my team being incredibly productive due to Angular's excellent upsides.
Regardless though, I think it's good that this article was written, even if a little prematurely. People should know both the upsides and downsides.
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).
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.
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:
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.
I remember reading this a few months back. Now I get it...
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.
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 translate to anything else.
I'll much rather work with technology that doesn't make me feel magically productive 10% of the time, but does make me actually productive 99% of the time. There are plenty of those around.
And yes. A programming language or framework is/has a user interface.
I do because studying advanced frameworks and working within them is the main way that I learn new patterns.
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..)
I agree the documentation sucks; but beyond that I actually don't have any complaints. I don't have anything to compare it to; but I have written some JS over the years and what angular is doing is blowing my mind.
Because it blows my mind I find it hard to bitch or find fault. I did have to spend several hours stepping through angular core code to figure out WTF was going on with $scope.$watch(); but again, I can't really say that $watch itself sucks; just that I had to read the code to actually understand how to use it.
If I had to pick something other than documentation to point at, I would say that silent shadowing of non-object primitives when "new" scopes are creates for things like ng-repeat and ng-if
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'.
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.
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 to completely understand what's happening under the covers.
I'm definitely looking for alternatives.
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.
Simpler, and fast. I haven't messed with Angular enough to give an honest comparison, but I'm a fan of React's general design - it maintains its own model of the DOM, and user interactions change that model, then it diffs the new DOM back to the browser DOM.
Fwiw this idea seems to slowly be catching on. There are at least two other frameworks that use a similar model - theGuardian.co.uk recently open-sourced their frontend JS framework Ractive, and the Lift web framework impllements a similar model on the server side (been around since 2007, just now the idea seems to be making its way to the frontend).
AngularJS was influenced by Flex and Spry( the creator worked at Adobe ) from the start, and still is.
Worth noting: Sproutcore was used to build iCloud, apparently.
The way to get around the bad documentation for me are sites like http://egghead.io/ and http://thinkster.io/ (and of course, tons of SO-ing).
Maybe I just struggle as I am new to front end development, and to stuck in my server side mindset.
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, but afaik, it's not one of their supported products, but a 10% time product - meaning that the creators / maintainers themselves can't work full-time on it either, and rely on the open source community to help them out.
Go forth and fork.
Ember-data looks much better than anything in Angular. Ember has a bit too much "convention over configuration" to my taste but the project is evolving well; I would not say it is production-ready but is getting close, so keep it under the radar.
They'd hire an intern to fix Closure bugs.
However, there'll be projects/components for which AngularJS (or EmberJS) would be better suited, and we'll surely love to give it a try.
 : http://docs.angularjs.org/guide/overview
Psyche. Good god.
I tried to learn AngularJs but I can't understand it so I gave up and used a simpler and more limited JS library (ractivejs).
watch( watchExpression, listener, [ objectEquality ] )
watchCollection( obj, listener )
There are also a lot of free videos on Youtube, that sometimes explain things more clearly than the docs.
I also find it is going in a very good direction with the recent changes in 1.2.0. They listened to a lot of feedback from the community.
While that used to be true, the directives page recently got updated to provide a much better and simple guide to directives along with plently of code samples -
By this way, we can save a lot of time dealing with DOM and re-use all existing technique too.
Ron Swanson approves this message.