16 ms·

Why does Angular.js rock?

281 points by Foxandxss 13y ago

Why does Angular.js rock? Is the first article on the new angular-tips blog!

gedrap 13y ago
A good summary, although I found a title a bit misleading - expected some sort of comparison 'why it's better than XYZ'
- Foxandxss 13y ago
  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 :)
  - gedrap 13y ago
    I am not saying that it's bad that it's not a comparison, I love it! Thanks for your post!
devasiajoseph 13y ago
This is actually the best and simplest introduction to Angular.js I have ever seen. You rock too!
sahrizv 13y ago
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 :(
- Foxandxss 13y ago
  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 :)
- ams6110 13y ago
  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.
  - mgkimsal 13y ago
    " 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.
  - dgerges 13y ago
    So true. So frustrating.
  - sahrizv 13y ago
    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.
jacques_chester 13y ago
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.
- Foxandxss 13y ago
  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.
  - waterside81 13y ago
    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.
- mgkimsal 13y ago
  "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...
hoverbear 13y ago
Good article, interesting site, terrible choice in background. Every time I scroll it flickers due to the pattern.
- Foxandxss 13y ago
  It came with the theme, I lack design skills but so far is not that bad and I don't have any flickering...
  - mcintyre1994 13y ago
    Fair enough, I get the flickering too. Firefox 22 on Ubuntu 13.04 if it helps at all.
AydinSakar 13y ago
great post!, keep going :)
MattStopa 13y ago
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.
- Alphasite_ 13y ago
  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.
ErikAugust 13y ago
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 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.
- jacques_chester 13y ago
  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 https://news.ycombinator.com/item?id=6140406
caioariede 13y ago
What are the alternatives to Angular.js that does not use this Dependency Injection magic?
- bsaul 13y ago
  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).
  - piranha 13y ago
    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!
    - joelhooks 13y ago
      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.
  - hamburglar 13y ago
    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.
deleted 13y ago
[deleted]
Bahamut 13y ago
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!
_random_ 13y ago
Because you have not heard of Knockout.js?
stevewilhelm 13y ago
> 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.
- Foxandxss 13y ago
  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.
hayksaakian 13y ago
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. Or you could use html5's autofocus http://davidwalsh.name/autofocus http://davidwalsh.name/autofocus and cut the JS ----- Otherwise great article, I'm really leaning hard towards angular now, over ember
- Foxandxss 13y ago
  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.
  - hayksaakian 13y ago
    Is there some way to make a shim with angular, that only applies the directive if autofocus is not supported
mcgwiz 13y ago
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...
at-fates-hands 13y ago
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.
- ricardobeat 13y ago
  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 http://backbonejs.org/#examples
occam65 13y ago
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.
puppetmaster3 13y ago
Angular and possibly other MVC .js are a solution that is looking for a problem. There were benefits to Server Side MVC, but those benefits are gone, but people masturbate still and love it. Thats OK. Advice: Just stick w/ CSS frameworks and jQuery.
avty 13y ago
I love AngularJS
throwa 13y ago
Similar article about why emberjs rocks: https://news.ycombinator.com/item?id=6153917 https://news.ycombinator.com/item?id=6153917 https://kerricklong.com/articles/why-ember-js-rocks.html https://kerricklong.com/articles/why-ember-js-rocks.html
overgard 13y ago
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?
- forkhammer 13y ago
  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.
  - overgard 13y ago
    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.
    - 13y ago

281 points by Foxandxss 13y ago

Why does Angular.js rock? Is the first article on the new angular-tips blog!

gedrap 13y ago

A good summary, although I found a title a bit misleading - expected some sort of comparison 'why it's better than XYZ'

Foxandxss 13y ago
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 :)
- gedrap 13y ago
  I am not saying that it's bad that it's not a comparison, I love it! Thanks for your post!

devasiajoseph 13y ago

This is actually the best and simplest introduction to Angular.js I have ever seen. You rock too!

sahrizv 13y ago

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 :(

Foxandxss 13y ago
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 :)
ams6110 13y ago
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.
- mgkimsal 13y ago
  " 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.
- dgerges 13y ago
  So true. So frustrating.
- sahrizv 13y ago
  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.

jacques_chester 13y ago

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.

Foxandxss 13y ago
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.
- waterside81 13y ago
  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.
mgkimsal 13y ago
"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...

hoverbear 13y ago

Good article, interesting site, terrible choice in background. Every time I scroll it flickers due to the pattern.

Foxandxss 13y ago
It came with the theme, I lack design skills but so far is not that bad and I don't have any flickering...
- mcintyre1994 13y ago
  Fair enough, I get the flickering too. Firefox 22 on Ubuntu 13.04 if it helps at all.

AydinSakar 13y ago

great post!, keep going :)

MattStopa 13y ago

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.

Alphasite_ 13y ago
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.

ErikAugust 13y ago

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

jacques_chester 13y ago
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 https://news.ycombinator.com/item?id=6140406

caioariede 13y ago

What are the alternatives to Angular.js that does not use this Dependency Injection magic?

bsaul 13y ago
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).
- piranha 13y ago
  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!
  - joelhooks 13y ago
    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.
- hamburglar 13y ago
  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.

deleted 13y ago

[deleted]

Bahamut 13y ago

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!

_random_ 13y ago

Because you have not heard of Knockout.js?

stevewilhelm 13y ago

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

Foxandxss 13y ago
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.

hayksaakian 13y ago

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. Or you could use html5's autofocus http://davidwalsh.name/autofocus http://davidwalsh.name/autofocus and cut the JS ----- Otherwise great article, I'm really leaning hard towards angular now, over ember

Foxandxss 13y ago
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.
- hayksaakian 13y ago
  Is there some way to make a shim with angular, that only applies the directive if autofocus is not supported

mcgwiz 13y ago

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

at-fates-hands 13y ago

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.

ricardobeat 13y ago
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 http://backbonejs.org/#examples

occam65 13y ago

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.

puppetmaster3 13y ago

Angular and possibly other MVC .js are a solution that is looking for a problem. There were benefits to Server Side MVC, but those benefits are gone, but people masturbate still and love it. Thats OK. Advice: Just stick w/ CSS frameworks and jQuery.

avty 13y ago

I love AngularJS

throwa 13y ago

Similar article about why emberjs rocks: https://news.ycombinator.com/item?id=6153917 https://news.ycombinator.com/item?id=6153917 https://kerricklong.com/articles/why-ember-js-rocks.html https://kerricklong.com/articles/why-ember-js-rocks.html

overgard 13y ago

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?

forkhammer 13y ago
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.
- overgard 13y ago
  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.
  - 13y ago