4 ms·

Of course the little detail here is that 50 tiny sprites apparently counts as graphically intensive. Why do web developers constantly make the argument that Ja

Of course the little detail here is that 50 tiny sprites apparently counts as graphically intensive. 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.

dleslie 10y ago
It's a cargo cult.
debaserab2 10y ago
Who makes that argument? No one suggests that.
erikpukinskis 10y ago
> The difference is night and day, 5000% and up for simple things like drawing. 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.
- GuiA 10y ago
  > 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. ...that's not how graphics benchmarking works. That would be like benchmarking a language by seeing how fast it can add up integers.
  - SomeCallMeTim 10y ago
    Actually their example of iterating over an array and making WebGL calls is very close to exactly what you need to benchmark.
    - candiodari 10y ago
      It would seem more to the point for me to compare something like a game downloaded from steam with a webpage, as that is directly comparing the user experience. 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.
  - pcwalton 10y ago
    > That would be like benchmarking a language by seeing how fast it can add up integers. So you mean like most language benchmarks. :)
- Game_Ender 10y ago
  WebGL has really high draw call overhead compared to native OpenGL. The rough rule of thumb is that you can do 2000% [0] the draw calls in a native app per frame than you can do in WebGL. It's not about execution performance it's about overhead of leaving JS and converting data to the format the GPU needs. 0 - http://floooh.github.io/2016/08/13/webgl-next.html http://floooh.github.io/2016/08/13/webgl-next.html
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 ago
    By 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 ago
      You mean like NativeScript? https://www.nativescript.org/ https://www.nativescript.org/
    - pcwalton 10y ago
      How would that differ from WebGL?
pcwalton 10y ago
> 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. 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.
- candiodari 10y ago
  But this is beside the point. Firstly, I've been doing demos for years, so 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.

dleslie 10y ago

It's a cargo cult.

debaserab2 10y ago

Who makes that argument? No one suggests that.

erikpukinskis 10y ago

> The difference is night and day, 5000% and up for simple things like drawing. 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.

GuiA 10y ago
> 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. ...that's not how graphics benchmarking works. That would be like benchmarking a language by seeing how fast it can add up integers.
- SomeCallMeTim 10y ago
  Actually their example of iterating over an array and making WebGL calls is very close to exactly what you need to benchmark.
  - candiodari 10y ago
    It would seem more to the point for me to compare something like a game downloaded from steam with a webpage, as that is directly comparing the user experience. 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.
- pcwalton 10y ago
  > That would be like benchmarking a language by seeing how fast it can add up integers. So you mean like most language benchmarks. :)
Game_Ender 10y ago
WebGL has really high draw call overhead compared to native OpenGL. The rough rule of thumb is that you can do 2000% [0] the draw calls in a native app per frame than you can do in WebGL. It's not about execution performance it's about overhead of leaving JS and converting data to the format the GPU needs. 0 - http://floooh.github.io/2016/08/13/webgl-next.html http://floooh.github.io/2016/08/13/webgl-next.html

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 ago
  By 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 ago
    You mean like NativeScript? https://www.nativescript.org/ https://www.nativescript.org/
  - pcwalton 10y ago
    How would that differ from WebGL?

pcwalton 10y ago

> 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. 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.

candiodari 10y ago
But this is beside the point. Firstly, I've been doing demos for years, so 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.