Web DevCenter    
 Published on Web DevCenter (http://www.oreillynet.com/javascript/)
 See this if you're having trouble printing code examples

JavaScript: Why You Don't Know More About It

by Steve Champeon

In the previous article in this series, JavaScript: How Did We Get Here?, I talked about the genesis and early history of JavaScript, with an eye toward both its weaknesses and strengths.

In the end, I pointed out that no matter how you feel about JavaScript, it looks like it's here to stay. And in my opinion, that's not a bad thing at all. But for those of you who may have long ago written off JavaScript as a toy, perhaps it will take a bit more convincing. So, let's dig in and find out why you might have done so, and what can be done to overcome your misbegotten prejudices.

Why don't you know more about JavaScript?

As with playing the guitar, JavaScript is very easy to pick up and begin noodling around with, but difficult to master. Good technique can go a long way, but creativity and inventiveness (and willingness to take chances) can make the difference between code that barely runs now, and code that will continue to perform in the future.

JavaScript fundamentals are easy (and for the most part, if you're a C, Perl, or Java programmer, you already possess them), but as with any language, you can't let yourself be limited by a lack of imagination or unduly curtail your projects because something "isn't natively supported."

Let me jump back to the music metaphor for a minute. If you already know how to play the piano, then you can understand the guitar quickly. But understanding is one thing -- playing well is another. To play well, you still need to learn how to strum, flatpick, and adapt the chords you know from the keyboard to the fretboard.

Like the language of music, JavaScript is very flexible. The Document Object Models (DOM) that make it so powerful in conjunction with a browser often provides multiple methods to accomplish a given task. Those who can coax JavaScript to sing often use unique and innovative approaches to solving problems. In many situations, coders use techniques developed during the "browser wars" to guarantee cross-browser compatibility. But in most every case, the programmer is using a combination of the core language with various DOMs implemented by the different browsers.

Comment on this articleHow did you learn JavaScript? What tips do you have for others just testing the water?
Post your comments

As with C, Java, and Perl, JavaScript has a few fundamental language features (which, in fact, often derive from the languages mentioned) and a wide set of additional library functions. Some of these are built into the language, and some made available by the environment in which the scripts are executed.

As a result, the "language" taken as a whole is fairly large, and requires a great deal of effort to learn in its entirety. Few programmers are familiar with the entire range of possibilities inherent in the language, and it's common for scripts written by one programmer to rely on an entirely different set of features than those written by another.

This can make it difficult to learn JavaScript simply by looking at the source. In addition, the ability to include external JavaScripts can present an obstacle to those unaware of the mechanisms by which these external scripts may be viewed, for example, the "view-source:" pseudo-protocol in Netscape Navigator 4 or good old lynx -source http://example.com/some.js.

A casualty of the browser wars

Related Reading

JavaScript: The Definitive Guide, 4th EditionJavaScript: The Definitive Guide, 4th Edition
By David Flanagan
Table of Contents
Sample Chapter
Full Description

During the browser wars, many improvements and extensions to the language (in addition to the DOM hacks and other features added under the rubric of "Dynamic HTML") took second fiddle in software reviews to UI enhancements and more powerful bookmark management tools. So, even if you learned JavaScript in the early days of Navigator 2, you may be unfamiliar with a good chunk of the present-day language. And to top it off, the most recent browser versions have greatly improved support for the W3C DOM recommendations. So, JavaScript has always presented an ever-rising learning curve to newbies and experts alike.

Even if you have been faithfully following the various vendor announcements regarding new JavaScript features and DOM enhancements, you may have thrown up your hands in disgust at the wide variance between implementations. Netscape went off in its own direction during the 4.x generation, with its LAYERS DOM. And Microsoft had similarly proprietary hacks (document.all, DHTML Behaviors) that presented this Faustian bargain: offering greatly enhanced functionality, but to a restricted audience, often targeting a single browser version.

And after all of that, even if you were lucky enough to learn one or both of the Netscape LAYERS DOM and Microsoft Internet Explorer's document.all DOM; time, audience, and budgetary constraints often forbid the full exploration of either DOM in the name of compromises and cross-browser workarounds.

On the other hand, if you were unlucky enough to have experimented with Dynamic HTML in the 4.x generation, you may have decided on your own that the lowest common denominator between the two major DOMs was too low for any useful applications. Some who reached this decision abandoned one or the other, in favor of whatever DOM offered the more powerful feature set for their needs. Still others simply gave up on DHTML as a platform for applications, and stuck to enhancing traditional web sites with UI and navigation hacks or primarily design-oriented uses.

Other advanced features of JavaScript required costly licenses (such as "signed scripts" that allowed the developer to manipulate the browser chrome in vastly more powerful ways, but which required each script to be signed using a certificate, often costing into the hundreds of dollars). For the average developer in the trenches, or for those simply wishing to extend their skillsets by noodling around, such barriers prevented a good deal of experimentation. That restriction may have been a sane requirement, but it also prevented many developers from using the features themselves.

Another reason why some have steered away from JavaScript is that once you publish a script to a web site, it is wide open for others to view and use, with little protection against theft other than copyright statements and unwieldy client/server license key hacks (where a script might be delivered dynamically, with some embedded code that disables it from working elsewhere) that are easily worked around.

Some less-than-ethical developers even resorted to using JavaScript obfuscators to encode their scripts and even to hide entire Web pages inside encoded document.write() loops. It's not easy to protect your intellectual property using JavaScript. Even though it's not much different than exposing your HTML or CSS to public scrutiny, many more ambitious developers prefer to keep their web applications from the roving eyes of their competitors.

As is the case with dynamic web sites of all kinds, the need to use server-side logic to manage cross-browser and cross-platform compatibility issues has added an extra level of complexity that many simply wished to avoid. The need to use PHP, mod_perl, Cold Fusion, ASP, and various other environments to produce or deliver code optimized to the target browser of the moment was a hurdle few wanted to deal with.

So, given all of these negatives, combined with the fact that Netscape, the Mozilla team, Microsoft, software reviewers, and the W3C haven't exactly made JavaScript and the DOM their top priority from a press relations standpoint, why has JavaScript survived, even thrived?

Some of the success of JavaScript can be attributed to the incorporation of commonly used routines, such as "rollovers" or "browser sniffers" into the GUIs of WYSIWYG HTML editors such as Macromedia's Dreamweaver. Rejected to some extent by developers, JavaScript came in the back way, via included scripts that were often well-written, but terse and difficult to read -- and some of which have suffered from a failure to foresee or anticipate the recent adoption of W3C DOM Recommendations.

Finally, if you're anything like the rest of us, you've probably been busy learning other Internet technologies, and in your case, perhaps JavaScript simply hasn't been your top priority. So, what have you been missing? What will you miss if you don't learn JavaScript now?

What are you missing by ignoring JavaScript?

Despite all the potentially negative implications of the discussion above, JavaScript is definitely worth learning.

If you're a consulting programmer or web developer, and you've managed to avoid JavaScript thus far, congratulations. I hope you've been spending your time wisely, and not learning Visual Basic for Applications, or Perl4, or PHP/FI, or any other language that has been replaced by more robust versions. I hope you haven't been learning a slew of proprietary APIs for extinct large-scale content management systems, or non-web software.

If you're an Intranet developer, or otherwise inside the firewall, I hope you haven't spent too much time learning proprietary and platform-bound languages such as VBScript. But at any rate, it's not too late to take advantage of JavaScript. Here are a few reason why you might want to learn it now:

Okay, okay -- so I've convinced you that JavaScript is worth learning. So what now?

How do I go about learning JavaScript?

First, decide what you want to use JavaScript for. Do you want to enhance traditional web sites? Do you want to provide enhanced functionality to server-driven web applications? Do you want your applications to run almost entirely on the client? What are your intentions with respect to using JavaScript and/or Dynamic HTML? Are you a designer or HTML production genius who wants to expand your capabilities? Are you a traditional developer wishing to build reusable components? Or are you the latest hire at a venture-funded startup who has realized that the JavaScript team gets all the glory? Regardless of what you want (or need) to do with JavaScript, there are resources for you.

If you're the sort who learns best by example and take pride in your ability to decipher code, start by viewing source on some of your favorite JavaScript-enabled sites.

If the JavaScript is referenced by <SCRIPT SRC="...">, simply cut the value of the SRC link and paste it into the Location: field of your browser (making adjustments for path information, as necessary). In many newer browsers, this will display the source intact, rather than running it.

If your browsing platform of choice is Navigator, use the "view-source:" pseudo-protocol as a prefix to the URL you created from the SRC value, to display the source. If you're on Unix/Linux, you can use the "lynx" text-mode browser to capture web files to local disk (use the -source switch and redirect the output to a file.) Then study the source and find a good JavaScript or Dynamic HTML reference manual, such as those written by David Flanagan and Danny Goodman.

If you're the sort who needs a more tutorial-oriented approach, there are many web sites that offer tutorials on JavaScript, from entry-level through advanced JavaScript and Dynamic HTML using the W3C DOM. In addition, there are several dozen books covering JavaScript and Dynamic HTML, although many DHTML books assume a basic knowledge of JavaScript, HTML, and Cascading Style Sheets. Be sure to check the publication dates and browser coverage, and ensure that the book you choose covers the versions of the browsers you need it to. Also check to see if the book has a companion web site or mailing list for further discussions of the technologies.

Once you've had a chance to dig in a bit, find a forum suitable to your tastes (whether Usenet newsgroup, BBS, mailing list or digest, or even chat) and start asking questions. Some forums have more stringent conventions with respect to the amount of work you are expected to have done on your own before asking for help, but most, if not all, expect you to provide a useful level of detail regarding your problem or question.

A frequent question on Webdesign-L, the mailing list that I run, involves the appropriate toolset for developers (whether handling loose markup, XML, Perl, JavaScript, or ColdFusion). In our next article, we will discuss what to look for in a development environment, and how to go about choosing the rest of your toolset when developing with JavaScript.

Steve Champeon is a recognized developer, author, and editor specializing in Web technologies. At his "day job," he serves as the CTO of hesketh.com, a Web services firm in Raleigh, NC.

Return to the JavaScript and CSS DevCenter.

Copyright © 2009 O'Reilly Media, Inc.