JavaScript Is More Than You Might Think

What JavaScript can’t do

Many of the operations JavaScript can’t perform are the result of JavaScript’s usage being somewhat limited to a web browser environment. This section examines some of the tasks JavaScript can’t perform and some that JavaScript shouldn’t perform.

JavaScript can’t be forced on a client

JavaScript relies on another interface or host program for its functionality. This host program is usually the client’s web browser, also known as a user agent. Because JavaScript is a client-side language, it can do only what the client allows it to do.

Some people are still using older browsers that don’t support JavaScript at all. Others won’t be able to take advantage of many of JavaScript’s fancy features because of accessibility programs, text readers, and other add-on software that assists the browsing experience. And some people might just choose to disable JavaScript because they can, because of security concerns (whether perceived or real), or because of the poor reputation JavaScript received as a result of certain annoyances like pop-up ads.

Regardless of the reason, you need to perform some extra work to ensure that the website you’re designing is available to those individuals who don’t have JavaScript. I can hear your protests already: “But this feature is really [insert your own superlative here: cool, sweet, essential, nice, fantastic].” Regardless of how nice your feature might be, the chances are you will benefit from better interoperability and more site visitors. In the Tips for using JavaScript section later in this chapter, I offer some pointers that you can follow for using JavaScript appropriately on your website.

It might be helpful to think of this issue another way. When you build a web application that gets served from Microsoft Internet Information Services (IIS) 6.0, you can assume that the application will usually work when served from an IIS 6.0 server anywhere. Likewise, when you build an application for Apache 2, you can be pretty sure that it will work on other Apache 2 installations. However, the same assumption cannot be made for JavaScript. When you write an application that works fine on your desktop, you can’t guarantee that it will work on somebody else’s. You can’t control how your application will work after it gets sent to the client.

JavaScript can’t guarantee data security

Because JavaScript is run wholly on the client, the developer must learn to let go. As you might expect, letting go of control over your program has serious implications. After the program is on the client’s computer, the client can do many undesirable things to the data before sending it back to the server. As with any other web programming, you should never trust any data coming back from the client. Even if you’ve used JavaScript functions to validate the contents of forms, you still must validate this input again when it gets to the server. A client with JavaScript disabled might send back garbage data through a web form. If you believe, innocently enough, that your client-side JavaScript function has already checked the data to ensure that it is valid, you might find that invalid data gets back to the server, causing unforeseen and possibly dangerous consequences.

JavaScript can’t cross domains

The JavaScript developer also must be aware of the Same-Origin Policy, which dictates that scripts running from within one domain neither have access to the resources from another Internet domain, nor can they affect the scripts and data from another domain. For example, JavaScript can be used to open a new browser window, but the contents of that window are somewhat restricted to the calling script. When a page from my website (braingia.org) contains JavaScript, that page can’t access any JavaScript executed from a different domain, such as microsoft.com. This is the essence of the Same-Origin Policy: JavaScript has to be executed in or originate from the same location.

The Same-Origin Policy is frequently a restriction to contend with in the context of frames and AJAX’s XMLHttpRequest object, where multiple JavaScript requests might be sent to different web servers. With the introduction of Windows Internet Explorer 8, Microsoft introduced support for the XDomainRequest object, which allows limited access to data from other domains.

JavaScript doesn’t do servers

When developing server-side code such as Visual Basic .NET or PHP (a recursive acronym that stands for PHP: Hypertext Preprocessor), you can be fairly sure that the server will implement certain functions, such as talking to a database or giving access to modules necessary for the web application. JavaScript doesn’t have access to server-side variables. For example, JavaScript cannot access databases that are located on the server. JavaScript code is limited to what can be done inside the platform on which the script is running, which is typically the browser.

Another shift you need to make in your thinking, if you’re familiar with server-side programming, is that with JavaScript, you have to test the code on many different clients to know what a particular client is capable of. When you’re programming server-side, if the server doesn’t implement a given function, you know it right away because the server-side script fails when you test it. Naughty administrators aside, the back-end server code implementation shouldn’t change on a whim, and thus, you more easily know what you can and cannot code. But you can’t anticipate JavaScript code that is intended to run on clients, because these clients are completely out of your control.