DEV Community

JQuery Footguns?

Ben Lovy on July 02, 2019

I've been tasked with building a small application over the next two weeks, and must use JQuery to do so. Left to my own devices I'd probably just...

Read full post

rhymes • Jul 2 '19

One thing I just remembered:

I used to use a convention to distinguish jQuery objects from regular variables, stuff like var $textBox = $("#textBox"). Don't know if it still makese sense but it did at the time :D

Paul • Jul 2 '19

I've also been doing this for a long time. It's very handy.

Ben Lovy • Jul 2 '19

Oh, I like that a lot. Most likely stealing this.

Austin S. Hemmelgarn • Jul 2 '19

Short list of things that come to mind:

Take the time to compare the jQuery AJAX stuff to a minimal open-coded implementation covering exactly what you need. You'll often find that just coding it yourself will both save space (if you can use a custom build of jQuery with the AJAX stuff stripped out) and save time. It also makes migrating to jQuery alternatives a bit easier. The same goes for the animation stuff (by the way, if you need animations more powerful than the basic canned stuff jQuery provides, I'd suggest looking into Anime.js, it's fast, tiny, and very powerful).
Cache your jQuery objects. For really trivial cases, performance isn't too bad, but the moment you start getting complex selectors (or using class selectors on older browsers), you will see some serious performance issues.
Use .prop() instead of .attr() whenever you can. It's significantly more efficient, and it ensures that the browser's internal understanding of the DOM state gets updated properly. Even further, use specific jQuery methods for the properties that have them (value for example, which has the .val() method).
Use event delegation whenever possible. This will help keep the number of event listeners down, which in turn helps a lot with app performance on many devices. Using event delegation also means you don't have to care if the specific element you want to match on even exists in the DOM when you add the event.
Make sure to keep track of which variables refer to jQuery objects. Most people just prefix such variables with $ as a reminder. This is more a case of writing readable code than actual performance.
Remember that jQuery always returns a valid object, even if your selector matches nothing (in that case, you get an empty jQuery object). This actually does have practical uses, but it also means that things that would crash if done through VanillaJS methods will silently fail to do what they say when using jQuery.
Keep in mind that many jQuery methods apply to all matched elements. In a lot of cases, there's no point in manually looping over the returned results of a jQuery selector call because you can simply update everything with one function call (which will be faster, especially for very large numbers of matched nodes).
Pretty much every jQuery method which mutates the state of the DOM returns the jQuery object it was called on. As such, you can often chain a series of methods that modify your selected element. While this doesn't make things any faster (at least, not measurably on any sane JS engine), it does make the JS code a bit smaller (each method you chain this way saves 2 bytes of code after running the source through a minifier).
Certain jQuery methods (most notably .addClass() and .removeClass()) are functionally idempotent and declarative. Put simply, $('#foo').removeClass('bar') will never return an error, and will always ensure that the element with ID foo does not have the class bar. As a result, stuff like this just wastes time:

if (!$('#foo').hasClass('bar')) {
    $('#foo').removeClass('bar')
}

Also, you might want to see if you can convince the decision maker to use Cash instead, it's like jQuery, just significantly smaller and significantly faster (and it unfortunately doesn't work with Bootstrap or some popular jQuery plugins like select2).

Ben Lovy • Jul 2 '19 • Edited

Wow, this is incredible, thanks so much for taking the time. Every point here is useful!

just coding it yourself will both save space ... and save time

This is my instinct as well, so I'm using the opportunity to specifically leanr about JQuery - otherwise I expect it to feel frustrating at times.

Use .prop() instead of .attr() whenever you can.

Did not know this, thanks much.

you don't have to care if the specific element you want to match on even exists in the DOM when you add the event.

Hadn't thought of that, that's good to keep in mind.

methods will silently fail

How do you mitigate this? Explicit run-time checks?

there's no point in manually looping over the returned results

This is one I did "know" but still somehow didn't realize you could use this way. Awesome.

functionally idempotent and declarative

This I did not realize and am a huge fan of. Unless I'm missing it, I don't think the docs make this very clear, but thinking about it, of course that's how they work.

Had not heard of cash, I'll make the case! Looks pretty snazzily familiar, he may go for it.

Austin S. Hemmelgarn • Jul 2 '19

Use .prop() instead of .attr() whenever you can.

Did not know this, thanks much.

Yeah, this one could stand to be covered more in a lot of jQuery tutorials. It's a regular source of subtle bugs as well as performance issues in code written by people who aren't familiar with jQuery.

methods will silently fail

How do you mitigate this? Explicit run-time checks?

I don't know what the norm is in big jQuery projects. For any of my stuff, I just make certain that things are strictly ordered such that this never happens (and when I can't ensure strict ordering, I use Arrive). FWIW, if you want to check, the most reliable approach is to check the length property of the returned jQuery object (if it's zero, nothing matched).

functionally idempotent and declarative

This I did not realize and am a huge fan of. Unless I'm missing it, I don't think the docs make this very clear, but thinking about it, of course that's how they work.

Yeah, the docs really don't make it clear, and while it kind of makes sense, it is inconsistent with how most programmers assume most things behave by default.

Had not heard of cash, I'll make the case! Looks pretty snazzily familiar, he may go for it.

Best time to go for it is when starting out. It's pretty easy to switch to jQuery after the fact if you need to, but not so much going the other way.

Ben Lovy • Jul 2 '19

most reliable approach is to check the length property of the returned jQuery object

That works for me - I don't think this project will qualify as "big". 1-2k lines of JS total. Hadn't seen arrive, that looks handy, but I think I'm going to see how I fare without it at first.

Seriously, this has been a huge help. You've boosted my confidence going in to this project, I feel a little less lost. Thanks again!

kip • Jul 2 '19

Something that I learned from jQuery was the event delegation and is easy to implement:

$('#parent').on('click', '#dynamicCreatedChild', e => {})

A good thing to remember too is the data() method used in jQuery not set values in data attr but can read it.

Using the data() method to update data does not affect attributes in the DOM. To set a data-* attribute value, use attr

docs

And use a internal system of cache, so if you update the attr data you need to retrieve with attr().

Since jQuery 1.4.3, data-* attributes are used to initialize jQuery data. An element's data-* attributes are retrieved the first time the data() method is invoked upon it, and then are no longer accessed or mutated (all values are stored internally by jQuery).

docs

Ben Lovy • Jul 2 '19

Beautiful, thank you for pointing this out!

Jacob McCrumb • Jul 2 '19

I haven't done much with jQuery event delegation, but I am guessing you need to be careful to turn off the listener if you need garbage collection?

MarvelousWololo • Jul 3 '19

hey, non related question but are you a freelancer or a full-time worker?

Ben Lovy • Jul 3 '19

Neither, really. This represents my first significant freelance situation, and I'm currently working towards finding myself a full-time role. I work in a non-tech capacity currently.

MarvelousWololo • Jul 3 '19

this is awesome then. i hope next time you would be able to find a client that does not demand jquery haha. in the time being you did not tell us what you are trying to build or do. could you share something on that?

Ben Lovy • Jul 3 '19

I'm hesitant to share the spec in any sort of detail, maybe I'll come back and recap after completing it! It's a small-scope full-stack application: Node/RethinkDB/JQuery/MaterialzeCSS.

MarvelousWololo • Jul 3 '19

is it a spa?

Ben Lovy • Jul 3 '19

Yep, but again, very manageable scope. They're primarily an angular shop.

MarvelousWololo • Jul 3 '19

awesome, man! congratulations! what are your skills? do you do both back end and front end? what is your stack? glad to hear. thanks.

Theofanis Despoudis • Jul 2 '19

Actually jQeury is not so bad. Especially the UI version of it its quite modular and you can build big applications with it. Just don't couple UI logic with business logic.

Ben Lovy • Jul 2 '19 • Edited

Ah, thanks for the link! I'd never heard of that, looks like a huge amount of work that can be saved there. I definitely don't have any sort of stigma against JQuery, just never got around to using it much.

Just don't couple UI logic with business logic.

Seems like good advice in general, JQuery aside. Thanks again!

Theofanis Despoudis • Jul 2 '19

I would suggest to use a template engine like handlebarsjs.com/ for anything related to building HTML

Ben Lovy • Jul 2 '19

Good tip! Manually constructing DOM nodes gets old fast.

rhymes • Jul 2 '19

The module pattern should help: learn.jquery.com/code-organization...

Ben Lovy • Jul 2 '19

Aha, I've seen this but never knew what it was called. Thanks for the link, great read!

rhymes • Jul 2 '19

Don't know if you know but jQuery has promises/deferreds/futures. You can do neat things with them :)

Ben Lovy • Jul 2 '19

Should they be used in lieu of es6 promises?

rhymes • Jul 2 '19

They came before, I think they've inspired them. I'm not sure how compatible they are. Methods like $.get() return such deferreds, but I haven't tried to mix the two :D

Ben Lovy • Jul 2 '19

A cursory glance suggests they aren't really compatible. I'll have to play with it, I've only used the newfangled jazz.

Edgar Ortega • Jul 2 '19

Saw this yesterday, you may want to consider it over jQuery blissfuljs.com/

Haven't worked with it so far

Ben Lovy • Jul 2 '19

Ooh, this does look really nice. For this project I've gotta use JQuery, not my rule, but I'm definitely going to explore this for something else. Thank you!

Marcelo Andrade R. • Jul 2 '19

Depending on the browsers the app is going to run, you may consider not use jquery at all: youmightnotneedjquery.com/

Ben Lovy • Jul 2 '19

Not up to me for this project, but thanks! I agree, I generally steer clear of any dependency at all if I can.

Ben Lovy • Jul 2 '19

Thanks for this! Great point that you always get back a JQuery object - those extra null checks are clunky otherwise.