JavaScript: The Return to Sender Issue

JavaScript: The Return to Sender Issue

By Jacques Surveyor.

A persistent problem with the Web API is the Return-to-Sender issue. JavaScript is capable of alleviating it, but it's not always enabled by software vendors.

The Web API is becoming increasingly popular because it simplifies development - users go to one place and get the latest code. Developers only have to be concerned with one server site where code needs to be updated and managed. Additionally, the interface is simple and universally used with browsers and even mobile/phone applications, but one of the biggest complaints about the Web API is that it does not have as rich a set of UI components as Macintosh and Windows applications. Finally, the Web API is gradually starting to disappear now that systems such as ASP.NET, JSF-Java Server Face, Java Swing , Struts and other UI software deliver more powerful components.

Return-to-Sender Problem

There is one problem that web development tools have had less luck in dealing with - the network delay associated with the send-and-respond interaction required in most Web user interfaces. This problem is also affectionately known as round tripping or return-to-sender delay. Return-to-sender is especially problematic in forms and data input processing where UI designers want to give users immediate feedback as they enter values or customize their screen layout. Just about every press of a button or entry of a data value requires a trip back to the server, a validation and/or formatting change and then a screen refresh sent back to the user. On Intranets the delay is not as pronounced as on the Web, but it can still add 2-5 second delays.

JavaScript is a nearly perfect solution to the problem. The JavaScripts are centrally maintained and delivered with the web page - so all the advantages of centralized Web API still apply, but JavaScript can eliminate many of those roundtrip validations and screen refreshes because the validation or formatting code executes locally in the browser. This includes supplying error messages and suggested response (or reformatting output or fields) as selected in a pulldown or button press. Whenever troubleshooting a Web system with response time problems, the first fix (after getting the network connections optimized) is to reduce round tripping with JavaScript.

Danny Goodman in his JavaScript Bible (as well as Doc JavaScript at WebReference.com) provide several generic JavaScript routines for data/form field validation and formatting. So why not just establish these routines as a library in such popular development tools as Visual Studio, Oracle JDeveloper, Sun NetBeans etc?

Mixed Support for JavaScript

Microsoft's Visual Studio does offer ASP.NET templates and they do include a large, if not complete set of validators and formatters that can be used in conjunction with JScript in delivering an application, but the thrust of Microsoft's direction with .NET is towards use of VB.NET and C# over JavaScript/JScript. In some cases this works just fine, but in other applications it creates unnecessary round tripping

Microsoft is not alone. Sun's new Java Studio Creator, the VB killer app., supplies JavaScript events and attributes within the new IDE, including the ability to drop in code for OnEvents, etc., but Sun supplies a whole set of JSF components that act as Java-based Converters and Validators. Many of these components require return-to-sender round tripping with the associated delays. The same mixed message comes through with Oracle's JDeveloper.

Admittedly, vendors can argue that mixing two programming languages (JavaScript and Java or C#/VB.NET) complicates matters for developers, but many developers are already using XML, HTML and even JavaScript - so this argument carries less weight. Another argument is that there are no standard libraries of JavaScript validation and formatting routines available. Perhaps Danny Goodman and Doc JavaScript would disagree, but unfortunately, that the case.

JavaScript doesn't come with a comprehensive set of application/development libraries, unlike Java and C#. Perhaps library vendors such as Microsoft, Oracle, and Sun would be inclined to provide wizards, coaches, tips and tutorials with options about how to package JavaScript. In the meantime, users are on their own. They have to create their own code to reduce costly return-to-sender trips.

There are some other advantages to JavaScript Validators and Formatting code. First, the code can be dynamic and context sensitive so that formatting and output can be geared to the input supplied. In addition, JavaScript validations reduces the need to reserve message space when several error messages come back with roundtrip code. With the exception of Microsoft, browser vendors have moved to reasonably complete CSS and DOM standards, so this simplifies writing validators and formatting code. Finally, JavaScript is ready, willing and able to reduce the Return-to-Sender blues.

Jacques Surveyer is a consultant and trainer; see some of his graphic tips and tutorials at ThePhotoFinishes.com

Created: March 27, 2003
Revised: October 12, 2004

URL: URL: https://webreference.com/programming/javascript/j_s/column10/1