Why does Angular.js rock?

http://angular-tips.com/blog/2013/08/why-does-angular-dot-js-rock/

by Foxandxss • 13 years ago

281 125 13 years ago

angular-tips.com

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

gedrap2• 13 years ago

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

Foxandxss8• 13 years 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 :)

gedrap2• 13 years ago

I am not saying that it's bad that it's not a comparison, I love it!

Thanks for your post!

devasiajoseph• 13 years ago

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

sahrizv9• 13 years 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 :(

Foxandxss8• 13 years 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 :)

ams61102• 13 years 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.

mgkimsal4• 13 years 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• 13 years ago

So true. So frustrating.

sahrizv9• 13 years 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.

andrewflnr3• 13 years ago

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.

jacques_chester10• 13 years ago

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.

sahrizv9• 13 years ago

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

aerolite• 13 years ago

Choose Backbone.js - the one true choice.

greghinch• 13 years ago

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!

sahrizv9• 13 years ago

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.

delambo• 13 years ago

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/

rrhyne• 13 years ago

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.

sahrizv9• 13 years ago

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

paulwithap3• 13 years ago

Are you sure you want to use Django?

sahrizv9• 13 years ago

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.

visionscaper• 13 years ago

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.

sahrizv9• 13 years ago

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

seilund• 13 years ago

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)

sahrizv9• 13 years ago

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

shadeless• 13 years ago

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?

d0m2• 13 years ago

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

sahrizv9• 13 years ago

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! :-)

jacques_chester10• 13 years 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.

Foxandxss8• 13 years 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• 13 years 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.

mgkimsal4• 13 years 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...

jacques_chester10• 13 years ago

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.

steveklabnik• 13 years ago

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.

ams61102• 13 years ago

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.

patrickaljord• 13 years ago

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

jacques_chester10• 13 years ago

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.

Oculus• 13 years ago

My way of looking at it was always

Documentation the Angular Way:

oinksoft• 13 years ago

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.

at-fates-hands2• 13 years ago

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

pm2• 13 years ago

I wanted to use it, but couldn't use it with Bootstrap (I know), so it was back to CoffeeScript and Backbone for me.

dchuk• 13 years ago

You can use either angular ui or angularstrap to get native angular support for bootstrap

6ren• 13 years ago

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

regularfry2• 13 years ago

That programmer was a pillock.

rdtsc3• 13 years ago

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.

pekk• 13 years ago

Is this not also true of Ember, ... ?

hoverbear• 13 years ago

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

Foxandxss8• 13 years 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• 13 years ago

Fair enough, I get the flickering too. Firefox 22 on Ubuntu 13.04 if it helps at all.

AydinSakar• 13 years ago

great post!, keep going :)

MattStopa• 13 years 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_• 13 years 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• 13 years 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

I'll be adding the barChart directive as well as adding dynamic option setting in the next day or two.

jacques_chester10• 13 years 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

caioariede• 13 years ago

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

bsaul• 13 years 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• 13 years 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!

hamburglar• 13 years 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.

Bahamut• 13 years 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_• 13 years ago

Because you have not heard of Knockout.js?

hayksaakian2• 13 years 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

and cut the JS

-----

Otherwise great article, I'm really leaning hard towards angular now, over ember

Foxandxss8• 13 years 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.

hayksaakian2• 13 years ago

Is there some way to make a shim with angular, that only applies the directive if autofocus is not supported

stevewilhelm• 13 years 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.

Foxandxss8• 13 years 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.

mcgwiz• 13 years 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-hands2• 13 years 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• 13 years 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

occam65• 13 years 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.

avty• 13 years ago

I love AngularJS

throwa• 13 years ago

Similar article about why emberjs rocks:

https://news.ycombinator.com/item?id=6153917

https://kerricklong.com/articles/why-ember-js-rocks.html

overgard3• 13 years 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?

forkhammer2• 13 years 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.

overgard3• 13 years 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.

wnevets2• 13 years ago

the biggest problem angularjs solves for me is boilerplate code and easier testable code.

overgard3• 13 years ago

boilerplate to do what?

Why does Angular.js rock?

Related Stories