Why is Babylon still not using WebAssembly?

I’d like to know why Babylon is still written entirely in Javascript and not making use of WebAssembly. If Babylon had it’s main target as WebAssembly and were written in a language such as C++, we would be able to use Babylon with many other languages, including Javascript, by use of scripting. We would also get much better performance and make targeting native platforms much easier. It simply makes no sense to write the core of an engine in Javascript when something like WebAssembly exists.

I am not asking to support another engine written in another language, which would be duplicating the efforts, I am suggesting that the core of the main Babylon engine itself should be replaced and written in a more performant language that is able to target WebAssembly, thus still supporting the web and with the benefit of being able to support many additional platforms.

Welcome to the community!

I don’t know much about WebAssembly but am aware it is being actively discussed. If you search the forums you may find more info but here’s an open Github issue, which would be a good starting point:

1 Like

You may also be interested in the Babylon Native initiative:


It actually makes a lot of sense (at least for us). We do not want to write the engine with C++ because our target is web developers. We want JS/TS developers to be able to contribute, open the source code and learn from it. Ask around in this forum for how many developers will be interested in using a black box instead of being able to read the code from a language they all know.

As @inteja mentioned you can dig into BabylonNative or GitHub - samdauwe/BabylonCpp: A port of Babylon.js to C++


Sorry to dig up the post, but do you have think use AssemblyScript ?
This is a similar language with ‘typescript’ but this is compiling to webAsm !


1 Like

We did (actually @jerome did) but it was not working when we tried

Actually it worked, but my attempts were quite simple… and painful to code. AssemblyScript has been greatly improving for months since those attempts.
Here’s my old test BabylonJS WASM SPS
40 K solid particles at this time. It should be faster (and easier to code) with the current version of AS.

@VSerain, Thanks for bringing that up. I have a set of Typescript libraries in simultaneous development, 6 at last count. They deal with very different types of data {phonetic english dictionary, audio fonts, animation, etc}. Having one floating garbage bag of a repo could get out of hand very quickly.

I had been thinking about doing rust in certain hotspots, but this sounds even better. If the BJS repo is going to try to do this, I think a lot of “little” back compatibility issues would be required. Probably need a BJS 5.0 major release to pull it off. Not that I am against that. For my own libraries, I do not maintain compatibility.

Things like union arguments number | number[] would have to go. Could get tricky when things like this are done in a constructor, since you can only have one. To avoid making the problem worse, adding stuff to BJS could try to live within some of the restrictions for new work, Basics | The AssemblyScript Book, thus keeping any refactoring down.

I will jump in. I wrote an open source utility in WebAssembly (md5-wasm - npm) and coded a lot of a BABYLON application in WebAssembly. WebAssembly is no panacea.

The technical issues are narrow and bothersome, code loading mechanisms, certain size limits and memory allocation – and maintenance costs will rise a lot, if the code changes. To prep conversion, you need to put everything in well-organized typed data structures that don’t move around a lot.

Having done that sort of grooming, you probably have already gotten most of your performance improvement. JavaScript compilers are very very good, especially if you follow certain rules. Generally I have gotten about 3x speed improvement in optimized WebAssembly over optimized JavaScript. The effort was high, though.

The MD5 function I mention above is a special case. An MD5 does about 20 million logic operations (UInt32) for a small file. This hits JS in a weak spot – my repo explains why. Since the calculation is standard and will never change, it was a good choice for an optimized WASM module.


i just wanna compare some web benefit from the native benefits

you always had a browser in any device and you don’t need anything for run your code

you keep requirement less for user so she / he just need now a url

c++ ? why not Java ? why Not … ? all language is a tools not the power
so it is war about be kill the application and have everything on the web
** it mean (html 5 ) not a babylon js

resource management ( web have 30 years targeting for management resource and load that same as streaming ,… )

secure ? who can make the secure than web definition you can log any request on the server and nobody can’t crack your app on registration ( all native local application have crack in my country :frowning: )

1 Like

@TheLeftover, picking your spots is really crucial. I quickly backed off on whole sale use a few minutes after I posted. Too many issues without any known gain.

That said, I have a C routine with high computation using specific types,

pitch shifting while maintaining duration using the Short Time Fourier Transform

I had tried to code it in typescript, but think Number is screwing things up. This case is not even just a case of speed up, but also bit manipulation not really working right.

Just wanted to drop a link to some examples of porting normal javascript to assembly script and how some folks have been going about it with three js source code being ported to assembly script

arbitrary node.js code


1 Like