sgomes
commented
7 years ago Note that that target you're pointing to is used for the optimized bundled version; the unbundled code never goes through that. It wouldn't make a lot of sense to output a bundled version as an ES module in this case, since it's not meant for reuse, and bundled JS is usually trying to target browsers that don't support ES modules anyway. The IIFE isn't used as a performance boost, it's simply the output format for Rollup that outputs the closest thing to vanilla, non-module JS.
For the unbundled versions (i.e., the ones that are output as ES modules), we don't use IIFEs at all. In fact, all we do is rewrite the import statements to work on the browser: https://github.com/GoogleChromeLabs/samples-module-loading-comparison/blob/master/gulpfile.js#L161
A minor observation is that the "optimized" build outputs as an IIFE rather than an ES module.
https://github.com/GoogleChromeLabs/samples-module-loading-comparison/blob/master/gulpfile.js#L186
I wonder if this was on-purpose? Actually my real question is: do modules need to embed code in an IIFE to disable pre-parsing? i.e. did you do this to boost performance? It would be sad if all deployed ES modules had to be IIFE-wrapped to achieve maximum performance.