by teemo_cute on 4/3/14, 1:11 PM with 80 comments
by acjohnson55 on 4/3/14, 1:50 PM
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...
by pilgrim689 on 4/3/14, 1:45 PM
by laureny on 4/3/14, 2:01 PM
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.
by kayoone on 4/3/14, 1:59 PM
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.
by kmkemp on 4/3/14, 1:49 PM
by cwp on 4/3/14, 2:12 PM
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.
by crazychrome on 4/3/14, 2:51 PM
It's not because google guys are less smart but they are in a very different working environment than `modern startup`. In today's startup, developers are designers. We don't have money to hire graphic folks, UX specialists. We learn by coding, therefore the feeling of having control is essential. The popular MVC/MVM model is used to maintain flexibility and separation of concerns, not to dispatch work to different people. The AngularJS framework gives me the impression that the developers desperately want to hand the sh*tty html/css parts to someone else as if it's necessary evil. AngularJS projects are difficult to control since by its nature, users of the framework are encouraged to let go something that are essential to the control freaks.
Are you a AngularJS advocate and a corp dev?
by jeremiep on 4/3/14, 1:44 PM
by johnatwork on 4/3/14, 1:37 PM
by icholy on 4/3/14, 1:46 PM
by joshdance on 4/3/14, 2:36 PM
> and AngularJS has only been around for a few years, while jQuery, almost a couple of decades.
jQuery was released in 2006. Unless my math fails me, that is less than a couple of decades.
Opinion is valid and he wrote an article, which is more than most have done, but some factual discrepancies. The whole # of google results factoid is off as well - http://www.google.com/trends/explore#q=angular%20sucks%2C%20...
by asattarmd on 4/3/14, 2:37 PM
When you write in AngularJS, you forget the nitty-gritty DOM manipulation, you just care about your data. AngularJS changes DOM for you. A Controller holds the data. AngularJS keeps the view updated with the data in the controller. You need to fetch data from somewhere such as REST API? Just ask for it, AngularJS gives you $resource. Just like that. No initialization, handling dependencies. Feeling there's code bloat in your controller? Extract a service and AngularJS will make it singleton for you and pass it whenever you need! Need to filter data before displaying it? Write a filter! Directives are bit difficult, I understand, but all the rest of stuff is easy and very intuitive.
Microsoft folks have been writing MVVM apps in WPF and Silverlight for nearly a decade now, writing their own DelegateCommand, using an IoC container, using an ORM and plugging all these things together. AngularJS gives you all of these as one framework! (considering $resource as the ORM). AngularJS got SPA right and IMO, is the way to build apps. I don't think it'll fail.
by crucialfelix on 4/3/14, 2:19 PM
Angular 2.0 addresses many of my complaints. I have a few legitimate ones.
Dependency Injection is being made simpler and I hope less fragile. If something goes wrong in the minimization phase you can easily get the dreaded module not found and your whole app/site is broken. But it makes testing clear and precise and its improved the quality of design of my sites and apps.
Simplify the directive API. Yep, its weird. Its fun when it works though. The ideas of directives will live on in other frameworks regardless. So Angular can't fail, it has already succeeded. Even if it dissolves into web components in the future.
When the animation system gets fully solved then I think angular apps will look/behave so cool that complainers will be compelled to learn it.
Really, its the Rails of the frontend. Which is both a compliment and a criticism ;) They both have too much magic.
by dillonforrest on 4/3/14, 2:25 PM
If the author IS trying to build a complex single-page app, then I see absolutely no reason why jQuery would be preferable to Angular. Angular does one job and does it well. jQuery is a strong candidate for most reasons you'd ever need javascript in the browser.
Yeah, I do agree that Angular's documentation is lacking, especially compared to jQuery's docs. Also, Angular is not my personal first choice front-end UI framework. However, for CRUD application development, I care much more about Angular's holistic approach rather than being able to procedurally manipulate each DOM node and event handler as I would in jQuery.
I appreciate the author's passion and think the arguments are valid, but I also feel that this is an unconvincing apples-to-oranges comparison. In my completely honest opinion, I'm not incredibly excited about EITHER Angular or jQuery, but I am grateful for both.
by all_the_things on 4/3/14, 2:08 PM
by Taurenking on 4/3/14, 1:52 PM
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...
by methodin on 4/3/14, 3:18 PM
Personally I find the angular concept easy to follow with the only hard part "how do I accomplish X" which is pretty easy to find answers for.
by deedubaya on 4/3/14, 2:13 PM
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.
by iomind on 4/3/14, 1:44 PM
If you don't understand this, you understand neither Angular, nor jQuery.
by thatthatis on 4/3/14, 3:02 PM
When I am struggling with "agh why do I have to do it like that" in either framework I later find that either 1) the difficulty was necessary for some important reason and they're saving future me from easy mistakes or 2) that the difficulty was due to me not knowing some really amazing concept or paradigm or pattern.
This isn't to say that angular is perfect, but damned if it isn't elegant, powerful, and well thought out.
I've found angular to be by and large incredibly intuitive and easy to use. But there is also an effect of they're solving pains I've had in prior projects, and using concepts I'm familiar with.
by dberg on 4/3/14, 2:00 PM
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.
by benesch on 4/3/14, 1:57 PM
> 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...
by nigekelly on 4/3/14, 2:22 PM
50% of your article was about how jquery was superior and simpler than prototype and moo tools. It may have been superior but it's nonsense to say it was simpler. I used prototype alot and it was simpler. To grab a div you simply:
$("mydiv")
not:
$("#mydiv")
So much more elegant than jquery!
Prototype comes from a js perspective whilst jquery seems to come from a css perspective. So I think prototype is better for traditional developers and jquery for web designers.
by kennu on 4/3/14, 1:44 PM
by nikon on 4/3/14, 2:17 PM
by jively on 4/3/14, 2:37 PM
JQuery does things in a very standard way, and has been the go-to tool for developers for years. Devs grow up on it, get used to it and find it difficult to fit new ways of working into their mental model. It's like shifting from procedural to functional: the concepts are a alien and because they don't fit & there's a psychological block to learning it.
Not sure that dooms it to failure... maybe to adoption by the masses.
by untog on 4/3/14, 1:58 PM
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.
by vojant on 4/3/14, 2:21 PM
It's similar to situation with php few years ago when Symfony2 and other big frameworks were introduced, many people still complain and they use simple non oop php to create websites.
World is changing, php changed and now javascript will change. Some people will stuck to jQuery but most will move to new mvc frameworks because they are much easier to maintain, also many backend developers is moving to REST architecture lately.
by romanlevin on 4/3/14, 1:57 PM
by brucehubbard on 4/3/14, 2:09 PM
by michaldudek on 4/3/14, 3:58 PM
by AlwaysBCoding on 4/3/14, 2:14 PM
Just some examples:
1. When you create a directive you initialize it with one of three different kinds of scopes. A parent scope (which is the actual controller scope object), a child scope (which prototypically inherits from the controller scope), or an isolate scope (which is an isolated scope with inheritance only to rootScope). If you don't explicitly define a scope you get a parent scope. If you write `scope: true` you get a child scope. If you write `scope: {}` you get an isolate scope. This is so fucking confusing for beginners. Why not just explicitly define what kind of scope you want so it's clear?
2. Every single example of learn AngularJS online, even examples from the 'official documentation' (that's in quotes because Angular's documentation is so atrocious that referring to it as documentation would be bastardizing the English language) give you examples of defining services, controllers and directives directly on the top-level ng-app module when in reality doing this is catastrophic and will make your app IMPOSSIBLE to unit test. You need to define services in their own modules that get aggregated into the ng-app module so you can unit test them, but there are no examples of that anywhere.
3. Speaking of unit testing, because it's supposed to be so easy in Angular right? You have this thing called angular.mock.module that's the key to everything. Now 'angular.mock.module' is different from 'angular.module' but is for some reason aliased to 'module' because that's not confusing or anything. Now you would expect for angular.mock.module to be just that, a mock module. BUT it's actually a module that depends on the angular 'ng' module meaning that it's not really a mock module at all, it's a module that includes the ENTIRE working Angular library. So you can use the 'mock' module to get the REAL injector and use that to get your REAL services which you put into the mock module to use in your tests. The entire flow is so confusing and non-descriptive that it's a wonder a beginner is ever even able to write a working unit test much less a good one. The funny part is all you hear about is "unit testing is so easy in Angular omgz" when really it's confusing as fuck but the Angular crew seems completely oblivious to that fact.
--- I could honestly write a book about my Angular rants, this is just barely skimming the surface, but the point is, Angular makes things hard and confusing when they don't need to be. I like the way Angular organizes code, but I'm willing to switch at the drop of a dime if something simpler comes along.
by mattgreenrocks on 4/3/14, 2:14 PM
What's with the win/lose sentiment? Is tooling a winner-take-all, zero-sum game? I was never informed of this.
by Arnor on 4/3/14, 1:59 PM
science
by theDustRoom on 4/3/14, 2:07 PM
by jf22 on 4/3/14, 2:14 PM
by StevePerkins on 4/3/14, 2:30 PM
However, I usually click on them anyway. I'm ashamed of myself. :(
by taybin on 4/3/14, 2:12 PM
by lmm on 4/3/14, 2:05 PM
by flylib on 4/3/14, 2:23 PM
by ing33k on 4/3/14, 2:22 PM
by andyl on 4/3/14, 2:08 PM
Our solution was to migrate from Angular to ReactJS. Much simpler, faster and better.