It’s more than whether JavaScript is suitable for games or animation.
I recently wrote about the troubles I had using the JavaScript-based Brickslayer game. Please read my earlier article to get a good idea about the numerous problems I ran into. Also read this comment to that article. Somebody going by the name joe, stated the following: quite right. JavaScript is NOT for games or animation. However for most other things on the web, it works quite well.
The point the comment makes appears to be half correct. JavaScript apparently is not suitable for games or animation, as shown by the issues I describe in my earlier article. But when it comes to the second point, about JavaScript being useful for most other things, I think we need to put in some further consideration. Based on what I experienced, I don’t think JavaScript is suitable for any serious application.
The most significant problem is no doubt the drastically different behavior of the same JavaScript code on modern versions of some of the major Web browsers. When it comes to developing more serious applications, that’s just not acceptable. Now, this may be solved in a number of ways. Formal standardization is one method. The use of a compatibility layer is another.
But it doesn’t seem to me to be a major step forward if we’re just revisiting many of the same issues that the C and C++ communities had to deal with 20 years ago. At least their efforts have matured to the point where it’s fairly easy to write code and know it’ll behave the same when compiled with different compilers from different vendors. We apparently don’t have that with JavaScript, even in the face of the ECMA standardization.
And I don’t think we should just accept that JavaScript “is not for games or animation”. Given the great amount of processing power offered by even a 5-year-old PC, there’s no reason why it should be so difficult to create a fully-functioning JavaScript clone of a 25-year-old game. The mere fact that multiple browsers ended up consuming 100% of the CPU suggests that modern JavaScript implementations suffer from some pretty serious performance problems. If they choke on tasks that could be readily performed decades ago, it’s doubtful they have what it takes to lead is into the future.
As software development moves forward, these are just the sorts of issues that we shouldn’t be revisiting again and again and again. The performance problems of JavaScript are particularly bothersome. It’d be one thing if we were pushing the limits of today’s technology trying to achieve something that had not been done before. But that’s not the case. We’re running into major problems just trying to duplicate what was done a quarter of a century ago, with far fewer resources! That’s not technological evolution. It’s a clear case of devolution!
Software development is often difficult enough as it is. So we need to stop backpedalling with JavaScript, and instead move forward using languages like Haskell and Erlang. They’ll let us do new and innovative things with the massive amount of computing power we have today in the average PC. This is in stark contrast to JavaScript, which appears to severely fail at replicating, never mind bettering, our past software development accomplishments.
July 28th, 2007 at 10:04 pm
You’re whole argument makes no sense, web browsers are not built for writing games.
You can’t compare a web browsers scripting implementation to Erlang or Haskell. It’s apples and oranges. The limitation isn’t JavaScript’s, it’s the browser’s, and it wouldn’t matter what language you coded “in the browser”, it’d still be the browser that sucks at playing games.
What you’re really saying is web browsers suck as a game platform, go figure, that’s not what they were built to do.
JavaScript is used as a scripting and macro language in lots of application, Photoshop for example. Would it make sense to try and write a game in Photoshop and then blame JavaScript for its horrible performance?
People who are saying JavaScript is the next big language, aren’t talking about “in the web browser”, they’re talking about taking the language itself, which is quite nice, and running it server side, on a real VM with some real horsepower behind it, not some shitty browser implementation.
Don’t blame the language because you’re abusing web browsers for things they weren’t meant to do.
July 28th, 2007 at 10:05 pm
The problem is not Javascript, but the rendering engine of the browser.
July 29th, 2007 at 8:56 am
I think you’re entirely missing the point. I don’t think anybody seriously wants to use JavaScript for the kind of problems that you would tackle with erlang or haskell. What JavaScript is for, and what it does very well, is turning web browsing into a more interactive experience. And Joe Average doesn’t give a damn about how many layers of APIs, libraries and compatibility hacks are between him and his flashy buttons and dynamic web pages. He’s just happy to click on a button and see some content appear without the whole page flashing like wild while reloading.
And that’s where Heskell and Erlang would miserably fail, even were they incorporated into brosers as alternatives to JavaScript. Because they are there to solve problems, and JavaScript is there to make UIs flashy. And it does so pretty damn well.
July 30th, 2007 at 11:20 am
Well, I think that Javascript is excellent for creating small and simple games. It’s quicker to load than Flash, and all modern browsers on all platforms have Javascript.
Have a look at the animations at my Javascript Bejeweled (http://free-online-games.nu/bejeweled.html), for instance. Not as CPU-heavy as Brickslayer, but quite nice, I think.