Does everyone use JQuery?

D

DoubleZedRed

Gawd
Joined
Jan 12, 2009
Messages
849
or am I mistaken, I was asking about doing some stuff in vanilla JS in IRC today and was told I should just be doing everything with JQuery...

Outside of practical application/abstraction/etc.

Is there any reason to use it over plain JS?
 
It depends on what you are doing.

If it's something simple and you can account for cross-browser issues easily, you should use Vanilla Javascript. Even though most computers/phones/tablets can load jQuery quickly and it really is very small (32KB). if you don't need it, there's no reason to use it.

For complex stuff, using a framework is better cause it lays all the foundation for you.

The reason people recommend jQuery is because it's so quick to do stuff (and they don't know the underlying vanilla javascript to do it otherwise)
 
as said above, use normal JS where you can, but jQuery is just much easier
make sure to use the google hosted version, most users will already have that cached
 
Yeah, and I would argue that it makes sense even for simple stuff. Take the code below that I wrote earlier this week. It's for a smooth menu animation, it's 7 lines of code and works flawlessly across devices and browsers. I couldn't imaging writing that in vanilla JS and having the compatibility or speed that this does without any real work.

Code: 
  $(document).ready(function () {

        $(".main ul li a").mouseover(function () {
            $(".main ul li div").fadeOut();
            $(this).next().fadeIn(200);
        });

        $('.main ul').mouseleave(function () {
            $(".main ul li div").fadeOut();
        })
        $('.main ul li div').mouseleave(function () {
            $(this).fadeOut();
        })
    });
 
Between Jquery and Javascript, yes its much faster, easier and more secure to do it through Jquery. However between Jquery and other frameworks such as Mootools, its only due to popularity/web trends that Jquery is recommended so much. Its also why every business is switching to HTML5/CSS3. It has little to do with needing it or it being significantly better than XHTML1 and the entire web industry works this way.
 
I use Prototype at work and I feel like I am using stone tools. jQuery being an electric drill.

jQuery is extremely easy and fun to use. This is why it seems that "everyone is using it".

I recently had to write a js widget that will potentially be used on hundreds of websites. Since it had to be compatible, the ideal solution was to write everything in plain javascript, since other libraries can collide and break stuff. In the end, due to mostly a lack of time, I used jQuery. I just had to make sure to check for it's existence first, load it if necessary, and run it in non-collide mode. The script can still break stuff, but it was much easier to write than it would be otherwise.

jQuery FTW.
 
Code: 
$(".main ul li a").mouseover(function () {
$(".main ul li div").fadeOut();...
Is there some reason why you aren't caching your selectors? Store the results of a selector query in a variable (or as an object property) and you can invoke jQuery methods upon them directly, which skips a time-consuming DOM traversal. This is particularly important when your selectors descend from a class, as traversing the DOM for classes is significantly slower than grabbing an element by its ID:
Code: 
var $main = $('.main');

To grab children from the cached selector, use the find method:
Code: 
$main.find('ul li a')

The $ prefix for the variable name helps to indicate that the variable refers to a jQuery object.

As for the OP's question, I consider the use of jQuery 'free', assuming you're grabbing it from Google's CDN. There's a penalty involved for parsing it, and the actual initialization of its code is blocking (assuming you're just loading it in via a script tag and not using an asynchronous method), but these costs are fairly minimal. Most users will have a number of versions of jQuery already in their cache, and the use of jQuery will simplify your application code (which means you'll be shaving off a few kilobytes for a large-ish application).

Just be certain that you're providing a locally-hosted fallback in cases where loading jQuery from the CDN, for whatever reason, fails.
 
No, just lazyness really as it worked and it was only a tiny snip-it of code. Saying that, you gave me the optimisation bug. So I thought I'd see what I can do with it.

Caching $main actually saved 50ms.
Doing the same with the divs yeilded another 15ms.
And going from the class to id (it's a bad habit using classes I know) saved another 15ms.

So all in all saved 80 milliseconds for every page and didn't loose the readability in the process. So yeah, it was worth it. Cheers!

Code: 
    $(document).ready(function () {
        var $main = $('#main');
        var $div = $main.find("ul li div");
        $main.find("ul li a").mouseover(function () {
            $div.fadeOut();
            $(this).next().fadeIn(200);
        });

        $main.find("ul").mouseleave(function () {
            $div.fadeOut();
        })
       $div.mouseleave(function () {
            $(this).fadeOut();
        })
    });

edit: Oh and changing $main.find("ul") to $main.first("ul") saved another 4ms!
 
Last edited:
allow me to add your missing (if not strictly required) semicolons
Code: 
    $(document).ready(function () {
        var $main = $('#main');
        var $div = $main.find("ul li div");
        $main.find("ul li a").mouseover(function () {
            $div.fadeOut();
            $(this).next().fadeIn(200);
        });

        $main.find("ul").mouseleave(function () {
            $div.fadeOut();
        });
        $div.mouseleave(function () {
            $(this).fadeOut();
        });
    });
 
And you should probably use the jQuery 1.7+ .on() event handler so that your events will persist even if content is updated by ajax
Code: 
        $mainParent.on(mouseover, '$mainsubselector', (function () {
            ....
        });
 
Actually i changed my mind about caching objects. They will be lost if the container they're in gets refreshed through ajax.

You should still use .on(), but use caution with cached elements.
 
mouseover, mouseout and etc. are wrappers for the bind method, which is itself now a wrapper for on. It's probably minutely faster to use on and save yourself on function calls, but we're not talking about a huge leap in performance here.
 
mastaBlasta said:
And you should probably use the jQuery 1.7+ .on() event handler so that your events will persist even if content is updated by ajax
Code: 
        $mainParent.on(mouseover, '$mainsubselector', (function () {
            ....
        });
Click to expand...

I think .delegate is quite a bit more readable.
 
wonderfield said:
Ah, you're one of those guys, huh? ;)
Click to expand...

we don't need no stinkin' semicolons
Code: 
$.ready ->
	$main = $ "#main"
	$div = $main.find "ul li div"

	$main.find("ul li a").mouseover ->
		$div.fadeOut()
		$(@).next().fadeIn 200
	
	$main.find("ul").mouseleave ->
		$div.fadeOut()
	
	$div.mouseleave ->
		$(@).fadeOut()

It used to be, I was like, "Why depend on jQuery as a crutch?", but it's just another tool and a tool that works well. That's all frameworks are. They handle the crap (x-browser/boilerplating) I don't want to. jQuery won't make a crappy JavaScript'er a better developer, but it can make a good JavaScript'er an efficient developer.
 
Last edited:
Why are you using the fat arrow on mouseover and mouseout? This script, if I'm not mistaken, will yield an error, as the this pointer (bound to the _this variable) will be undefined in this context, and there will be no next or fadeOut methods associated with it. Within the scope of the handler, this refers to the DOM object from which it was called, which needs to be wrapped in $() to refer to the jQuery object for that DOM object. Each should use the -> operator.
 
damnit, you're right. forgot what context i was in. habit.
 
odoe said:
It used to be, I was like, "Why depend on jQuery as a crutch?", but it's just another tool and a tool that works well. That's all frameworks are. They handle the crap (x-browser/boilerplating) I don't want to. jQuery won't make a crappy JavaScript'er a better developer, but it can make a good JavaScript'er an efficient developer.
Click to expand...

That's what I had originally thought, but everywhere I turn it seemed like someone was suggesting that I was wasting my time playing around with any concepts in JS which is why I posted this thread.
 
With any language you'll find there are a lot of libraries that ease your work, but it's still good to understand what they are doing... So yes you should also learn plain JS.
 
You must log in or register to reply here.
Back
Top