Why does Angular.js rock?(angular-tips.com)
angular-tips.com
Why does Angular.js rock?
http://angular-tips.com/blog/2013/08/why-does-angular-dot-js-rock/
Why does Angular.js rock? Is the first article on the new angular-tips blog!
21 comments
Angular is god's gift to programming bloggers. The documentation is so famously patchy, contradictory and impenetrable that an entire cottage industry of talmudic literature has sprung up around it overnight.
I've spent the last two weeks slicing and dicing the developer guide and all the directly related API documentation -- this one-page demo is better than the entire Angular tutorial. It also covers the most important 20% of the Developer Guide.
Based on my current understanding, I'd explain Angular in a different direction. Everyone starts with the binding, introduces a few inbuilt directives, then possibly writes a directive.
I'd start with the $digest() loop, then build out to the runtime loop generally, then explain how link()ing makes the $digest() loop possible via $watch().
There is an enormous amount of Angular that is damn near liable to cause you to scratch your head clear through to your grey matter unless you spend 15 minutes reading the $digest() source code and eyeballing the dev guide in a few places. The docs by themselves simply will not teach you how Angular works, which rather falls short of the purpose of having documentation.
I've spent the last two weeks slicing and dicing the developer guide and all the directly related API documentation -- this one-page demo is better than the entire Angular tutorial. It also covers the most important 20% of the Developer Guide.
Based on my current understanding, I'd explain Angular in a different direction. Everyone starts with the binding, introduces a few inbuilt directives, then possibly writes a directive.
I'd start with the $digest() loop, then build out to the runtime loop generally, then explain how link()ing makes the $digest() loop possible via $watch().
There is an enormous amount of Angular that is damn near liable to cause you to scratch your head clear through to your grey matter unless you spend 15 minutes reading the $digest() source code and eyeballing the dev guide in a few places. The docs by themselves simply will not teach you how Angular works, which rather falls short of the purpose of having documentation.
I totally agree with you. That is one of the reasons I created this blog. I am 24/7 in #angularjs in freenode and I see questions repeated over and over again. My goal is to write about those solutions we give to them so they won't need to ask again.
On the other hand, my goal was to "sell" angular to the readers, not to scary them with $digest issues :)
Said that, I have in my TODO things about this matter.
On the other hand, my goal was to "sell" angular to the readers, not to scary them with $digest issues :)
Said that, I have in my TODO things about this matter.
I'm quite experienced with JS, jQuery etc. but never really "got" what Angular was all about. This is the first time the light bulb went off - so thanks for a great write up.
"The docs by themselves simply will not teach you how Angular works."
Well said, and I agree, but I wonder why this is? There's some cred to be gained by making and using something so impenetrable that only a select handful of people 'just know' how something works, and everyone aspires to be like them?
I've found plenty of people/blogs/sites telling me I'm doing angular 'wrong' (and not just angular - other frameworks/libraries) but precious few people can demonstrate a 'right' way to do things which actually accommodates real world use cases. On top of that, what was canonical at one point is later made obsolete via a single patch/push, but the blogosphere/google never quite catch up.
Less an angular-specific rant, more an observation as to how more projects seem to be heading. As I become one of the 'older' generation, I'm seeing more younger devs (under 25, less than 3 years of professional experience) embracing this code lifestyle, and seem to think it's great, and old fogeys like me just 'can't keep up'. Maybe I can't, but perhaps if you'd document your stuff a bit more, we could just use the library instead of having to read every single line of code, commit, watch for patches, finagle and beg to get pull requests taken and used, and pray that the next point release doesn't break everything. Obviously not all projects are like this, but it seems there's a growing trend among younger projects to work this way. Or maybe I'm just getting old...
Well said, and I agree, but I wonder why this is? There's some cred to be gained by making and using something so impenetrable that only a select handful of people 'just know' how something works, and everyone aspires to be like them?
I've found plenty of people/blogs/sites telling me I'm doing angular 'wrong' (and not just angular - other frameworks/libraries) but precious few people can demonstrate a 'right' way to do things which actually accommodates real world use cases. On top of that, what was canonical at one point is later made obsolete via a single patch/push, but the blogosphere/google never quite catch up.
Less an angular-specific rant, more an observation as to how more projects seem to be heading. As I become one of the 'older' generation, I'm seeing more younger devs (under 25, less than 3 years of professional experience) embracing this code lifestyle, and seem to think it's great, and old fogeys like me just 'can't keep up'. Maybe I can't, but perhaps if you'd document your stuff a bit more, we could just use the library instead of having to read every single line of code, commit, watch for patches, finagle and beg to get pull requests taken and used, and pray that the next point release doesn't break everything. Obviously not all projects are like this, but it seems there's a growing trend among younger projects to work this way. Or maybe I'm just getting old...
They say that great athletes make bad coaches. Why? Because they can't explain what came instinctively.
Similarly, the wrong person to write documentation is the creator of a system. He or she will not know what leaps of understanding are being made throughout the text. That's why big IT companies have historically hired technical writers, which is a profession in its own right.
Those general observations aside, I believe that for some of the Angular team English is a second language.
But otherwise, in the case of the Angular docs, there is a simple lack of attention to detail. Poor fit and finish. It's pretty clear that a lot of the documentation is the first draft.
In the comments you can always find someone complaining and someone else saying "fork it on github". If you actually go and look at github, there are hundreds of unanswered pull requests. So clearly that isn't working either.
Similarly, the wrong person to write documentation is the creator of a system. He or she will not know what leaps of understanding are being made throughout the text. That's why big IT companies have historically hired technical writers, which is a profession in its own right.
Those general observations aside, I believe that for some of the Angular team English is a second language.
But otherwise, in the case of the Angular docs, there is a simple lack of attention to detail. Poor fit and finish. It's pretty clear that a lot of the documentation is the first draft.
In the comments you can always find someone complaining and someone else saying "fork it on github". If you actually go and look at github, there are hundreds of unanswered pull requests. So clearly that isn't working either.
"They say that great athletes make bad coaches. Why? Because they can't explain what came instinctively."
Thank you for finally explaining to me why mathematicians are such famously bad teachers of math. They just start scribbling symbols without explaining what they mean because of course you know what they mean...
Thank you for finally explaining to me why mathematicians are such famously bad teachers of math. They just start scribbling symbols without explaining what they mean because of course you know what they mean...
I first heard it from one of the world's most experienced weightlifting coaches, Lyn Jones. It explained a lot to me too.
The corollary is that people who love something, but can't do it easily, tend to be good coaches. Because they've had to really make an effort and have diligently sought out ways to improve themselves.
Put another way: "those who can't do, teach" isn't an insult to teachers. It's praise.
The corollary is that people who love something, but can't do it easily, tend to be good coaches. Because they've had to really make an effort and have diligently sought out ways to improve themselves.
Put another way: "those who can't do, teach" isn't an insult to teachers. It's praise.
Great quote from George Leonard's Mastery:
"In his book Zen Mind, Beginner’s Mind, Zen master Shunryu Suzuki approaches the question of fast and slow learners in terms of horses. “In our scriptures, it is said that there are four kinds of horses: excellent ones, good ones, poor ones, and bad ones. The best horse will run slow and fast, right and left, at the driver’s will, before it sees the shadow of the whip; the second will run as well as the first one, just before the whip reaches its skin; the third one will run when it feels pain on its body; the fourth will run after the pain penetrates to the marrow of its bones. You can imagine how difficult it is for the fourth one to learn to run.
When we hear this story, almost all of us want to be the best horse. If it is impossible to be the best one, we want to be the second best.” But this is a mistake, Master Suzuki says. When you learn too easily, you’re tempted not to work hard, not to penetrate to the marrow of a practice.
“If you study calligraphy, you will find that those who are not so clever usually become the best calligraphers. Those who are very clever with their hands often encounter great difficulty after they have reached a certain stage. This is also true in art, and in life.” The best horse, according to Suzuki, may be the worst horse. And the worst horse can be the best, for if it perseveres, it will have learned whatever it is practicing all the way to the marrow of its bones."
(Shameless self-plug - I wrote a blog post about this a while ago: http://i.saac.me/post/lurning-cearves/)
"In his book Zen Mind, Beginner’s Mind, Zen master Shunryu Suzuki approaches the question of fast and slow learners in terms of horses. “In our scriptures, it is said that there are four kinds of horses: excellent ones, good ones, poor ones, and bad ones. The best horse will run slow and fast, right and left, at the driver’s will, before it sees the shadow of the whip; the second will run as well as the first one, just before the whip reaches its skin; the third one will run when it feels pain on its body; the fourth will run after the pain penetrates to the marrow of its bones. You can imagine how difficult it is for the fourth one to learn to run.
When we hear this story, almost all of us want to be the best horse. If it is impossible to be the best one, we want to be the second best.” But this is a mistake, Master Suzuki says. When you learn too easily, you’re tempted not to work hard, not to penetrate to the marrow of a practice.
“If you study calligraphy, you will find that those who are not so clever usually become the best calligraphers. Those who are very clever with their hands often encounter great difficulty after they have reached a certain stage. This is also true in art, and in life.” The best horse, according to Suzuki, may be the worst horse. And the worst horse can be the best, for if it perseveres, it will have learned whatever it is practicing all the way to the marrow of its bones."
(Shameless self-plug - I wrote a blog post about this a while ago: http://i.saac.me/post/lurning-cearves/)
That's actually incredibly optimistic... it means if someone has to struggle really really hard to get something, they're quite possibly better to teach it to others. The struggle itself imparts a unique skill that those that get it more "naturally" might not have.
Those who understand how to do should teach.
> Put another way: "those who can't do, teach" isn't an insult to teachers. It's praise.
"But otherwise, in the case of the Angular docs, there is a simple lack of attention to detail. Poor fit and finish. It's pretty clear that a lot of the documentation is the first draft."
Spot on.
"In the comments you can always find someone complaining and someone else saying "fork it on github". If you actually go and look at github, there are hundreds of unanswered pull requests. So clearly that isn't working either."
Agreed.
I would disagree that the person/team writing something isn't fit to document it. Yes, sometimes they're not the best choice, but often they're the only person, and there's no 'choice' at all.
Spot on.
"In the comments you can always find someone complaining and someone else saying "fork it on github". If you actually go and look at github, there are hundreds of unanswered pull requests. So clearly that isn't working either."
Agreed.
I would disagree that the person/team writing something isn't fit to document it. Yes, sometimes they're not the best choice, but often they're the only person, and there's no 'choice' at all.
Let's be precise - at the moment there are exactly 68 open pull requests, _one_ of them being about documentation: https://github.com/angular/angular.js/pulls
There is a huge difference in the open source world between ranting and actually doing something about your pain-points.
There is a huge difference in the open source world between ranting and actually doing something about your pain-points.
One open pull request, but every single page of the documentation is filled with comments from confused people asking for better docs. Fortunately, there's also sometimes a comment giving a proper explanation of that piece of the API.
Sounds like the PHP docs
There were more when I first checked.
Besides, it's hard for me to fix that I couldn't understand the docs when starting from the position of ... not understanding the docs.
Besides, it's hard for me to fix that I couldn't understand the docs when starting from the position of ... not understanding the docs.
1. Yea, I agree.
2. This industry(Comuter Science) is not taught very well.
3. I cringe when I see those 500 page "manuals".
Writing documentation is really hard.
It's also hard to get people to contribute to documentation. I had a conversation with someone recently that was frustrated about the Rails documentation: "Here's my blog post about how to do X. Apparently that's what Rails people do rather than write docs." When I asked why they didn't contribute to the docs rather than make Yet Another Blog Post that feeds into the exact problem they were talking about, it just hadn't actually occurred to them. Getting started contributing to a new project is difficult, posting something to your blog is easy.
Most people don't find writing docs to be fun, and Open Source is largely driven around doing what's fun.
It's hard to see the flaws in something you're close to. The people who are closest to a project forget how hard it is to come in from nothing; I had a conversation recently about Hackety Hack where someone was upset it didn't have the ability to make folders and multi-file projects, and when I tried to explain to them that the beginners (children and adults) that I teach actually struggle with things like file management, they were shocked. We all forget just how much we know, because it's easy to us!
Furthermore, there's an incentive for people to write blog posts over contribute to official docs, since then people will link to their blog, with all the benefit that comes along with.
I am not informed on the state of Angular's documentation, and I think Rails has pretty decent docs these days, but there's lots of reasons why docs are often poor in open source projects.
It's also hard to get people to contribute to documentation. I had a conversation with someone recently that was frustrated about the Rails documentation: "Here's my blog post about how to do X. Apparently that's what Rails people do rather than write docs." When I asked why they didn't contribute to the docs rather than make Yet Another Blog Post that feeds into the exact problem they were talking about, it just hadn't actually occurred to them. Getting started contributing to a new project is difficult, posting something to your blog is easy.
Most people don't find writing docs to be fun, and Open Source is largely driven around doing what's fun.
It's hard to see the flaws in something you're close to. The people who are closest to a project forget how hard it is to come in from nothing; I had a conversation recently about Hackety Hack where someone was upset it didn't have the ability to make folders and multi-file projects, and when I tried to explain to them that the beginners (children and adults) that I teach actually struggle with things like file management, they were shocked. We all forget just how much we know, because it's easy to us!
Furthermore, there's an incentive for people to write blog posts over contribute to official docs, since then people will link to their blog, with all the benefit that comes along with.
I am not informed on the state of Angular's documentation, and I think Rails has pretty decent docs these days, but there's lots of reasons why docs are often poor in open source projects.
> Writing documentation is really hard.
If that is the case then one should wonder about the project itself. If the idea and functionality cannot be easily expressed then one wonders whether that project is worth pursuing.
I stopped being interested in the project. I did look at the source and all the magic going on behind the scenes and didn't like what I saw. It reminds of those large frameworks management would buy for big enterprises and say "just use this, this will be really easy, we'll increase the productivity 100%!".
If that is the case then one should wonder about the project itself. If the idea and functionality cannot be easily expressed then one wonders whether that project is worth pursuing.
I stopped being interested in the project. I did look at the source and all the magic going on behind the scenes and didn't like what I saw. It reminds of those large frameworks management would buy for big enterprises and say "just use this, this will be really easy, we'll increase the productivity 100%!".
I realized something recently about docs-vs-blogs. An important difference between the two is that official documentation of a project is the place to say "this is how it is done", whereas blogs are a place to say "this is how I do it". If there isn't a consensus on how something should be done, but you think the way you do it is nice, it definitely makes sense to write about that in a blog post, but it only possibly makes sense to propose your way for official documentation.
I think it took all those blog posts to generate all the consensus necessary to make the "pretty decent" (I would say "very good") Rails docs possible.
I think it took all those blog posts to generate all the consensus necessary to make the "pretty decent" (I would say "very good") Rails docs possible.
An official blog can be, "This is how it is done, as of the time of posting."
However, then you end up with blog posts like, "here what's new in 3.5", without any documentation for users who never used 3.4 (or 3.3, 3.2...)
However, then you end up with blog posts like, "here what's new in 3.5", without any documentation for users who never used 3.4 (or 3.3, 3.2...)
You made a good point here. That point of view will prove to be useful to me :)
My very first PR to the Emberjs project was an improved entry-level tutorial, just to work people past the pain points I'd experienced getting up and running following the then-current getting started guide (which were neither few, nor far between). The initial response? "This would be better as a blog post."
WOW - that's crazy. Thanks for a recent real world example.
I agree with you.
I don't feel I have the experience to write better angular docs. That could be a goal in a future for sure.
Even when I am going to write about things that could be used to improve the official docs, one of my main goals is to answer via blog the questions I see everyday: "Why this doesn't work?", "My directive is not doing what I need", "My service is not updating"...
I think that the documentation itself needs to be done from various angles, and this is one for me.
I don't feel I have the experience to write better angular docs. That could be a goal in a future for sure.
Even when I am going to write about things that could be used to improve the official docs, one of my main goals is to answer via blog the questions I see everyday: "Why this doesn't work?", "My directive is not doing what I need", "My service is not updating"...
I think that the documentation itself needs to be done from various angles, and this is one for me.
Documentation is hard because those who are documenting assume too much about those who are learning. This concept applies as much to closed source projects as it does to open source projects. It's all a matter of being open to those who are learning, and incorporating what they don't understand.
What these "younger devs" don't realize is that in most cases they are simply reinventing stuff that has existed for years. Even today, the best JS MVC frameworks only just provide the capabilities to build UIs that (for example) were trivial in PowerBuilder 20 years ago.
The fact that it's considered "gee whiz" that you can enter a value into a form field and have that value automatically validated and bound to an attribute in a "model" shows how little we have really advanced.
Web UIs offer a lot in the way of visual styling and easy distribution... but the actual building of apps hasn't really advanced much.
The fact that it's considered "gee whiz" that you can enter a value into a form field and have that value automatically validated and bound to an attribute in a "model" shows how little we have really advanced.
Web UIs offer a lot in the way of visual styling and easy distribution... but the actual building of apps hasn't really advanced much.
I sometimes wonder what the world would look like if somehow it was all hypercards or DCOM or OpenDoc or NeWS or just about anything other than a simple document format painfully hammered into the shape of an applications platform.
It's fun to run the counterfactuals, but ultimately, we go to war with the lousy technology stack we have, not the mediocre one we want. I'm just overjoyed that, thanks to Android and iOS, people are writing native applications again.
There are known IKnowns: there are APIs we know that we know.
There are known IUnknowns: that is to say, there are APIs that we now know we don't know.
But there are also unknown IUnknowns: there are APIs we do not know we don't know.
Just reinventing the wheel to not having to use Powerbuiler makes a lot of sense to me. Even if it takes 20 years. Even if it only covers the trivial features. 5 years ago, I used to work on two huge Powerbuilder projects.
I don't remember having real models or support for them in Powerbuilder and these projects. Everything was just datawindows, embedded SQL and stored procedures.
I'm really glad that I'm now working on a web application at a different company.
What these "younger devs" don't realize is that in most cases they are simply reinventing stuff that has existed for years.
And this is also true for so many aspects of the modern "stack" - remember "time sharing"?
And this is also true for so many aspects of the modern "stack" - remember "time sharing"?
"Those that don't learn from history are bound to repeat it"
This includes both repeating the mistakes and design issues, but also getting excited about the "invention".
This includes both repeating the mistakes and design issues, but also getting excited about the "invention".
I wouldn't say that Angular is reinventing the wheel. Elegant and efficient two-way data binding is a non-trivial problem, and I haven't seen it implemented well (or at all!) in any UI framework that I have worked with in the last 15 years.
Delphi had amazing data binding. You literally dropped two non-visual components on your form; plonked down data-aware components; and then pointed it at any number of databases via ADO, DAO, ODBC or BDE and you were flying.
Unrivalled flexibility and power and you could do knock together a CRUD app in a couple of hours.
Add to that the incredible flexibility afforded by 3rd party components like DevExpress and you had grids and other tabular components that even today any amount of HTML5, JS and CSS and backend programming could only dream of achieving.
And we did this in the 90s.
Unrivalled flexibility and power and you could do knock together a CRUD app in a couple of hours.
Add to that the incredible flexibility afforded by 3rd party components like DevExpress and you had grids and other tabular components that even today any amount of HTML5, JS and CSS and backend programming could only dream of achieving.
And we did this in the 90s.
How was it at near-platform-universality and secure HTTP transmission?
Windows was the near-universal platform and fairly sophisticated networking ability was inbuilt.
You mean getting something else (that's orthogonal) in exchange, justifies a regression to pre-90's in other areas?
Plus it was trivial to make n-tier architectures. Tying it to the web was quite easy too, and there were components out there that made data interchange via HTTP trivial - like SOAP.
It's so true... It's sad we've wasted so much effort putting square pegs in round holes.
They're working on new docs that are much better, see here:
* http://code.angularjs.org/1.1.5/docs/api
There's also a interactive tutorial that's being worked on (it used to be online but not anymore).
See the presentation here:
https://docs.google.com/presentation/d/1WHCcp3G3HxoE7b_ut_ER...
* http://code.angularjs.org/1.1.5/docs/api
There's also a interactive tutorial that's being worked on (it used to be online but not anymore).
See the presentation here:
https://docs.google.com/presentation/d/1WHCcp3G3HxoE7b_ut_ER...
That is good news. However, the dev guide looks identical.
People don't, as a rule, read reference documentation cover to cover and then somehow spontaneously grok the principles of operation.
People don't, as a rule, read reference documentation cover to cover and then somehow spontaneously grok the principles of operation.
My way of looking at it was always
Documentation the Angular Way:
Documentation the Angular Way:
The documentation is not impenetrable, it is just that AngularJS is a library that takes a while to get up to speed on. What is lacking right now is writing on best practices and application design. The O'Reilly book offers some of this, but generally it's just a warm-up with a couple case studies at the end.
http://docs.angularjs.org/guide/concepts is a model of good documentation, and http://docs.angularjs.org/guide/directive is exhaustive. The most difficult parts of the framework are very well-documented, but that some parts of the API have been woefully overlooked.
As you can see in that first link, Angular is an elaborate framework, and there is a lot to stuff in your head at once. This is why newcomers find the learning curve steep: It is a new way to write applications.
http://docs.angularjs.org/guide/concepts is a model of good documentation, and http://docs.angularjs.org/guide/directive is exhaustive. The most difficult parts of the framework are very well-documented, but that some parts of the API have been woefully overlooked.
As you can see in that first link, Angular is an elaborate framework, and there is a lot to stuff in your head at once. This is why newcomers find the learning curve steep: It is a new way to write applications.
>>This is why newcomers find the learning curve steep: It is a new way to write applications.
As someone who's run the gamut of "trendy" JS frameworks, I picked up Angular much faster than Backbone, Ember and Knockout combined. Maybe it's the MVC thing, I don't know, but something just clicked with me with Angular. After watching a few tutorials, I able to build something from scratch without much effort.
As someone who's run the gamut of "trendy" JS frameworks, I picked up Angular much faster than Backbone, Ember and Knockout combined. Maybe it's the MVC thing, I don't know, but something just clicked with me with Angular. After watching a few tutorials, I able to build something from scratch without much effort.
Maybe it's because you picked AngularJS last and spent your learning curve / wtf-moments on the previously mentioned frameworks.
I wanted to use it, but couldn't use it with Bootstrap (I know), so it was back to CoffeeScript and Backbone for me.
You can use either angular ui or angularstrap to get native angular support for bootstrap
This is kind of a dumb question, but do you know of any good solutions that allow the use of Angular with CoffeeScript, Bootstrap, AND a higher-level templating language like HAML?
(I know I'm pretty much combining "hip" programming buzzwords here, but I am curious.)
(I know I'm pretty much combining "hip" programming buzzwords here, but I am curious.)
Angular + Bootstrap = use Angular UI Bootstrap. For
Coffee use on-the-fly transcompilation of your choice (i.e. grunt-contrib-coffee + grunt-contrib-watch). For any of
higher-level templating again use on-the-fly compilation (i.e. grunt-haml + grunt-contrib-watch)
I haven't used it, but I think this might be what you are looking for: https://github.com/tuyen/yeoman-angular-haml
Based on yeoman (http://yeoman.io), which I used briefly for the first time a few days ago, and it seems like a nice system. It already has pretty good integration with the AngularJS seed project.
You could probably roll something together using middleman (http://middlemanapp.com) too, with a bit more legwork.
Based on yeoman (http://yeoman.io), which I used briefly for the first time a few days ago, and it seems like a nice system. It already has pretty good integration with the AngularJS seed project.
You could probably roll something together using middleman (http://middlemanapp.com) too, with a bit more legwork.
A programmer once pointed out to me that my project wasn't "cool" because it was too easy to use. There were no bragging rights; using it didn't impress anyone.
Therefore, to get the aura of cool, make it a bit impenetrable. Then, initial users get to feel valuable by passing on the sacred holies to the next tier of disciples, and so on, this arcane oral tradition enforcing social hierarchies of "competence", in mockery of the technology adoption life-cycle. It's similar in social effect to the initial artificial scarcity of gmail. Bonus: bloggers give you free publicity. Every extra post squeezes out more google juice.
In addition, if you have to work for it, you value it more. And you'll remember it better. And because it remains difficult to use, your hard-won skills retain their value. Worked for git and unix. (Of course, it also has to be useful).
Therefore, to get the aura of cool, make it a bit impenetrable. Then, initial users get to feel valuable by passing on the sacred holies to the next tier of disciples, and so on, this arcane oral tradition enforcing social hierarchies of "competence", in mockery of the technology adoption life-cycle. It's similar in social effect to the initial artificial scarcity of gmail. Bonus: bloggers give you free publicity. Every extra post squeezes out more google juice.
In addition, if you have to work for it, you value it more. And you'll remember it better. And because it remains difficult to use, your hard-won skills retain their value. Worked for git and unix. (Of course, it also has to be useful).
That programmer was a pillock.
My personal view if it is too hard or complicated to write documentation, too hard and complicated to explain how it works, then it is not worth doing.
I tried looking at it and got lost in lots magic $scope, $directives and other arcane constructs.
Yes I would have probably liked to have it described how you suggest, start with how it works.
I tried looking at it and got lost in lots magic $scope, $directives and other arcane constructs.
Yes I would have probably liked to have it described how you suggest, start with how it works.
Is this not also true of Ember, ... ?
I am just starting up web development and have decided to use Django for backend. However, this Angular vs Ember comparisons have lowered my confidence as I think whatever choice "I" make, will turn out wrong in the long run. Can the experienced people here tell me what I should choose?
I am fine with either style of approach to HTML(template vs declarative) and I just want a batteries included framework, which I can use in production, with no severe limitations which may haunt me later.
P.S I am very new to HN and I cant do Ask HN posts :(
P.S I am very new to HN and I cant do Ask HN posts :(
whatever choice "I" make, will turn out wrong in the long run
Get used to that feeling if you want to be a web developer. You are in one of the most "churning" areas of software technology. None of today's popular JS frameworks were around even a few years ago, and in a few years time I expect we'll see an entirely new set of popular frameworks.
Forget about the "long run." Pick something with a decently-sized community of users and support. Learn it well enough to do what you want to do. Expect to throw that away and learn something else next year. The era of actually achieving "mastery" of any development tools is long gone, at least in the world of web front-end development.
Get used to that feeling if you want to be a web developer. You are in one of the most "churning" areas of software technology. None of today's popular JS frameworks were around even a few years ago, and in a few years time I expect we'll see an entirely new set of popular frameworks.
Forget about the "long run." Pick something with a decently-sized community of users and support. Learn it well enough to do what you want to do. Expect to throw that away and learn something else next year. The era of actually achieving "mastery" of any development tools is long gone, at least in the world of web front-end development.
" None of today's popular JS frameworks were around even a few years ago, and in a few years time I expect we'll see an entirely new set of popular frameworks."
You're right, but what needs also to happen is for many others to lose the attitude that others are "doing it wrong" if they don't immediately intuit every nuance of some new library that's 3 months old and was only written for one use case, but touted as the latest hotness which suddenly you're forced to use at work (for example).
I'm fine with understanding the churn and rapid pace - what I don't appreciate is the attitude that just because everything's not 100% obvious to me that somehow it's my fault, when there's little to no docs, no test cases, and a README file that shows a trivial hello world.
You're right, but what needs also to happen is for many others to lose the attitude that others are "doing it wrong" if they don't immediately intuit every nuance of some new library that's 3 months old and was only written for one use case, but touted as the latest hotness which suddenly you're forced to use at work (for example).
I'm fine with understanding the churn and rapid pace - what I don't appreciate is the attitude that just because everything's not 100% obvious to me that somehow it's my fault, when there's little to no docs, no test cases, and a README file that shows a trivial hello world.
By "in the long run" I meant the course of my web app development and enhancement. But I feel happy that there is a consensus on transient utility of these technologies.
Community size is a strong factor for me but (un)fortunately both ember and angular have large communities.
Thanks a lot for your guidance, esp. the last sentence.
So true.
So frustrating.
I would recommend you to take a deeper look at Ember.js.
The article above by Jesus Rodriguez is a good article. It shows how Angular is easy to create _very_ small widgets with. But it doesn't tell you much about how to write a big application.
My experience with Ember (we're creating a very large app with around 100 different routes) is extremely good. More functionality != more bulk. All new features we add to the app fit nicely with the existing code. We never have to go back and refactor large parts of the app. It's the same simple pattern you apply over and over again. I seem to get the opposite impression from Angular apps, where as soon as your app grows more complex you need to take a lot of things in a different direction.
Take a look for yourself at some big and serious companies who are building large open source Ember apps:
Discourse: https://github.com/discourse/discourse/tree/master/app/asset...
Travis CI: https://github.com/travis-ci/travis-web/tree/master/assets/s...
Balanced Payments Dashboard: https://github.com/balanced/balanced-dashboard/tree/master/a...
And check out the new getting started guides: http://emberjs.com/guides/ (especially the screencast by Tom Dale)
The article above by Jesus Rodriguez is a good article. It shows how Angular is easy to create _very_ small widgets with. But it doesn't tell you much about how to write a big application.
My experience with Ember (we're creating a very large app with around 100 different routes) is extremely good. More functionality != more bulk. All new features we add to the app fit nicely with the existing code. We never have to go back and refactor large parts of the app. It's the same simple pattern you apply over and over again. I seem to get the opposite impression from Angular apps, where as soon as your app grows more complex you need to take a lot of things in a different direction.
Take a look for yourself at some big and serious companies who are building large open source Ember apps:
Discourse: https://github.com/discourse/discourse/tree/master/app/asset...
Travis CI: https://github.com/travis-ci/travis-web/tree/master/assets/s...
Balanced Payments Dashboard: https://github.com/balanced/balanced-dashboard/tree/master/a...
And check out the new getting started guides: http://emberjs.com/guides/ (especially the screencast by Tom Dale)
I am actually inclined towards Ember.js since the time I was faced with this choice. I just wanted to take the opinion of all the experienced developers here, to back my choice or change it. Thanks for easing the choice. I'll go through the Ember docs. :-)
Thanks for sharing, it's always useful to hear about real-life usage. One thing I didn't hear much regarding Angular/Ember is testing, can you tell us how you approached it?
I can't speak for OP but if you look through the Balanced Dashboard repo there are some good examples:
If you approach it like that, and I assume this would be the same for Angular, there's very little testing that's specific to the framework you're building on top of.
At Balanced, even when running unit tests on models to test features in isolation we're still not touching anything inside Ember, occasionally we may jump into the internals to short cut getting the app to a particular state but 99.9% of the time you don't need to.
https://github.com/balanced/balanced-dashboard/blob/master/test/integration/guest_user_flow.js
If you approach it like that, and I assume this would be the same for Angular, there's very little testing that's specific to the framework you're building on top of.
At Balanced, even when running unit tests on models to test features in isolation we're still not touching anything inside Ember, occasionally we may jump into the internals to short cut getting the app to a particular state but 99.9% of the time you don't need to.
I'm currently contemplating if I should use AngularJS or Ember.js for my upcoming project. Although I have experience using Ember, I was kind of put off by it because of a) the fundamental changes they made to the routing system in a very late stadium of the platform’s development (AFAIK it was officially introduced in Ember 1.0 prerelease) and b) Ember can be a mind-bender sometimes when you’re working on a large application (having many views and sub-views).
So, I was looking at AngularJS as a potential alternative. At first glance it seems quite straightforward. Until I saw this:
Cage Match – Ember.js vs. AngularJS : http://vimeo.com/68215606
I know that Tome Dale (Ember.js) and Rob Conery (AngularJS) only demo the respective platforms superficially in this video, but it got me leaning towards Ember again.
To comment on your wish to have “a batteries included framework, which I can use in production”: Ember certainly has a lot of batteries included: it’s a framework that makes opinionated choices how you should build a web app.
So, I was looking at AngularJS as a potential alternative. At first glance it seems quite straightforward. Until I saw this:
Cage Match – Ember.js vs. AngularJS : http://vimeo.com/68215606
I know that Tome Dale (Ember.js) and Rob Conery (AngularJS) only demo the respective platforms superficially in this video, but it got me leaning towards Ember again.
To comment on your wish to have “a batteries included framework, which I can use in production”: Ember certainly has a lot of batteries included: it’s a framework that makes opinionated choices how you should build a web app.
-To comment on your wish to have “a batteries included framework, which I can use in production”: Ember certainly has a lot of batteries included
Thanks for considering those factors. Your reply was very helpful.
Don't worry so much about picking the right tools. Just pick something that is popular and start using it. You want something that is popular to start with because a) there will be a large support community and b) there will be more jobs available for someone who knows a popular framework. That second point is most important, because until you start building/working on an in-production project, most of your efforts will be purely academic. Once you have some years of experience under your belt, you can reflect on the technologies you know and figure out where you would like to grow into next.
Ultimately, the goal is to be in a position where you can confidently examine new and old frameworks and techniques, and make confident, informed decisions about what to use. But at the beginning of your career, you won't have the experience and perspective to make those decisions, so just start working on something and don't worry about making sure it's the 100% right thing for all time.
Good luck!
Ultimately, the goal is to be in a position where you can confidently examine new and old frameworks and techniques, and make confident, informed decisions about what to use. But at the beginning of your career, you won't have the experience and perspective to make those decisions, so just start working on something and don't worry about making sure it's the 100% right thing for all time.
Good luck!
Thanks for reminding me of the employment aspect!
For the popularity, I believe both ember and angular have large communities.
I checked the jobs and angular although leading here, is comparable to ember in terms of job opportunities.
If you look at Google trends there is a massive spike in Angular interest:
http://www.google.com/trends/explore#q=angularjs%2C%20emberj...
I'm not saying this should play the biggest part in your descision, but it's worth noting. I implemented 2 small apps in both frameworks, giving me a small fixed amount of time for each. I liked both, Angular gave me less head-scratching and out-of-the-box Twitter Bootstrap integration.
I'm not saying this should play the biggest part in your descision, but it's worth noting. I implemented 2 small apps in both frameworks, giving me a small fixed amount of time for each. I liked both, Angular gave me less head-scratching and out-of-the-box Twitter Bootstrap integration.
Another consideration is the projects that have been built with each framework. That can help you gauge popularity, where the jobs are, where you could get a job (or potentially poach someone from), and the capabilities of each library/framework:
http://backbonejs.org/#examples
http://emberjs.com/ember-users/
http://builtwith.angularjs.org/
http://backbonejs.org/#examples
http://emberjs.com/ember-users/
http://builtwith.angularjs.org/
What kind of "batteries" are you looking to be included? Knockoutjs doesn't automate saving to the server (though it can do everything up to the Ajax call), and IMO it has a pretty intuitive model and near-perfect docs. As a recent convert, I would recommend that you consider it. Unless you've already rejected it for your own reasons, in which case I'm curious what those are.
PS: the tutorial does have a little opaque magic. IMO the biggest need in the docs is some overarching theory. The trick is that applyBindings applies to the whole document by default, but can be restricted to another DOM node.
PS: the tutorial does have a little opaque magic. IMO the biggest need in the docs is some overarching theory. The trick is that applyBindings applies to the whole document by default, but can be restricted to another DOM node.
Knockout only really works if you totally intermix your model code with it. You have to annotate every darn thing until it's impossible to see what the underlying logic was.
Angular's docs suck, but my own code is safely isolated and can be easily developed and tested in isolation.
Angular's docs suck, but my own code is safely isolated and can be easily developed and tested in isolation.
Hm. In my case, I would have had to invent something like ko.observable anyway, so I guess it works for me. Maybe I'll learn better when things get more complicated.
I'm not saying that it's wrong. KO's approach is a defensible architectural alternative. I guess I took an unnecessarily snotty tone in my previous comment.
However, KO's design it didn't sit well with how I wanted things to work. Basically I want plain javascript for my own core logic and then to have round-trip binding to the user interface with a minimum of fuss.
For simple cases, Angular does that reasonably well. More complicated cases require a much more intimate engagement with Angular's design and architecture, which is where my gripe about the docs becomes relevant.
However, KO's design it didn't sit well with how I wanted things to work. Basically I want plain javascript for my own core logic and then to have round-trip binding to the user interface with a minimum of fuss.
For simple cases, Angular does that reasonably well. More complicated cases require a much more intimate engagement with Angular's design and architecture, which is where my gripe about the docs becomes relevant.
No offense taken. I did find that my "model" code was basically the same as the viewmodel. I'm not sure how much that matters or how hard it will be to change, hence "maybe I'll learn better".
I was looking for a framework which can handle as much as possible of the configuration, plumbing and any other processes which are involved in web development. I know that is not exciting and causes limitations, but being a novice in this field, I do not want to be messing around with the basics. I rather want to focus on the core business aspects of my venture. :-)
Django for a backend will work good with any frontend framework (ember.js, angular.js, backbone.js, etc).
I think that none of the actual frontend frameworks will disappoint you. I just showed my opinion in one of them :)
I think that none of the actual frontend frameworks will disappoint you. I just showed my opinion in one of them :)
I'm a django expert and I've built dozen of projects with it. So it would be hypocrite of me to tell you not to learn it. On the other hand, when I first started learning it, it was a young framework not well known (PHP was still hot.. Rails and Django developers were the hipsters of the web on the edge of technology ;-)
I'm pretty happy about my choice to be on the edge as when it got mainstream, I was already very proficient with it. So, in that sense, I think I'd still suggest you to pick a more edgy framework.. say Node with Angular (or ember).
I'm pretty happy about my choice to be on the edge as when it got mainstream, I was already very proficient with it. So, in that sense, I think I'd still suggest you to pick a more edgy framework.. say Node with Angular (or ember).
I understand the point you are making. The only problem with picking up a relatively less mature/complete framework is that I intend to use it in production.
Since I am starting up as a novice, I cannot afford to sacrifice maturity for the high of being on the edge. I realize there's benefit for me in being on the edge as you mentioned( and I would love to play with the newest toy), but in my case, I unfortunately can't do that. Thanks for stopping by! :-)
Btw, node.js / angular is production ready. There are others edgy framework or languages that I wouldn't recommend for the exact reasons you are saying.
Choose Backbone.js - the one true choice.
If I were starting again, I'd start with something like the mean.io. It's a stack that's javascript from database to front end. You'll be starting with the latest and in only one language, which could lower your learning curve a bit.
Mean.io is especially appealing to newcomers like me because it hides significant complexity in linking up stuff on the node.js platform. However, the only thing which puts me off is the instability/novelty of node and consequent unsuitability for production environments.
Django OTOH has been battle hardened, and there is help available if I hit a wall. Not at all to say that the node community is not helpful. It's vibrant and helpful but there are simply too many gotchas yet to be resolved, and more importantly, discovered and I do not want to be the one doing this discovery, midway through my startup. :-)
Are you sure you want to use Django?
Actually I did give a thought to Node.js/express and more pleasantly, the recent one called Mean.io. Mean.io is especially appealing to newcomers like me because it hides significant complexity in linking up stuff on the node.js platform. However, the only thing which puts me off is the instability/novelty of node and consequent unsuitability for production environments.
Django OTOH has been battle hardened, and there is help available if I hit a wall. Not at all to say that the node community is not helpful. It's vibrant and helpful but there are simply too many gotchas yet to be resolved, and more importantly, discovered and I do not want to be the one doing these discoveries, midway through my startup. :-)
Regarding ROR, I'd say I have never even seen the language or the framework. Since I have done previous work in NLP/ML I was inclined to learn python so that I can utilize the huge spectrum of Python based ML/NLP libraries, which I believe Ruby lacks.
Regarding ROR, I'd say I have never even seen the language or the framework. Since I have done previous work in NLP/ML I was inclined to learn python so that I can utilize the huge spectrum of Python based ML/NLP libraries, which I believe Ruby lacks.
As someone who made that choice a while back, I can understand your reasons. I was also familiar with Python from my projects at college and so Django was a natural choice for building a web app. But, I struggled with a lot of basics in Django and then switched to Rails. I can speak with confidence that Rails ecosystem is amazing and the learning curve is easier thanks to the bunch of tutorials and screencasts available.
Though, I hear that the beginner resources in Django have improved a lot lately. If that is the case, it should be an equally good choice.
Though, I hear that the beginner resources in Django have improved a lot lately. If that is the case, it should be an equally good choice.
That was just a little joke that went over a few heads. At least you have one framework choice nailed down.
The issue I've consistently had with a lot of the "frameworks" coming out recently, is the lack of subject matter experts. It's like someone throws this stuff together, makes an attempt to sketch out some documentation and then just lets the developers have at it. Most of the developers who make videos or tutorials simply do a few basic ones, and leave the rest up to the community to figure out after that.
It would be nice if there was a team of developers who actually incubated this stuff so they could write some decent documentation, along with a gamut of examples from simple to highly complex so these frameworks didn't always looked like a half baked rush job on getting it out.
I know our industry moves fast, but I think we'd be better served with a complete set of documentation, with people who've been using these for some time and who can lay out a solid road map for developers interested in utilizing these frameworks.
It would be nice if there was a team of developers who actually incubated this stuff so they could write some decent documentation, along with a gamut of examples from simple to highly complex so these frameworks didn't always looked like a half baked rush job on getting it out.
I know our industry moves fast, but I think we'd be better served with a complete set of documentation, with people who've been using these for some time and who can lay out a solid road map for developers interested in utilizing these frameworks.
That's one of the reasons I prefer Backbone. It was born out of a business project, still maintained by it's creator, and usage examples and production apps abound: http://backbonejs.org/#examples
Certainly amusing demo.
What might actually have a chance at winning me over (having deep real-world experience with and trust of other tools) is an account of more complex usage:
- deep look at componetization/composition techniques,
- how it plays with CommonJS/AMD/Harmony,
- honest accounting of drawbacks, pain points, non-ideal usage scenarios,
- explanation of all the magic, e.g. what's happening under the covers to do data-binding, does the global namespace get polluted by DI features, etc...
What might actually have a chance at winning me over (having deep real-world experience with and trust of other tools) is an account of more complex usage:
- deep look at componetization/composition techniques,
- how it plays with CommonJS/AMD/Harmony,
- honest accounting of drawbacks, pain points, non-ideal usage scenarios,
- explanation of all the magic, e.g. what's happening under the covers to do data-binding, does the global namespace get polluted by DI features, etc...
I spent most of the last 4 months doing all my front end work in Angular. The biggest problem I for me is that A) there are a lot of nooks an crannys and B) the views end up being pretty ugly.
I've been doing more with Ember recently, and while some things are not as easy, some other important things are much easier. On top of that the views are easy to read. So at least for now I feel like Ember is better for me.
I've been doing more with Ember recently, and while some things are not as easy, some other important things are much easier. On top of that the views are easy to read. So at least for now I feel like Ember is better for me.
i've found i prefer angular + ui-router to plain old angular routing, it makes the views much easier to handle. That said, i could never put enough time into ember to really understand it.
It works great but what if we want the input to have the focus when the page loads? jQuery right? We grab the input and we call the focus() method in it. NO.
With directives we want our HTML to be as self-descriptive as possible so we are going to create a focus directive.
http://davidwalsh.name/autofocus
and cut the JS
-----
Otherwise great article, I'm really leaning hard towards angular now, over ember
True, but the directive will reach to those places where html5 is not a welcome guest.
But to be sincere, I picked one thing to a directive, there are infinite ideas but I needed one easily enough for a "hello-world" type of post.
But to be sincere, I picked one thing to a directive, there are infinite ideas but I needed one easily enough for a "hello-world" type of post.
Is there some way to make a shim with angular, that only applies the directive if autofocus is not supported
Once, just once - I want to read an article like this and in the conclusion read "It doesn't rock. This framework just really sucks."
Anyway, I've been using Angular for a couple of weeks now, and happen to really enjoy it.
Anyway, I've been using Angular for a couple of weeks now, and happen to really enjoy it.
So those are some neat features but I guess my overall question with all these client side frameworks is: what problem are they solving? I see like these lists of interesting features but I don't see a coherent message behind "why I need this".
Usually I go seeking out a library when it does something that I really don't want to have to do on my own, so what's the thing this is preventing me from having to do?
Usually I go seeking out a library when it does something that I really don't want to have to do on my own, so what's the thing this is preventing me from having to do?
Here's the brief answer, as I understand it: they're frameworks that provide model-view data binding, ease data/presentational decoupling, and (in some cases) provide single-page app (SPA) infrastructure in the mode of MV*. In short, they're designed to tackle some of the common complexities that arise when writing feature-rich multi-part SPAs.
You can do it all on your own, for sure, and I actually think that writing a complex front-end-heavy application without anything but jQuery is a really great way to show yourself the potential use of these libraries. It's not really super hard to write decent, well-structured and segregated code... but it does begin to feel, after a while, like you're spending your time hooking up wires you've hooked up before.
At that point, you either write your own abstraction, or you go looking for an abstraction that someone else (preferably smarter than you) will maintain.
You can do it all on your own, for sure, and I actually think that writing a complex front-end-heavy application without anything but jQuery is a really great way to show yourself the potential use of these libraries. It's not really super hard to write decent, well-structured and segregated code... but it does begin to feel, after a while, like you're spending your time hooking up wires you've hooked up before.
At that point, you either write your own abstraction, or you go looking for an abstraction that someone else (preferably smarter than you) will maintain.
That's just more buzzwords though. I mean, why do I even need model view data binding? I'm not saying it's not nice to have, but I've written some pretty complicated applications and I never really found data binding to be some sort of killer feature. It's generally struck me as a great demo feature that in reality I'll pretty much never use.
I guess I'd find these things more convincing if they showed me some sort of problem they're solving by showing how awful it would be without what they're doing -- because without seeing the actual problem they're solving, it kinda strikes me as the work of architecture astronauts. It all sounds great on paper, but when I go to use it I can't imagine even needing most of the features this article describes.
I guess I'd find these things more convincing if they showed me some sort of problem they're solving by showing how awful it would be without what they're doing -- because without seeing the actual problem they're solving, it kinda strikes me as the work of architecture astronauts. It all sounds great on paper, but when I go to use it I can't imagine even needing most of the features this article describes.
Well, they are buzzwords, yeah, but it's important to note that buzzwords become so because of their popularity and prevalence.
Why do you need model-view data binding? Emulating the responsiveness of desktop apps, for one, or having live-update capability. I wrote an app recently that let you add line items to an object, and the client wanted the cumulative fiscal information to auto-update without reload. I'd agree that the standard 'Hello, <your input content here>' example is overly contrived, but what about a field that calculates and updates tax owing as you type? That's not hard to write with just javascript, but when you do that about fifty different times in an application, having a convenient data binding mechanism is really convenient.
The other utility that I find quite convenient is DRYing up insertion logic--I hate that I often have duplication between server-side templates for existing objects, and some sort of client-side template for dynamically inserting new objects. Rendering it all client-side makes my life a lot easier when I want to add or change the surrounding template, and having the ability to do the initial render with a minimum amount of boilerplate is phenomenally helpful.
Those are two very real, very frustrating problems with which I feel any one of these frameworks helps a lot. I'm happy to go into greater depth if you'd find that helpful or revelatory.
Why do you need model-view data binding? Emulating the responsiveness of desktop apps, for one, or having live-update capability. I wrote an app recently that let you add line items to an object, and the client wanted the cumulative fiscal information to auto-update without reload. I'd agree that the standard 'Hello, <your input content here>' example is overly contrived, but what about a field that calculates and updates tax owing as you type? That's not hard to write with just javascript, but when you do that about fifty different times in an application, having a convenient data binding mechanism is really convenient.
The other utility that I find quite convenient is DRYing up insertion logic--I hate that I often have duplication between server-side templates for existing objects, and some sort of client-side template for dynamically inserting new objects. Rendering it all client-side makes my life a lot easier when I want to add or change the surrounding template, and having the ability to do the initial render with a minimum amount of boilerplate is phenomenally helpful.
Those are two very real, very frustrating problems with which I feel any one of these frameworks helps a lot. I'm happy to go into greater depth if you'd find that helpful or revelatory.
It's like Rails vs. a custom web app. If you asked me to maintain an existing Rails app, I would feel pretty comfortable just knowing that it's Rails. If you asked me to maintain your web app that you build from scratch that doesn't necessary follow standard patterns like MVC, I'd have a much harder time.
> Angular has a lot of built-in services, managing $http requests, $q for promises, etc. But in this part we are not going to talk about any built-in service, because they are more complex to explain and that belongs to a new article.
Statements like this worry me. Authenticated requests to REST API's should be drop dead simple in any JS framework.
Statements like this worry me. Authenticated requests to REST API's should be drop dead simple in any JS framework.
Well, not that complex, I just tried to show the minimum things possible. My first idea for a service was a twitter search but that implies an explanation of $http and things related with it. Auth request are not that bad, it is certainly not as simple as we want (but that happen in every client side framework) but not bad. I want to cover auth in a future article.
What are the alternatives to Angular.js that does not use this Dependency Injection magic?
Dependency Injection can really be done in a dark magic way (the java / spring way), but after reading the source code, i can tell you angular.js way of doing it is really not that dark. More importantly, is extremely easy to use. No .xml file, no configuration file, just put the service in that function signature, done (unless you want to minifiy, which means you'll also have to add it as a string right next to it).
Well, in my option DI is one of the worst parts of Angular. It's a module system which can't be integrated with anything. Doing something like commonjs/amd would be much nicer:
app.controller('Name', function(require) { var $scope = require('$scope'); var y = require('some-service'); });
And suddenly, no problems and no weird syntax!
app.controller('Name', function(require) { var $scope = require('$scope'); var y = require('some-service'); });
And suddenly, no problems and no weird syntax!
Require is a service locator, so you are getting some of the inversion of control benefits, but I greatly prefer the injections of the dependencies I need instead of relying on a locator.
In practice the DI approach is very nice, and works consistently. It also makes unit tests more straight forward.
In practice the DI approach is very nice, and works consistently. It also makes unit tests more straight forward.
As far as I can tell, the DI is "magic" in most of the examples in that it's using your controller function's parameter names to decide which services to pass in. The Angular docs I've read seem to indicate that this is not actually the recommended way to do it, but rather you should use the controller.$inject array to indicate which services you want. The annoying part to me is that this other, more magical behavior is used in just about every example I've encountered and IT IS NEVER EXPLAINED ANYWHERE. I was glancing through the code and I saw reference to gleaning the dependencies automatically by calling .toString() on the controller function and then parsing the arg list, which is ick ick ick. Who in the hell expects their arbitrarily-named anon function args to actually have meaning outside their own scope? This is a total misfeature, IMO.
I like this article - there is a huge need for content on how to do things in Angular.
I personally love Angular quite a lot, and often help people in #angularjs on Freenode - stop by if you ever have a question, a lot of us are helpful!
I personally love Angular quite a lot, and often help people in #angularjs on Freenode - stop by if you ever have a question, a lot of us are helpful!
Good breakdown of some of the useful built-in directives as well as an easy-to-understand guide to creating a directive.
Top commenter is definitely right that Angular's own docs create a cottage industry for bloggers and others willing to bang their heads against stuff until they figure it out.
Just started an Angular directive that allows for reusable Flot charts: https://github.com/ErikAugust/flang
I'll be adding the barChart directive as well as adding dynamic option setting in the next day or two.
Top commenter is definitely right that Angular's own docs create a cottage industry for bloggers and others willing to bang their heads against stuff until they figure it out.
Just started an Angular directive that allows for reusable Flot charts: https://github.com/ErikAugust/flang
I'll be adding the barChart directive as well as adding dynamic option setting in the next day or two.
There's something about those docs that seem to inspire blunt skull trauma analogies. Me the other day, for example: https://news.ycombinator.com/item?id=6140406
[deleted]
Good article, interesting site, terrible choice in background. Every time I scroll it flickers due to the pattern.
It came with the theme, I lack design skills but so far is not that bad and I don't have any flickering...
Fair enough, I get the flickering too. Firefox 22 on Ubuntu 13.04 if it helps at all.
Similar article about why emberjs rocks:
https://news.ycombinator.com/item?id=6153917
https://kerricklong.com/articles/why-ember-js-rocks.html
https://news.ycombinator.com/item?id=6153917
https://kerricklong.com/articles/why-ember-js-rocks.html
This is actually the best and simplest introduction to Angular.js I have ever seen. You rock too!
A good summary, although I found a title a bit misleading - expected some sort of comparison 'why it's better than XYZ'
Hello, I am the author of the post.
I think that there is a lot of comparison out there to create yet another one.
On the other hand, I don't have a deep knowledge of the competence to compare and I don't want to shot myself in the first post :P.
About the title, something can "rock" by its own.
Thank you for the comment :)
I think that there is a lot of comparison out there to create yet another one.
On the other hand, I don't have a deep knowledge of the competence to compare and I don't want to shot myself in the first post :P.
About the title, something can "rock" by its own.
Thank you for the comment :)
I am not saying that it's bad that it's not a comparison, I love it!
Thanks for your post!
Thanks for your post!
great post!, keep going :)
I love AngularJS
Because you have not heard of Knockout.js?