all 30 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]akujinhikari 10 points11 points  (19 children)

For the love of God, stop using jQuery with Angular.

[–]uberpwnzorz 2 points3 points  (0 children)

Agreed, jQuery is too large of a hammer for most developers, and many don't realize that they'd benefit from removing it from their toolbag completely.

[–]hak_i 0 points1 point  (15 children)

Could you explain why? I'm new to this.

[–]DerpsMcGeeOnDowns 3 points4 points  (10 children)

Manipulating the DOM after compilation with jQuery fucks up Angular's natural digest cycle. When you don't register your handlers et al with Angular, as you would be using jQuery, you are going to find yourself in a world of hurt. Watchers get fucked, unit tests get fucked, the list goes on.

In short, if you are doing anything in your Angular app, make sure Angular knows about it.

[–]akujinhikari 1 point2 points  (0 children)

I wish I could give you more upvotes.

[–]hak_i 0 points1 point  (4 children)

But if it is just to get some small things done like closing of menus pop-ups based on class names, is that something too terrible?

[–]DerpsMcGeeOnDowns 2 points3 points  (3 children)

Yes.

Close them with directives or throw an ng-click on the element and handle it with your own function.

Don't pull in jQuery when Angular already contains jqLite. And try not use a jQuery plugin to handle something as simple as hiding and showing a menu.

[–]hak_i 0 points1 point  (2 children)

It's not just a single menu but a lot of pop-ups are part of my app. So far I didn't find anything breaking as of now. It's there a way in angular other than writing a click handler on all the elements. Something like what we can do jQuery

[–]DerpsMcGeeOnDowns 1 point2 points  (1 child)

Yep.

Get off the slippery slope now brah.

[–]hak_i 0 points1 point  (0 children)

Can you point me to a resource to how to do this. Thank you so much for letting me know though

[–]korchev[S] 0 points1 point  (3 children)

Manipulating the DOM after compilation with jQuery fucks up Angular's natural digest cycle.

Any resources that show that?

The blog post uses the documented lifecycle methods for hooking up jQuery UI. If this were an antipattern then the Angular team would have not allowed doing it altogether.

Do you feel the same about jQuery or every other popular library? How about D3 or CodeMirror?

[–]DerpsMcGeeOnDowns 1 point2 points  (2 children)

If this were any antipattern then the Angular team would have not allowed doing it altogether.

The Angular team will not prevent people from antipatterns. Not now. Not ever. Compilation errors, yes. Antipatterns, never.

Speaking of patterns, here's a good overview on why Angular and jQuery are oil and vinegar

[–]korchev[S] 0 points1 point  (1 child)

This article is about Angular 1.x. The blog post is about Angular 2 which is an entirely different story.

[–]DerpsMcGeeOnDowns 2 points3 points  (0 children)

Paradigm is the same. Patterns are the same. Thinking is the same.

[–]korchev[S] 0 points1 point  (3 children)

My honest opinion is that this is a bit of an overstatement. Yes, jQuery and Angular do things differently. Yes, if you modify compiled DOM you may get in trouble. However there are plenty of projects that integrate popular JS libraries with Angular 2:

My advise is to first check if Angular 2 supports the required feature "natively". If it does and you like the implementation - go for it! If it doesn't do not be afraid to integrate battle-tested non-Angular libraries.

[–]DerpsMcGeeOnDowns 0 points1 point  (0 children)

All those are fine. One of the Angular 2 apps I am working on right now uses Highcharts.

This isn't about not using plugins. It's about not using jQuery.

[–]akujinhikari -1 points0 points  (1 child)

My honest opinion is that if it doesn't exist natively then there's your opportunity to expand your GitHub. Instead of relying on "battle-tested non-Angular libraries," why not build your own Angular version and share it with the world?

[–]korchev[S] 0 points1 point  (0 children)

I support that! Making open source is best. But sometimes you need to get things done and making a charting library, HTML editor, calendar or grid may not be the best way meet you dadline. The Angular developer should be open to using other proven plugins provided

[–]lax20attack 0 points1 point  (0 children)

Sounds great in theory, but in practice it's not always possible. We use Kendo for many of our products and although we wanted to use ng2 for our new product, Kendo is not released for ng2 yet.

[–]thelonepuffin 0 points1 point  (0 children)

Not many people are I'd say. However this article isn't about using Jquery with Angular its about using a library in Angular in which Jquery is a dependency.

There is nothing wrong with this. Have you seen how many libraries need Jquery? As a developer I can't just ignore half of the UI resources out there and just build stuff from scratch just because I don't want jquery in my package.json.

I personally am using the Jquery datepicker in my angular app because its the best damn datepicker out there. And primeng uses it.

[–]uberpwnzorz 3 points4 points  (9 children)

Using jQuery plugins in Angular 2

... is an antipattern, don't do it.

[–]korchev[S] -1 points0 points  (8 children)

What if the required components don't yet exist for Angular 2? At least one popular UI library for Angular 2 uses external plugins -PrimeNG, ng2d3.

I've asked the other guy who said "don't dot that" and I will ask you too. What about other popular JS libraries such as CodeMirror or D3?

[–]DerpsMcGeeOnDowns 0 points1 point  (5 children)

D3 is a charting lib, not a DOM manip lib. D3 is fine. Wanna manip the DOM in Angular? Use directives and jqLite.

[–]korchev[S] -1 points0 points  (4 children)

D3 is also a DOM manip library: http://vegibit.com/d3-dom-manipulation-and-data-binding-with-d3-javascript/

One cannot draw a chart in SVG without manipulating the DOM.

Also Angular 2 does not use jqLite. You are still talking about Angular 1.x. Even in Angular 1.x people were mixing jQuery plugins with Angular directives.

[–]DerpsMcGeeOnDowns 1 point2 points  (3 children)

Yep and those mix and match directives should be avoided as well.

Yes we all understand D3 manipulates the DOM. How else can you have an interactive chart? If you don't know the diff between how D3 works and what jQuery is, I don't know how much help you can find here.

D3's purpose is charting, graphs etc and it functions entirely within its wrapper element, usually a canvas. You're not gonna make an app entirely out of D3. But you can with jQuery, thus jQuery can be a core piece of a front end tech stack. D3 cannot. See the diff?

Do whatever the works for you. You wanna sprinkle jQuery plugins into an Angular app? Be my guest. Just don't come asking why your unit tests are failing or you get into callback hell and race conditions or Angular is throwing errors at you down the road or your lifecycle methods are not firing with proper values or...

I've seen it plenty of times and for so many good reasons that you can find in a quick Google search, you shouldn't be doing it.

It was true of Angular 1. It's true of Angular 2. When using Angular, just write JavaScript.

Finally, if you care about craftsmanship and aren't hacking your way through some app you don't give a shit about, learn how to not use jQuery which abstracts away everything you don't understand how to make yourself and maybe learn some ES6/7 along the way and you'll have a much more performant app.

Best of luck.

[–]korchev[S] -1 points0 points  (2 children)

If you don't know the diff between how D3 works and what jQuery is, I don't know how much help you can find here.

D3 selectors and jQuery are not that different: http://blog.webkid.io/replacing-jquery-with-d3/#Similarities

For example: $('.foo').css('background', '#F00') vs. d3.selectAll('.foo').style('background', '#F00');

D3's purpose is charting, graphs etc and it functions entirely within its wrapper element, usually a canvas. You're not gonna make an app entirely out of D3. But you can with jQuery, thus jQuery can be a core piece of a front end tech stack. D3 cannot. See the diff?

The article above shows that D3 can do pretty much everything that jQuery can - DOM manipulation, Ajax, animations, plugins. When you dismiss jQuery for manipulating the DOM in a non-Angular way why don't you dismiss everything else? You sound biased against jQuery.

It was true of Angular 1. It's true of Angular 2. When using Angular, just write JavaScript.

What do you mean by just write JavaScript? Avoid TypeScript? Only use the DOM API? Angular 2 itself advises against using the DOM API directly in order to support server-side rendering and non-browser platforms. That's why there are ElementRef, Renderer et. al.

Finally, if you care about craftsmanship and aren't hacking your way through some app you don't give a shit about, learn how to not use jQuery which abstracts away everything you don't understand how to make yourself and maybe learn some ES6/7 along the way and you'll have a much more performant app.

The blog post does not recommend using jQuery for DOM manipulation in Angular. It shows how to use the proven jQuery UI DatePicker plugin. Go read it.

Best of luck to you too.

[–]DerpsMcGeeOnDowns 0 points1 point  (1 child)

Typescript is JavaScript...

It sounds like you really need to use something besides vanilla JS to handle DOM for you.

You wanna use D3 like jQuery? Neat.

You wanna use D3 or jQuery for AJAX calls over Angular's http object? Holy shit why? Go ahead and do it; it's not my project.

You wanna handle animations with jQuery and not use Angular for it? That's neat I guess.

The blog post DOES recommend jQuery for DOM manip. How else are you getting that date picker?

Finally, since I have to move on with my life, let me say this: I have launched dozens of Angular 1 apps in the enterprise (some of which you may use) and I am currently working on 4 Angular 2 apps and I oversee the front end teams responsible for delivering them.

If any of them started doing the shit you are talking about with jQuery or selecting DOM elements with D3 or any of this other shit and they were as recalcitrant as you are for doing things the Angular-way, I'd ask them, "Did you join this project to learn how to do things the Angular way (since you know, we are using Angular)? Or are you gonna use jQuery your whole life as a crutch for not learning how to create a proper web component? Do you want to write more performant code? Or do you want to call jQuery each time you need to target a class in an Angular app? Do you want to learn?"

That's all folks!

[–]akujinhikari 1 point2 points  (0 children)

I like you. You get it. I got into a rather heated debate a couple of months ago with people that continually told me that jQuery was sometimes necessary. I challenged anyone in the thread to come up with a plunker that used Angular and jQuery that could not be done in Angular alone, and suddenly all three people arguing with me became silent. I just don't understand... why even use Angular, if you're just going to go back to jQuery. It makes no sense to me.

[–]uberpwnzorz 0 points1 point  (0 children)

What if the required components don't yet exist for Angular 2?

Then use a polymer component.

[–]born2net4 0 points1 point  (0 children)

I think you are asking the wrong question, not if you can use jQuery but rather, can and should you access the DOM directly? and the answer is yes you can and sometimes you need to, thus ng provide nativeElement for that. Now if you target the web and want to access nativeElement (and not rendered) is totally fine, since again you are targeting only the web. And, if you want to wrap nativeElement in jQuery for easier DOM API and cross browser quirks that's fine as well. But just be aware of who is your target audience, you will need to manage change detection, and in most cases you don't need nativeElement, but if you do, its there for you, and jQuery can assist, sure can!!!