Hi all, I’d just like to say that I am really impressed with the Babylon engine and I am a recent convert from three (I hope I’m allowed to mention that library here!?).
I’m working on a pretty large project for a construction company and some of the other devs are not as enamoured with Babylon as I am. The source of the issue is bundle size.
Now I know that this issue has arisen before and the solution seems to be a more fine-grained specification of import paths than the usual “@babylonjs/core” (for example). However, this isn’t really an option as we have quite a lot of code and the other devs are going to use this as a stick to beat me with if I suggest changing all the imports now, and we’ll almost certainly go back to three (which I actually don’t want to do). Our current bundle size is over 6MB and this is pretty much all down to Babylon according to the visualizer. Although I can’t give you any details from the project, I have experimented with a smaller project of my own and the bundle size there is over 4MB (detals here if relevant → GitHub - DoctorTone/babylonMatEditor: Physical material editor for babylonjs). Is there anything that I can do to bring the size down? Any help would be greatfully received, thanks.
hi @DrTone - Welcome to the forum!
I don’t think it’s possible to gain tree shaking without explicit imports.
Babylon.js ES6 support with Tree Shaking | Babylon.js Documentation (babylonjs.com)
You could bundle your own version with that you needed, but it’s not how I would try to solve.
If you are using model loader you can be explicit there and get some gains as well. The visualizer will show the low hanging fruit.
Hi, thanks @brianzinn, I’ll look at how much work there is to modify the imports. I think we’ll just have to go with it, at least I only have to do it once! Many thanks!
I can’t believe that anyone who has used Three after using BabylonJS would prefer Three, but it really isn’t that bad. If you already use named imports to just import what you need, you’ll just be swapping out the from babylonjs with from @ababylonjs/XXX. I will tell you that it can be tricky to get it to include everything you need, as there are some functions in BabylonJS that are not actually defined in the module with the class. For example, if you want to use scene.createDefaultCameraorLight or scene.createDefaultEnvironment, you will actually need to import import "@babylonjs/core/Helpers/sceneHelpers";. There can be some trial and error involved, but once you do it the results will be well worth it.
One other thing I’ll mention is that I was able to get tree shaking to work very well using Vite, but I haven’t been able to get Angular to do as good of a job. I created a post about it, but have yet to find anyone who is doing tree shaking with Angular.
Hi, yes, sometimes I think people get obsessed with one technology over another or just like using something so much that they won’t ever consider changing. The arguments against Babylon were performance issues (with very limited metrics), bundle size (which we have hopefully addressed) and number of downloads (which is always a factor but not enough on it’s own in my opinion). I loved using three, as I said I used it for about 10 years! The one area where I think Babylon does lag behind is integration with React. The react three fiber library is very impressive and doesn’t seem to be something that Babylon has an equivalent to (yet!?).
Hi, I think I did give this a very quick look over and I have combined the two, just not sure that it’s quite as evolved as react three fiber. I will definitely give it another glance, thanks!
@DrTone i had similar concerns on bundle size. using es6 imports was the key. thinking about how to modularize the architecture more was helpful… single responsibility principle applies. I know thats easier said and done when migrating from another platform. 
We got things down to a reasonable size. We service millions of concurrent users and BJS has been awesome. It scales. Im curious if you woudlnt mind sharing how large your bundles are on threejs vs what you are seeing in bjs? The question of bjs vs threejs is about your usecase, i think they are both great and I will say threejs is better for ‘minimal’ applications that dont need all the advanced features babylonjs offers. Just depends on your usecause and your customers needs now and in the future.
what build tools are you using? have you looked into using some npm tool that also creates gzipped versions of assets?
my dist code for babylon is ~ 2.5mb and gzipped its ~500kb
( yes , you do need targeted imports for tree shaking )
( some things like the debug layer and inspector should be excluded in production because they do bump up the size quite a bit )
Hi, sure, at the moment our bundle size is approx 6MB, most of that being Babylon. In my smaller app the bundle size is about 4MB (all before gzip), with all of it being Babylon, as there’s nothing much else in the app!. I’ll experiment and see what I can get these down to. It does seem as though a reasonable reduction is possible after some more targeted imports, I will let you know. It also seems that the community on here is very helpful 
!!
Do you have sourcemaps enabled? They add much to the size. Here is my own question related to the bundle size - How to achieve the most minimal build size
A quick way to change all import is to create a proxy module in your code 
Swap all your imports from babylon to this file, and in only this file, re-export only the part you use from babylon.
If you use code splitting use as many modules as expected chuncks.