Yep, I would recommend terser as well. It is well integrated in the tools and wonderfully configurable.
I would also recommend using dynamic loading and chunks to allow the user to download what they need when they need it instead of a single large package with all dependencies.
Just wondering - what looks weird? is it too much or too little?
That’s interesting approach. I don’t know actually is it improve loading process or not. Depends on current project I think. But I definitely should give it a try. As for now I don’t think it’s profitable approach for my projects as I think my projects load all the dependencies right at the start In this way the speed of loading will decrease because of many requests making to a server for all of those dependencies + an additional delay for loading each module.
Parallel downloading of resources will result in a faster load of your page. Better yet - loading only what is needed for your opening screen, and downloading the rest while the user interacts with whatever on the opening screen is a wonderful approach for a fast, intuitive, and user-friendly website
Wow, I didn’t think about it. Definitely I should try to use soon!
I remember as I had been figthing with my webpack for 2 days to avoid creating chunks. So now it’s time to try to turn it back Thanks for your thoughts on this subject!
Another consideration is that Babylon currently uses side effects quite a bit, which means if you aren’t careful with your imports, you can easily pull stuff in that is never actually used at runtime. For our new Babylon Viewer, I used code coverage tools (I used Istanbul, maybe Chrome Dev Tools code coverage would be enough in your case) to find code that wasn’t being executed, then some custom tooling leveraging Rollup to understand why different modules were ending up in the bundle (e.g. the import chain). @sebavan also suggested https://webpack.github.io/analyse/ might be helpful for bundles created with WebPack, but I haven’t tried it yet.
Sorry, I don’t understand what are you talking about. Tree shaking feature works in another way. Here is the setup for ES6 tree shaking: Babylon.js docs
Nothing complex there! You just need to include “very precise” imports like:
import { HemisphericLight } from "@babylonjs/core/Lights/hemisphericLight";
and avoid imports for the whole your project like this:
import { HemisphericLight } from "@babylonjs/core";
← in this case you will import all the BJS code in your bundle.
Then, don’t forget to set in your webpack.config.js:
optimization: {
usedExports: true,
},
in case you use webpack. Or something similar if you use Vite or other bundlers.
Yeah, and don’t forget about some “silent” imports that you should import because some thing will not work without it. You find them in that ES6 article or find by yourself using IDE suggestions. Here are some of them:
Would be great to know which part is not understandable, so we can improve the docs and provide our users with everything they need to get what they want.
The general idea of tree shaking is - don’t import the entire framework, just import what you actually need. The rest of the work is done using your bundler (if you use one). Terser/webpack/rollup/vite - these are just tools that will do the magic of bundling, minifying and so on to your code.