Why do web developers constantly make the argument that Javascript is not slower than C (or Swift, or C++, or any native programming language) ? The difference is night and day, 5000% and up for simple things like drawing.
Why do web developers constantly make the argument that Javascript is not slower than C (or Swift, or C++, or any native programming language) ? The difference is night and day, 5000% and up for simple things like drawing.
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.
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.
I find that seriously doubtful, you're going to have to provide a citation if you want me to swallow that.
The relevant comparison is a single JavaScript function in Firefox looping through a static array and making WebGL calls vs. a C++ function looping through the same array and making OpenGL calls.
If the difference is 5000% or more I will donate $20 to the charity of your choice.
...that's not how graphics benchmarking works. That would be like benchmarking a language by seeing how fast it can add up integers.
If you artificially limit the scope to something trivial, anything can work. I mean, that might be interesting for web browser developers, sure, and by all means, use it for that. But what matters is what experiences can be created by it.
The web experience for games sucks.
So you mean like most language benchmarks. :)
Probably because that's completely untrue, and would be irrelevant even if it were true.
If you're doing "drawing" (which in this case means blitting) on the CPU to begin with, you've already lost.
1) it is possible, even at high resolutions
2) anything worth doing in opengl can't work in javascript for other reasons (mostly data size). And yes, you could download hundreds of megabytes worth of data files just to show an intro screen and then a few gigabytes for a game over an internet connection. I hope you have patient customers and a huge webhosting budget.
So let's be honest here : for small games, the effort of doing it with OpenGL/WebGL is not worth it. For large games it cannot be done, but for other reasons (that actually also apply to small games: 50 megabytes is incredibly oversized for a webpage, but still rather small for a game, so these problems actually overlap)
I myself feel guilty for stating this, but it actually works better to render the entire game server-side and videostream it to the client. Yes, javascript (and the web ecosystem) is that bad.
Is there no use for it ? Well, I appreciate the speed at which I can try out shaders locally. None of the niceties of javascript such as debugging or any sort of development process work, but it's still nice that you can get up & running in an hour or so.
But any reasonable game on javascript or the web platform ? Doesn't work and at this point it's so far from working it's a bad joke.