Native performance is wrong, javascript (unless it's like asm.js or something) will never be "native performance".
All CocoonJS is, is just a OpenGL layer with html/css/javascript support. And while it is faster then just flat out using JSC. It is not faster then c/objective c + opengl.
There have also been several reports of CocoonJS actually being slower then UIWebView. A simple google search for "cocoonjs performance" returned several issues.
That is not entirely correct - UIWebView canvas rendering is far behind OpenGL layers like CocoonJS, Ejecta or directCanvas(AppMobi) in terms of performance - the difference however is, that those tools are able to ONLY render canvas-contents, so you are not really able to render any HTML5 forms, input ect... but that's not what canvas-games are about.
It still uses Javascript. Native OpenGL+ObjC/C (done correct) will always be faster. All it really is, is better performance then UIWebView as it doesn't have all the webcore/kit stuff.
ALl I'm getting at is saying "native performance" is not correct. In a world where even 2-3 FPS can mean a usable game or a not usable game. I think the terminology matters a lot.
But you should still recommend people to using those solutions, just don't pass them off as something they are not.
Native performance is wrong, javascript (unless it's like asm.js or something) will never be "native performance".
All CocoonJS is, is just a OpenGL layer with html/css/javascript support. And while it is faster then just flat out using JSC. It is not faster then c/objective c + opengl.
There have also been several reports of CocoonJS actually being slower then UIWebView. A simple google search for "cocoonjs performance" returned several issues.