You Used JavaScript to Write WHAT?
The key to understanding when (and when not) to deploy JavaScript has as much to do with the intent of the target application as it does JavaScript itself.
Fri, January 25, 2008
CIO — The word "JavaScript" has become a lightning rod in the Web development community. Depending on who you listen to, JavaScript is either the shining beacon of light leading us toward Web 3.0 or it's an insidious plot to bring the Web to its knees, one hover button at a time. If you eliminate the radical points of view on each end of the spectrum, you are left with very real questions about when it makes sense to use JavaScript, and when it doesn't. There is no doubt that overzealous scripters have built applications that stretch the limits of JavaScript...and in some cases, reason.
What kind of JavaScript development scenario qualifies as stretching the limits of reason? For one, attempting to build complex multimedia applications such as action games. Sure, in many ways it's technically possible to accomplish given that JavaScript is a powerful technology with the capability to manipulate images, carry out animation timing, etc. But high-performance multimedia is in no way JavaScript's strong suit. Even if performance wasn't a critical consideration, JavaScript still falls short when compared to other options, such as Adobe Flash. If you're trying to create complex multimedia software with JavaScript, you're ultimately reinventing several wheels; specialized tools exist for the very purpose of empowering Web developers to build rich, online multimedia experiences.
Okay, so maybe Halo 4 in JavaScript was never really on the table at your company. Does that mean everything else is open game? Not hardly. There are still other pitfalls awaiting the overconfident JavaScript developer who insists on using a JavaScript hammer to whack away at every interactive Web nail in sight.
But the problem of abusing JavaScript as a Web development technology is ultimately more subtle than just pointing out a handful of less-than-ideal coding techniques or application categories. Yes, it's true that nifty little Web effects such as image roll-overs should be carried out using Cascading Style Sheets (CSS), not JavaScript. It's also true that it's generally a bad idea to craft hyperlinks using JavaScript code that breaks down when JavaScript is absent. And don't even get me started on using JavaScript to detect browser versions or, most horrific of all, hijack the browser's status bar to display a cute animated message. The real issue of assessing the role of JavaScript in a specific Web application comes down to the role of the application. Is it a page, a program, or some combination of the two?
