Your thoughts on PlayCanvas supporting http://webassembly.org/ in feature?
Hi @trsh.
We’ve been looking at WASM and it’s development. But, there is very little benefits to use it it actually has more negatives for Vanilla JS libraries and engines:
- Source code should be written in LLVM friendly language, most common C or C++. This will make our engine not web-friendly for web-developers.
- Debugging will be not easy at all. As wasm - is stored in binary form, partly pre-processed to allow JS engines to minimize time spent parsing code. This makes debugging nearly impossible.
- Speed benefits are questionable in real world applications. Some speed up can be achieved by making some maths faster, but in real apps this is not the bottleneck, but actually user code and GPU - is the bottleneck, so this will not be speed up by wasm.
- It will likely make our engine size bigger as in C you would need to write more code than same implementation in JS. This will lead to longer loading times.
- There is no GC (Garbage Collection) available from wasm, it is not easy to deal with Web APIs from wasm, and development process is actually less comfortable comparing to Vanilla JS.
WASM is created to help bring big and bulky stuff to the web. Stuff like Unity and UE4 or any other things, that has not been created for the web, but they keen to get their engines to somehow run in the web.
WASM is not needed for vanilla JS libraries and projects, only in extremely rare edge-cases for very small parts that could make some crazy maths faster. But there is GPU access using WebGL, and very big chance it could be off-loaded to GPU, so no wasm needed, again.
1 Like
Thanks! Very reasonable explanation.
I do miss a lot of stuff in Vanilla (like compilation errors, enums, classes with priv. and publ. methods, etc.). Especially when the project get’s larger, it’s hard to maintain it and avoid typed/logic errors (and even harder to find them). So WASM is clearly an overkill, but maybe typescript could be considered 
Sorry for turning you down twice in a row (double kill! 
) but here is just recent github ticket regarding TypeScript and explanation about why we don’t have it: https://github.com/playcanvas/engine/issues/899
A lot of typing errors can be cached using JSLint and warnings in IDE. Some consistent coding standards might help as well, like naming convention for private/public properties and methods.
There is nothing you cannot do with vanilla JS that you could do with WASM. But there are many-many obviously limiting and just hustle to follow rules developing with C when targeting a web. Speed of development with C will be much slower than with JS. And obviously with C application can be made as hard to maintain as in any other language. This is more down to some discipline and conventions put in place by developer.
For example, our Editor is 318 JS files (concatenated in one) and 72,500 lines of code. But the way it is structured and the concepts used around the codebase, keeps us easy to extend it and add stuff to it, without slowing down development process as we go.
If we talk about structure/OOP, Yes. If we talk about not calling a function with string arg, where integer was meant (or with wrong count of arguments) - then not. In my experience TypeScript initially shows down the development process, but in long term it’s a win in all directions.