Right, yeah, thanks! I meant, it took a number of replies before anyone mentioned it. (updated the post as you were typing that)
Asset containers are relatively new. We will continue to improve as we go. It’s documented here: Asset Containers | Babylon.js Documentation (babylonjs.com). Contributions to improve the documentation is certainly welcome.
Babylon scenes have a cache of all of the nodes in the scene hierarchy in a flat array. Adding to individual nodes of the hierarchy will not update this cache and maybe will be slow if we did. I’m guessing this is different than what other engines do.
I think you have experience with other engines that work differently and thus you have “intuition” that it should work a certain way. I’m not saying it’s bad intuition but changing API contracts is not something we do lightly due to our commitment to backward compatibility which few JS libraries do.
1 Like
Deprecation within our team is a complex topic that we’ve been discussing at length. Babylon maintains a strong commitment to backward compatibility, even between major versions. This means that code written for Babylon 3 should ideally work seamlessly with Babylon 6. We only break backward compatibility when a browser API changes, necessitating adjustments for continued functionality.
In terms of deprecation in a back-compat-enabled framework, we follow a specific approach. When we decide to deprecate a function or API, we mark it as deprecated without removing it. Instead, we continuously introduce new functions, create updated versions of APIs, or extend the contract of specific functions to ensure smooth transitions for developers.
For instance, our physics engine architecture offers an excellent example. We maintain the old API, allowing users to upgrade to newer versions of the engine without issues. However, if developers wish to adopt the new physics architecture, they will need to make some code adjustments to ensure compatibility.
It’s important to note that the deprecation policy applies to current public packages like “babylonjs” and “@babylonjs/core.” These packages will remain backward compatible. On another note, we are working on porting the engine to a more ES-modules-friendly architecture, but this is still a work in progress and not yet ready for demonstration. Once completed, this new package will not be backward compatible, as the API will undergo significant changes, and we will remove deprecated functions.
However, the development of this new package is quite extensive and will require substantial time and effort before it becomes fully functional. Until then, our deprecation approach will continue to ensure smooth transitions for our users while maintaining a commitment to backward compatibility.
TL;dr - we do deprecate functions and APIs, but we never remove them from our public APIs, prioritizing the seamless experience for developers across different versions of Babylon.
4 Likes