High coupling in the Babylon codebase compared to Three.js


I wanted to ask if anyone else feels that things are too tightly coupled in Bablyon compared to, for example, Three.js.

A while back, I started a port of Three.js to AssemblyScript (TypeScript to WebAssembly compiler):

I originally was interested in Babylon because it is already written in TypeScript, so porting would be easier.

However, when I started to port classes, I soon realized that the everything in the library is highly coupled: importing Babylon’s Scene class means practically importing the whole Babylon library and instantiating many parts of the library (new This, or new That) even if those parts will never be used.

Essentially, with Babylon you want the banana (f.e. Scene) and you get the Gorilla and the whole jungle (rest of Babylon lib).


To get an understanding of this, look at the import statements in Babylon’s scene.ts:

Just the import statements alone cannot be viewed on one page or one screen.

In contrast, the Three.js code base is much more loosely coupled, which to me is very attractive from a code authoring perspective, so I ended up choosing Three.js and accepting more work in porting JavaScript instead of TypeScript because I felt the end result would be cleaner.


As an example of Three’s lose coupling, here is Three’s Scene.js:

(Babylon’s forum blocks links to Three.js, so I posted it unlinked.)

Explore the code base, and you’ll see that classes try to be minimal, do only one thing well (or representing only one concept well).

After starting the port of Babylon, going back to Three.js felt pleasant.

Has anyone else (especially on Bablyon’s team) thought about this difference between Babylon and Three.js? What are your thoughts on this? Are there any plans or desires to decouple the Babylon code base?

I replied to you on Twitter (you were flagged as spam by Discourse for some reason :slight_smile: )
Here is a copy of my answer:

For the coupling question, you have to remember that BJS is developed with TS so importing the types are mandatory to get TS to compile (which is clearly easier if you create your engine with JS).

That being said, we try as much as we can to use only the interface to reduce that “cost” (from scene):

The scene is somehow the worst case scenario as it contains everything else (because it stores meshes, lights and all the scene graph family). Thus due to TS we need to import these classes.

The current (on going) work is to make sure we rely on declare as much as possible (when there is no need for constructors or instanceOf)

In a nutshell: I understand your concerns but this is really inherent to TS (where three.js is a framework developed with JS and where they compute the d.ts as part of their build).

More reasoning why I still believe TS is a great choice (at least for babylon ;)): Why we decided to move from plain JavaScript to TypeScript for Babylon.js | Eternalcoding