> Performance is bad enough without putting the JavaScript intermediary in there
Flash performance is a combination of code and graphics. Taking LightSpark or Gnash would not give you something that integrates in an optimal way with the browser's hardware accelerated graphics systems, you would need to do a lot of plumbing for that. So yes, the C++ might be faster than JavaScript, but the graphics might end up making it less performant overall.
Plus, the native code is nonportable and nonsandboxed. Portability might be the simpler of the two, but it is still not trivial these days to maintain a single C++ codebase across multiple compilers and OSes. Sandboxing is the big problem though: A fast ActionScript implementation must have a JIT, and JITs are extremely hard to secure. The browser already has a dynamic language JIT (for JS), so using that instead of adding an entire new one is far preferable. In addition, the C++ code must be secured too which takes effort and introduces risk.
So there are very good reasons for going this route. But I agree there are tradeoffs and benefits the other way too.
Flash performance is a combination of code and graphics. Taking LightSpark or Gnash would not give you something that integrates in an optimal way with the browser's hardware accelerated graphics systems, you would need to do a lot of plumbing for that. So yes, the C++ might be faster than JavaScript, but the graphics might end up making it less performant overall.
Plus, the native code is nonportable and nonsandboxed. Portability might be the simpler of the two, but it is still not trivial these days to maintain a single C++ codebase across multiple compilers and OSes. Sandboxing is the big problem though: A fast ActionScript implementation must have a JIT, and JITs are extremely hard to secure. The browser already has a dynamic language JIT (for JS), so using that instead of adding an entire new one is far preferable. In addition, the C++ code must be secured too which takes effort and introduces risk.
So there are very good reasons for going this route. But I agree there are tradeoffs and benefits the other way too.