To say that a particular technology is mature can mean a number of different things. It could mean that it enjoys widespread use, and its value is unquestionable. It could also mean that it has reached a plateau, with most of its major advancements behind it.
The former is certainly true of Web applications.
It has been a popular theory for quite some time that desktop applications will eventually be obsolete, and we’ll all have “dumb terminals.” I believe in a client-server architecture similar to this, in which the clients aren’t quite “dumb,” but perform some of the more superficial processing tasks in order to take load off the server. An example of this in today’s Web applications is JavaScript calculating and validating form data before it gets submitted. The JavaScript executes client-side.
In order for this type of client-server computing to advance beyond where it is today and avoid any potential plateau, Web applications need to get better at mimicking desktop applications. They need to become more responsive and more dynamic. This column presents some JavaScript examples to that end, and outlines some considerations for determining what processing tasks should be assigned to the client.
Example 1: HTTP behind the scenes
This one is so cool that I can’t take credit for finding it. I was tipped off by my brother, Michael, that JavaScript can send and receive HTTP messages without reloading the current page. Try this in IE6:
Try entering a URL in the small text box, click “Make Request,” and watch the resulting HTML get printed into the larger text box. The implications of this are huge. Consider using JavaScript to make SOAP calls without reloading the page – your Web browser can send data to the server without needing to do a traditional form submission.
Example 2: dynamic number of form field rows
This script adds a row of input fields without refreshing the page. It is useful for any kind of data entry without a predetermined number of records. By combining this with Example 1, you could save the field data to the server row by row without submitting the entire form.
<input type="button" value=
“Add Row”onClick=”addRow()”>
I hope the above examples illustrate that JavaScript is robust enough to handle a sizeable chunk of application processing. But just because you can do something client-side, does that mean you should? I can think of two considerations to help with that decision: security and bandwidth.
For security reasons, some validations will have to take place on the server. Ultimately, a clever hacker can try to send any
