Section A. Conceptual overview

A. Conceptual overview

JavaScript is a scripting language interpreted by the browser. It adds usability to a Web site by handling certain bits of interaction, such as validating a form or creating a new menu, in the browser instead of on the server.

Handling interaction in the browser

To understand JavaScript's purpose, it's useful to take a quick peek at client-server communication.

A client is usually a program on the user's computer, while the server is usually a remote computer that holds interesting data. When the client needs data (a Web page, for instance) it sends a request to the server, and the server responds by sending the requested data. After getting this response, the client may send a new request, which leads to a new response, and so on.

Figure 1.1. Client-server communication. The client requests something, and the server responds.

In the case of the World Wide Web, the client is a browser. When the user types in a URL or clicks a link, the browser sends a request to a Web server. The server responds by sending an HTML page. When the browser receives the HTML, it displays the page and awaits further instructions. When the user clicks a link or submits a form, the process is repeated. Every round of client-server communication requires a bit of time during which the user can't do anything, and may feel disoriented.

Less communication

This is where JavaScript enters the picture. JavaScript is a client-side programming language, which means it works in the client (the user's browser), not on the server. Therefore, any job that is handled by JavaScript doesn't require a round of client-server communication.

Figure 1.2. Form validation without JavaScript. The server receives the form, checks it, and generates a new page that's sent back to the client. When the user submits the form without mistakes, the server processes it and sends back a Thank You page.

For example, take form validation. Let's assume the user enters her data but forgets to fill out the Address field before hitting Submit. The incomplete form is sent to the server, where a server-side script notes the missing address and creates a new HTML page. This page, noting the error, is sent back to the client. After the user has entered the missing address, she submits the form again. Now the form is complete, and the server-side script can store the form data and send the user to a Thank You page.

With JavaScript to perform the form validation, you can skip the first request/response. When the user hits Submit, JavaScript checks the form. It sees that the address is missing, halts the form submission and generates an error message. When the user submits the form again, JavaScript again runs a check, doesn't find more problems, and allows the form submission to go forward. Only now does the browser send out a request, to which the server responds by storing the form data and sending back a Thank You page.

Figure 1.3. Form validation with JavaScript. The script checks the form on the client and halts the form submission if it finds errors. When the user submits the form without mistakes, the server processes it and sends back a Thank You page.

As a result, the script conveys a usability benefita smoother-working pageand JavaScript's purpose is fulfilled.

Fat vs. thin

Of course form validation is a simple example. It's been around since 1996, and although it's still one of the most popular scripts, it's not really challenging technically, or even conceptually. Nowadays JavaScript is capable of handling much, much more interaction.

That raises the question: How far should you take it? Should you create one giant JavaScript application to hold all your interactions and present your entire Web site in a single page? Or should you create separate and static HTML pages that use JavaScript only to add some subtle enhancements? In other words, should JavaScript be used as often as possible, or in a more restrained, limited way? Or, perhaps, not at all?

The answer depends on how you interpret JavaScript's purpose. Some say that nearly everything should take place on the client side, citing improved usability as their main argument. After all, any page refresh requires waiting, which might disturb a user's concentration. There's something to be said for that point of view.

Others maintain that as much interaction as possible should take place on the server, citing improved accessibility as their main argument. Some browsers do not support (enough) JavaScript to handle advanced scripts, and users of these browsers will not be able to use (or even see) script-heavy pages. There's something to be said for that point of view, too.

The first group embraces the idea of a fat client, the second group that of a thin client. (There are many more names for both, but for clarity's sake I'll stick to these two.)

A thin client relies totally on client-server communication. Basically, the logic of each round of interaction ("The user clicked here. What happens next?") is dictated by the server. When frequent page updates are necessary, this can lead to a slow and frustrating user experience.

A fat client, on the other hand, handles as much interaction as possible at the client. When the user does something, a script in the browser decides what to do next. Although no client can do entirely without communication with the server, the fat client tries to limit it to fetching extra bits of data, handling all other concerns itself.

Which approach is better?

Although the fat client certainly conveys some usability benefits, I feel that in the end the thin client is more likely to emerge as the "standard" way of using JavaScript, because of two fundamental imbalances between the thin and fat models.

The first is that the thin client is overall more in keeping with the Web's structure. The Web was conceived as a collection of documents, not as a collection of interfaces.

This conception of the Web has ruled the browsers' basic functions since the dawn of time. A browser has a Back and a Forward button to send you on to the previous or the next document, and not the previous or next step in an interface. A browser can bookmark documents, but not steps in an interface.

The second imbalance is about accessibility. Obviously, from an accessibility point of view, a thin client is preferable, because there's less to go wrong. Conversely, a fat client will fail much more spectacularly, since there's more functionality to fail.

Neither imbalance is unsolvable. It is possible to write complicated (hence fat) scripts that make sure the Back and Forward buttons, as well as bookmarks, continue to work in an advanced interface. It's also possible to write a perfectly accessible fat client. We'll discuss a few possibilities in 10D.

Nonetheless, all this takes a lot of extra work, for which not all projects have reserved time and money. Besides, writers of fat clients tend to focus on the usability problem (Back/Forward/bookmark) and ignore the the accessibility problem, thinking "This application is so advanced it's never going to be accessible anyway."

The purpose of JavaScript

In view of all this, is JavaScript's purpose best served by creating fat or thin clients?

The answer is, of course, "It depends." It depends on the site you're creating, on your target audience, and on your skills as a JavaScript programmer. This book will help you to improve the latter, but it doesn't (and cannot) say anything useful about your site or your target audience.

In the end, the choice between fat and thin is entirely your own. When in doubt, stay on the thin side, but in order to become a truly well-rounded JavaScript developer, you should create a fat client at least once.