Angular JS Kinda Sucks

UPDATE: 7/11/2015

It’s apparent to me that there needs to be more of a focus on architecture and not as much frameworks. Learn how to do it and why you should do it before you can just assume that throwing a framework will just magically fix anything ahead of time.

UPDATE: 4/3/2015

I feel like I have to clarify for the people who keep trying to explain that jQuery is not angular.js. No duh! I’ve learned that over the years. However, what people don’t seem to understand is that I’m not comparing angular.js to jQuery. I’m comparing the difficulty to lean angular.js to jQuery. With difficulty in mind, I read an interesting quote the other day: “More entrepreneurs than ever before will enter this booming market with limited coding ability and they will need something other than [insert preferred framework / language here]”.

And now for the original post…

Ok, so I ran across this angular js framework and looked it over, tried to duplicate some functionality that I already had existing with jQuery, and was not impressed.

First of all, I can do anything in jQuery, and have full control. Full control of the selectors, HTML, the DOM. I like that. I like knowing what I’m doing and what’s happening in my application. Somehow, angular fails to let me know what’s happening behind closed doors, unless I go dig into the code itself. Hm. Never had to do that with jQuery.

+ jQuery

The documentation is just plain horrible. Basically, it comes down to how basics work, not how you can and should build an application, even though they stress that you must first architect your application before you build it. Architect it how? Are there examples? Some nice examples would be of projects that are relevant to the outside world. Data manipulation? Dynamic AJAX driven application? It just seems like a lot of hype because it’s the “cool” thing to do and everyone is doing it. Well, not everyone. About 0.1% of sites out there use Angular, while well over 55% of websites use jQuery. Most of the documentation is just hard to understand without explaining the parts of the application or explaining the magic behind the app, or even explaining why I’m naming certain things the way I name them. Anyway, just confusing.

+ jQuery

Which brings me to my final reason for not liking it. Intuitiveness. It’s not intuitive at all! If you know JS and jQuery, everything is build so you can just figure things out. .show(), .hide(), $.ajax({stuff}), $(‘whatever selector you want full control of here’).doThings(). It’s easy to read, just like OOP. In angular it feels like you’re looking at fog. ng-this, ng-that, and now you have to assume that somehow everything is aware of everything else on the page. WTF?

+ jQuery

Speed of development? Hardly. We had some experience with it at work where some front-end code was handed down to be integrated by back-end guys, and… well… everything broke. Why? The back-end guy knew only jQuery. Now, he has to spend additional time and resources to learn angular, and the learning curve is STEEP!!!! And once he learns it, maybe someone will come up with another stupid framework that will do exactly the same thing jQuery does, only more abstract. Can we get practical with our development, stop being such lazy-ass programmers, learn to code properly, and stop complaining about how working on something feels like work? Beware of lazy programming and short cuts to faster deployment schemes. Sounds a lot like get rich quick schemes. How well have those worked out so far? Is everyone rich yet?

+ jQuery

Just not for me. Might be for you, but for me, I stand by the saying, “If it ain’t broken, don’t fix it!” And jQuery is definitely not broken. It’s by far the most favorable, intuitive, powerful “framework”/library to date. It’s not a hula hoop. It’s a cellphone.

Updated on Feb 27th, 2014:
After attempting to look through documentation and examples on stackoverflow, I’ve come to the conclusion that I’m much happier with jQuery, for the simple reason that I know how to use it and it does everything I’ve ever wanted, because it’s a tool for short-cutting a lot of mundane tasks that JS threw at us. .each() loops, .ajax calls, class selectors, very easy to understand and build on top of. After looking at many examples of angular implementation, I’ve noticed a pattern of jQuery being used on top of angular. Obviously to take care of the many things that angular can’t. It seems to me that performance wise it wouldn’t be smart to use angular, simply because it would be additional bulk on top of your programming. It doesn’t complement JS, it complicates it by changing the rules, and way of thinking. jQuery respects JS and complements it greatly. So…

+ jQuery

If anyone has the solution to how they would take care of the example I’ve created using jQuery with angularjs here, I would love to read it.

  • Myself

    All I can say is YES to all of those points!

    I’ve had more trouble with our one project that’s using AngularJS than I have with any of our other projects that use standard JQuery. Every time our back-end devs need to make a change they have to wait for the FEDs to help out because the FEDs don’t want the back-end devs to mess with their code. This means that either our back-end devs are sitting on their hands waiting for the FEDs to make their changes or the other projects that the FEDs are working on have to get put on hold for hours at a time while they make changes to the AngularJS code. IT’S TOTALLY RIDICULOUS!!!

    • Gary Bisaga

      I suggest you need better leadership – not the stereotyped pointy-haired management but well-respected leaders to help people work together. I just read a post about a guy who is trying to refactor a legacy Angular app – in the comment stream I commented that I don’t know whether to be amused or terrified at the idea of a “legacy Angular app.” Also, I suggest the reasons you have less trouble with that on jQuery are two: simply familiarity, and the fact that you can hang on any poorly-designed functionality using “non-intrusive javascript” (how I am coming to hate that term!) in a way that seems to work great, but is very fragile and will break on any unexpected user input or seemingly innocuous page change.

      Admittedly, Angular is much less amenable to this kind of quick-fix page hacking, but I count that as a strength, not a weakness.

      • George

        Page hacking? Requirements from business and product change all the time. Restructuring of HTML is mandatory to keep up with standards and google’s endless ever changing SEO rules. When google says you can’t do this or that, you have to go back over your design and move things around, restructure your DOM, no matter how wonderfully you’ve written your code. Making those kind of changes while using angular is fragile business. So which makes more sense? Having a dynamic and modularized page that you can structure however you want, or having constraints as to what you can move around because of the fear that things will break?

  • disqus_t0C3Xnbwn4

    how would you do 2 way data binding with jquery? injecting new functionality? modular structure for a highly dynamic application?

    congratulations, you just started writing a version of angular.

    • FailPolice

      Um, Angular is just another version of what I’ve been doing all along, only bloatier and more frameworky, less domainy.

      To answer you question, there are libraries for that or you can do it yourself in less than 100 lines of code.

      • You may attempting to use AngularJS for something which you can do with jQuery. In this case, you should probably just use jQuery. But when you need to do something that AngularJS does, which jQuery does not, then you should be using AngularJS.

        Just because it is too hard for you to learn it, or too much of a paradigm shift from your DOM manipulation, it doesn’t mean that it is a bad framework.

        • FailPolice

          I never said Angular is a bad framework & please, I’m not worried about learning to use it. I’m really adamant about this because of my experience with Rails just taking over all mindshare, perpetuating and ossifying some antipatterns and blocking the adoption of better practices. I say let a thousand flowers bloom and let’s not get all religious on how other people should architect things.

          Personally, I like architecting according to the domain instead of according to a framework. The domain is the purest expression of what the application should do. Framework nomenclature often crowd the domain with irrelevance and give a false sense of progress.

      • Gary Bisaga

        I respectfully disagree. Some of your points are good, regarding documentation, non-trivial application structure, etc. But the answer is not to throw away the structure but make it better. I’m going to go out on a limb here and suggest that your own personal documentation, standards, and training that you create for your own good custom architecture are likely even less good than Angular’s. If I am wrong, I apologize, but that would mean you are in the tiny 0.001% minority.

        I am further going to suggest that after you see a few custom application architectures that the original developers were convinced were do much better and more domainy than anything available, and you are tasked with either maintaining them or (possibly worse) being architect over teams of people maintaining them, you will cry out for well-known (even if imperfect) standard packages. Far too often our perfect maps of the way things ought to be are dashed on the cruel rocks of reality.

        • FailPolice

          Thanks for the respect. However, I think you misunderstood. The OP nor I *do not* condone throwing away structure. We don’t hate freedom 🙂

          Instead, I prefer to architecture the app with the domain terminologies front and center. Frameworks want framework terminology being front and center and the domain fits in the designated areas. I believe the framework should be as invisible as possible. There should be patterns, idioms, structure, and all that good stuff, but the most important attribute of a maintainable codebase is clarity of the domain.

          When you build a house, the most important thing is the feel of the rooms, not the nails and boards. Yes, the nails and boards are necessary for the building to stand, but I certainly don’t want that to be the focus when designing & experiencing the house.

          • Gary Bisaga

            Oh, sorry, I thought you WERE the OP. 🙂 And I do not disagree with the idea that domain needs to be front and center. I, too, dislike endless discussions about the most “clever” ways of doing certain things in the framework, ignoring the problem you are trying to solve. It is unfortunate that in a tool like Angular, everybody wants to write their own (essentially) Angular Level 2, only less well-tested, documented, and capable.

            I still believe, however, that mature use of Angular can be done with domain focus front and center, yet still taking advantage of the useful capabilities of Angular. Two-way data binding is great – and not just for toy apps. Directives are great if you look at them as reusable components – especially domain-oriented ones. I would LOVE to see somebody come out with solid, well-tested, well-documented and capable domain-oriented directives. And I believe that’s better than throwing out the baby with the bathwater. (I wonder if anybody has ever done that? Sorry, my mind wandered. 🙂

            Thanks for the discussion. As usual, these kinds of discussions are great for focusing the mind on doing what we should all be trying to do, build better software for real users (rather than building frameworks for ourselves). And I believe Angular has the potential to let me do just that, which is why I’m still positive on it.

          • FailPolice

            The reason why people like building the second layer is because the framework does not satisfy the needs of the application domain. My stance is to use thin libraries, that do few things but do them well without the bloat and the upgrade nightmares.

            Making frameworks is relatively easy now days. There are plenty of idioms to choose from, but you can have a good sense of what is out there and what your preferences are. My preference is to not be fighting a framework to get it to do what I want.

            In fact, you average experienced developer can quickly build forward thinking frameworks that work for their project, due to the plethora of libraries & articles out there. In my experience, the project is better off because it’s completely self-contained without an outside organization imposing upgrades and other schisms.

          • Bojan Matić

            You are confusing frameworks and libraries. What you’re basically saying is that you prefer libraries to frameworks. A framework, by definition, dictates (at least partially) how you frame your work. That’s why it’s called framework 😉

          • George

            I think the idea is that a framework is too constrained. Not enough freedom to do what you want to do, whereas jQuery (library) will be there if you need it, but you don’t have to adhere to its rules constantly. You CAN use simple JS if you wish.

            The best thing to do, if you want something solid, is pull out a piece of paper and architect what needs to be done. Don’t just cowboy code everything just because everyone else is doing it.

          • Bojan Matić

            Sure, frameworks can get too constrained and that’s when they really suck.

            Take, for example, frameworks such as Ruby on rails or Django – people have found them to be constraining when you try to go against the grain e.g. try to do something the framework authors didn’t envision. That can be a real problem, but that isn’t to say that those frameworks don’t have their place.

            Now, I believe Angular does a really good job of letting you structure your application however you see fit – it tries to not be opinionated. Some people have actually cited this as a weakness of Angular. They argue that it’s all to easy to make some bad choices early on that end up costing you a great deal later and it would be nice if the framework was there to help guide you from the start. So you see that different people want different things.

            I would say the biggest disadvantage of Angular is that you can’t just plop in any old DOM-mutating jquery plugin onto your page. You have to integrate it with the angular way of doing things e.g. make a directive out of it. Although that integration is most often easy and most of the time there are a couple of directives already available for you to choose from.

    • Two-way databinding? KnockoutJS!

      • haydenchambers


      • You can easily implement two-way databinding with jQuery!

        Although it seems kinda pointless when a mature framework can take care of it for you…

    • George

      Well, I would do it so it’s custom enough to not impede me. Also, I would definitely connect the backend into my design since most of front end actions affect the back end in some way. With angular JS, you type Hello World in the text box, the H1 tag gets exactly what I type, which is great, but what happens in the back end? From my understanding, web apps are supposed to be intelligent JS applications that manipulate backend data with V a minimal footprint. Where’s the ease of use when you have to save your data to the backend? You still have to write out lines and lines of code to accomplish this with angularjs. Or am I way off? Can any angular expert please explain this to me? Keep it simple please.

      • Bojan Matić

        IMO the best way to use angular is to design your backend as an API that clients can use and view your angular application as the first of many such clients (even though it might be the only one).

        That most often means the backend is just a glorified database exposed through a REST-ful API.

  • ismael

    People from HN don’t know both to understand this is not a parody.

    I have developed with jQuery and now with AngularJs and I can say angularjs is nightmare do build non-usual-forms. It is pretty good for hello world demostrations.

    jQuery is enough as a dom manipulator and angularjs as a framework can’t do his job.

    A datepicker is a hell to build one while jQuery one line and config you have it.
    DOM manipulation is tricky mixed with jQuery while in the doc it is said you should try to develop without jQuery.
    Validation is pretty shit, the way you need to achieve this is with tons of lines of code.

    There are some work around like angular-strap (wrapper for bootstrap), but still I don’t like it.

    Angular for me is good to develop minor-component, but in level os Single Page App it is a hell.

    • dmackerman

      Again, you’re talking about a widget (datepicker). Angular is an application framework. It helps structure your Javascript code so it’s manageable and TESTABLE. Let’s see some of your application code you’ve written in jQuery, and compare it to the same code written with Angular.

      • I think we’re seeing the clear divide between people who make things, and people who use things.

        I wonder if I can use jQuery to magically build me an application, because you know, it may only take one line? $.createApplication(“this is my idea”).gotoUnicornLand();

        • FailPolice

          Way to simplify the groups of people.

          People who use Angular == smart, educated, fine gentlemen, experienced engineers
          People who don’t use Angular == dumb, ignorant, philistines, newbies

          If I read your bible and tithe to your church, will my soul be saved?

        • George

          I’m pretty sure you can extend a plugin to help you get to unicorn land. That’s another reason I love jQuery.

    • SpongerobertoSquarepantalones

      Then use jQuery to build a datepicker directive for Angular.

  • Probably you don’t understand the difference between a framework (Angular.js) and a library (jQuery).

    And Angular.js is pretty cool.

    • FailPolice

      Do you need Angular to do all of these things?

      • Nope in my opinion, is this a reason to not use the good parts?

        • FailPolice

          There are many excellent libraries out there that allow you to pick and choose the good parts and leave out the bad, or bloated, parts.

          • I’m interested, can you mention some so I can check?

          • FailPolice

            A stack that I like and can vouch for is:

            * node.js for the app server
            * browserify (commonjs for the front end)
            * backbone (I have a single app object which keeps the data & events in one place)
            * a reactive programming library (I use backbone-signal)
            * Handlebars
            * jasmine (with black box testing. I also use jasmine-flow to facilitate edge case testing)

            The main thing tying it all together the structure is browserify. What is nice is the final javascript download can remain small because commonjs modules greatly alleviate the concern of application structure, since you follow a module directory structure. This allows me to pull in snippets of javascript from the web, or the good parts of libraries, while maintaining structural integrity.

            I have a custom two way binding implementation that is < 50 LoC since my current app doesn't need much in that regard and my views have refresh methods which listen to updates changes in the signals.

            However, there's rivets.js, if you want a standalone library, or knockout, if you are good with a light-weight framework.

            With this stack, I built a light-weight, & relatively transparent, framework that is specific to the application and based off of obvious conventions and some common function calls accessible through commonjs modules.

            Since I'm using node.js on the front and back end, I'm can easily share code between the two systems. It's nice, especially for caching.

          • Well, for code organization I prefer AMD, but none of this tools listed covers AngularJS good parts, double binding, dependency injection, directives…

            I usually use x-tag when I only need directives but it has not the power of AngularJS’ directives.

            I’ll take a look to rivets.js, looks interesting thanks 🙂

            I could implement dependency injection and simple directives, but I personally am against using my own implementations for my project, javascript lacks standarization and failing on [YAFS]( only makes the problem bigger.

          • FailPolice

            I prefer to use view objects bound to signals. It is straightforward and it scales with complexity.

            DI is a simple pattern of passing arguments to functions. You hardly need a framework for that.

            Directives are a need that arise from needing to scale angular’s patten of putting logic in the html. I believe rivets covers that. I prefer not to put logic in my views.

            I understand the fear of making yet another framework. However, frameworks are often a simple set of patterns and function calls you use on the project. It’s easy, and quick, to make a good, simple, framework and it feels great to work with code you enjoy. Most of the time is spent on selecting the right patterns to use.

            Even in the angular community, people layer their own frameworks on top. Same happens in rails.

          • I agree signaling is a good solution but I think double binding is better, it scales as well, in fact in my experience a lot better; and it’s more DRY. Maybe if you work alone or have the luck to find and hire only good JS developers you can maintain a signaling system, but as you usually have to work with juniors or non-javascript programmers I prefer the options than request less effort from the developers.

            DI in angular is implemented as passing arguments to a function, but DI can be implemented in many ways, in fact DI is a method where a module requests objects who implement it’s dependencies interfaces to a centralized system (the DI container) without knowing anything about it’s real implementation. This looks dumb until you unit test and follow SOLID.

            Directives are a need I had at Backbone, Backbone encourages you to write as much logic as you can on the “View” (who works like a controller) and leave the HTML (the real view) clean. When I organize code I don’t want the logic to add a class or selecting an item on my controller, it’s view’s logic, in my controller I want only business logic. Directives have two utilities in my opinion, make it possible and easy to add view-logic to the HTML without touching the controller and to apply DRY to the HTML.

            I think most of the time is spent maintaing code and I want to maintain my app’s code, not the code than makes my app’s code work. So if I have a mediocre solution maintained by others and a perfect-fit solution I have to maintain I prefer the first option.

            I like the community to create more tools on top of Angular, what I don’t like is to spend valuable effort and time from good programers to reinvent the wheel while we need more people making Javascript move forward.

            BTW: English is not my mother language, sorry if I mess up 😉

          • Just to make an example, I’m building an app than must send every key the user sends to a bash instance, and you know what? there is no standard way to detect keys in user’s language 😀

            Not `event.which`, not `event.charCode`, not `event.keyCode`, not even `event.keyIdentifier`. I had to create an input and listen to `keyup` to make sure the input has the new character and get the character from the input and detect when a special key is pressed as ESCAPE, BACKSPACE, HOME… by it’s key code but as it’s `keyup` if the user presses many keys I don’t know it until the user releases one.

            We have lots and lots of MVC and we haven’t a well standarized keyboard control?

          • Guest

            I guess we have to agree to disagree with Signals vs two way binding. I find signals more scalable and flexible, since signals are composable, while two way binding is not. I find signals as being pretty DRY. Maybe you can explain how two way binding is DRYer? I’m not seeing it right now.

            I don’t really use unit tests anymore. I favor black box testing, as it is refactor-proof. I know my system works when my tests pass. With unit tests, mocks, etc, you don’t know. So, again, why do I need a framework to implement DI? It always seems like a holdover from the Spring days when DI was implemented using xml config files.

            Directives are *not* a need in backbone. I have shared logic using commonjs modules (using browserify). It’s lightweight and great.

            I havn’t spent any time updating my framework logic in months now. It took less than a week to get all of the pieces in. The framework I created is lightweight and scales very nicely. In fact it will scale in complexity better than if I were using Angular.

          • I though reasons why double binding is more dry were obvious:

            Double binding:
            {{ }}
            {{ }}

            {{ }}
            {{ }}
            user.on(“change”, myView.render);
            foo.on(“change”, myView.render);

            Now in both cases if I change I’ll have the change reflected in the view. Since signaling requires more code it is less DRY as I add models to the view. Why do you say double binding is not composable?

            I’m sorry for keep using the term “Unit test”, my fault, I mean testing. I don’t like to mock every component’s dependency it takes so much effort to develop and maintain to really not test compoents intercomunication. But to mock some concrete dependencies can make my test a lot more simpler. For example I always mock timeouts, intervals, ajax, events, and any type of asynchrony from my test, the code than implements the asyncrony is not on my code and when my tests are synchronous they execute a lot faster and are simpler to develop and maintain. Also I mock third parties and dependencies when they are from another business layer and yes, DI makes it simpler in this case.

            And more important DI is not only about testing, it’s part of my SOLID test, if a component is adding complexity throught DI it’s usually because it’s coupled. And finally, you can’t compare Spring days DI (In my case WindsorContainer) with Angular’s DI, I think Angular’s DI is a vague approach but WindsorContainer was a huge moster. I think we can think a little bit about it and find a good place between.

            I’m not saying directives were a need on Backbone I said they were a need *I* had, you’re free to disagree. Anyway I don’t see why are you mentioning shared logic and browserify here, I have nothing against browserify and shared logic is part of a developer’s job, doesn’t matter if it’s done using CommonJS, AMD or plain javascript. But we were talking about directives, weren’t we?

            As I told you on the last comment, it’s not about developing time or adding features, it’s maintaining time what bit by bit takes your time and focus. One thing is true, the tool than fits better to a developer is a tool he made himself, but we can’t keep reinventing the wheel.

          • FailPolice

            Btw, I forgot to mention that the codebase is also phonegapped to support all mobile platforms. Mobile apps should be small and mobile web should have a small download size.

            Re: developer time. Using a custom, lightweight framework saves time. Using a heavy framework has a cost throughout the entire lifecycle of the project. This is in debugging, testing, understanding, upgrading, etc. I prefer straightforward & iterative solutions because they are maintainable, understandable, fast, more flexible, and more future-proof.

            Re: double binding vs signals, the problem being solved is slightly different. Double binding is a view concept which adds sugar to reduce logic to bind to the view. Signals are a data model pattern based on reactive programming ( In my project, I use a single app model which contains all of the public signals.

            I prefer to have a refresh method instead, so the entire view does not need to be rerendered. I don’t have a good library at the moment to do this binding from the view. I took a look at ember for something to extract, but it seemed not worth it. Until a lightweight library emerges, this is a disadvantage. I think rivets.js is too heavyweight for the app. The refresh logic takes a small percentage of the codebase and I havn’t been burned enough to be motivated to seriously try to add better double binding.

            I also fake/mock/stub external systems, which includes time. Since my testing is black box, my code does not need to be architected to be “testable”. I’m used to architecting on the fly so I don’t need the overhead of having tests provide design feedback.

            I mentioned commonjs as a tool to building highly scalable applications in a simple manner. Commonjs meets the needs that you used directives to meet in a simpler way. Commonjs is also a more flexible tool.

            Commonjs and AMD are different as well. Commonjs & browserify is a build-time tool. AMD is a run-time tool. Commonjs & browserify has less overhead in the runtime and smaller file sizes.

          • Well, we found a possible reason why we don’t agree, I have to do one application for mobile and one for desktop web since they are heavy RIAs Gmail-like and I’m talking about destop web.

            I disagree, in my experience every time I or other developers say “I can implement that” we waste more time than learning the right way to use the tool.

            As I said I think angular best features are double binding and directives, obviously this makes no sense on backend.

            If you say double binding is sugar you can also say C is sugar for Assembler. For me it’s about not repeating my intentions, when I add a value to my templates I don’t have to say in the code “when this changes update the view” it’s implicit.

            Angular composes the view using ng-scope, when a binded value change it does not render the entire view but the component’s. I think it’s not about pain, but about productivity, since I use doble binding I can prototype any idea I have in one hour. In fact I tried once to implement the same project with backbone and Angular and in angular it took me 10 hours, on Backbone I quit after 2 weeks (~60 hours) with the project not finished. I can create a alternative, test if I like it and continue my job in the same day. My main project is a huge RIA but I don’t have performance problems yet and I won’t solve them until I have them. “Premature optimization is the root of all evil”.

            I don’t know the terms POJF and DSL in this context 😛

            I don’t think to test feedback is a overhead, it saves time since bad design decisions tend to propagate through the app.

            I still don’t seeing how CommonJS compares to directives. I remember you I said directives help writing view-logic in the view and writing DRY HTML.

            I know CommonJS and AMD are different, but it does not matter which one we use, since we make little components and share logic. By the way, AMD is a run-tyme *and* build-time tool while browserify is a build-time only tool. I like AMD because I can code everywhere without a build step and when the project is ready I can ask RequireJS to build my project.

    • ismael

      Why would you want two-way data bind? Only use is for hello-world demo showing a text appearing while you type.

      • Build a real application, then come back here. I’ll wait.

        • Using AngularJS every day on a large real world application, we make heavy use of two way binding. It is excellent.

      • dmackerman

        Infinite uses, really. You no longer have to listen to the DOM. You let your data speak for itself. When data changes, you aren’t manually updating DOM nodes.

  • I bet you don’t even MVC, bro!

    • FailPolice

      Is MVC the end all be all, “bro”?

      • Do you ever tried to write a large application, “bro”?

        • FailPolice

          I have several times (probably longer than you have been programming as a professional). I love writing it according to my domain, not according to some framework infrastructure that will soon become passe. Ever need to maintain the large codebases for longer than a few months? Good luck on your next upgrade 😉

          • I had a hard laugh. Writing it according to your domain? how much, 100 lines of code?

            No, really.. hit us with a real application written by you.

          • FailPolice

            Well if I did, I would lose my anonymity. Hit us up with one of your apps 😉

          • Ok, I understand. You are just trolling around. Good luck.

          • FailPolice

            Um, nope, not trolling. Sorry my design concerns are flying over your head, as you seem like a junior level programmer. Maybe I’ll dump some work your way. Btw, you really should get your site (, no?) working. Good luck to your journey sir!

  • FailPolice

    Cue in the Angular fanbois come out of the woodworks to downvote any criticism over their precious framework, lolz!

    It’s a cultural war after all. Framework hegemony vs Library autonomy.

    • George

      That may be one of the factors here. I’m not a fan of frameworks because of their bulk and constraints. Check out this other article of mine:

      Other may be ok with bulk, and throw a bunch of “exceptions” in order to fix their laziness, like caching, etc. Not me. I’m ok with well written code that doesn’t come back to bite me later on.

      • FailPolice

        I commend your attention to detail and commitment to architectural integrity. Please continue, as the world benefits.

        Frameworks are useful, even to me, as they provide some useful architectural anecdotes based on other people’s experience, that can be applied to my projects.

      • Gary Bisaga

        Please don’t dismiss people with other views as lazy developers who don’t care how crappy their software is. I respect your opinions, and respectfully suggest you be teachable rather than considering everybody with a different view complete buffoons. Some of us have been around the block a few times too, you know.

        My experience suggests that “well written code that doesn’t come back to bite me later on” is rare when you don’t have structure to guide you. Much more common are poorly-thought out hacks of “non-intrusive javascript” that are impossible to debug by another programmer or yourself in six months. You may dismiss me as an idiot, and that’s your right, but I hope you do not.

    • vSkiper

      There is always cultural war out there. But it doesn’t mean you are you are on the winning side. 8-bit assembler does the real magic, everything else is just bells and whistles.

      • FailPolice

        I feel like I’m winning because I’m focused on building an innovative products and not on the latest framework hotness to build cookie cutter applications. I’m fast and I build maintainable code with appropriate architecture for the app. I have lots of experience scaling in complexity, user base, and automated testing.

        And I’m am *much* happier to be free from imposing frameworks telling me how I *should* solve the problem and their conformity inducing monocultures. I like making my own decision instead.

        Maybe the borg will win, but the borg won’t win over me 🙂

  • Colin E.

    jQuery might be right for you, if you are writing simple web pages with some dynamic behaviour. jQuery has it’s niche and works very well for that.

    But … for big, complex projects and apps with 1000s of lines of JavaScript, you sure as hell need more than jQuery!

    • 30+ modules, so glad we picked Angular > jQuery (not that jQuery was even an option).

    • George

      Well, the project we are working on deals with a lot of everything, actually. But, what we found works best for us was jQuery with custom code for data binding that comes from the backend. This means that the end user triggers an action (usually a click). With that click, we send an ajax call to be processed. Once processed, we return back a success value along with any elements that need updating in a json object. The success function finishes everything off by giving the end user feedback on the response from the server, if it was successful or not. I still have not found Angular to be useful in that manner.

      Here’s what I mean by that:

      The HTML:
      Click Me

      The JS (jQuery):
      $(document).on(‘click’,’.input’,function(e) {
      var $this = $(this);
      url: ‘/ajax-folder/ajax-file.php?action=’+$this.attr(‘data-action’),
      dataType: ‘JSON’,
      type: ‘POST’,
      data: $this.attr(‘data-data’),
      success: function (data) {
      for (_selector in data.htmls) {

      And the PHP:

      “#myoutput1” => “Some value to be returned in HTML
      “jsons” => array(
      “success” => true


      If Angular can accomplish this dynamic task in the same manner, I would love to see the code from the experts.

      I built it this way because it makes sense.
      1. User triggers
      2. JS sends ajax request to do action for backend data
      3. Backend processes (database and calculations) and returns values for the “view”
      4. JS interprets the code from backend into readable html.

      Why do I need to use the backend? Well, that’s where all our data is stored! This data needs to be used by other users to view. This way, there’s a safety net built in knowing that you won’t get a response until the data has been successfully saved!

      For this reason, not being able to find an angular way to solve this problem, I say it kinda sucks!

      Yes, I was told about local storage, etc… but how good local storage on my browser for my buddy who is also using this web app across the ocean?

      The benefit of what I had written above is that when you want to add a new function to the web app, all you have to do is 2 things. Create the trigger element on the front end with the right class name and its response counterpart, and add that functionality in the backend in the form of a PHP function.

      // HTML
      data-action=”functionanme” class=”input”
      // PHP
      function functioname() {}


  • vittoriozaccaria

    > front-end code was handed down to be integrated by back-end guys, and… well… everything broke. Why? The back-end guy knew only jQuery.

    Wat. Tell me a reason why a back-end dev should know about jQuery/Angularjs.

    • And also tell us why the incompetence of developers makes a framework bad.

  • It’s not about fanboys, it’s about to know the right tool for the right need. All your article makes me think you are following the law of instrument “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”

    What I get from your post is “Angular does nothing I can’t do with jQuery” and you know what? jQuery does nothing you can’t do with plain Javascript, a good craftsman knows where to use each tool and is not afraid of learning to use a new one.

    Yes, Angular Docs sucks, and in my humble opinion, Angular modules just add noise to the code and dependency injection could be a separated component, and directives could split on many smaller-simpler tools. But this doesn’t prevent me learning it and use it when it’s the tool than fits.

    Actually Angular uses jqlite or jQuery if it’s on the page but it limits it to where jQuery belongs, DOM manipulation, that is the directives.

    So don’t go blaming a tool just because you didn’t want to learn it, if you don’t want to learn it it’s ok. Angular provides some awesome utilities hidden inside a lot of noise, but this utilities worth it: double binding, html-js communication, directives…

    • FailPolice

      It sounds more like the author prefers a hammer over a power screwdriver to pound in a nail. The author did learn how to use the power screwdriver contraption, but it just did not seem quite as good as that hammer for that nail.

      Now that power screwdriver has some interesting facets to it. For example the rotational torque is a great approach for screws. Sometimes the screws are better off being screwed in with a hand screwdriver, sometimes with the power screwdriver.

      That’s the nice thing about tools. You can learn the properties of each one and use what is appropriate to the task at hand.

      • PaulBrickell

        When you only know how to use a hammer, everything looks like a nail.

  • When you use AngularJS, you’re not writing JavaScript anymore, you’re writing Angular. If you’ve ever met a lot of enterprise Java developers, you realise they don’t really talk Java, they talk whatever framework they use. Frameworks are supposed to be exactly that: A starting point to build your product. You shouldn’t have to start thinking in the frameworks style of things, you should be able read one page of documentation and away you go, checking the API if you have issues. That’s what it’s like with a lot of other JavaScript MVCs.

    What framework defenders forget to acknowledge a lot of the time is that beginners feedback is the most important to making their product truly succeed. Once you’ve learned the framework you’ll never recover that initial feeling of being a beginner and you won’t remember what tripped you up. So don’t attack peoples feedback thinking they’re just stupid and don’t see the light.

    My only criticism here is that JQuery is indeed a library, not a framework and the author should have used some other frameworks for comparison instead. Building single-page web applications that use routing with just JQuery is certainly a lot more work than learning a framework.

    • FailPolice

      I consider Backbone a library, not a framework. You can also easily build your own framework from existing libraries. It’s really fun, rewarding, and leads to more maintainable code, especially for larger projects.

  • This post reminds me of the days when most of my colleagues were coding web sites in PHP with very little organizational strategies and loving it, and I was trying to convince them why a more organized web development framework written in Ruby would be better. They didn’t see the value because they were too close to the problem to see that their cowboy coding ultimately resulted in a lot more work and complexity.

    It’s true that AngularJS has a slightly higher learning curve, but I think you’re also taking for granted your current familiarity with JQuery and not understanding that the tools offer a different level of abstraction. You might be able to dig a small ditch faster with a shovel, but if you take a little time to learn how to operate the bulldozer, it will ultimately allow you to accomplish things that you never could with that shovel.

    • Gary Bisaga

      I think our friend needs a little more real-world experience too. The first ten sites and apps I built, I probably would have said something similar. Thirty years later and having used every major framework and language out there, I look at things a bit differently.

      • FailPolice

        Maybe you havn’t learned much after 30 years. Why not honor your preferences instead of letting other people tell you what to do?

        The OP has a legitimate reason to follow his path. Why are you so threatened that you have to attack him as being an immature developer. Does that reflect 30 years of maturity on your end?

        • Gary Bisaga

          If I didn’t say that he can follow his own path, then I should have. Whatever works for somebody is great. I *would* say that I suspect I wouldn’t like to be on the team who has to maintain his code, but he can do whatever he wants. Freedom is great.

          I don’t think what I said is an attack, but you’re probably right that I am making an assumption. This is based on what he says: anybody who rails against the laziness of other programmers hasn’t seen many of them. The fact is – and I’ve seen a LOT of programmers – that most programmers want to do a good job, and are pretty smart, but I believe that lack of structure severely handicaps them.

          • FailPolice

            I think people (at least the engineers with promise) gravitate toward structure. My experience with junior level team members, who have good intentions (not lazy) and strong personalities, is they will adopt and blindly follow the prescription of the framework’s mindset.

            They are in the Shu phase of Shu Ha Ri.

            I prefer to work with senior level developers who can make distinctions because I’m not a conformist and I like to maximize the effectiveness of the architecture, which sometimes leads off the beaten path. I prefer to avoid locking horns over these sort of issues and to build innovative products. Sometimes the right structure is to have code ownership so people can be autonomous.

            I agree that the OP would be better served to lose his generalized judgement over others, and I think this judgement attracts judgement in the other direction.

          • Gary Bisaga

            FP, I find a lot to respect in what you say. And our goals are totally the same, whether it’s good products for the end users, good environments for developers, etc. However, my experience is slightly different than yours, and perhaps this leads to the difference in our viewpoints.

            My experience with junior developers is that they do NOT blindly follow the framework’s mindset, at least after the first six months. My experience is that they are far more likely to assume that everybody before them is an idiot – I’ve had several junior devs tell me that precise thing, though not wording it quite so crassly, since I would fall into the “idiot” category – and, if they are at all smart, will go off and create their own better framework. They even do it a bit self-righteously, confident that they are making things better for the team and the world at large.

            And, all else being equal, their frameworks often do have some nice features, some things that leave me thinking “hey, that’s clever.” Unfortunately, they typically lose interest in them after a period of time and the others are left picking up the pieces, sans documentation, sans comprehensive unit test suites, but laden with features that completely violate the principle of least astonishment. I have been in that position far too many times, and don’t prefer to be there again or have people working with me be in that position.

          • FailPolice

            I think the best solution is to quarantine such junior developers and allow them to get it out of their system on their own project. Unfortunately, that is usually the Executive Management’s call in startups, and they often don’t have much product team experience, and they are thinking bottom-line most of the time, thus junior developers remain on the core product. I now make sure that my coworkers (Executive Management included) have a good head on their shoulders. It’s simply not worth the soul crushing to work with the wrong people.

            Re: frameworks, Rails was a heavily opinionated framework built conceived by a junior level DHH. It’s pre-v1 flaws still continue today. It also goes through destructive changes with each major version release.
            The fortunate thing is Angular does seem better designed than Rails, it just leads in a direction that I’d rather not take, plus the javascript ecosystem is more vast & rich than ruby’s ecosystem.

          • George

            Experience does something magical to a developer. It makes them realize that no matter what tools you use, it’s still conditionals and loops. Keeping things grounded (PHP vs Zend) will leave your world as opened as Minecraft will. Agreed with your management statement. If the “new guy” can express themselves better to management, they will usually win, even if they’re wrong.

          • George

            How can programmers be considered good programmers if they lack structure and self discipline? That’s something that frameworks will only keep you from learning, while, “cowboy coding”, if you’re smart, will teach you what to do and what not to do. I was recently involved in an interview where I asked the employer why he doesn’t prefer developers with framework experience? His words were pretty much, “Because you get trapped in a framework mindset, and can’t get out of it to save your life if that’s all you’re familiar with”. The employer dealt with framework developers until he had enough of them. Too many had too many differences, and so he started collecting pure PHP devs, and his company has been striving technologically ever since. It’s as real (not abstract) as it gets.

            Pretty much what FailPolice said.

          • Vance Feld

            Sounds like more of a symptom of limited experience than using a framework. I’ve used dozens of frameworks and can roll my own cowboy 3D game engine from scratch (like defining even the physics). If your framework is right for the job, why wouldn’t you use it?

          • Vance Feld

            Wait a minute. “How can they be good…if they lack structure and self discipline” implies that they are disciplined enough to organize their code in a specific thought out way. But you’re saying he’s only hiring people without framework experience. So, inevitably they have just created their own in-house framework (through “self discipline”) and they are getting really good at that. So when they move on to another company or task, they will suck by the very same definition.

          • George

            They didn’t “create a new framework” They used the tool that was already available. PHP itself is an amazing framework. JS is also an amazing framework. They’ve been around since the early stages of the browser, and they’re still around. Any abstract structure on top is simply unnecessary. I believe, as programmers, we don’t focus enough on architecture and too much on framework.

          • d00per

            I totally agree with what that guy said about being trapped with frameworks. “Programmers” nowadays are integrator. They merely understand the whole process behind the framework, they just try to connect bricks together with little knowledge of what’s really going on. Don’t start me with STUPID CSS templates and the like. I’ve met so many Tech Directors who justify their position by forcing a stupid template engine on people because it’s cool to save a few brackets. We all know that guy and he needs to die in a fire.
            I have worked with frameworks for many years and let me tell you that they bring so much headaches. Updating, migrating, maintaining, nothing beats raw code. It doesn’t mean you can’t have a custom framework! Hell! Someone has to program them don’t they? So for all you Angular JS programmer wannabees, have a bit more ambition and make your own sauce, then you can call yourself a programmer.

          • I don’t think frameworks will keep people from learning to write good structured code, inherently. I think, in fact, that a good framework or set of de-coupled components cobbled together to form a de-facto framework will support good OO design practices, but it requires discipline of the coder and not falling into the trap of “everyone who came before me is an idiot” that afflicts so many advanced-beginners. (if not all of us at that stage!) I agree with the Shu Ha Ri reference, and when I say advanced-beginners I’m referring to
            I’m probably still in the advanced beginner phase myself, but maybe I’m starting to overcome that by thinking about the software game through these broader perspectives. I’m not personally moved by this article because I think AngularJS, despite a few misgivings I have, addresses many of the frustrations I’ve encountered with JQuery; lack of conventions for application structure chiefly among them.

        • airtonix

          lol… “attack”, way to gaslight.

          • FailPolice

            lol. way to miss the nuance

    • Fred G. Vader

      “This post reminds me of the days when most of my colleagues were coding web sites in PHP with very little organizational strategies and loving it…”

      Boy do I identify with you here Carl. Sad to say this sums up the majority of my 18 year career. It amazes me how programmers love to code willy nilly with no structured approach and then complain 2 to 3 weeks later when it comes back to bite them in the ass. And of course I would try and point out that a bit of discipline and architecture would help avoid those issues but they just wouldn’t hear of it. It is so hard to find a good team of disciplined and organized coders to be a part of.

      • George

        Totally agree! So many “new guys” on the block just seem to depend on frameworks to direct them because they have no direction. It’s like swaddling a baby. It feels good to be swaddled, but you can’t crawl, or walk much. Instead, control your urges to write spaghetti code, and sit down and build your idea on paper. This is System Design 101! You should spend as much time planning a project as you do programming, and QA-ing. It’s a trimester process.

    • MyNewScreenName

      So what does Angular JS really offer that other frameworks/libraries don’t? I am hearing the following items over and over, let’s analyze them.

      – Double binding: on change listener for model and view, Backbone and jQuery already do that
      – Dependency injection: RequireJS already does it.
      – Directives: templating, Backbone and jQuery already do that.
      – Testing: Jasmine already does that.

      – Combining all of that into one blackbox: nobody else does that, good job Angular!

  • bluehat2k9

    Bro, do you even code?

  • You obviously don’t know what you are talking about, which is a shame. You should at least taste Angular before deciding to dislike it this much.

    • George

      I did taste it, and it’s great if you don’t have to interact with the backend. As soon as you do, angular becomes useless if you can already do it in jQuery. Most of the work I’m involved in with FED development deals with backend data. Check out my one response above, and explain to me how I don’t know what I’m talking about? Just because angularjs is great for front end only, doesn’t mean it’s great in real world applications for what I’m doing. So, for me, the statement stands. It kinda sucks!

  • I’m not sure if the author is trolling, or just uninformed. The article was hilarious, though. Are you really comparing jQuery, a library built for abstracting operations, to Angular.js, a framework for building rich single-page applications (SPA)? Angular literally /uses/ jQuery through `angular.element` (if available) for DOM manipulation. It’s only a part of what the framework provides. Do you know how Angular’s Directives, Controllers, Services, Dependency Injection, Testing, Promises, Router, etc work? I think it’s safe to say you don’t understand Angular.js at all. The claims you make in this article are ridiculous and make no sense. You’ve probably also never heard about Ember.js, Backbone.js, Knockout.js, or other frameworks for building SPA. Try building a medium-to-large single-page application using only jQuery. Have fun reinventing the wheel.

    Good and popular example of Ember.js in action – (+ includes jQuery)
    Another good example that uses Backbone.js – (+ includes jQuery)
    Here’s a list of apps built using Angular.js – (+ many include jQuery)

  • George

    I may be uninformed, or under-experienced when it comes to angular. I will attempt to create a sizable application in the next couple of months because the one I already built in jQuery works great! Need to move div and p elements around in order to please product business logic and design? No worries. “Reactive” elements are bound directly by IDs and moving them around on the page makes things so easy, as easy as cut and pasting the code.

    From what I’ve seen, even in the hello world sample, you define your app within an element structure, and if you need to move that code around later, you have to redefine it somewhere else. This is where it can get tricky. If I already have items inside that are dependent on that “app” and its model, I’m screwed because now I have to rewrite everything since my “app” scope has changed. And what do I do if I have other models dependent on that “app”? Do I just make apps everywhere? Wouldn’t that get heavy on initial load? What if a parent element also needs to be an app? In jQuery it really is as easy as copying my div’s or p’s or a’s into a new area of the page/app and I don’t have to change anything else. Not in JS, not in jQuery.

    And when I write code in jQuery, usually, it will be dependent on backend ajax calls. What I mean by that is, any change on the front end will have a reaction that needs to store or update data in the backend. For that, when I trigger events on the front end, I always trigger an ajax call to save data, AFTER WHICH I come back to the DOM to update my elements / view. How would angular be able to handle that any better? I’m not asking sarcastically, I’m asking for advice.

    Angular may be perfect for apps that you build one time and never have to touch again or don’t interact with backend that much, but for my requirements, it’s not something I’d use at the moment, simply because of the re-design difficulty factor and lack of flexibility.

    It will eventually come down to HOW you build the app, not in WHAT you built it that matters.

    And yes, I may be writing a layer on top of jQuery that resembles angular, but at least I’ll have full control of the new layer. I would know what it is because I built it to make sense for my needs.

    • FailPolice

      Haters will hate. The “lack of experience” comments is just a jibe to get you to conform. Use your brain, keep your options open, make the best decisions you can, & continuously improve your processes. That will be your advantage and make you stand out in the midst of experienced sheep.

      Frameworks, especially opinionated ones, involve an upgrade treadmill. So you will probably need to touch the Angular codebase as the Angular framework evolves, sometimes leading to lots of extra work and schisms with your existing architecture.

    • Gary Bisaga

      Will it be documented or tested as well as Angular is? Are you producing screencasts for the developers down the line who have to modify your code? I suggest it won’t be fun for the next programmer to come in. Now, if jQuery works for you, that’s great, and I say good luck with it. But I can say that I have seen a LOT of poorly-written, fragile code; most real apps are not single-person efforts but involve the efforts of many people trying to work together against contrary deadlines and priorities. I may not be as smart as you, but I know what I think will get a good, solid application built for users, and at this point I think Angular gives me a good structure to do exactly that.

      • FailPolice

        I bet you will also see lots of poorly-written, fragile code using Angular.js, written by poor developers. Just give it time. There are no silver bullets.

        • Gary Bisaga

          Of course you will. There’s no escaping that. But that’s not at all what we are talking about. We are talking about about poorly-written, poorly-documented, fragile frameworks.

        • George

          Check this please…

          No documentation needed since it’s so simple to use. You can learn how it works within 15 minutes. This is what I need. This is the needs of my app. If you can somehow magically make this happen in angular JS, and make it easier, I would love to see it! If not, angular js kinda sucks… still.

    • Fred G. Vader

      I would suggest reading this answer on stack overflow –

      Another good read is the “No jQuery Challenge” –

      Also statements such as this “Angular may be perfect for apps that you build one time and never have to touch again or don’t interact with backend that much…” are exactly why some of your readers label you as immature. Do you really think that Google employs and dedicates millions of dollars a year towards angular for apps that never have to be touched again or are “built one time”. Come on dude, I gather you’re smarter than that.

      You’re just struggling with a paradigm shift in your thinking and the way in which you approach problems and solve them. I’ve been there plenty of times myself throughout my career. Change sucks – I get that – but let go of what you know long enough to try and understand the angular approach and you’ll find yourself being more effective when using angular.

      If you really are going to try and write a sizable application using angular then I am really look forward to a follow-up post on your experience. Best of luck!

  • “Intuitive” is another word for “familiar”. It’s not always easy working with tools that are different from tools that are already familiar to you. However, learning multiple tools/libraries will ultimately make you a better developer if you understand the different design decisions behind each tool and acknowledge that everything is a tradeoff.

  • vSkiper

    Of course you can do anything by using 10 times more jQuery LOCs with no testing. Do not give up!!

  • adyba

    I remember old russian televisions have had a potentiometer that adjusted the distance between red, green and blue dots of the screen pixel. Awesome right? jQuery full control of the selectors + DOM manipulation is such potentiometer, but it doesn’t made the TVset any better.

  • d00per

    I will piss a lot of people off, but if you need angular to have a structure in your code, you are not a good programmer. If you need a framework to do your routing because you can’t do it by hand in mod_rewrite, you are not a good programmer. And if you are the type of guy who loves having 100 files with 1 line of code in it, just to save some brackets and have someone organizing your code for you, we can never be friends. AngularJS is just another framework trying to reinvent the JS wheel for people who can’t properly code APi’s based frameworks. AngularJS sucks balls and so do people loving it. It feels like we are back on Symphony, what a joke.

    • George

      You don’t piss me off at all… You’re right! Ah yes, Symphony… and Symphony 2… First day on the job with Symphony 2, tried to pass in cookie and session information. Failed! Can only do one or the other. Had to use basic PHP to overcome that. This is what I’m talking about frameworks having limitations! If you build it yourself, you have MUCH better understanding of what you’re doing, and the only limits are HD space and RAM.

      With jQuery, I use it as a shortcut tool for many of the things I would have done in JS. What’s funny is that I, as well as other developers at the time, were working on our own jQuery type library while jQuery was evolving. We ended up using jQuery because it was already built for us and met every one of our needs. jQuery saved us. Angular made things so complicated that at one point, we had 3 front end experts in angular try to explain angular js to a backend guy and why he broke the site when he tried to move elements around.

    • BraveEagle75

      Ugh, Symfony, talk about that pain in the ass! I agree with this response very much as I can write native code without the need for a library. I have done my share of coding with frameworks only because “one” developer evangelized the concept until their nose bled and we were forced into Symfony or AngularJS or Ruby On Rails.

      My personal conclusion was that:
      1) We wasted a lot of time teaching and learning a new way of doing things
      2) We most likely did it wrong
      3) We really didn’t have the time to learn new technology
      4) Developers were frustrated with lack of productivity
      5) Product was late

      Sure, pulling yourself and others out of their comfort zone can sometimes carry some great ingenuity and rewards but 90% of the time, you fail before you succeed. When you work in environments where you need to succeed first, having everyone dazed and confused trying to learn a new framework effects morale and breeds frustration. I would much rather utilize my development staff for their strongest abilities and not bury them in niche frameworks that make them uncomfortable. Trying to teach a team of tenured Javascript developers on using AngularJS is demeaning to their rockstar capabilities in the native language itself.

      Certainly, AngularJS evangelists will disagree and carry the same ego that Ruby on Rails community has, “You are doing it wrong if you don’t do it OUR way”

      • d00per

        Amen to that. Not to mention, all these frameworks aren’t perfect and have their share of bugs. Have more than one tech on top of each other and welcome to your nightmare.

  • Brdavs

    I agree with Carl completely. You should also (if you value your professional development) never show this post at a job interview. It will not bode well with seasoned programmers in any environment.
    Let me address each of your assessments:

    1. Angular hides DOM manipulation.
    That is the point of Angular. You are not supposed to manipulate your dom while implementing application logic. Angular is pretty good at this job. What you said was: pizza sucks, because it does not taste like a hamburger. Even if you put ground meat on it. Yes. That is the point of pizza.

    2. Horrible documentation
    You have a point there, but try to read documentation on any serious and professional tool. Not just programming. With great power comes great responsibility (and steep learning curve). Did you REALLY read the documentation? Failing to read and understand documentation does not make it non-existant.

    3. Intuitiveness
    Just wrong. Say if you were missing a leg and God would suddenly bestow one on you, you would have a hard time using it intuitively. Would you conclude, that having both legs was useless or stupid? By the way… OOP and what you gave as an example has nothing incomon. jQuery has a distinctly functional programming paradigm.

    4. Speed of development
    First small project will take 3x longer whan with jQuery. Next one will be 0.5 times. Not to mention if you actually build more than simple “mouseovers”.

    5. If it ain’t broken don’t fix it.
    While I agree 101% with this saying – it’s largely completely irellevant. jQuery and Angular do not have the same aim, paradigm or usage intent. You are comparing apples and oranges and you just concluded, that apples are much better, because you know nothing about fruits.

  • George

    Check out the post here:

    Let me know if any angular expert can duplicate that functionality exactly, and make it any easier?

  • Girls kinda suck.

    After attempting to look through Girlfriends for Dummies and examples at the pub, I’ve come to the conclusion that I’m much happier with masturbation, for the simple reason that I know how to do it and it does everything I’ve ever wanted.

  • Ngoni Mudzudzu

    I agree with you 110%. I have studied AngularJS and have come to the realization that JQuery does so much more. Also there is nothing wrong with DOM manipulation!

  • I recently left this comment elsewhere but it also applies here:

    Listen up aspiring programmers. Learn one language fairly well and you will also learn that it’s not the language you needed to learn…what you needed to learn was how to understand and write efficient code – how to re-use, re-factor and abstract – and while most languages switch up the syntax, these are universal skills across all languages. Learn a language as simple as VB or PHP and you will pick up other languages very quickly because programming logic was the actual barrier to entry, not the language itself.

    Some languages do however make the logic more difficult to understand than others, or obscure some of that logic behind a framework that does the heavy lifting. This can sometimes be a good thing, because as you refine your skills and your code, you will start to notice a mini-framework taking shape or mirroring some of the functions already provided by an existing framework. When you notice these similarities, you should start to understand by now whether using an existing framework would have been a good idea or not, and why someone decided to design that framework in the first place.

    Ignore the criticism about this language or framework vs that one, the arguments originate from those who have nothing better to produce than a debate. Try both, try them all, see what you prefer and don’t defend it like it’s your life blood…technology will continue to change and you’ll be jumping ship often or you’ll be going down with the first ship that sinks. Compare the real pros and cons, then apply that to your situation and be ready to try new things. Success is not about what you can theorize, it’s about what you can deliver, and that is your life blood.

    The true challenge comes with keeping your tangled spaghetti under control so the code can continue to scale…something frameworks attempt to help with, but you also have to be careful with frameworks that impose training wheels over the way your code and logic glue together because this will offer you less flexibility and incentive to try new things or discover why existing frameworks do what they do. For example, when you want a single page app that runs offline and delivers video game quality animation and interaction, MVC/angular/ember might not be the panacea you’re looking for. When you want to build the same old tried and true “web app” that many people have built before you, MVC has a proven track record. Adhere to the trends when necessary and don’t be afraid to break away from them. After all, frameworks were built by programmers like us who were attempting to solve architectural problems and prevent tangled spaghetti in their own solutions.

    Keep these things in mind because now’s the time to code, so go do it.

    • Slayerment

      A+. Would hire 🙂

  • Vance Feld

    Angular makes everything so easy. No need for jQuery. If you think you can’t do x,y,z in angular, you’re likely just doing it incorrectly which makes it appear more “complicated”.

    • George

      You’re probably right, which brings me to the “counter intuitive” factor. I’m doing it wrong because the framework itself is not set up to be easily used to do it right. So, it doesn’t suck all the way. It just, kinda sucks.

  • I have a big doubt about AngularJS and the rest of framework/library/whatever :
    What i do 99.9% of the time with javascript is ajax and dom manipulation. Do we really need a full framework to do ajax and dom manipulation?. In fact, i work with javascript mainly with “objects” (such grid, calendar) rather with programming in client side.Also, the information loaded come from server-side and usually is loaded directly in the html.

    IMHO, i don’t think that AngularJS is bad, it is just that we usually don’t need it. And, if we would need it then JQuery solves the problem.

  • BraveEagle75

    At the end, no matter what indirect layer of complexity we throw on top of native Javascript, we are simply manipulating the DOM, giving the user an interface to use and making AJAX calls, Javascript does what it does very well, even without these complex layers.

    AngularJS is by no means a “bulldozer”, Javascript is the bulldozer, AngularJS is an awkward interface for those who are bored with native Javascript. jQuery is a tool that helps you leverage the most important UI features of Javascript for the most common UI tasks, AngularJS creates it’s own arrogant world of how to interface with a web page, in a much more, complex and indirect manner.

    +1 for native Javascript, +1 for jQuery making the most common functionality more accessible, -500 for AngularJs which obfuscates and over-complicates simple tasks.

    I have worked with all libraries over 20 years and have the experience and discipline to choose the right tool for the job. I also have the knowledge and experience to test my code thoroughly (not Unit tests – that is a different sour topic). If the only argument to user AngularJs is to speculate that it “might” allow me to accomplish more than uhhh, DOM manipulation, user interaction and Ajax calls, the argument is lost and I choose to avoid AngularJS.

  • Fergal Moran

    One word, organisation.
    I see where you’re coming from but jquery doesn’t offer any guidance about organisation of code. Working on large projects for multiple customers you’re always going to be able to figure out the structure of an angular application quite easily. There are a bazillion different ways of organising jquery projects, so.. not so easy.

  • leha

    stupid child!


    You are spot on here! I have built an offline ERP that works on a browser (now top this complexity!!) with more than 100 screens with jQuery and it works fine. Any changes asked my client and business analysts are delivered within hours, not weeks. Performance wise its within the benchmarked limits. Readability is good enough, and more importantly didn’t have to interview or train folks in any framework since learning curve is pretty fast with jQuery.

    Since with Angular JS one already needs to have sort-of final blueprint of the app ready before you even start coding, it is next to impossible imagining an iterative approach of software development with Angular.

    I simply don’t understand this “2-way data binding is awesome” or “Angular isn’t suppose to do that” or “You don’t get Angular JS” lobby. How is that suppose to ensure smooth decoupling of view with a resource in service oriented architecture enabled with REST? Isn’t people not getting Angular JS but getting jQuery easily, a testament to its intuitiveness?

    While a framework approach will be better for a server side application where you don’t want two developers to do
    — transaction management
    — handle requests
    — handle threads
    — write facades, delegates, or views
    — integrate with other homogeneous systems like Database
    in their own way, so it makes sense to use a framework and impose those restrictions on the developer.

    But in a single-threaded and single-user client apps, why would you want to impose any kind of restriction on a developer? Unless, all these server-side architects are asked to do a client side app design and they simply can’t unlearn that junk they learnt during server-side architecture design without knowing why it was done!!!

  • YemSalat

    If you are making websites – 100% you don’t need Angular. But if you’re planning to build a semi-complex app – good luck using jQuery for that cause you’ll need it.
    Angular is not a “jQuery replacement” for thing like .hide()/.show()
    Its a completely different beast built for completely different purposes.

    Your lack of experience in web app development is probably the main reason you wrote this article.

  • franleplant

    There are a lot of things well said in this post about where Angular has made fundamental mistakes in which I agree, but comparing Angular js, a big old Framework with jquery, a simple library, is like comparing Apples and Oranges.

  • Rick O’Shea

    Angular is a declarative client-side MVC framework complete with dependency injection and sophisticated data binding. You’re comparing an apple orchard and processing facility with a slightly sour orange. There’s no rational comparison to be made with one exception: Angular can use jQuery but also replaces that simple DOM querying facility with a lighter but equally effective DOM query facility of its own.

  • Jaroslav Sivy

    Great article.
    Based on my experience, frameworks like angular give you something, but take away something.

    Reminded me experience with telerik controls (despite its framework for something else) – they are nice, easy to use and fast to develop. But when i had to implement something more complex that required to shape them like i wanted, it was a real pain. I was not in control how they did their thing and it was difficult to change them to work the way i needed.

    I like to be in control of every aspect of what my application does -to the lowest possible level, so i can step into any flow and shape it to my liking. What framework does – they make some things easier, but they hide the control and just give you lever to use.

    Its easy to throw gazzilions of frameworks into the mix, just because they just do something better, but the result is slow bloated application that could be much faster.

    I like to keep things as simple and as fast as possible. Another abstraction layer just takes away speed and control.

    Using basic tools is like matches – they can burn you, but can make you a fire. They may require more work, but at the end of the day – if used right, application maintenance is easier, code is easier to understand and code is not bloated with different syntaxes, templates and schemes from different frameworks.

    Also its easier to bring new people on the board, because basic tools (jquery) will be part of their workset.

    Simplicity, control and speed is my mantra, so i have to agree in every aspect with OKMaya.

    • toach

      I am not disagreeing with your philosophy but in this case, like the author, you are making an apple to oranges comparison.
      Telerik is not a development framework but a brand of pre-made controls to assist in rapid application development. And while there are tools like an ORM and a CMS none would really qualify as a proper framework.
      They do have a binding library similar to KnockoutJS within KendoUI which would be a closer comparison but I don’t get the sense that is what you are talking about here.

      A more apt comparison in this case would be MS MVC to Webforms.

      I don’t mean to nitpick but this post has sparked an ongoing discussion and I think clarity is important.

      • Jaroslav Sivy

        I was not comparing telerik controls to Angular framework. I was giving example of properties, that they share both and that i personally dont like. And yes, you can compare apples and oranges. They are comparable in some aspects :-).
        What i wanted to pinpoint is, that i prefer few universal tools that i can use for everything then dozens s in the mix.
        Also i was just noticed that Google’s OpenID 2.0 is going to become Oauth 2. Good luck with migration of something more complex in Angular (or other frameworks) if they won’t keep backward compatibility.

        • toach

          Well, apples and oranges are fruit so I guess you got me there. 🙂
          And I don’t disagree with your point or it’s validity in a discussion about angular.

          However based on the discussion on this blog, particularly the angular will fail post, there seems to be a lot of confusion about what angular actually is, why/when it would be used, and the difference between a library (jQuery) and a framework (angular).

          That is the only reason I replied at all.

          • Jaroslav Sivy

            Again, you are assuming, that am comparing framework (Angular) to library (jquery).
            I may wrote it wrong, because english is not my native language.
            What am saying is, that i dont like frameworks and i prefer to work with libraries directly.

            Main reason is, that i am in full control. I can do anything with that tool, and not just what framework allows me within its boundaries (size, performance, complexity or other).
            (and i hate when framework prevents me / or is difficult to do some things with it).

            I believe, that its better to build your own “framework” or i prefer term toolset for four reasons.
            #1. i built it, so i know it the best
            #2 i can amend and shape or even rewrite it easily, because of point #1
            #3 i am not “that” dependant on somebody elses interface
            (especially case when that somebody can change it)
            #4 I like evolution. I prefer when code evolves and not changes. I like Porsche because it changes with every version to get up to date with today.
            I dont like iexplorer, because its the opposite and look how it ended.
            Tools will allow you to evolve, but frameworks don’t.

            I dont care if people like to use this or that. its their preference.

            I like the code i code. 🙂

  • Matt Terry

    jQuery != Angular … they are built for completely different purposes, not sure why anyone would compare the two, comparing Angularjs, Emberjs and Backbonejs seems more logical

  • Robin Chalas

    compare AngularJS and jQuery is like compare an apple with an orange, or more simply : you compare a full frontend framework with a DOM manipulation library.

    AngularJS has services, controllers, and partial views.

    It’s not a simple animations library, it’s a new alternative to manipulate data from back-end in client side.

    An optimized framework for build scalable modules and directives for strong web app, manipulate data in JSON, everytime, everywhere in your app.

    jQuery is approved by all, i use it in all my projects.

    It’s the reason of why Angularjs contains jQlite, and it’s why compare them is a big error.
    Compare it with ReactJS, Backbone, Knockout make more sense.

  • I understand jQuery and don’t like learning +jQuery

  • Makis Spyratos

    Angular is for people who aren’t ui guys… Or Exactly the people who err shouldn’t be working on the ui… The java guys at financial institutions loooove it. Web guys hate it.

    I was hiring for the role of ui developer… Most of the angular people couldn’t even do basic string concatenation…. What a rabbit hole angular is… I personally use Canjs and jquery structure and magic and no mumbo jumbo

  • hhvdblom

    Less=More 🙂 Nowadays I see developers very busy on Client side coding. If Thats important then there is nothing wrong with that but if its lots of data-entry screens with no-need for fancy Client side forms I would say dont invest to much in these frameworks. jQuery is good because it offers cross-browser support. Dont over engineer.

  • Just wanted to chime in and say I agree completely. I’ve been researching AngularJS a bit lately because I’ve heard the hype and wanted to see what it was about. As usual, back to PHP/jQuery and actually building things real and making money. I really get the feeling that the people always jumping around from framework to framework loading in 20 different includes to do one simple task are the people who are new to development and following the orders of some startup higher-up who themselves doesn’t know what the hell they are talking about or how to make money. Would hire OP for not being a lemming and seeing through the BS.

  • What i don’t like about AngularJS is his performance. Personally, i don’t have problem with the performance of my code, even when im not optimized it. With Angular, performance should keeps in check. And it is what Angular starts to fail : if you use so much binding then it will hurt your performance. Then, Angular is Goldilocks, if you sub-use then its useless and if you over use then its slow.

    And yes, you can compare Apple with Oranges , i can made juice from both.

    Also, Data Binding its not REALLY USEFUL. Im more into Data Mapping -> Logic (UI Logic ) -> Send to Server Side, and its possible with plain JQuery.