Comments on: IIFE argument madness

By: Sean

Sean — Wed, 29 May 2013 08:01:01 +0000

Good article, makes me reconsider my current practice.

One reason to pass in $, and other dependencies, is to satisfy jshint in strict mode.

    (function($, _)) {
        "use strict";
        // use underscore and jQuery
    })(jQuery, _);

Jshint accepts the $ and _ as global variables and won’t complain. This is useful for one object per file at dev time. It’s just one way to let jshint know, you can also use an rc file or comments aimed at jshint directly. So I don’t think this is a conclusive reason to pass them in, just an added bonus.

By: Mattias Aspelund

Mattias Aspelund — Mon, 27 Aug 2012 12:37:55 +0000

Nice, this article actually solved a problem for me. I’m adding features to an old site with a lot of prototype.js legacy code. Of course, I’ve been running with the compatibility mode. I haven’t even thought about the simple and easy workaround with

 (function($) {
        // my code
  })(jQuery)

That’s actually pretty good.

Nice post.

By: Durgesh

Durgesh — Sun, 19 Aug 2012 17:59:57 +0000

I am new to Javascript. And in my small career I have seen ECMASCRIPT 5. I dont know any way to override undefined with this edition.
So, I ofcourse agree with your points regarding undefined. But I sometimes really need the $ in IIFE.

BTW, I really like your style of writing.

By: Jamie

Jamie — Mon, 13 Aug 2012 11:58:57 +0000

@Rudie – true, they are not exactly the same, and that’s an important distinction. Using a function to test for undefined would throw an exception is testing for the existence of global. For me, most real-world use cases involve testing parameters and properties for existence, though, so it’s not really an issue.

As for == vs ===, it comes from habit. I prefer to write code that, when testing two objects that should be the same data type, uses a comparison operator that requires them to be the same data type.

Since, as you noted, a good compressor will optimize it. That’s one of the reasons we use them. So I prefer to write expressive code without worrying about whether an ‘==’ doesn’t carry a risk in one specific situation, and let the optimizer worry about saving characters. That’s just my style, it’s neither right nor wrong, and it has no effect on performance or size of the compressed code. But developing habits like this helps me write code with fewer bugs, ymmv.

By: Rudie

Rudie — Wed, 01 Aug 2012 23:07:37 +0000

This might throw an exception too btw:

if (u.isUndefined(something)) {

and therefore is definitely not the same as

if (typeof something === 'undefined') {

(I also don’t get the ===. There’s absolutely no point at all whatsoever. Good minifying even removes a = because it knows that.)

By: Rudie

Rudie — Wed, 01 Aug 2012 23:02:35 +0000

I’m pretty sure this will throw a ReferenceError if window doesn’t exist:

(function(exports) {
  exports.foo = function foo(){};
})(window || exports);

Valid as argument would be something like:

'undefined' != typeof window ? window : exports

which is so much worse. I agree with James:

“Frankly, I prefer putting this inside the IIFE at the top. Why should the reader have to scroll all the way down to see this information?”

It’s such a stupid, hyped thing. Nobody actually thinks about it.

By: Brian

Brian — Tue, 10 Jul 2012 16:51:54 +0000

@James. I agree, that’s quite readable. However, you now have an extra function call whenever you use it. The IIFE undefined seems cleaner, and more performant to me, vs that, without any sacrifice in protection or readability. It’s better than the type of/string comparison we all have learned, as it is more performant, and IMHO more readable. It’s equivalent, again IMHO, to the alternative I had also learned as the “better” version of that typeof check; namely:
void 0 !== foo
yet ‘undefined’ is more readable (at a minor cost of a local scope lookup). And if someone then is at the point where even that tiny cost matters, personally, I think they’re perhaps a bit too far into microoptimization territory. 😀

By: James Treworgy

James Treworgy — Mon, 09 Jul 2012 12:50:46 +0000

Regarding “undefined”: do a lot of people really test code against a variable named “undefined”? Even though I’m sure it works 99.99% of the time, it just seems, well, wrong. Undefined isn’t a value. It’s a type. I learned a long time ago to do:

if (typeof something === 'undefined') {

Ok, a bit verbose, but so’s a ton of stuff in javascript. So put it in your toolbox like you do with anything else, and make a function:

if (u.isUndefined(something)) {

It’s expressive, correct, and doesn’t test your stuff against something that you hope doesn’t exist. It seems odd that anyone who’s concerned enough about such things to create a wrapper like the one we’re discussing, would worry about the definition of “undefined” instead of just not using it.

By: Joe Zim

Joe Zim — Mon, 09 Jul 2012 12:19:06 +0000

@James
If you’re encapsulating your code in an IIFE anyway, how much less readable is it to throw window and undefined in just for the sake of compression. Considering EVERYONE’s doing it (which is what you’re complaining about) I don’t think anyone has any misunderstanding of what’s going on when they see that at the top of the code. They shouldn’t need to bother going to the bottom of the code to see what you’re passing in.

By: James

James — Mon, 09 Jul 2012 10:40:10 +0000

@NiKo, in that case, yes, it’s valid. I see the pattern a lot in client-side-only code though.