3 ms·

What you describe is a reoccurring theme when it comes to JavaScript applications in general, but it's much more visible when games are involved. The unfortuna

What you describe is a reoccurring theme when it comes to JavaScript applications in general, but it's much more visible when games are involved. The unfortunate reality is that JavaScript, WebGL, and these other technologies running on extremely powerful computers (even if we're talking modern mobile devices) still can't compete with games written back in the 1980s, in C and assembly, which ran perfectly fine on what are now 25-year-old 386 PCs with a mere fraction of the processing capabilities of a modern system. As an industry, or even as hobbyists, we should not be in this position. At best, we can call the current situation a complete stall in advancement. At worst, but more realistically, it's been a significant step backward.

antimagic 13y ago
It's not really a fair comparison - much of a game's work is pushing pixels, and today's systems have an order of magnitude more pixels to push (1080p = 2MegaPixels, 640 x 480 = 300 000 pixels). Today's game written in Javascript will also run on numerous different CPU architectures, on different OSes. This generality means that you can't take advantage of platform specific hacks that allow the eking out of every last scrap of performance from the silicon. So yes, when you make a game do a lot more work, and you want it to run on multiple platforms, forcing optimisations to be platform-agnostic, you shouldn't be surprised that it's hard to match the performance of 25 years ago. On the other hand, if you use the same technologies as 25 years ago, you'll smash the performance from back then. Likewise, if you try to run SimCity in a browser ported onto a 386 PC, it would be an insult to dogs to say that it runs like a dog...
- willvarfar 13y ago
  I think its an entirely legitimate observation. The screens are bigger, but the CPUs are several orders of magnitude faster ... on paper. As I specified that it was a webGL game, we understand that actually there's more CPU than ever to focus on the actual sim crunching. Its a sad observation that there is approaching an order of magnitude performance gap between chrome and FF on this type of Javascript performance, and many orders of magnitude between JS and bare metal.
- lucian1900 13y ago
  But the difference between NaCl and native is almost nothing, and that's almost as portable. Even PNaCl has almost native performance, and that's precisely as portable as JavaScript. The web as a platform is terrible, despite the amazing work of browser vendors.
- PommeDeTerre 13y ago
  There are only about 7 times more pixels in the modern system in your example. Yet in the same time, x86 processors have gone from 25 MHz to 3,000 MHz, if not higher. That's a difference of 120+ times. That's not even considering that basically all PCs (including laptops) and many mobile devices, now have CPUs with at least 2 cores, although 4 or 8 cores is pretty typical, too. Back then, uniprocessor PCs were really the only practical option. The amount of memory available today is significantly larger, too. At the end of the 1980s, it was impressive to have 2 MB of RAM in a desktop PC. These days, we're generally looking at 4,000 MB of RAM, if not more. That's 2,000+ times more RAM today! When it comes to mobile devices, we're still looking at hundreds of times more RAM. The speed of memory today is also much faster than it was back in the 1980s. And, of course, we've seen absolutely massive strides in video card technology in that same period of time. Given those kinds of increases in the power and amount of resources that are available now, JavaScript and the other web technologies have absolutely no excuse for performing as poorly as they do. I don't even buy the argument that JavaScript is much more portable than C was back then. SimCity was ported to many, many platforms. I remember playing it on PCs running DOS, on an Amiga, and even on an SNES at one point.
daredevildave 13y ago
What? Sorry, that's just not true. MS-DOS games in 1992: http://www.youtube.com/watch?v=D6E4FZdY-pM http://www.youtube.com/watch?v=D6E4FZdY-pM JavaScript games/tech in 2013: http://playcanvas.com/demos/ http://playcanvas.com/demos/ http://services.runescape.com/m=itemdb_rs/bestiary/?show=50 http://services.runescape.com/m=itemdb_rs/bestiary/?show=50

antimagic 13y ago

It's not really a fair comparison - much of a game's work is pushing pixels, and today's systems have an order of magnitude more pixels to push (1080p = 2MegaPixels, 640 x 480 = 300 000 pixels). Today's game written in Javascript will also run on numerous different CPU architectures, on different OSes. This generality means that you can't take advantage of platform specific hacks that allow the eking out of every last scrap of performance from the silicon. So yes, when you make a game do a lot more work, and you want it to run on multiple platforms, forcing optimisations to be platform-agnostic, you shouldn't be surprised that it's hard to match the performance of 25 years ago. On the other hand, if you use the same technologies as 25 years ago, you'll smash the performance from back then. Likewise, if you try to run SimCity in a browser ported onto a 386 PC, it would be an insult to dogs to say that it runs like a dog...

willvarfar 13y ago
I think its an entirely legitimate observation. The screens are bigger, but the CPUs are several orders of magnitude faster ... on paper. As I specified that it was a webGL game, we understand that actually there's more CPU than ever to focus on the actual sim crunching. Its a sad observation that there is approaching an order of magnitude performance gap between chrome and FF on this type of Javascript performance, and many orders of magnitude between JS and bare metal.
lucian1900 13y ago
But the difference between NaCl and native is almost nothing, and that's almost as portable. Even PNaCl has almost native performance, and that's precisely as portable as JavaScript. The web as a platform is terrible, despite the amazing work of browser vendors.
PommeDeTerre 13y ago
There are only about 7 times more pixels in the modern system in your example. Yet in the same time, x86 processors have gone from 25 MHz to 3,000 MHz, if not higher. That's a difference of 120+ times. That's not even considering that basically all PCs (including laptops) and many mobile devices, now have CPUs with at least 2 cores, although 4 or 8 cores is pretty typical, too. Back then, uniprocessor PCs were really the only practical option. The amount of memory available today is significantly larger, too. At the end of the 1980s, it was impressive to have 2 MB of RAM in a desktop PC. These days, we're generally looking at 4,000 MB of RAM, if not more. That's 2,000+ times more RAM today! When it comes to mobile devices, we're still looking at hundreds of times more RAM. The speed of memory today is also much faster than it was back in the 1980s. And, of course, we've seen absolutely massive strides in video card technology in that same period of time. Given those kinds of increases in the power and amount of resources that are available now, JavaScript and the other web technologies have absolutely no excuse for performing as poorly as they do. I don't even buy the argument that JavaScript is much more portable than C was back then. SimCity was ported to many, many platforms. I remember playing it on PCs running DOS, on an Amiga, and even on an SNES at one point.

daredevildave 13y ago

What? Sorry, that's just not true. MS-DOS games in 1992: http://www.youtube.com/watch?v=D6E4FZdY-pM http://www.youtube.com/watch?v=D6E4FZdY-pM JavaScript games/tech in 2013: http://playcanvas.com/demos/ http://playcanvas.com/demos/ http://services.runescape.com/m=itemdb_rs/bestiary/?show=50 http://services.runescape.com/m=itemdb_rs/bestiary/?show=50