> I think the fact that the Angular community has made real progress towards divorcing themselves from jQuery is one of the most encouraging signs for their future. The design of Angular is just different enough, and it is just compelling enough, that it has convinced a whole range of developers to build a new generation of libraries that I suspect are more likely to be suited to whatever the next iteration of the web as a platform will look like.
This part bothered me a bit. The article doesn't make the case for why jQuery needs replacing or why all that duplicate effort is a good thing. Don't get me wrong: I'm not married to jQuery and I'm open to the idea of there being a better way.
I just don't find the idea that we have to move away from jQuery that self-evident.
As I've gotten comfortable with it, I've come around to seeing it their way. I'll never write jQuery-selector spaghetti code again if I can avoid it. Here's my favorite SO question on the topic: http://stackoverflow.com/questions/14994391/how-do-i-think-i...
I don't understand. I mean, Angular doesn't seem any more "declarative" than the Behavior.js you could write 7 or 8 years ago.
And jQuery made setup a bit different, but you could easily still keep doing the same thing with declarative decoration.
When talking about directives (specifically) Angular doesn't appear (to me) to really offer anything new outside of some questionable conventions for structure.
I think that there are always arguments made like this with any language/framework and the endgame comes down to where there is a use case there is a will.
I recently participated in do a full webapp conversion from jquery to angular. One driver was a realization that jquery and related tools filled quite a bit of bulk in the platform(cutting them out the minified js ended up being 1/5th the original size).
Another was a conscious decision to rebuild API first and angular provided a unique ability to very cleanly abstract a View/Service/Server type of architecture that has just never worked for us in Jquery.
Plenty of people will continue to use JQuery just as plenty of people continue to develop in Perl despite other communities feelings that it does't fit their use case.
I think that the angular way is just cleaner, and less likely to break because it is pretty sensibly encapsulated.
I suspect these libraries developed for angular, is a break from the past that the web is going to need eventually.
I wouldn't build a large app straight on top of jQuery ;)
Given how poor Angularjs performs that's not really the point of Angular.
> such as use of global DOM selectors like $('.foo').
Which is perfectly valid especially when doing event delegation.
The point of Angular is not to replace jQuery,the point of Angular is to have a clean way to integrate DOM manipulation into pages that have a complex application logic. Something devs should do with or without AngularJS,just that Angular forces (some) S.O.C.*
But one still does DOM manipulation in directives. with jQLite BUNDLED with Angular. AngularJS is no magics ,AngularJS has its own limited jQuery. Makes sense because the unique point of jQuery is DOM manipulation,not building applications with complex logic.
So people saying "I replaced this fairly large jQuery app with AngularJS" are lying, You cant write a "fairly large app" just with jQuery,You need to roll your own framework on top of it, at least.
* : My advice to anyone jumping in the next framework bandwagon is never couple your application logic to any framework. But that's what we see with AngularJS, everything in controllers or services tied to AngularJS apis... so much for separation of concerns...
angular.module("whatever").controller("YourController",
["dep1", "dep2", function (dep1, dep2) {
whatever...
}]);
why have the magical version if all it does is break, and there's a perfectly valid way to do it that is really not THAT much more complex.
The magic version is the first thing they teach you, and then you have to read the fine print to see you shouldn't be using it.
Why just not have it in the first place?
I'll agree with that.
Initially, I thought your point was the dependency injection as a concept needs to go away in Angular.
You already need to set up a build pipeline to get your minification, concatenation, etc. in the first place. It's hardly a terrible burden to have to stick an ng-min step in there as well. It seems like you're trying to justify an instinctive distaste for this feature by exaggerating how problematic it is, when in reality it isn't problematic at all.
Looks like I misunderstood the author's intent. This should be the only way, though.
Also, I didn't even realize that this way doesn't require .toString magic.
Angular is not really interesting because it's the new big thing. It's really interesting because it's right. (bitch of a learning curve though).
I think that it started us off into a bold new direction, and due to it's popularity will increase the general audience who would be attracted to it or related systems.
I don't know if it's going to still be around if/when we reach whatever the 'platonic ideal' of this approach to web applications is.
The problem is that you have to change your mindset from server rendered pages + jQuery. Second problem is with UI directives. Nice abstraction and encapsulation, but try to restyle something easily.
Yet people don't seem to be too eager to use both together. Why do you think that is?
From what I've seen on Angular people are really hyped about extending html and two way binding but when it comes to communication with the server they just wrap arbitrary ajax call done via $http or $resource in Angular service or factory or provider and call it a day. After seeing what backbone does, this seems to me to be as reckless as manipulating the DOM using jQuery.
That's something that can be done in 30 seconds with jQuery but my determination in making it work the 'Angular Way' has turned it into a 48 hour Donald Duck cartoon.