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. 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.
> 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 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[1] , 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...
The problem with Closure is that it really sucks for small projects. It was built for large products with hundreds of developers and millions of users; many of the library features (eg. static typing; dependency management; compilation; CSS renaming; namespacing & scoping; full component libraries) are absolutely invaluable for that use case, but don't get you much when you're just prototyping a few ideas. I don't think Google's webapps could run on any framework but Closure, but when I and many of my coworkers want to do a quick prototype, we reach for JQuery or Angular. Or even just native DOM APIs.
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.
We started our project from the get go in closure because this overhead can be automated.
The benefits outweigh the pitfalls IMO, and a week spent on process will pay huge dividends down the line.
I think Angular is just the latest in their web dev portofolio, driven by internal needs. They have Closure, which is basically their own jQuery + package/module/dependency loader & framework. Then there's Dart, which is kind of their version of CoffeeScript/TypeScript/etc. (and even looks strikingly like Angular at times[1]).
There are definitely overlapping concerns, but they've dogfooded Angular for both the YouTube TV[1] portal as well as their DoubleClick site, and so I don't think it's just for external purposes.
> Then there's Dart, which is kind of their version of CoffeeScript/TypeScript/etc.
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.
We've been running a client side SaaS on the Closure library/tools/compiler for a couple years now. You are right that it is not widely used outside Google (and certainly not as popular as Angular) but it is well-tested and there are some people out there using it for production work.
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.
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.
I would prefer to clear the confusion by calling Closure templates "soy templates", and differentiate it from the Closure compiler (for compiling javascript).
- 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.
http://cljsfiddle.net/ goes a long way towards having a tool people can just play with to try out ClojureScript without being twarted by setting up Clojure/JVM/Lein/Lein-cljsbuild/
Maybe I'm a bit of a masochist, but it's not that hard to read the compiled output, especially when you have a decent mental model of what it should be. It doesn't look like idiomatic javascript, but the structure is pretty regular.
Nope, you're thinking of GWT. Relatively few Google products actually use GWT; the bulk of them are on Closure. GMail's client (and Google+, and Docs, and Search) all use Javascript-compiled-to-Javascript for the client side.
I've always wondered why GWT isn't much more popular (at least, for google properties). I know of a half dozen apps written in GWT by google. The rest is probably in closure (or something else).
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.
GWT on AppEngine (which it has great integration for) has a ten second startup time when not loaded, and on the free tier they unload it when not in use, so that's not the greatest.
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.
a lot of people who i've spoken to have the same impression of GWT (that it's slow, and not "webby"). I suspect it's because it has the same UI library model as java Swing, and that has the reputation of being slow (thru no fault of java to be honest - its usually the programmers who made it slow, when it could've been fast).
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).
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. Honestly sometimes I don't even know why I bother with it, I feel it being counter-productive if I actually think about it. It just seemed cool concept at the time but over the long run, I feel I am just digging my own grave. Great post for venting about the frustrations, I been needing to vent myself too.
I can totally relate to "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 "
Where'd you get the wrong idea that it was a Startup?
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[2], 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.
Development history
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.[3]
I stand corrected, my apologies. I simply assumed that it was Misko's side project (by assuming, I mean made an ass of myself). I'm going to pay more attention next time they talk about its history to see if they actively attempt to not bring that part of its history up. Agree with novaleaf, it's super weird they never mentioned it.
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 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?
> 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?
No.
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.
Ultimately I've found that using vanilla Javascript offers everything I need to just "get things done" and complete a project successfully. Sure, I might not be able to get something out the door in a day. But at the end of the project I've delivered clean, maintainable code on time. And anyone who knows Javascript will be able to read it.
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.
Finally someone said it. Even if I write more code by only using libraries and no frameworks (which is debatable), at least I'm happy while writing it.
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 think it depends on how good you are. If you're a great developer, with deep knowledge of patterns, a strong commitment to refactoring, with lots of experience such that you're aware of the pitfalls you are likely to befall, then you're probably right: frameworks will buy you little.
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.
You touch on one of the other benefits of a framework; they're a fairly decent way to learn. But, unfortunately, much of that is because you're learning what NOT to do.
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.
I felt like Backbone.js (when I was actively using it) had really clean and complete docs. Couple that with the fact that the source is incredibly readable and debugging anything strange was never that tough.
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.
whereas Angular pretty much re-envisioned everything.
Angular is the first time I've written a web-app and been completely lost from second one without a fully stateful JavaScript debugger willing to break at any point and letting me inspect the call-stack, parameters and locals.
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.
To each their own, I guess. I've rewritten numerous apps in a fraction of the original time (and original line count) using Angular. There's a bit of a learning curve, but once I started "thinking Angular" (aka, if you're touching the DOM you're doing it wrong), it was great.
> Everything which was simple transformed into horrible, black voodoo magic
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.
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.
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, so I feel that pain at the start was worth it. Back at the time though I was tearing my hair out, especially over router changes. The changes improved things by an order of magnitude though. I trust the Ember team, I'm happy now, the start could have been easier.
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.
I'm currently working on a big Angular app that is about to move into production (although it's not to be something that's widely used in public) - we have found that Angular causes everything to be structured in a nicely organized fashion overall. This app is not structured perfectly by any means either, due to bad design on some of our pre-existing code base.
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/
I agree that the documentation could be better. When I first started working with Angular I had similar issues. However, after spending a decent amount of time working with the framework, I find the documentation fairly clear. The problem is really the lack of concrete examples of how things fit together.
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.
The irony is that not only is there a commenting system to complain about the docs, but that at the top of most of the pages is a prominent "Improve this doc" button, which when clicked, takes you directly to the file in Github. Some of the docs are .md (markdown) while the rest are the actual code files. I don't know how often they accept pull requests, much less for doc-only changes, but they have almost 150 PR's in queue.
And this is something I was unaware of until now, a "Contributor License Agreement"[1] is required for a pull-request to be accepted. Sheesh, that's kind of a PITA...
It was a while ago when I last did it, but the team are perfectly happy to merge-in docs corrections and improvements. IIRC, the CLA is not necessary for docs either, only for actual code.
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.
In my case it's because I don't understand it well enough to write doc. The people who _do_ understand it well have managed to do so despite the state of the documentation, so maybe they think the doc is sufficient?
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.
A lot of us have invested a lot of time learning Angular, pains and all :) . I've contributed to the docs, as well as source. I've also reported issues, big and small.
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.
The barrier of having to contribute via GitHub is actually a fairly large one. Think about it; not even all developers understand git. The design challenge of creating a simple way to contribute/improve documentation (read: educational materials) is something we're working at Coursefork [1]. It's a tough one to solve, but we think we've cracked it.
I think the documentation has improved. I think the Developer Guide provides a good high level. Perhaps some opinionated best practises & design patterns would help.
Google has the chance to build the new framework that will run the web in 2-3 years.
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.
AngularUI is indeed very much 'off on their own doing what they want', they are not a part of the core team AFAIK. Even inside the AngularUI team, quality, convention and style can be dramatically different across different modules ( cough ng-grid ).
Personally, I skipped the docs and went straight to the API guide. Reading that had me only Googling for edge cases, such as scope changes within ng-repeat.
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.)
> 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 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.)
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.
You misunderstand. I don't expect a Linux user to understand video driver internals. But I do expect a developer using OpenGL to have some grasp of the situation once he runs into a problem.
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.
Between frameworks like Ruby on Rails, Node.js, AngularJS and smaller libraries like Backbone.js, jQuery, and jQuery UI, I've relied more on code for all of them. Documentation has only ever helped me to get started, and as a quick reference. But do anything significant, and thorough understanding is simply a must; something I can only find in 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.
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.
AngularJS code. I regularly dive in whenever I run into an obstacle.
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.
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.