I'm not convinced this is the correct way to solve the problem of porting C++ to web.
AFAIK emscripten can grow heap now and the security implications seem irrelevant to me (you're still inside of a managed memory pool you're not going to do anything that JS code can't do already) - maybe it can allow for more XSS opportunities but I'm not a security expert, seems to me there are much easier ways to do XSS than exploiting bugs in compiled C++ code.
While allocating heap objects trough JS objects might allow VM to reduce fragmentation it's going to put big pressure on the GC (which is a big downside).
With WebAssembly coming up this approach will get even worse in terms of performance
I think the point about security is that a C++ program compiled to use a virtual memory array in javascript could be subverted (to do something the programmer and user did not intend) with a buffer overflow etc. the same way a C++ program compiled and running natively could be subverted. With this translation-to-js-objects kind of transpiling, the result is more like java - less arbitrary code execution, more "unhandled exception".
I wonder if it would be worthwhile to use Cheerp's approach to compile C++ to Dex bytecode for Android. Given that ART compiles Dex bytecode ahead of time to native code, what would performance be like? Yes, Android has the NDK, but apparently working with that is quite painful. And compiling C++ code to Dex bytecode would reduce package sizes, since it would no longer be necessary to ship binaries for ARM and x86, in 32-bit and 64-bit flavors.
I'm certainly ignorant on this, but why are we stuck with JavaScript? Seems like such a huge crutch, something people have been working to fix, or avoid, yet here we are still with it. Doesn't it make more sense to adopt the ffi model to gain access to things like sockets, files, canvas that the browser or even OS provides access to; similar to how you would program for mobile native apps. I don't understand the hold up of why we are stuck in this situation.
I'd say most of this is due to the issue of adoption. You can come up with a standard for native code, but if you can only run it in one browser that's basically useless. Even if all browser suddenly implemented some new native standard, then all existing browser instances that can't/won't be updated can't access your new shiny website.
Another issue is that native code, assuming that it's secure, is still not portable across different architectures. So you still end up having to have some sort of VM anyway to ensure portability.
That's basically where asm.js comes in. It's a static subset of javascript that allows it to be compiled, it becomes a VM. But since it is javascript, it will work on all existing browsers, they don't need to support a new standard. It'll just be slower.
What do you mean? You can already code in other languages besides JavaScript. With Emscripten specifically you can use the C++ extern keyword to call JavaScript functions.
Or are you wandering why you can't just run a high privileged system/machine specific binary directly from a web page?
Wouldn't it make more sense to improve Emscripten's huge TypedArray array so it can grow and shrink, or be chunked. Or maybe even implement a "virtual" TypedArray that you can just allocate as the full size of virtual memory.
I wonder why it's an issue to allocate 2GB of zeros anyway. With virtual memory, it should all map to the same zeroed page until they get written. And With transparent huge page support, it should only allocate few such pages until they get written.
Because many browsers are still 32 bit even in 64 bit systems. That means they get 2GB of virtual space in total. And frequently they don't have 256 MB of aligned and continuous virtual memory (and I suffered the pain of trying to develop a web application that uses 128 MB for months, in the end we ditched the C++ part).
That's fair, I guess. Although I thought browsers like chrome run every window in a different process, thus each has their own virtual memory.
I guess the browsers should specialize on very large typed arrays, because with asm.js etc they will most likely be very sparse (e.g. allocate 2gb of zeros, use 50mb).
Note though that the blogpost is 5 months old, and the comparison is out of date. For example, as also noted in other comments, Emscripten can handle memory as either
1. Singleton fixed typed array (what most users use; the fastest)
2. Singleton growable typed array (aka asm.js memory growth; still not optimized in all browsers, though)
3. Split memory, in which each chunk of memory can be allocated separately, which allows fully dynamic memory usage the way C and C++ do natively (allocating and freeing pages to the OS), https://github.com/kripken/emscripten/wiki/Split-Memory (but the flexibility makes it harder for JS engines to optimize)
AFAIK emscripten can grow heap now and the security implications seem irrelevant to me (you're still inside of a managed memory pool you're not going to do anything that JS code can't do already) - maybe it can allow for more XSS opportunities but I'm not a security expert, seems to me there are much easier ways to do XSS than exploiting bugs in compiled C++ code.
While allocating heap objects trough JS objects might allow VM to reduce fragmentation it's going to put big pressure on the GC (which is a big downside).
With WebAssembly coming up this approach will get even worse in terms of performance