It's always a little bit harder to learn an existing framework than to just write your own stuff from scratch to suit your project. But the former is pretty much guaranteed to be more productive than the latter.
I am not a smart man. While I have had my struggles with some aspects of Angular, there is no way I could be delivering projects of the complexity I'm working on now without it.
I suspect it's only difficult to people who don't make sophisticated things.
jQuery is fine for regular websites and the like, but inadequate for large scale client apps. That's what Angular is for. There is not much benefit using angular to build your marketing site.
If you don't understand this, you understand neither Angular, nor jQuery.
He isn't comparing the features of Angular to the features of jquery at all, he is just comparing it to a framework that has stood the test of time due to it's simplicity. He doesn't explicitly say it but I am sure when he talks about 'easier' ways to do what you can do with Angular, I believe he means other similar frameworks e.g. Ember, Backbone etc.
The moment you databind, you can't use nearly as many other libraries as easily or safely. This means you want as fully-featured a databinding library so you don't need other stuff.
There's tons of articles about providing Angularjs updating support when you use jQuery..it's (or used to be) just painful.
A tool doesn't fail because it's difficult, it fails if its difficulty is not worth the results it produces. A chainsaw is more difficult than a plain old saw. You gotta make sure it's fueled up, oiled and whatnot. You might even have to read instructions the first time! But is it worth it? That's the question, and it goes completely unaddressed in this post.
I get the feeling that this article author doesn't get it. I can't say quite what they are missing, but I have a nagging feeling that they are missing something very basic.
I find it quite easy to add a small feature to the existing angular app. And it's modular so the app's complexity isn't snowballing. And the new feature is covered by unit tests. Could you say the same for a jQuery app? If "yes", did it need heroic measures? This just falls out of the default angular app template. For the first time I feel that the client-side approaches the engineering rigour that we have on the server.
It's the opposite of the "spaghetti nightmare" mentioned. I'm sure you can tie yourself in knots of code with angular, but you can also avoid it.
Exactly. If you don't want to burden your little head with OPAs and APIs and application architectures, just stick the jQuery and happily manipulate the DOM here and there as you see fit. If you want to make something bigger, something more app-like (in your browser), something that's not merely a web page, you're going to need some structure like that found in an MVC framework.
Coming off working on a large Backbone app, I've seen how bloated, needlessly repeated, and painstakingly verbose things can get. Angular solves a lot of the problems I have with Backbone by taking care of basic plumbing for me so I can focus on the unique parts of my app. It's magical, but that's what I want in a framework: less pounding out boilerplate and more writing application code.
Minor aside, I like the chainsaw metaphor and use it a lot when thinking about programming tools and languages.
Before choosing a tool / language, I check if the task is to (metaphorically) cut a single tree or an entire patch of trees. If the answer is former, I choose an axe (a simpler tool), else I stick with the chainsaw no matter how difficult it gets, as it will pay in the long run.
Pretty much this. Angular isn't there to replace jQuery or do simple things that can be done in minutes in jQuery; Angular's for building applications. I like the analogy in the first comment on the page itself.
The article links to another page where the author rants about why Angular sucks; the second paragraph already indicates the author is trying to do direct DOM manipulation, which is exactly what Angular tries to prevent you from doing. It's an abstraction layer (amongst other things).
tl;dr I wonder if the author ever worked on a production-sized single page application.
"1. Now imagine coming to a website where you have to wait even 30 seconds for every page to load because it has to build objects. Just doesn’t make any sense.
2.Why build objects on every page load, when all the objects are going to be gone once the page is loaded anyway?
3.It’s like building a stock car at the start of every race only to completely take it apart at the finish line. Pointless."
He also gives out some advice:
"Note to OOP Web Devs. Stop being lazy and learn to actually program."
No offense to the author, but he's clearly a junior developer with a blog. Literally every single indicator points to that: overly simplistic, linkbait-y headlines, complete lack of technical examples, no technical anecdotes, overly long articles.
We all go through the "all other software sucks, it's too complex" phase. The difference is how you handle the realization, and how you let that taste influence your own programming. Some software is necessarily complex.
I think the author is right, if Angular stays how it is today. I've spent a lot of time trying to learn and believe in Angular. I've failed to be persuaded that it's the end-all, be-all that many people think it is. Nothing I've read--not the docs, nor ng-book--have successfully given me the mental model for what the heck is going on behind the scenes. I think directives are a horrible hacky mess. I recently struggled mightily to design a simple recursive tree directive. Apparently it can't be done without hacking the compile/link plumbing [1].
But my understanding is that Angular is actually going to vastly simplify and modularize in version 2 [2]. I've read that Web Components will be replacing directives [3]. Notably Google is also sponsoring Polymer, which is based on Web Components. Object.observe is going to vastly simplify the scope situation.
You've further reinforced my gut feeling of staying away from Angular at the time.
I'm a data guy, and I only mess with web apps to present my stuff. Recently I wanted to do a realtime map app to display tweets processed by some ML stuff I had built.
I started to look at Angular, got a headache, and then built it with Meteor. It was ridiculously, almost embarrassingly easy. I felt like it was 1996 and I was sneakily using Microsoft Frontpage to build my web page instead of hand coding it.
Now, I'm not an idiot. I understand that Angular is a toolkit for building things which are much, much bigger and more complex than anything I touch. But if they can make it easier with version 2, I'll wait until then.
First of all. Yes, Angular IS kinda difficult. The docs sucks and it has a huge learning curve if you're not doing a stupid app.
BUT
It is not jQuery. It's a full blown mvc framework. And the 2 are completly different products and they serve different purposes...
- want to do simple Dom manipulaition? use jQuery.
- want to connect the browser client with a backend system in an efficent way? Angular may be the tool you're looking for.
"The problem is that it's backed by Google. Well, Google is composed of many smart people writing complex apps and inventing revolutionary algorithms. The people working there are in the top 1% of society when it comes to intelligence. What about us on the bottom 99%?"
While I do not consider myself amongst the top 1% smart people here mentionend, I can still find my way out of Angular...Perhaps, it's learning curve is a barrier between who really wants to invest time in it or not...
I agree with the premise but disagree with the argument.
> Which brings me to the pattern of ever failing technologies. Remember Moo Tools? Prototype? ... Prototype and moo tools tried to be innovative, but they just made things harder. Not only were they not intuitive to use, but referring to the documentation was even worse. Would take hours what jQuery could accomplish in mere minutes.
That's just not true. I can't speak to MooTools, but I used Prototype back in the early Rails days, and it was a pleasure. Great documentation and it jived with the Rails automagical convention-over-configuration approach. Prototype failed because a) it stopped being actively developed, and b) it overrode native object prototypes in a way that could cause other libraries to catastrophically fail. But Prototype didn't fail because it wasn't intuitive, and it didn't fail because it wasn't documented. IIRC, Prototype documentation was actually better than jQuery documentation.
> The main reason Angular JS will fail is because it’s difficult.
This is fair criticism, but there's no supporting evidence provided—only that Angular JS didn't "feel" right and that more people search for "Angular sucks" than "jQuery sucks" on Google.
I think Angular got a lot of core ideas right: two-way binding and extending HTML. But it also comes with an extremely steep learning curve. The directive definition object, with its pre-compile, post-compile, pre-link, and post-link phases is too complex and exposes too many warts of using the DOM as a templating language. The documentation takes several passes to grok, and you'll more-than-once have to dig into Angular internals. The several ways to create a service (`.provider`, `.factory`, and the supremely confusingly `.service`) are unnecessary obfuscation and force you to use singletons; custom classes/prototypical inheritance in Angular requires some mind-bending use of first-class functions.
If you're not careful to fully understand Angular, it's easy for your first Angular app to turn into a mess of spaghetti, since Angular enforces too much awkward structure at the directive/controller levels, and not enough at the data management layer.
But these are issues that the Angular core team is well aware of. I'm really excited about the Angular 2.0 roadmap [0]. And even if Angular fails, some of its ideas are so good they're being incorporated into ES6, like Object.observe [1].
As far as I can tell, it's that theres more search results for "angular sucks" vs "jquery sucks". But that's a horrible metric, all you have to do is go 10 pages back and see that most articles have nothing to do with "Angular sucking". As for more people thinking angular sucks, http://www.google.com/trends/explore#q=angular%20sucks%2C%20... is a pretty strong rebuke to that point.
So far, they've got the mindshare and a serious head start.
I keep on hearing this, but I really haven't heard of it being in any large projects other than DoubleClick. I don't know if I'd consider being used in a bunch of small hobby projects a 'head start'.
Being used all over the place in the Silicon Forest (Portland/Hillsboro Oregon). Everything from startups to places like Nike and Intel are building out tons of Angular stuff. OSS and .Net shops both using it extensively here.
Not saying that represents the market, but just saying it's taken off in my corner of the world significantly.
there is a lot more, it's being used in a lot of startups and major companies throughout the world today, pretty sure the stats show it is far ahead of ember in real world adoption so far
Databinding is a lock-in feature. Annoying as hell, but true. There's no databinding library that I've seen that does not reduce your ability to use other libraries. I've never seen one that jives at ALL with third-party client templates (like dustjs).
There are few cases where I want such a thing (like say updating the count on a shopping cart when an item is added). I don't ever want an item you're adding in a form to be showing up as you type it in a list in the background. That adds nothing and on the whole it's probably a UX negative effect.
I think it's brought up so much mostly because it's cool tech. But I don't see it actually solving problems.
MS had the same tech, with an arguably simpler implementation, years ago in ASP.NET. And while I've been out of MS development for awhile I feel like it's been largely deprecated. And it was never a "best practice" in the first place. It was mostly just a demo tool for MS sponsored "conferences" (read sales demonstrations by MS employees who went on to found Telligent).
That is only one use case for two-way data binding. A better example is that choosing an option in a select list instantly modifies your model, which triggers changes in some other computed properties on your model, which instantly binds back to the UI to populate that second drop down list with the filtered options.
Sure. But most if not all of that logic is on the server anyways. So to actually make it work that way would be (IME) a duplication of effort.
Then you have to deal with the fact that some of these second-order effects may be dealing with thousands of options. Do you really want to be calculating cartesian products on the client in JS? Ignoring the performance concerns, you could be talking about preloading a ton of data.
And then you're addressing complexities on the client side, coming up with potentially inconsistent solutions for because you're evaluating these on a case by case basis, and you've already solved these problems on the server.
While there might be some UX cost to round-tripping to the server, the client solution to approaching such problems is then consistent, and arguably far simpler. And you generally have much much better tooling to tackle these problems on the server, and more flexibility in applying your logic across web, mobile, batch processing scenarios, etc.
I mean, you could make your same argument for WebControls in ASP.NET. And it's my impression everyone mostly agrees it was a bad idea (at least I haven't noticed any competitors thinking it was an idea worth stealing). Except now it's on the client, with much weaker tooling, multiple runtimes it has to work with, etc.
We could go back and forth all day I'm sure. It's just a POV I felt like putting out there as someone who survived the two-way-data-binding wars of the early 2000's and isn't eager to see that idea rise to prominence again.
If that logic is on the server, you wouldn't use Angular for it...
But from a strict MVC standpoint, it seems smart for that logic to be on the client. The server provides a getter API: /api/schools_by_state/CA for example. The client does an ajax call if you choose "California" to get the schools list, which it can do in under 100ms on a fast enough world...then it can cache California schools on the client side, so it doesn't need to fire that call again.
And of course you want that calculation to happen on the client, for 2 reasons:
1. In sparse-use sets (like pick a state, then pick a city, then pick a district) you will only really need to use 10% of the data, you can save a ton on bandwidth here.
2. In situations where the render patterns get complicated, it's really just a PRESENTATION issue. The server may validate that you're not using noncompatible dropdowns, but it otherwise should not care what happens in the browser related to that.
Binding a select-box to an event that makes that request and fills it in is trivial. And that data comes from the server.
If you're saying that you bring back a coarse interface (of school -> (state, city, district)), well that seems like a reasonable way to tackle it to me. But then that's not really what the other poster was suggesting (at least as I understood it), and Angular really does practically nothing for you in this scenario. You still have to specify your endpoint. You're still binding the data. And the two-way aspect of it is at best useless since the selected value is right there in the Form to be serialized, and at worst harmful because you're building and keeping large objects in JS for... no practical advantage I can think of at the moment.
Even stepping into the territory of calling something like this a "pattern", something that's been really common and fairly trivial beginning from the very earliest examples of Prototype.js really serves to add needless complexity to something that's actually very simple IME.
The two way binding can be so useful though. The best example I've seen was an array of coordinates bound to a directive that used D3.js to visualise it. There were some special function you could call that would affect and expand your data and immediately update the graph, and you could manipulate the individual points on the graph and it would propagate to the data seamlessly.
I guess to me two way binding is one of those things that you don't think of often, but when you don't have it you suddenly find yourself writing tons of boilerplate code to get the same effects.
The only cases when I didn't want the two way binding were when I was creating or editing an item. And then it's trivial to bind the form to a separate object while you work on it, then push your changes to the collection/original when you're done.
If you think it's oversold, you've probably only seen a bunch of stupid tutorials about neat features with it.
What Two-way data-binding gives you is a structurally-controlled presentation layer.
You can represent the page's state as objects with properties, and it "just renders". You can have a "readonly" property, and it makes everything readonly. You can have a "show edit box" property...bang. A "loading" variable, etc.
The idea is that you can treat the front end html like everyone else has always treated their world: as a finite state machine.
Since I am primarily a back-end developer (with more middle-tier experience than I originally would've wanted to admit), this jives really well to me. Instead of jumping in and hacking at the DOM every time data gets updated, I just use Angular for pages that are "that dynamic".
I really don't want to have to render new DOM elements (even with a template engine like Dustjs) and overwrite them into the page, just to represent a small state change.
With a data binding library, I don't have to. I don't use Angular for many things, and I sure don't use the "SPA routing" functionality... but when I need to do constant rapid-fire AJAX requests for growing subsets of a huge dataset (say, schools/programs by region and proximity), Angularjs saves you a lot of code: code that's generally quite ugly.
What I dont like about Angular: "it is built on the idea of adding HTML attributes to make it powerful enough to build applications. This is not a solid theoretical foundation and results in lots of neologisms -- scopes, transclusion, directives, reliance on dependency injection (in JS? really?), its own module system, its own idea of model/view/controller, etc etc.". Quoted it from pete hunt. When I studied CanJS or React, I felt the design made more sense.
I'm not sure I agree with the comparison here. I used MooTools back in the day, and it was just as easy to use as jQuery to my mind. The syntax was slightly different but not hugely - when I gave into the inevitable and switched to jQuery it didn't take long for me to understand it.
jQuery succeeded because it captured the largest amount of mindshare, particularly important for a library that relies on numerous plugins. Right now Angular is looking pretty similar - it's not pretty, but it is widely adopted.
Apples and oranges...Coming from a backend developer background i actually found angular pretty easy to pick up. Most of the backend frameworks are much more complex. And angularJS is to be compared with application frameworks, not with a javascript toolkit to enhance static websites like jquery.
Try to build the kind of apps you can build with angular in a few days with jquery and you will see what mess you end up with.
I have exactly the same feeling. I am mostly backend developer who started with angular this week. After few days I was able to create mvc app, thanks to the multiple plugins I was able to finish it really fast. DI and other features make it easy to maintain over time. jQuery is cool for simple frontend features, but not for maintaining complex mvc frontend.
I don't think the argument is that jQuery can do the same things. I think the argument is that you can have two way bindings and a lot of the benefits without a lot of the complexity of Angular.
You can probably apply the same logic to most things, especially something like scala. On the surface when you see a method definition in scala that looks like
you kinda scratch your head. But once you understand whats happening it doesnt feel so intimidating. I think technologies that have a good long term benefit, but a difficult upfront learning curve tend to get this kind of reaction. I think Angular is a brilliant framework and makes coding in javascript enjoyable. Yes, I had to read 10 articles before I understood what the hell transclusion was, but once you invest a little time learning, it doesnt feel so bad.
> The main reason Angular JS will fail is because it’s difficult.
I'm glad good scientists don't stop studying something because it's difficult, it would have sucked for quantum theory.
Seriously, though, that's the argument? A technology will fail because it's difficult? Hopefully the OP meant "overcomplicated" or "I tried to learn it and it was beyond my ability", but saying that something will fail because it's difficult is just stupid.
Besides, even if Angular were to fail overnight, right now. The download sites go dark, the team is disbanded and starts working on something else, I'd argue that Angular has already succeeded by showing everyone a new way to tackle single apps and how to structure Javascript applications.
Having said that, I'm pretty sure Angular is going to be around for quite a while.
Angular allows for a clear separation of concerns and it's easy to teach individuals standards (isolate dom manipulation, no global state if possible, clear techniques like promises and data binding). It's similar techniques, if not easier, than node.js. Should we assume node.js will fail because it's too difficult for the author?
Simpler, yes, but simplicity often comes at the expense of power. What happens in a year, when you have a bunch of experienced developers, struggling to overcome the limitations of ReactJS? Most likely you'll end up reinventing many of the things that Angular provides out of the box.
It is always tempting to take short-term gains over long-term costs, and in some situations, it may be the right thing to do. A company that gets a product out of the door in a couple of months using ReactJS may beat a company that spends 12 months building a "better" one with AngularJS. But the reverse may happen instead: The company that adopted a simpler technology may become bogged down trying to extend beyond its limitations, giving their competitors a chance to accelerate past them.
It's the old story of the tortoise and the hare. Except, as with any fable, real life is never so clear-cut, and gains in one area will almost always be countered by losses in another.
That's a good, albeit very generic argument where you can switch Angular and React with simply A and B. My guess is that you haven't tried React? It's been in production at Facebook/Instagram for a few years now and powers the money-making parts of the site.
Trading simplicity for power is a false dilemma. If there's any library on the web that demonstrates this, it has to be React.
I think a better argument would have been not adding Angular to every project by default because it's the new hotness/shiny. There is a great use case for Angular but if all you need are some onclick's then yeah Angular is overkill and complicated. But if you need two-way binding and a semi-complicated UI then it simplifies a lot of stuff vs. straight up JQuery.
This is a fundamental problem for frameworks. To be better, you have to be different. People don't like different. They do like better, though, so the design goal has to be maximize better while minimizing different.
Angular's explosive growth suggests they've done a reasonably good job of that, and will continue to increase their better:different ratio. You can't please everybody, though.
It may have a steep learning curve, but it is also a massive jump forward in frontend web dev.
It isn't for every project, but the main project I use it on now would have been at least 10x as much jQuery style code to write. Writing code isn't hard, maintaining it is.
84 comments
[ 4.0 ms ] story [ 146 ms ] threadI suspect it's only difficult to people who don't make sophisticated things.
If you don't understand this, you understand neither Angular, nor jQuery.
The moment you databind, you can't use nearly as many other libraries as easily or safely. This means you want as fully-featured a databinding library so you don't need other stuff.
There's tons of articles about providing Angularjs updating support when you use jQuery..it's (or used to be) just painful.
I find it quite easy to add a small feature to the existing angular app. And it's modular so the app's complexity isn't snowballing. And the new feature is covered by unit tests. Could you say the same for a jQuery app? If "yes", did it need heroic measures? This just falls out of the default angular app template. For the first time I feel that the client-side approaches the engineering rigour that we have on the server.
It's the opposite of the "spaghetti nightmare" mentioned. I'm sure you can tie yourself in knots of code with angular, but you can also avoid it.
Coming off working on a large Backbone app, I've seen how bloated, needlessly repeated, and painstakingly verbose things can get. Angular solves a lot of the problems I have with Backbone by taking care of basic plumbing for me so I can focus on the unique parts of my app. It's magical, but that's what I want in a framework: less pounding out boilerplate and more writing application code.
Before choosing a tool / language, I check if the task is to (metaphorically) cut a single tree or an entire patch of trees. If the answer is former, I choose an axe (a simpler tool), else I stick with the chainsaw no matter how difficult it gets, as it will pay in the long run.
The article links to another page where the author rants about why Angular sucks; the second paragraph already indicates the author is trying to do direct DOM manipulation, which is exactly what Angular tries to prevent you from doing. It's an abstraction layer (amongst other things).
tl;dr I wonder if the author ever worked on a production-sized single page application.
http://okmaya.com/2014/03/10/git-kinda-sucks/
- d3 kinda sucks
- docker kinda sucks
- golang kinda sucks
- everything that's hard, kinda sucks
It eschews OOP, for the following reasons:
"1. Now imagine coming to a website where you have to wait even 30 seconds for every page to load because it has to build objects. Just doesn’t make any sense.
2.Why build objects on every page load, when all the objects are going to be gone once the page is loaded anyway?
3.It’s like building a stock car at the start of every race only to completely take it apart at the finish line. Pointless."
He also gives out some advice:
"Note to OOP Web Devs. Stop being lazy and learn to actually program."
We all go through the "all other software sucks, it's too complex" phase. The difference is how you handle the realization, and how you let that taste influence your own programming. Some software is necessarily complex.
But my understanding is that Angular is actually going to vastly simplify and modularize in version 2 [2]. I've read that Web Components will be replacing directives [3]. Notably Google is also sponsoring Polymer, which is based on Web Components. Object.observe is going to vastly simplify the scope situation.
[1] http://stackoverflow.com/questions/14430655/recursion-in-ang...
[2] http://blog.angularjs.org/2014/03/angular-20.html
[3] http://stackoverflow.com/questions/18089075/what-is-the-diff...
I'm a data guy, and I only mess with web apps to present my stuff. Recently I wanted to do a realtime map app to display tweets processed by some ML stuff I had built.
I started to look at Angular, got a headache, and then built it with Meteor. It was ridiculously, almost embarrassingly easy. I felt like it was 1996 and I was sneakily using Microsoft Frontpage to build my web page instead of hand coding it.
Now, I'm not an idiot. I understand that Angular is a toolkit for building things which are much, much bigger and more complex than anything I touch. But if they can make it easier with version 2, I'll wait until then.
First of all. Yes, Angular IS kinda difficult. The docs sucks and it has a huge learning curve if you're not doing a stupid app.
BUT
It is not jQuery. It's a full blown mvc framework. And the 2 are completly different products and they serve different purposes...
- want to do simple Dom manipulaition? use jQuery. - want to connect the browser client with a backend system in an efficent way? Angular may be the tool you're looking for.
"The problem is that it's backed by Google. Well, Google is composed of many smart people writing complex apps and inventing revolutionary algorithms. The people working there are in the top 1% of society when it comes to intelligence. What about us on the bottom 99%?"
While I do not consider myself amongst the top 1% smart people here mentionend, I can still find my way out of Angular...Perhaps, it's learning curve is a barrier between who really wants to invest time in it or not...
> Which brings me to the pattern of ever failing technologies. Remember Moo Tools? Prototype? ... Prototype and moo tools tried to be innovative, but they just made things harder. Not only were they not intuitive to use, but referring to the documentation was even worse. Would take hours what jQuery could accomplish in mere minutes.
That's just not true. I can't speak to MooTools, but I used Prototype back in the early Rails days, and it was a pleasure. Great documentation and it jived with the Rails automagical convention-over-configuration approach. Prototype failed because a) it stopped being actively developed, and b) it overrode native object prototypes in a way that could cause other libraries to catastrophically fail. But Prototype didn't fail because it wasn't intuitive, and it didn't fail because it wasn't documented. IIRC, Prototype documentation was actually better than jQuery documentation.
> The main reason Angular JS will fail is because it’s difficult.
This is fair criticism, but there's no supporting evidence provided—only that Angular JS didn't "feel" right and that more people search for "Angular sucks" than "jQuery sucks" on Google.
I think Angular got a lot of core ideas right: two-way binding and extending HTML. But it also comes with an extremely steep learning curve. The directive definition object, with its pre-compile, post-compile, pre-link, and post-link phases is too complex and exposes too many warts of using the DOM as a templating language. The documentation takes several passes to grok, and you'll more-than-once have to dig into Angular internals. The several ways to create a service (`.provider`, `.factory`, and the supremely confusingly `.service`) are unnecessary obfuscation and force you to use singletons; custom classes/prototypical inheritance in Angular requires some mind-bending use of first-class functions.
If you're not careful to fully understand Angular, it's easy for your first Angular app to turn into a mess of spaghetti, since Angular enforces too much awkward structure at the directive/controller levels, and not enough at the data management layer.
But these are issues that the Angular core team is well aware of. I'm really excited about the Angular 2.0 roadmap [0]. And even if Angular fails, some of its ideas are so good they're being incorporated into ES6, like Object.observe [1].
[0] http://blog.angularjs.org/2014/03/angular-20.html
[1] http://addyosmani.com/blog/the-future-of-data-binding-is-obj...
Custom Elements + Two-way Data Binding + Services seems to be a pretty powerful combination.
There are definitely two questions worth asking:
1) Is that combination really what we want? (I think it is)
and
2) Is Angular's approach the only right way to do it?
So far, they've got the mindshare and a serious head start.
I keep on hearing this, but I really haven't heard of it being in any large projects other than DoubleClick. I don't know if I'd consider being used in a bunch of small hobby projects a 'head start'.
Not saying that represents the market, but just saying it's taken off in my corner of the world significantly.
Youtube App for PS3
there is a lot more, it's being used in a lot of startups and major companies throughout the world today, pretty sure the stats show it is far ahead of ember in real world adoption so far
Square, Vine, Yahoo, NBC News, Groupon, Twitch, Urbanspoon, Discourse, Ghost, TravisCI, and now Netflix?
Databinding is a lock-in feature. Annoying as hell, but true. There's no databinding library that I've seen that does not reduce your ability to use other libraries. I've never seen one that jives at ALL with third-party client templates (like dustjs).
There are few cases where I want such a thing (like say updating the count on a shopping cart when an item is added). I don't ever want an item you're adding in a form to be showing up as you type it in a list in the background. That adds nothing and on the whole it's probably a UX negative effect.
I think it's brought up so much mostly because it's cool tech. But I don't see it actually solving problems.
MS had the same tech, with an arguably simpler implementation, years ago in ASP.NET. And while I've been out of MS development for awhile I feel like it's been largely deprecated. And it was never a "best practice" in the first place. It was mostly just a demo tool for MS sponsored "conferences" (read sales demonstrations by MS employees who went on to found Telligent).
Then you have to deal with the fact that some of these second-order effects may be dealing with thousands of options. Do you really want to be calculating cartesian products on the client in JS? Ignoring the performance concerns, you could be talking about preloading a ton of data.
And then you're addressing complexities on the client side, coming up with potentially inconsistent solutions for because you're evaluating these on a case by case basis, and you've already solved these problems on the server.
While there might be some UX cost to round-tripping to the server, the client solution to approaching such problems is then consistent, and arguably far simpler. And you generally have much much better tooling to tackle these problems on the server, and more flexibility in applying your logic across web, mobile, batch processing scenarios, etc.
I mean, you could make your same argument for WebControls in ASP.NET. And it's my impression everyone mostly agrees it was a bad idea (at least I haven't noticed any competitors thinking it was an idea worth stealing). Except now it's on the client, with much weaker tooling, multiple runtimes it has to work with, etc.
We could go back and forth all day I'm sure. It's just a POV I felt like putting out there as someone who survived the two-way-data-binding wars of the early 2000's and isn't eager to see that idea rise to prominence again.
But from a strict MVC standpoint, it seems smart for that logic to be on the client. The server provides a getter API: /api/schools_by_state/CA for example. The client does an ajax call if you choose "California" to get the schools list, which it can do in under 100ms on a fast enough world...then it can cache California schools on the client side, so it doesn't need to fire that call again.
And of course you want that calculation to happen on the client, for 2 reasons:
1. In sparse-use sets (like pick a state, then pick a city, then pick a district) you will only really need to use 10% of the data, you can save a ton on bandwidth here.
2. In situations where the render patterns get complicated, it's really just a PRESENTATION issue. The server may validate that you're not using noncompatible dropdowns, but it otherwise should not care what happens in the browser related to that.
Binding a select-box to an event that makes that request and fills it in is trivial. And that data comes from the server.
If you're saying that you bring back a coarse interface (of school -> (state, city, district)), well that seems like a reasonable way to tackle it to me. But then that's not really what the other poster was suggesting (at least as I understood it), and Angular really does practically nothing for you in this scenario. You still have to specify your endpoint. You're still binding the data. And the two-way aspect of it is at best useless since the selected value is right there in the Form to be serialized, and at worst harmful because you're building and keeping large objects in JS for... no practical advantage I can think of at the moment.
Even stepping into the territory of calling something like this a "pattern", something that's been really common and fairly trivial beginning from the very earliest examples of Prototype.js really serves to add needless complexity to something that's actually very simple IME.
IMO.
I guess to me two way binding is one of those things that you don't think of often, but when you don't have it you suddenly find yourself writing tons of boilerplate code to get the same effects.
The only cases when I didn't want the two way binding were when I was creating or editing an item. And then it's trivial to bind the form to a separate object while you work on it, then push your changes to the collection/original when you're done.
What Two-way data-binding gives you is a structurally-controlled presentation layer.
You can represent the page's state as objects with properties, and it "just renders". You can have a "readonly" property, and it makes everything readonly. You can have a "show edit box" property...bang. A "loading" variable, etc.
The idea is that you can treat the front end html like everyone else has always treated their world: as a finite state machine.
Since I am primarily a back-end developer (with more middle-tier experience than I originally would've wanted to admit), this jives really well to me. Instead of jumping in and hacking at the DOM every time data gets updated, I just use Angular for pages that are "that dynamic".
I really don't want to have to render new DOM elements (even with a template engine like Dustjs) and overwrite them into the page, just to represent a small state change.
With a data binding library, I don't have to. I don't use Angular for many things, and I sure don't use the "SPA routing" functionality... but when I need to do constant rapid-fire AJAX requests for growing subsets of a huge dataset (say, schools/programs by region and proximity), Angularjs saves you a lot of code: code that's generally quite ugly.
jQuery succeeded because it captured the largest amount of mindshare, particularly important for a library that relies on numerous plugins. Right now Angular is looking pretty similar - it's not pretty, but it is widely adopted.
science
Try to build the kind of apps you can build with angular in a few days with jquery and you will see what mess you end up with.
def split: scala.Seq[Task[Combiner[S, That], FlatMap[S, That]]]
you kinda scratch your head. But once you understand whats happening it doesnt feel so intimidating. I think technologies that have a good long term benefit, but a difficult upfront learning curve tend to get this kind of reaction. I think Angular is a brilliant framework and makes coding in javascript enjoyable. Yes, I had to read 10 articles before I understood what the hell transclusion was, but once you invest a little time learning, it doesnt feel so bad.
I'm glad good scientists don't stop studying something because it's difficult, it would have sucked for quantum theory.
Seriously, though, that's the argument? A technology will fail because it's difficult? Hopefully the OP meant "overcomplicated" or "I tried to learn it and it was beyond my ability", but saying that something will fail because it's difficult is just stupid.
Besides, even if Angular were to fail overnight, right now. The download sites go dark, the team is disbanded and starts working on something else, I'd argue that Angular has already succeeded by showing everyone a new way to tackle single apps and how to structure Javascript applications.
Having said that, I'm pretty sure Angular is going to be around for quite a while.
Our solution was to migrate from Angular to ReactJS. Much simpler, faster and better.
It is always tempting to take short-term gains over long-term costs, and in some situations, it may be the right thing to do. A company that gets a product out of the door in a couple of months using ReactJS may beat a company that spends 12 months building a "better" one with AngularJS. But the reverse may happen instead: The company that adopted a simpler technology may become bogged down trying to extend beyond its limitations, giving their competitors a chance to accelerate past them.
It's the old story of the tortoise and the hare. Except, as with any fable, real life is never so clear-cut, and gains in one area will almost always be countered by losses in another.
Trading simplicity for power is a false dilemma. If there's any library on the web that demonstrates this, it has to be React.
Angular's explosive growth suggests they've done a reasonably good job of that, and will continue to increase their better:different ratio. You can't please everybody, though.
It isn't for every project, but the main project I use it on now would have been at least 10x as much jQuery style code to write. Writing code isn't hard, maintaining it is.