I just mean if you import ammo or ammo typed from node_modules, it’ll get parsed in the build process. If you do it as a separate tag , the build tool wont see it at all
1 Like
This is why I don’t get loading Babylon via es6 imports. Especially if you’re using 70 -80% of the modules where tree shaking has limited value. It slows load down by 20 seconds or so versus a script import b/c it’s loading a giant bundle versus multi-threading load. Is the proper technique to break up the build into smaller vendor files? But even so, it then slows down the build process. For something like ammo that doesn’t get updated, i can’t imagine it making much sense to include in the build. Anyway, bit of a ramble, but webpack drives me up the wall.
that’s not webpack. this is vite 
Try it, you won’t regret it.
And webpack SHOULD cache this and not rebuild it when running the dev server.
Anyhow - this is just a suggestion. Make up your mind after making a clear decision based on your use case.
Eventually there will not be any need for a build process. You will just host modules and import them when needed. We are “half way there”, IMO.
Also, babylon mutates prototypes, which causes v8 to recompile every instance of that object every time the prototype changes. If you do it all up front it’ll feel less janky. Idk for sure but i suspect this is a pretty big roadblock to individual imports ever being faster for bjs. You can still do individual imports into kind of a app specific bundle of bjs, that definitely helps
A totally different subject/thread TBH, but this is an issue that will be addressed soon. I actually think we discussed it already.
Anyhow - if you want to continue this - open a new thread. Let’s let the OP have an answer without the extra overhead.
Hai hai
@jeremy-coleman @RaananW Thank you for the great suggestions! I’ll try both of them out
Though I am leaning a bit towards the ES6 module solution with ammojs-typed because i want to prioritize loading speed over a network over anything else, meaning sending as little data to the user as possible, even if it means crowding a single thread just to shave 20% of the entire JS that makes up Ammo.
I would like to assume that the target user of Babylon apps already has a somewhat decent processor to load and display a WebGL scene, but a good internet connection is not as guaranteed
1 Like