This content was published by Andrew Tomazos and written by several hundred members of the former Internet Knowledge Base project.

Proposed Changes Toward End

There are however downsides of web software over locally running software. If the server you are using is a long way away, there will always be a delay between a user action and the web server software finding out about it. If the server is on the other side of the planet, that delay cannot be less than a tenth of a second from simple physics, and any routers or gateways will add to the burden..

This is because the electrons can only travel at the speed of light, and if the server is running on the other side of the world, it takes them somewhat over a hundred milliseconds to travel there and back. Studies have shown that a person will notice any lag over 6 milliseconds, so this is not a trivial point.

There is one common workaround - key software that runs the user experience is sent to the local web browser, and runs there. This might be as simple as a web form with a few text fields, as intricate as a javascript based calendar, or as complicated as an interactive flash movie or Java applet. Once the user has finished whatever complicated interactions they need to, the web browser can send the results back to the server. A sixth of a second to save a document is far less egregious than a sixth of a second delay when changing a control setting.

This fails when the software needs to perform a round trip to the server in response to a common user action. For example, both video conferencing and multiplayer gaming require a constant stream of user actions to flow between separate places. There will always be a little bit of lag, and if the users are separated by great distances, that lag will be noticeable. As said above, any lag over six milliseconds will be noticed.

Web applications often feel slow today because of how web pages are loaded. Most servers and most browsers look at each page as a brand new page to display, so as soon as they are told that a page needs to change, they reload the entire thing from scratch. This is the right thing to do when one is moving between Google search results, but if the different page is just the result of a spreadsheet cell updating, then throwing out the entire page on any change is way too much work.

In addition, there is no easy way for a server to change a page without reloading everything. In conventional applications, multiple things are often going on. In most mail programs, for example, it can check for new messages as you compose a reply to an old one. This is far more difficult to do with Hotmail or Gmail's web interfaces, as they do not have an independent program running. Further, current reload technology, as mentioned above, redraws everything during a reload.

There are solutions to this problem. Some of them require effort by the application vendor - a Java applet, for example, can do two things at once and present a UI that only redraws changed items. Others require effort by browser makers, such as optimizing the redraw of pages which have not changed by much. Still others require new protocols, such as the various push protocols that have been proposed which let a server send back information about what has changed. All of these will likely become more mainstream over the next few years.

++ SUMMARY ++

There are a bunch of different groups scrambling to create and distribute technology to make web software deliver as much a first-class user experience as desktop software.

We know of a variety of solutions to these problems, but it is not clear which ones are going to become popular. This depends greatly on which company's vision of the future gains market and mindshare. Sun, Adobe, Apple, Google, and Microsoft all have technologies to solve some of these problems. As users, if we vote with our feet and our dollars, we can encourage the best of them to flourish. The underlying problem - getting software distributed via a web browser and loaded in a few seconds - is well understood, but non trivial.

Back to Index