hardware is not so limit as you think !
You are still missing my point. If a game is slow because it is drawing more to the screen than the GPU has bandwidth to handle, then it doesn't matter what technology you use. You could write it in carefully optimised C++, or even hand-tuned assembly instructions, and it would not be any faster at all, because the bottleneck is in the GPU hardware. The only way to optimise in that case is to draw fewer objects, which you can already do in C2.
This thread highlights exactly my resistance to making native exporters. People identify that the game is slow on weak hardware, specifically call out a case where GPU hardware limitations are the bottleneck, and then ask for native exporters as a solution. In the described situation, the suggested solution will not help. Developing native runtimes to try and fix that case is pure folly.
As I've always said before, WebGL uses the GPU pretty much identically to a native app. Javascript has some performance overhead, but it's generally not the bottleneck except perhaps in a minority of exceptionally complex games. And with modern devices like the iPhone 6S benchmarking close to laptop CPU performance and continuing improvements to Javascript JIT compilers, this overhead is becoming even less significant. Were it a significant problem, something like WebAssembly would solve it in a far more practical and portable manner.
Anyway few people seem to understand the hardware issues involved here, so I guess we will face continuing calls for native exporters to fix hardware limitations :-\