Ok, so it doesn't lazy load CSS and images, just js?

If so, what does this improve? Time to first paint? Time to first interaction? Time to DOM ready? I looked at their page, and it doesn't seem to answer questions like this simply. It just says when a user requires the code it loads it.... huh?

How much code are people putting into their apps that this would ever be needed? (serious question)

When I do site analyzing, 99/100 the images/css are the biggest contributors to site size, have JS libraries gone nuts?

You can use it to lazy load CSS/images/anything you have a webpack loader for. Some of the loaders like CSS can't help but be sideeffect-full, so lazy loading them isn't always the best plan, but it certainly is possible.

> If so, what does this improve? Time to first paint? Time to first interaction? Time to DOM ready?

Could be any or all of those, yes, depending on architecture. Webpack bundles CSS, images, etc into combined JS files ("chunks"), tries to get the important hot path stuff into the first chunk, and then load other chunks as needed. With dynamic loading you can further make sure that additional chunks load out of the hot path, after first paint/first interaction/DOM ready/whatever else.

The number one cause of slowness for a page is the time it takes to parse, eval, and execute JavaScript (even if it is dead code).

So this static async bundle creation helps ensure that you are only shipping what you need on initial download.

We don't use Webpack to build websites.

I am in a couple threads discussing this, so I apologize if this is doubling things up.

To be redundant (for absolute clarity) you know how to use Webpack, you do use it, it offers value to you, but not for building websites? Can I assume it only has value (for you) with building complex webapps? (can I also assume this is for Node.js?)

At this point I've used it for web pages, web apps, Electron builds, and haven't needed to but could have also used it for Node.JS server apps as well. Webpack is certainly flexible enough for all of the above.

Aren't Electron builds done with Node.js though?

https://electronjs.org/docs/tutorial/about

This says it's made with Node.js...

Electron embeds Node.js, of course, but from a platform standpoint feels sufficiently different from a Node.js server application (the more traditional use of Node.js) or console application (a growing usage of Node.js) that it can be useful to make a distinction. Especially, because the bulk of an Electron app in my experience is running in the Chromium web renderer process(es) ("client side") than in a more traditional Node.js process.

One technique I used to build an electron app was developing in the browser, and then using a webpack plugin to copy the generated bundles from my web app into a shell app & trigger the electron build. In this way I wrote one version of the code which ran in both browser & electron app. I have used the same technique for other platforms like Cordova

Dynamic imports return a promise, so it's more like:

    import('./myComponent').then(myComponent => /* ... */)

Or:

    const myComponent = await import('./myComponent')

That quibble aside, it's also relatively powerful:

    const dynamicComponent = await import(/* webpackChunkName: "components" */ `./components/${componentType}/index`)