Jump to content
Search Community

what is faster, target with or without $() for non document.getElementById()

Jonathan test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Hello All,

 

My question has to do when using the tween target. I know as far as speed that targeting elements in the DOM by ID is faster than targeting a class. I know to use document.getElementByID() when i need to target a ID.

 

If you pass a string (text) into a tween as the target (like TweenMax.to("#myID", 1, {left:"100px"})) TweenMax will feed it to $ (typically jQuery) or if that isn't loaded, it will default to document.getElementById() (automatically removing the "#" prefix if it's there).

 

But when it comes to other selectors ( like classes, attribute selectors, etc... ) GSAP knows to add the jQuery $() if jQuery is included in the page.

 

So my question is... 

  • What is faster...  to omit the $(), or include it: ??
//  jQuery is loaded in the page
//  Which is faster ?

// without the $
TweenMax.to(".myClass", 2, { color:"#FC0"});

// with the $
TweenMax.to($(".myClass"), 2, { color:"#FC0"});
  • If I include the $() does it help with speed or performance, since im including the $()
  • or does it not even matter?

Thanks in advance for any help with my questions :)

Link to comment
Share on other sites

Hi Jonathan,

 

Since usually JS execution is not the biggest issue in terms of performance, It shouldn't be a big difference, but if we're talking about an insane amount of code, I'll say over 5000 lines, maybe there it could be a slight difference in favour of including the JQuery selector in the code instead of letting GSAP doing it for you, it reduces the amount of checks the library has to do while processing the code.

 

I'm pretty sure that Carl and Jack did some stress tests in this matter when they included the feature, and I'm also very sure that if they see anything that would be detrimental in terms of performance it wouldn't be in the engine.

 

Bottom line creating the selectors and even better, store the selectors in variables (specially when you animate or reference an element a lot in your code) is faster but it would be very difficult to notice in a real life working app.

 

In my case I always pass the selectors myself and always include the tag (when working with JQuery), like this:

var element = $("div#divID");

TweenLite.to(element, time, {vars});

Once I read that in some cases (again we're talking about a lot of nodes in your app) it can speed up things to add the type of tag you're refering (div, ul, li, p, span, a, img, etc), but I'm used to work like that now so I always type my code like that.

 

Best,

Rodrigo.

  • Like 3
Link to comment
Share on other sites

I love that you're so interested in maximizing performance, jonathan. 

 

As Rodrigo said, you'd probably never see even the slightest difference in real-world apps, but technically it'd be slightly faster to use the jQuery object instead of asking GSAP to do that for you. The fastest, of course, is to pass the raw element itself instead of involving jQuery at all.

  • Like 1
Link to comment
Share on other sites

Rodrigo, I would have thought for an ID selection that,

var element = $("#divID");

would be (just a tad) faster than

var element = $("div#divID");

since it doesn't have to involve sizzle for the selection and can just use document.getElementById(); Of course, it wouldn't be a difference you'll ever notice unless you are running selections 100s of times a second. On the other hand, in older IE (6/7/8?) something like

var element = $("div.divClass");

would perform significantly better than

var element = $(".divClass");

since before querySelectorAll existed, sizzle has to parse through the entire DOM looking for elements with .divClass. If it can restrict it's search just to divs, that's faster.

 

Either way, caching the result in a var pretty much makes it a non-issue.

 

Also I used to hear that a descendant selector like

$("div.parent span.child");

would perform much better as

$("div.parent").find("span.child");

(and jquery still recommends this on their site). It looks like the performance of querySelectorAll is improving a lot in Chrome and Firefox though, so I'm not certain this holds true in the latest browsers.

  • Like 3
Link to comment
Share on other sites

Hey Guys.. Here are some JSPERF test cases:

class name VS tag and class name :
http://jsperf.com/jquery-class-name-vs-tag-classname/5

selectors VS find() :
http://jsperf.com/browser-diet-jquery-selectors/14

find() VS descendant :
http://jsperf.com/find-vs-descendant-selector/36

 

jquery VS document.querySelector

http://jsperf.com/jquery-vs-document-queryselector/31

 

jquery VS document.querySelectorAll

http://jsperf.com/jquery-vs-queryselectorall/12


Hope these links are useful :D

  • Like 4
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...