Nice article, thanks. I agree with your premise that we shouldn’t be using IIFEs unnecessarily.

I just want to point out that sometimes using IIFEs for closures can be beneficial. However those are fairly rare cases, so I still agree when you say “We don’t need IIFEs for closures as much anymore”. You don’t seem to be saying that we should never use IIFEs for closures.

A simple example is when using the facade pattern. It would also be helpful to not pollute the module with the real function. For example, when using recursion with tail call optimisation:

const sumRange = n => {
const _sumRange = (n, current = 0) => {
if (n <= 0) return current;
return _sumRange(n - 1, current + n);
return _sumRange(n);

_sumRange is essentially an IIFE. I’ve just separated the call into a different line for readability.

This is optional, and we could structure the code otherwise, but in my opinion it’s a bit cleaner than having the sumRangefunction in the module (especially if we have multiple other functions in there) or giving the user the option to use it when they shouldn’t do.

(As a final note, yes JavaScript doesn’t have tail call optimisation, but the exact same principle applies with the “trampolining” technique. That’s more complicated, so I used tail-call optimisation instead.)

Written by

Web developer — . Specialising in front end development. I love programming and strive to be the best software developer I can be.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store