Should I use IIFE or window onload to initialize?

Question

Both of the following code snippets worked:

Using IIFE in js file:

(function initialize() {
  txtInput = document.getElementById('txtInput');
  txtResult = document.getElementById('txtResult');

  txtInput.value = "0";
  txtResult.value = "0";

}());

Calling initialize() on window load event in html file:

window.addEventListener('load', initialize, false);

Is one a better approach than other; in terms of performance or otherwise? As it stands right now, I am leaning more towards adding event listener to the window object, because it is more readable.

Crucible

it's window.addEventListener('load', initialize, false); -> will be executed on dom content loaded. – Startle

Not really, it will call initialize when all resources has loaded, with 3rd party stuff the difference can be huge. – Sotted

It all depends on if you intend to run this before or after the elements are actually added. If you are sure that they exist - use the IIFE. – Secundine

@LShetty oops, fixed the typo. – Crucible

Answer 1

It depends when you want the code to run. If you want the code to execute ASAP you can use an IIFE but there is really no point using an IIFE if you don't use it to protect your variables and/or not polluting the global scope.

(function initialize() {
    // do somthing
}());

or

// do somthing

will execute at the same point in time.

If you want to defer execution there are three points in time usually used by web devs. <script>s at bottom, DOMContentLoad and window.onload.

• <script>s at bottom will execute after they are fetched from the server.
• DOMContentLoaded basicly execute as soon as </html> has been read by the HTML parser.
• very simplified window.onload executes after all CSS, <img>es and <script>s have been loaded.

Note that in reality, with attributes like async and defer on <script>s, this is more complex, . This is why there is a mountain of resource loaders available.

Sotted

Got it. I guess the issue of timing is more important than the performance here. Looks like, window.onload gives more flexibility in this respect. Would you agree? – Crucible

What if you do want to prevent pollution of global scope and defer execution until the DOM is loaded? Sounds like you would need both to use an IIFE and to listen for DOMContentLoad (and to wrap the latter in the former, yeah?). – Blank

No, you don't need a IIFE in this case. You only need a function bound to the DOMContentLoad event. JavaScript has function scope and nothing inside the function will leak out if you don't want to. – Sotted

Answer 2

Probably the result of each approach matters, not the performance. The first approach runs immediately while the second one waits until dom is ready. The end result is that in your first approach, you may end up getting undefined for both textInput and textResult, unless you place the script on the bottom of page.

Agram

Not " equvilant to jQuery.ready(", but equvilant to $(window).load() – Secundine

Unless mallgi01 moves his code to the bottom of the page! – Startle

Answer 3

The IIFE in a script element (whether inline or external loaded) just before the closing body element certainly appears most clever. It confuses the hell out of commoners.

document.addEventListener('DOMContentLoaded', function() ... is easy to understand. It's almost plain English: event listens for DOM content loaded. So, poof, the majesty is gone. Note this is distinct from window onload.

I use the event listener, as it adheres to the KISS principle, it's a purpose built tool, and it does what it says it does (which probably includes stuff/functionality I haven't even considered).

Zarger