Although this is very cool stuff, I have a hard time trying to understand where this is going to prove useful.
I would image that the major target for something like this will be in doing ports of old games to the browser. Anything other than that would seem like a non-starter.
I'm not sure why a developer would take the long road to write a c++ app with the intention of eventually converting it to javascript. Also, If your a company has the expertise you would be basically open-sourcing something that is closed source. So the business logic doesn't make sense unless you don't stand to make money on the code.
you would be basically open-sourcing something that is closed source
From my perspective, reading optimized builds is practically the same as reading assembly. In my opinion, it'd be easier to work from an unstripped mac/linux binary (i.e. with function symbols) than from optimized emscripten output.
There are at least 2 major scenarios where C++ ported to JS is useful:
(1) the web as "just another platform" next to desktop, game consoles and native mobile apps, the advantage here is that you can use the same code base for all platforms and only need a small percentage of platform specific code (about 2% platform specific code from my experience)
(2) cross-compile existing C/C++ middleware libs for use in "traditional" JS web apps, this has been demonstrated for physics engines (bullet), but would also work for pathfinding, AI, and other specialized libs
If you're concerned about opening up your precious source code by cross-compiling to JS, restoring the original code is just as complicated as restoring from a compiled binary, since the JS code has been generated from LLVM bitcode, and is additionally minified. You're basically getting a big, opaque ASCII blob out of an emscripten compile.
The only disadvantage of cross-compiled code is that you get a certain static size overhead for parts of the C/C++ runtime that gets compiled into the generated Javascript file which is somewhere between 100 and 300 kByte. This overhead gets (relatively) smaller the more complex the application is, and emscripten/LLVM is very aggressive about dead code removal.
So, a small web page which just wants to use some WebGL effects doesn't make much sense to write in C++, but once you start to write a real game and use JS libs like three.js (currently at 424kByte minified), the size advantage of manually written JS quickly disappears.
It's hard to overstate how fantastic (1) is. A single code base for all platforms is really amazing. C++ is much closer to universal than Python, Java, etc.
Besides performance, the big appeal for me is being able to build largish systems with the sanity-checking and refactoring support provided by strongly typed languages.
Comments
Although this is very cool stuff, I have a hard time trying to understand where this is going to prove useful.
I would image that the major target for something like this will be in doing ports of old games to the browser. Anything other than that would seem like a non-starter.
I'm not sure why a developer would take the long road to write a c++ app with the intention of eventually converting it to javascript. Also, If your a company has the expertise you would be basically open-sourcing something that is closed source. So the business logic doesn't make sense unless you don't stand to make money on the code.
Maybe i'm not being imaginative enough.
From my perspective, reading optimized builds is practically the same as reading assembly. In my opinion, it'd be easier to work from an unstripped mac/linux binary (i.e. with function symbols) than from optimized emscripten output.
There are at least 2 major scenarios where C++ ported to JS is useful:
(1) the web as "just another platform" next to desktop, game consoles and native mobile apps, the advantage here is that you can use the same code base for all platforms and only need a small percentage of platform specific code (about 2% platform specific code from my experience)
(2) cross-compile existing C/C++ middleware libs for use in "traditional" JS web apps, this has been demonstrated for physics engines (bullet), but would also work for pathfinding, AI, and other specialized libs
If you're concerned about opening up your precious source code by cross-compiling to JS, restoring the original code is just as complicated as restoring from a compiled binary, since the JS code has been generated from LLVM bitcode, and is additionally minified. You're basically getting a big, opaque ASCII blob out of an emscripten compile.
The only disadvantage of cross-compiled code is that you get a certain static size overhead for parts of the C/C++ runtime that gets compiled into the generated Javascript file which is somewhere between 100 and 300 kByte. This overhead gets (relatively) smaller the more complex the application is, and emscripten/LLVM is very aggressive about dead code removal.
So, a small web page which just wants to use some WebGL effects doesn't make much sense to write in C++, but once you start to write a real game and use JS libs like three.js (currently at 424kByte minified), the size advantage of manually written JS quickly disappears.
It's hard to overstate how fantastic (1) is. A single code base for all platforms is really amazing. C++ is much closer to universal than Python, Java, etc.
Besides performance, the big appeal for me is being able to build largish systems with the sanity-checking and refactoring support provided by strongly typed languages.