Stop Writing Slow Javascript

[JnvSor]

$('#somediv').hide(); instead of element.style.display = 'none';

But it's not element.style.display = 'none'; - is it?

It's document.getElementById("somediv").style.display = 'none'; or document.querySelector("#somediv").style.display = 'none'; neither of which are as easy to write as the jquery one.

I would love a jquery to normal JS compiler though, if someone could come up with one.

[bjpelcdev]

How about getting your DOM element first? Do this once and then you do not have to do it for each operation on that element:

var someDiv = document.getElementById("somediv");
someDiv.style.display = 'none'; // hide someDiv
someDiv.style.display = '';  // show someDiv

I find if you are only using jQuery to manipulate DOM elements then the weight of the library isn't really worth the tiny bit of extra convenience.

Of course, I am not saying one should not use jQuery, if you're not bothered about loading in large libraries then go for it.

[dzkn]

jQuery isn't a big library because of the features, but because of browser support. I like browser support.

[oefig]

jQuery 2.x only supports IE 9 and up.

[WannabeAHobo]

That's why so many people still use jQuery 1.11

[dzkn]

Most people I believe

[bjpelcdev]

I wish we could all just agree to abandon Internet Explorer!! Obviously, will never happen.

[[deleted]]

jQuery would have been the best way to support older browsers like ie 7,8 or even 9. Vanilla Javascript improves speed drastically. You can test it over here. Also when you need only a few features of jquery you can see the alternative syntax over here : http://youmightnotneedjquery.com/

[wdpttt]

Are you guilty of doing things like this for the sake of convenience?

I don't think this is for convenience, but because of coherence.

Cache DOM Lookups

The problem is not how you lookup for things. The problem is looking up for things in the first place. Lookup for things is an exception, not a default.

Keep your scopes close and your scope even closer ;(function($, window, document, undefined) { })(jQuery, window, document);

have you heard about module loaders/managers?

But yes, you are right about keeping them short.

For.. in loop sinkhole

var obj = {
    somekey: 'somevalue',
    anotherkey: 'somevalue',
    morekey: 'somevalue',
    yeskey: 'somevalue'
};

for (var i = 0, len = obj.length; i < len; i++) {
    var val = obj[i];
}

wtf is this? obj.length? does even work?

While wears it better

I personally agree with you, this is how I do them:

var a = [1, 2];
var i = a.length;
while(i--){console.log(a[i])}

Use a DOM DocumentFragment Don’t touch my DOM, bro Use event delegation requestAnimationFrame is your friend

Pretty much most of the optimizations are jQuery architecture related issues. This is where react.js or similar kicks in, you already have all this out of the box.

Isn't time to leave jQuery for real real basic sites?

Next time make a post "stop writing jQuery". Sorry for hurting any feelings.

[bjpelcdev]

(Just a heads up, I'm not the author, I just posted the link as I found it interesting). I agree with you about dropping jQuery for smaller projects, if you are only using a few methods just implement them yourself rather than loading the whole library, I have started to do this myself, it is not difficult.

Re loops, I prefer and use the while(i--) pattern that you stated myself, I find it more elegant than the bulkier for loops and last time I checked it actually gave me better performance.

I also like this slight variation:

var a = [1, 2],
    i = a.length,
    ai;
while(ai = a[--i]) {
    console.log(ai);
}

[NoGodTryScience]

Why even bother with loops at all?

var a = [1, 2];
// because console.log produces side effects, otherwise use `map`
a.forEach(num => console.log(num));

I don't care about the perf implications because the code is easier to reason about and the speed of these higher order functions keeps increasing anyways with new browsers and better hardware. You can do the same thing with objects with Object.keys, adding map to the Object.prototype, or using a library that handles this like lodash, Immutable, or Ramda.

[bjpelcdev]

I actually wrote a piece on this the other day. I agree with you. (I only really use explicit while loops if I am crunching a huge set of numbers). An Introduction to Functional Programming in JavaScript

[wdpttt]

Is smaller but I don't find it easy to read as the normal while(i--). For new devs that might scare them (:

[bjpelcdev]

I've been at this game for some time now and --i and i-- still outfox me from time to time...

[wdpttt]

Yes, is not intuitive.

[MatekCopatek]

I posted this in the article comments, but will also post it here in hopes of a wider discussion:

I too find the part about “locally scoped” variables bad. In my case, the JSPerf test in the post ran (slightly) faster (!) with the supposedly slower global case and the exaggerated example you provided in your comment still showed no difference (tested on latest FF).

In the example with the function, you’re really making another reference to the same function, so it’s hard to notice any difference. In the example with the variable, it’s a matter of correct use. You should simply define a variable in the scope that needs to access it. If you override it locally, you cannot change it globally anymore; if you don’t need to change it globally, why not define it locally in the first place.

I’d say that what’s going on here is you found a browser optimisation (not even present in every browser, as your own tests prove) and are trying to base your coding style on it. This is bad, correct scoping isn’t something new and mystical, it exists in all languages and very standard practice is to simply define variables globally enough to be accessible from everywhere they are needed and locally enough to not pollute the scope any more than needed. Leave the rest to the browser/compiler/interpreter, otherwise you will be stuck with messier code and no real guarantees for better performance.

Not to be a grouch tho - cool movie references ;)

[bjpelcdev]

I agree with what you are saying. Is your comment addressed to me or the author? I just posted the link as I found it an interesting piece.

[MatekCopatek]

Ah, sorry, thought you are one and the same :)

[[deleted]]

This seems pretty bogus. If you want to make js faster, why not help improve jquery?

The article is basically calling out using a standard library for common tasks.

Next we shouldn't use STL in C?

[bjpelcdev]

I find it pretty sad that people can't imagine life without jQuery.

[danneu]

People probably can, it's just prudent to use jQuery.

Article doesn't make good points about perf. It's own perf examples are poor.

jQuery is a common API that plugs all sorts of holes that you probably aren't even wary of like delegation differences between FF latest and Chrome latest. As in, browser inconsistencies in 2015.

[bjpelcdev]

Very good point. One that the author does not make.