Re:A look at asm.js and the future with WebAssembly
by flohofwoe on Saturday January 16, 2016 @08:53AM
(#10915260)
Good article. If the limitations of the web platform are taken into account from the beginning when writing multi-platform C or C++ code, and one doesn't go crazy with C++ templates, it actually is not too bad. Porting a huge existing code base with many external dependencies is quite another topic.
I found the performance of asm.js in current JS engines the least limiting factor, instead it's the higher level APIs like WebGL, WebAudio that become the limiting factor.
Also, existing (game development) middleware hardly focused on reducing code bloat so far, which then results in huge Javascript blobs (but also huge native executables).
I've started a little while ago writing a low-level C++ engine from scratch with all of this taken into account (here: http://floooh.github.io/oryol/) where the size of the Javascript blob is (roughly) in the same ballpark as a three.js demo (minified and compressed three.js is around 100kByte, Oryol 3D samples start around 90 kByte.
So basically: asm.js and WebAssembly yay, HTML5 APIs nay :)
I found the performance of asm.js in current JS engines the least limiting factor, instead it's the higher level APIs like WebGL, WebAudio that become the limiting factor.
Also, existing (game development) middleware hardly focused on reducing code bloat so far, which then results in huge Javascript blobs (but also huge native executables).
I've started a little while ago writing a low-level C++ engine from scratch with all of this taken into account (here: http://floooh.github.io/oryol/) where the size of the Javascript blob is (roughly) in the same ballpark as a three.js demo (minified and compressed three.js is around 100kByte, Oryol 3D samples start around 90 kByte.
So basically: asm.js and WebAssembly yay, HTML5 APIs nay :)