4 ms·
C is always going to be faster than almost anything you compare it to, of course. But the V8 interpreter is also not 5000% slower; for computationally intensive
by Mahn 10y ago
C is always going to be faster than almost anything you compare it to, of course. But the V8 interpreter is also not 5000% slower; for computationally intensive tasks it's not actually significantly slower. The problem in OP's case is that JS lacks an interface to interact with the display and render that is as "close to the metal" as their "native" counter parts. You are drawing sprites on a html canvas which is then rendered by a web view, which just not that great no matter what language you use to get there.
What I'm getting at is that it's easy to blame Javascript, but really that's not the whole picture, and if Google and Apple chose to support Javascript natively it wouldn't have these dramatic performance issues.
- pcwalton 10y ago> Google and Apple chose to support Javascript natively it wouldn't have these dramatic performance issues What would "supporting Javascript natively" mean? If you mean AOT, classic AOT (without some pretty fancy research-level PGO or something) is not a viable compilation strategy for JS. I do agree heavily with your overall point that the JS blame is misplaced. People often forget that JS is faster than Objective-C at important things like method calls for systematic reasons.
- Mahn 10y agoBy supporting natively I mean provide a layer of APIs that let developers interact with the phone and in particular with the display at a low level, while still writing JS; I imagine that if you could draw on the screen bypassing canvases and html views entirely it would solve most issues.
- DonHopkins 10y agoYou mean like NativeScript? https://www.nativescript.org/ https://www.nativescript.org/
- pcwalton 10y agoHow would that differ from WebGL?
- LeoNatan25 10y agoI assume the grandparent means access to UI APIs, not just drawing. I think there would still be significant performance drawbacks to "native JS".