Traditional Web applications mitigate server loading and enhance the user experience by embedding logic in client scripted algorithms. Form validation, data sorting, and paging functionality are often performed on the client, as are user message boxes, dynamic text elements, and pop-up menus. Such client-side scripting makes for a vibrant user experience while requiring little server interaction. By distributing the computational needs of specific functionality to their clients, traditional Web systems have achieved a bit of a free ride -- dynamic functionality without additional server loading. Most highly trafficked, public Web sites couldn't scale to their user base (or achieve the desired interactivity) without considerable use of client-side scripting.
Microsoft's .Net facilitates a broader set of functionality for Web applications. It establishes a bias for server-side programming that may be uncomfortable for those used to extensive client-side scripting. While adapting to the new paradigm, developers will have to learn how to judicially apply postbacks for optimum event handling on the server without sacrificing application response or scalability. Additional challenges surface when assigning event-driven, browser-based functionality to rendered server controls.
Limiting browser exposure through .NetMicrosoft's .Net strives to mitigate the development and maintenance overhead associated with extensive client-side scripting. Using Visual Studio .Net Designer with its drag-and-drop functionality, a developer can roughly develop an entire ASP.Net application without ever editing actual presentation script. Visual Studio .Net enables automated client script production. While a more common development scenario combines drag-and-drop with limited hand scripting via the Visual Studio .Net Code Editor, a developer is still limited to editing only the server tags of any Web control. The developer is completely isolated from its underlying JavaScript or HTML. Traditional client-side developers may bristle at the notion of automatically rendered JavaScript, but Web controls go a long way in eliminating cross-browser development difficulties. ASP.Net employs sophisticated algorithms for rendering browser-specific code compatible with most browsers and most versions. Also, ASP.Net renders HTML (rather than DHTML) for browsers that do not support DHTML. Web controls reduce custom presentation coding through more than just automated JavaScript rendering. The Web control event model enables sophisticated and elaborate event-based server processing, rivaling client/server or stand-alone applications. The key, of course, is the server in the server-based event model. To take advantage of the dramatic features in the Calendar, DataGrid, Button, or any other Web control, all significant processing must be done on the server. Microsoft's .Net has mitigated the overhead required for maintaining and developing client-side script -- but in doing so, it drastically altered the client/server balance of traditional Web programming. Successful implementation of a .Net application requires coming to terms with this new bias. Postbacks
.Net's focus on server programming will immediately become apparent to the developer considering server postbacks. Postbacks are associated with any Web control event and are basically requests for processing sent to the server. For example, assuming an event handler has been written, a list box will fire an event anytime a user selects a new item. Posting back to the server allows that event to be handled by initiating a round trip to the server. While server requests are certainly not new to .Net, you do need to consider their frequency. .Net applications, if coded unwisely, can post back to the sever with nearly every event on every control. Obviously the network traffic and server loading will result in extreme latencies under even moderate traffic. .Net mitigates postback overuse by allowing developers to disable automatic postbacks on some controls. Rather than automatically initiating a postback when the user changes the control, events are cached and submitted on the next post when autopostback is disabled. Some controls however, such as the Calendar and DataGrid control, don't allow the disabling of the autopostback functionality. These controls will initiate a server round trip with every change to the control. Additionally, the control's view state can be set to help minimise network traffic. The view state enables server controls to maintain their contents over a browser refresh. Since this is done via passing the control's serialized values back and forth between the browser and the server, disabling the view state when not necessary will improve performance. Back to the client
Certain basic application functionality is currently impossible to handle strictly from the server. For example, consider setting the focus on a TextBox server control. Currently, there is no .Net method or property available to set focus to any server control, and the request must be handled through client script. With a control placed directly on a Web form, this is a relatively straightforward scripted operation: Access the server control by its ID and invoke the focus method. The situation becomes more complex, however, when the target control is the child of a DataGrid, DataList, or other compound control. Let say, for example, that you want to set the focus to a TextBox inside a DataGrid control when the grid is first put into edit mode. As with a stand-alone control, you'll use the ID of the control when you invoke the focus method call. However, at design time, the specific TextBox doesn't yet exist since the grid isn't yet populated. So you have to create the client script at run time on the server (i.e., on the edit event) and then render it to the client. Since the client script must specify the ID of the target control, your application code will have to determine the selected row and column in the DataGrid and then locate the associated TextBox control's ID. Similar difficulties arise for triggering the simplest of client interactions, the alert box. Because an alert box is solely browser-based functionality, .Net does not have an activation mechanism. In this case, a client script must be rendered that accesses the browser DOM and invokes the alert method. The client script itself is trivial; however, when combined with, say, the delete action from a DataGrid server control, you're again in the situation where you must write server code to discover the child control's ID and embed it in rendered client script. Never say never
Microsoft envisions a highly interactive future based on server event handling and machine-rendered client script. Currently, due to server processing capability, network latency, and browser incompatibilities, this future has to be carefully adopted. But with the accelerating increase in network bandwidth and processor throughput, the Microsoft future of unbridled server-side events and drag-and-drop JavaScript is likely only a mouse click away.
Have your say instantly in the Tech Update forum.
Find out what's where in the new Tech Update with our Guided Tour.
Let the editors know what you think in the Mailroom.
