What would you want if backward compatibility was broken?

[Symbitic]

This might be phrased as a question, but I think it’s more like a feature discussion.

As we all know, the Babylon developers take great care to always maintain backward compatibility with every release. Even with the upcoming 5.0 release, everything should still work as-is. That has been a great boost to developers: they can rest assured their code won’t break just because a new release has been uploaded to the CDN.

But this comes at a cost: JavaScript is simply not the same language as it was when Babylon was developed. Promises, async/await, ES6 modules, and TypeScript did not exist back then. Building and maintenance is a hassle to get everything to behave the same. Side-effects significantly increase the build time, size, and complexity. When refreshing a page with a development build, there is a noticeable delay before the web page is available again. There are plenty of other compromises that the core developers have made over the years.

If the next release were allowed to break backward compatibility, what would you like to see done?

Please note: this is a purely theoretical discussion. The 5.0 release hasn’t even been released yet. It will be years before work on a 6.0 begins, even if it does decide to break backward compatibility

Here are some things on my wishlist:

1. ES6 modules only. It’s time to stop worrying about IE11. All modern web browsers now support modules. Browsers can import the built modules directly, or tools such as webpack or rollup will bundle them when
2. A better build system. No more globally installed Gulp required for contributing. I tried porting the build system to Rollup. You can read about my attempts here and see my old code on GitHub. It required all sorts of special tricks to get all of the same modules (and there are multiple copies of each module that must be built), type definitions, shaders, and everything else to work identically to the current system. I’d like Gulp to be replaced with either Rollup, webpack, or just plain-old tsc and leaving the rest to the browser or application bundler.
3. No side effects by default. This is the root of all evil in Babylon: it makes the file size explode. Tree-shaking just doesn’t work properly with side effects. At the very least, take advantage of modules by having them dynamically imported with something like async importSideEffects().
4. No callbacks for things like ImportMesh. You all-to-easily get into callback hell once you start hooking things up to the model you just loaded. Callbacks are fine for things like observables but for query-response type APIs, Promises should be used.
5. Remove old APIs like WebVR. This one is obvious enough. WebVR is deprecated and shouldn’t be used anymore.
6. Allow WebGPU without additional code. The upcoming 5.0 release will include WebGPU, but it requires a special WebGPUEngine. Migrate the regular engine to have initAsync and let the engine choose between WebGL and WebGPU.

Does anyone else have any fantasies about what they would like in a non-backward compatible release?

[RaananW]

I will let @Deltakosh answer regarding back compat, but I do have an answer for your wish list

@Symbitic

ES6 modules only. It’s time to stop worrying about IE11. All modern web browsers now support modules. Browsers can import the built modules directly, or tools such as webpack or rollup will bundle them when

Is planned, will be done. Hopefully for 5.0, probably a little after

@Symbitic

A better build system. No more globally installed Gulp required for contributing. I tried porting the build system to Rollup. You can read about my attempts here and see my old code on GitHub. It required all sorts of special tricks to get all of the same modules (and there are multiple copies of each module that must be built), type definitions, shaders, and everything else to work identically to the current system. I’d like Gulp to be replaced with either Rollup, webpack, or just plain-old tsc and leaving the rest to the browser or application bundler.

Same

@Symbitic

No side effects by default. This is the root of all evil in Babylon: it makes the file size explode. Tree-shaking just doesn’t work properly with side effects. At the very least, take advantage of modules by having them dynamically imported with something like async importSideEffects() .

Very much love this. And it is planned as well (same answer so far ;-))

@Symbitic

No callbacks for things like ImportMesh. You all-to-easily get into callback hell once you start hooking things up to the model you just loaded. Callbacks are fine for things like observables but for query-response type APIs, Promises should be used.

This is the first back-compat issue! probably not gonna happen. We do have ImportMeshAsync that returns a promise…

@Symbitic

Remove old APIs like WebVR. This one is obvious enough. WebVR is deprecated and shouldn’t be used anymore.

Planned.

@Symbitic

Allow WebGPU without additional code. The upcoming 5.0 release will include WebGPU, but it requires a special WebGPUEngine . Migrate the regular engine to have initAsync and let the engine choose between WebGL and WebGPU.

I’ll let @Evgeni_Popov / @sebavan answer that

[Deltakosh]

@RaananW

I will let @Deltakosh answer regarding back compat

Well I do not have much to add We protect backward compat and this is great for developers but it comes with some drawbacks
As @RaananW said we have plans to improve the situation though (without compromising backward compat)

[Evgeni_Popov]

@Symbitic

Allow WebGPU without additional code. The upcoming 5.0 release will include WebGPU, but it requires a special WebGPUEngine . Migrate the regular engine to have initAsync and let the engine choose between WebGL and WebGPU.

If you want to let the system use WebGPU if available and WebGL if not, use BABYLON.EngineFactory.CreateAsync(). This will first try to instantiate a WebGPU engine if available, else a WebGL engine, and if not possible will return a null engine.