Why do we need IIFE's to have module scoping in Javascript?

Question

Suppose I have core.js

var ajax = function(){};
var something = function(){super};
var globalconstant = 5;
var someutilitymodule = {
onekey: something;
twokey: something;
}

If I include this in my file as <script src="core.js">

1) I pollute the global namespace

2) Might [replace/get replaced by] another variable .

However won't making it an Object solve the problem ? I.e I make core.js like this

core = 
{
    ajax : function(){},
    something : function(){super},
    globalconstant : 5,
    someutilitymodule = {
                        onekey: something;
                        twokey: something;
                        }
}

What is the fundamental problem in this approach ? Is it because that you can't access other items until the full Object is created ? Like for example core = {a:"Foo" , b:a} won't work ? However I could solve it by

core = {};
core.a="Foo";
core.b=core.a;

Why do we have to get into IIFE(Immediately Invoked Function Expression) if we are not really interested in closures ? For "module namespace" in Javascript that doesn't mind having everything public in a different namespace , won't this approach work and create Module effect in Javascript ?

Are there any pointers to read more on this ? I know its a bit vague but I am new to this concepts like IIFE requirejs etc . So trying to understand from a newbie perspective .

IIFEs allow you to have local data that can't be accessed from the outside. — Felix Kling, Aug 28 '14 at 21:31
IIFE is always mentioned along with Module scoping as though there is not other way to create module scope . IIFE does Module Scoping with Private Data - Correct. If you don't need private data but you need Module scoping this approach is just fine no ? Pythons Modules I guess is a bunch of Key Value pairs internally ! It does that internally , here we explicitly say that core.a = "Foo" ; thats my thought. — Nishant, Aug 28 '14 at 21:33
`core = {a:"Foo" , b:a}` won't work because `core.b` doesn't assume that the current root is `core`. `core = {a:"Foo" , b: core.a}` will work, so the argument about accessing other items is invalid. [This article by Ben Alman](http://benalman.com/news/2010/11/immediately-invoked-function-expression/) explains IIFE's pretty well — webketje, Aug 28 '14 at 21:38
Thanks , I didn't know that . So yes that argument is valid . Yes I have read Ben Almans IIFE article . Will revisit . — Nishant, Aug 28 '14 at 21:40
You mean someutilitymodule = {onekey: this.something;} ? This is getting to be confusing :P . NVM I'll have a look at that . Good point though . — Nishant, Aug 28 '14 at 21:49
Huh, I'm stunned by @PHPglue 's comment. That certainly won't work. Because you are in the global context (`window`) `this.something` refers to `window.something`, so in this case you'd need `this.core.a`, which is basically the same as `core.a`. You should only use `this` in a function scope. — webketje, Aug 28 '14 at 21:52
That's not what I meant. Would have to be `core.something` in `core.someutilitymodule`. — StackSlave, Aug 28 '14 at 21:59
Okay Yes , that correct . "this" usually will make it callee dependent. — Nishant, Aug 28 '14 at 22:00
@Tyblitz: `core = {a:"Foo" , b: core.a}` **does not work** because `core` doesn't have a value yet when you are trying to access it (`b: core.a`). — Felix Kling, Aug 28 '14 at 22:17
@FelixKling , my bad. I tested this before but the difference was like: `core = {a: 2, b: function() { return core.a }}`, which of course only executes when you call the function. Sorry & thanks for pointing out! — webketje, Aug 28 '14 at 22:47
So the arguement stands good about writing self references at a later point . — Nishant, Aug 29 '14 at 10:02

score 0 · Answer 1 · edited May 23 '17 at 10:25

This question is related to JavaScript - Advantages of object literal .

"Object Literal Notation" is techincal term for this . It is one of the commonly used patterns for segregating code in JavaScript although Module Pattern like http://css-tricks.com/how-do-you-structure-javascript-the-module-pattern-edition/ is the more advanced form and it uses IFFE just to get extra features like private variables using closures .

However IFFE variables can't be accessed at a later point unless you define methods in the function right away . You can't extend methods to use this IIFE variables later on .

For example :

//counter here is the iife functions' counter variable
var module = (function(){var counter=1; return {getCounter: function(){return counter}}})()

//counter here is the global counter variable as it was created from the global scope
module.setCounter = function(arg){counter = arg + counter}

Why do we need IIFE's to have module scoping in Javascript?

1 Answers1