I think the fact that the author is comparing angular with jquery as if they're two tools for doing the same thing probably illustrates a lack of understanding of what angular really is and what it's supposed to be for...
But it depends on the complexity and size of a project and how many developers are involved. I prefer frameworks too, but for a small WebApp, it is overkill to use frameworks like angular/backbone/whatever.
Angular's value proposition for the dev is that if you take time to learn its unusual idioms and opinions, it will pay off. Its a very opinionated framework which contains some concepts most web developers aren't terribly familiar with - e.g. dependency injection - but which promises increased control over managing complex interactions, and consequently faster development times.
Of course this means that for simple jobs jQuery may be better suited, unless you're trying to LEARN Angular, in which case it makes sense to struggle through trivial apps with complex tools until it clicks. None of this supports the article's thesis, of course, which is something akin to "I dont understand this, it must be lame!"
Well, I think Angular may be unintuitive for people having gotten used to the "jquery way" of thinking. But I think the jquery way of thinking is the problem here. For too long people have been doing direct DOM-manipulation, and fail to see how they can achieve what they want in a more declarative manner.
When I started using Angular I had really no experience with jquery or any other js framework, and I felt Angular was intuitive.
Data binding coupled with a declarative syntax isn't a "new thing", especially in the enterprise world, .NET and Java. It's an acquired taste and I never really felt comfortable with it. You can build some perverse architectural monstrosities on top of it. Of course that's true for every technology or framework, but I am of the opinion that many of frameworks that tout data binding / declarative syntax actively encourage going into this direction.
I'm somewhat surprised that it's so popular with the JS crowd right now.
There's a reason data binding is popular with the JS crowd, and it's the same reason it's been somewhat popular with the big enterprise crowd. When your application starts getting very complicated, such as the user changing an input field that is reflected in a bunch of dynamic calculations across the app, it becomes desirable to simply change one value and have everything update. This is only desirable if your application is big enough that it's not just easier to re-run every calculation manually.
Big enterprise has had this problem for a long time in their big multi window monster apps they use for stock trading, etc. JS webapps have been very simple for a long time and haven't really needed it until recently. Now that they're getting complex, JS devs are looking into how to solve the problem and it generally comes down to MVC OOP style or FP style. You can see these two derivatives in AnglularJS and ReactiveJS.
"Here’s an idea of pricing for you. I work on projects based on complexity. If you have 100 pages with simple text and images on it, the task is not complex. Just time consuming. So I consider that a complexity of 1, times 100 times. So, complexity is 100.
If you have one page with one complex interactive form, with a calculator, that grabs prices from out there on The Web, then it’s a one page design, but complexity of that one page is way high, depending on all of the features on it. Calculator, 2 points. Search 3 points. Connecting to databases and APIs, 5 points. You get the idea.
Both projects can be about 100 points. One more complex than the other, and one more pages than the other. And now for the prices:
$125 – $250 per point.
That’s it. Why the wide range? Depends on a lot of things. But, on average, I can do about 39 points in two weeks. Considering the overhead, taxes, etc, that comes to about $60-$120 per hour."
"Notice that we added a DOCTYPE to tell browsers what kind of document we have. We picked 4.01 Transitional because of its flexibility to allow deprecated elements, like <font>."
If you know PHP, you know that you shouldn't be doing it like that. He sounds like a novice. There's nothing wrong with that, but when looking at that kind of thing I would take an opinions as a grain of salt
It doesn't really matter what the language is, SQL injection vulnerabilities are serious in any language. A competent web developer understands that -- especially a "Programmer Extraordinaire".
I don't get it. What is this article even supposed to be about?
A big point about angular's tutorial is that it isn't really explicit enough is how everything links together. It's a lot easier to learn angular by taking some sort of class or going to some presentation, because the tutorial in its current form does not explain general architecture.
Another issue is a lot of people present angular as this sort of "oh hey, check out the data-binding stuff!" , when that is just a small part of the entire mechanism. Angular's big advantage is that it allows you to organize your javascript into nice little modules, and it gives you deterministic behavior about how these load (with the dependency resolution and whatnot).
To me this post boils down to "I already know jQuery, this isn't jQ, so WTF". Well, godspeed, you fancy bastard.
I wouldn't use Angular for a small'ih average website where you want some minor JS-based UI functionality. But I found Angular much more suited than jQuery for big sites that are maintained by more than just one developer. You can look at some piece of HTML and you can tell from the list of directives what's going on. No stray click handlers and whatnot.
One of my more recent clients had used jQuery for ~8 years, the HTML had changed a lot in that time and the JS had grown like a cancer due to developer fluctation and people just adding code to fix their current problems. Quite frankly, it was a mess. I believe that with a framework like Angular it wouldn't have gotten out of hand like this, mostly due to its modular approach to everything.
"I believe that with a framework like Angular it wouldn't have gotten out of hand like this,"
I disagree completely and in every possible way. This has been the hallmark of every new language/framework/coding philosophy/rant that has ever been made about coding in the last 30 years. And it's always wrong. It's wrong because it doesn't get the real issue:
Your code is bad because you have multiple untrained developers just adding code to fix their current problems. It doesn't matter which framework you use - just adding in some code to fix something over a number of years will destroy your code base. It will destroy your jquery codebase, it will destroy your angular codebase, and it will certainly destroy even your ML codebase.
I wish the coding community will one day wake up to this fact and realize it's not a technology problem, but I'm pretty sure in 10 years time I will read a post about how you need to switch your horrible old messy AngularJS app to XYZ which will fix all your problems.
"I'm pretty sure in 10 years time I will read a post about how you need to switch your horrible old messy AngularJS app to XYZ which will fix all your problems."
More likely given the rapidity of churn in the JavaScript world, in about 10 weeks.
> Your code is bad because you have multiple untrained developers just adding code to fix their current problems
Yes, definitely! That is the core problem. My point, the one I obviously failed making, is that it's easier for an untrained dev to just add a line or two to a codebase where everything looks the same due to a lack of clear boundaries (modules, classes, whathaveyou).
I had to sift through ~10k lines of JS code that had accumulated over
a span of several years. There was no modularity, no real clear-cut structure, which made everything hard to read, so noone really bothered—they just layered crap on top, done.
Having a JS thing called `HerpDerpCtrl` where you can tell from searching your HTML whether or not it is still in use would have made the job of cleaning up much easier. That's why I like frameworks, they provide a structure.
It won't solve the problem of having bad developers in your team, or a lack of meaningful code reviews, or missing tests, but I believe it'll make it harder for people to screw things up.
After seeing this said numerous times about a number of different frameworks, I still disagree. The universe will invent a better idiot and your framework guarantees will make it even more difficult because they will find ways to subvert them and/or add in different modules from other frameworks. So while it might make it harder for people to screw things up at first glance, it will probably mean that when you inherit the code in 10 years time, they've managed to blow AngularJS's whole foot off and you're left trying to reconstruct the whole thing using tweezers.
I have only one thing to say to the poor future maintainers of AngularJS apps in the future. Godspeed.
As a back end developer that tried Angular for a month or so, I completely agree with all the criticism of Angular he has. The documentation is terrible. There are no examples of how to architect something. Things are not intuitive in Angular.
I don't really know JQuery either, so I can't say he is right or wrong with that criticism but currently Angular seems to be hyped up a lot in my opinion. (Or am I just too spoiled by the decent development tools we have backend?)
"How do I “think in AngularJS” if I have a jQuery background?" was asked a while back on StackOverflow and is a fairly good read for anyone looking to pick up AngularJS after jQuery
Is this satire? Because it sure sounds like so. Angular and jQuery serve different purposes. If you want to create a modal or the like then go ahead and use jQuery. But when you're creating a complex frontend application you'll find that jQuery soon gets out of hand
I am not fond of AngularJS myself, but this article is plain BS. How can you even compare jQuery and Angular? It's like comparing tomato to a shoelace.
If you want to compare, compare it with something like Backbone.
News flash: every aspect of programming for the web ranges from "sucks as much as an open chest wound" to "kinda sucks". "Kinda sucks" is the best we're going to get for a while.
Secondarily, jQuery and angular.js don't serve the same use cases and are not directly comparable. Not all tools need to be general purpose. It's OK for a lathe to be a lathe, a drill press to be a drill press, a soldering iron to be a soldering iron. Complaining that a soldering iron makes a poor hammer just means you don't know how to use a soldering iron, it doesn't mean it's a poor tool.
What kind of spaghetti does this guy and his colleagues build where there is such strong back-end and front-end interdependency that the server-side code cares what the front-end is doing for DOM manipulation or client-side-MV* like this, I wonder.
Hmm, I don't know why he complains. JQuery is a library, of course it does certain stuff better than a framework, you need to learn framework to make it works, same thing apply to any framework.
It is a fairly ridiculous argument. Look at it this way, would you rather be thrown into a large project that had been built entirely using jQuery or one that had been meticulously structured with a framework. Yes, the latter might be harder to pick up initially but the benefits will be felt later on when new features are added or something breaks.
I agree the documentation does suck. But there are several good books out now that explain things well.
Get a book, read it, understand it, spend some time working with it. Then compare Angular to JQuery, I bet a lot of your 'its complicated' complains will have disappeared..
wrong, i have read all google result page searching for solutions for angular and i'm still don't know how to build a proper directive or how to understand the life cycle of the application.
Besides the wrong comparison with jQuery and AngularJs I have to say angularjs is horrible to build Single Page Applications.
jQuery have enough third party lib to solve most problems.
I have done 2 big application and I'm still convincing my boss that angularjs must be deprecated immediately.
Directives and Services have too much workaround to solve the problems we already have defeated and they cast the spell to bring the undead back.
Problems I see:
* fast development
* easy way to build reusable components (see AngularStrap source code)
* few lines of code with real problems (like a huge form)
* form validations
* testing is pretty crap to do, a new born framework (karma) is already obsolete.
* to much problem with $scope needed to workaround with setTimeout(fn, 0)
Features is does have:
* build a quick to do list
* build a quick hello world sample
I'm not totally sold on Angular yet, but these points are ridiculous and jQuery has very little relevance in deciding on whether Angluar is good or not.
I made the mistake of looking at another post:
http://okmaya.com/clean-php/clean-php-step-10/
Separating business logic, data models, and views.. yeah I bet that kinda sucks too huh? The author has clearly not worked on large scale software projects where a framework like Angular could pay big dividends in structure and testing.
I have a feeling that these declarative-style js frameworks are really meant for programmers used to server-side PHP or Rails programming. Manipulating the DOM directly is foreign to them, because all they know is printing html.
First off, this article is 4 months old.
Second, <everything else that's mentioned here>
Third: You won't get the actual idea behind Angular without some good tutorials indeed.
This one gave me the best insight and i've been churning out my own angular based chrome extension with behaviors, services and modules within a week.
Fourth: There's a new book in progress (with some free chapters) that explains how to build Angular.js from scratch and explains everything in-depth (Something that was indeed lackin from angular.
Anything that forces users to have javascript on sucks, by definition.
It's exactly the same as the all-flash or flash-heavy sites of the early 2000s and I can't wait until javascript-only sites are consigned to the same dustbin of "why did we ever think this was a good idea?".
That may be true if your site is an article repository (blog, news etc) where the primary purpose is consuming text. If I'm on your site to read, then I certainly don't want to be "interacting" with the page.
But the browser is the new OS, complex applications are written for the web as a platform/runtime and this is not a bad thing. This is where Angular can help. It's not built to help you show/hide a few dom elements, it there to give you a powerful structure for developing web applications.
Let me tell you what was I thinking when I finished reading your post. I came up with a little story to demonstrate my opinion about it: So you grab your fine apple juice which you drink every day. The sourness pampers your palates. Then someone comes and gives you a pomegranate. He says "This is the finest fruit I've eaten so far!". You take a bite out of it and spit it out saying "This is awful! Apple juice is much better! Quit bothering me with your stupid ideas!". The guy leaves with an uneasy expression on his face while you drop the pomegranate and never eat it again. Unluckily you never learn how savory the pomegranate is.
So first no one should tell you that Angular is better than jQuery since they have different purposes. Angular is an MVW framework while jQuery is a javascipt library. Another thing is you think something sucks back it up with data. I see no concrete examples just some guesswork. And lastly: I can bet that if you try to read through SICP you'll say that LISP is crap and useless because it does not look like jQuery. If you don't take the time to understand something properly you'll never learn anything new. The world is full of diverse programming languages/libraries which simply don't compare to each other.
65 comments
[ 0.26 ms ] story [ 127 ms ] thread"Get the job done" got replaced with "its cool to use xyz".
Each time I've thought 'there has to be more to do than that'.
If I were doing JQueries - there would be an entire stack of event driven DOM updates still to code.
But it depends on the complexity and size of a project and how many developers are involved. I prefer frameworks too, but for a small WebApp, it is overkill to use frameworks like angular/backbone/whatever.
Of course this means that for simple jobs jQuery may be better suited, unless you're trying to LEARN Angular, in which case it makes sense to struggle through trivial apps with complex tools until it clicks. None of this supports the article's thesis, of course, which is something akin to "I dont understand this, it must be lame!"
Which is funny because it started out as a way for web desginers (not developers) to learn how to write apps.
This is an apples to oranges comparison.
Well done.
When I started using Angular I had really no experience with jquery or any other js framework, and I felt Angular was intuitive.
I'm somewhat surprised that it's so popular with the JS crowd right now.
Big enterprise has had this problem for a long time in their big multi window monster apps they use for stock trading, etc. JS webapps have been very simple for a long time and haven't really needed it until recently. Now that they're getting complex, JS devs are looking into how to solve the problem and it generally comes down to MVC OOP style or FP style. You can see these two derivatives in AnglularJS and ReactiveJS.
If you have one page with one complex interactive form, with a calculator, that grabs prices from out there on The Web, then it’s a one page design, but complexity of that one page is way high, depending on all of the features on it. Calculator, 2 points. Search 3 points. Connecting to databases and APIs, 5 points. You get the idea.
Both projects can be about 100 points. One more complex than the other, and one more pages than the other. And now for the prices:
$125 – $250 per point.
That’s it. Why the wide range? Depends on a lot of things. But, on average, I can do about 39 points in two weeks. Considering the overhead, taxes, etc, that comes to about $60-$120 per hour."
If you know PHP, you know that you shouldn't be doing it like that. He sounds like a novice. There's nothing wrong with that, but when looking at that kind of thing I would take an opinions as a grain of salt
A big point about angular's tutorial is that it isn't really explicit enough is how everything links together. It's a lot easier to learn angular by taking some sort of class or going to some presentation, because the tutorial in its current form does not explain general architecture.
Another issue is a lot of people present angular as this sort of "oh hey, check out the data-binding stuff!" , when that is just a small part of the entire mechanism. Angular's big advantage is that it allows you to organize your javascript into nice little modules, and it gives you deterministic behavior about how these load (with the dependency resolution and whatnot).
I wouldn't use Angular for a small'ih average website where you want some minor JS-based UI functionality. But I found Angular much more suited than jQuery for big sites that are maintained by more than just one developer. You can look at some piece of HTML and you can tell from the list of directives what's going on. No stray click handlers and whatnot.
One of my more recent clients had used jQuery for ~8 years, the HTML had changed a lot in that time and the JS had grown like a cancer due to developer fluctation and people just adding code to fix their current problems. Quite frankly, it was a mess. I believe that with a framework like Angular it wouldn't have gotten out of hand like this, mostly due to its modular approach to everything.
I think the distinction is more nuanced, Angular isn't intended for producing web sites, so much as web applications.
I disagree completely and in every possible way. This has been the hallmark of every new language/framework/coding philosophy/rant that has ever been made about coding in the last 30 years. And it's always wrong. It's wrong because it doesn't get the real issue:
Your code is bad because you have multiple untrained developers just adding code to fix their current problems. It doesn't matter which framework you use - just adding in some code to fix something over a number of years will destroy your code base. It will destroy your jquery codebase, it will destroy your angular codebase, and it will certainly destroy even your ML codebase.
I wish the coding community will one day wake up to this fact and realize it's not a technology problem, but I'm pretty sure in 10 years time I will read a post about how you need to switch your horrible old messy AngularJS app to XYZ which will fix all your problems.
More likely given the rapidity of churn in the JavaScript world, in about 10 weeks.
Yes, definitely! That is the core problem. My point, the one I obviously failed making, is that it's easier for an untrained dev to just add a line or two to a codebase where everything looks the same due to a lack of clear boundaries (modules, classes, whathaveyou).
I had to sift through ~10k lines of JS code that had accumulated over a span of several years. There was no modularity, no real clear-cut structure, which made everything hard to read, so noone really bothered—they just layered crap on top, done.
Having a JS thing called `HerpDerpCtrl` where you can tell from searching your HTML whether or not it is still in use would have made the job of cleaning up much easier. That's why I like frameworks, they provide a structure.
It won't solve the problem of having bad developers in your team, or a lack of meaningful code reviews, or missing tests, but I believe it'll make it harder for people to screw things up.
I have only one thing to say to the poor future maintainers of AngularJS apps in the future. Godspeed.
I don't really know JQuery either, so I can't say he is right or wrong with that criticism but currently Angular seems to be hyped up a lot in my opinion. (Or am I just too spoiled by the decent development tools we have backend?)
http://stackoverflow.com/questions/14994391/how-do-i-think-i...
If you want to compare, compare it with something like Backbone.
Secondarily, jQuery and angular.js don't serve the same use cases and are not directly comparable. Not all tools need to be general purpose. It's OK for a lathe to be a lathe, a drill press to be a drill press, a soldering iron to be a soldering iron. Complaining that a soldering iron makes a poor hammer just means you don't know how to use a soldering iron, it doesn't mean it's a poor tool.
What kind of spaghetti does this guy and his colleagues build where there is such strong back-end and front-end interdependency that the server-side code cares what the front-end is doing for DOM manipulation or client-side-MV* like this, I wonder.
Get a book, read it, understand it, spend some time working with it. Then compare Angular to JQuery, I bet a lot of your 'its complicated' complains will have disappeared..
jQuery have enough third party lib to solve most problems.
I have done 2 big application and I'm still convincing my boss that angularjs must be deprecated immediately.
Directives and Services have too much workaround to solve the problems we already have defeated and they cast the spell to bring the undead back.
Problems I see:
* fast development * easy way to build reusable components (see AngularStrap source code) * few lines of code with real problems (like a huge form) * form validations * testing is pretty crap to do, a new born framework (karma) is already obsolete. * to much problem with $scope needed to workaround with setTimeout(fn, 0)
Features is does have:
* build a quick to do list * build a quick hello world sample
I made the mistake of looking at another post: http://okmaya.com/clean-php/clean-php-step-10/ Separating business logic, data models, and views.. yeah I bet that kinda sucks too huh? The author has clearly not worked on large scale software projects where a framework like Angular could pay big dividends in structure and testing.
Third: You won't get the actual idea behind Angular without some good tutorials indeed. This one gave me the best insight and i've been churning out my own angular based chrome extension with behaviors, services and modules within a week.
http://www.ng-newsletter.com/posts/chrome-apps-on-angular.ht...
Fourth: There's a new book in progress (with some free chapters) that explains how to build Angular.js from scratch and explains everything in-depth (Something that was indeed lackin from angular.
Site: http://teropa.info/build-your-own-angular/
Sample: http://teropa.info/build-your-own-angular/build_your_own_ang...
It's exactly the same as the all-flash or flash-heavy sites of the early 2000s and I can't wait until javascript-only sites are consigned to the same dustbin of "why did we ever think this was a good idea?".
Edit: It also breaks search engine indexing.
http://webaim.org/techniques/css/
http://motherfuckingwebsite.com/
But the browser is the new OS, complex applications are written for the web as a platform/runtime and this is not a bad thing. This is where Angular can help. It's not built to help you show/hide a few dom elements, it there to give you a powerful structure for developing web applications.
So first no one should tell you that Angular is better than jQuery since they have different purposes. Angular is an MVW framework while jQuery is a javascipt library. Another thing is you think something sucks back it up with data. I see no concrete examples just some guesswork. And lastly: I can bet that if you try to read through SICP you'll say that LISP is crap and useless because it does not look like jQuery. If you don't take the time to understand something properly you'll never learn anything new. The world is full of diverse programming languages/libraries which simply don't compare to each other.