5 ms·

You need to use dynamic imports var myComponent = import('./myComponent') instead of classic imports import myComponent from './myComponent' Then We

You need to use dynamic imports var myComponent = import('./myComponent') instead of classic imports import myComponent from './myComponent' Then Webpack automatically generates separate js files and these files are loaded by the browser only when the dynamic imports are called. Reference: https://webpack.js.org/guides/lazy-loading https://webpack.js.org/guides/lazy-loading

RobertRoberts 9y ago
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?
- ggregoire 9y ago
  We don't use Webpack to build websites.
  - RobertRoberts 9y ago
    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?)
    - WorldMaker 9y ago
      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.
      - RobertRoberts 9y ago
        Aren't Electron builds done with Node.js though? https://electronjs.org/docs/tutorial/about https://electronjs.org/docs/tutorial/about This says it's made with Node.js...
        WorldMaker 9y ago
        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.
        joshribakoff 9y ago
        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
- WorldMaker 9y ago
  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.
- thelarkinn 9y ago
  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.
WorldMaker 9y ago
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`)

RobertRoberts 9y ago

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?

ggregoire 9y ago
We don't use Webpack to build websites.
- RobertRoberts 9y ago
  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?)
  - WorldMaker 9y ago
    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.
    - RobertRoberts 9y ago
      Aren't Electron builds done with Node.js though? https://electronjs.org/docs/tutorial/about https://electronjs.org/docs/tutorial/about This says it's made with Node.js...
      - WorldMaker 9y ago
        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.
      - joshribakoff 9y ago
        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
WorldMaker 9y ago
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.
thelarkinn 9y ago
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.

WorldMaker 9y ago

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`)