Power. HTML is limited in its computational power. This is intentional in its design, as it prevents the execution of dangerous programs on the client machine. However, Web programmers, as they have become more sophisticated in their applications, have increasingly been hamstrung by these limits. Tasks unable to be coded in HTML must either be executed on the server in some other language, or on the client in a program in some other language downloaded from a server. Both solutions are awkward for the programmer, often produce a sub-optimal segmentation of a application across program modules, both client and server, and reintroduce safety considerations.

Performance. Because of an HTML program's limited functionality, and the resulting shift of computational load to the server, certain types of applications perform poorly, especially in the context of clients connected to the Internet with rather low bandwidth dialup communications (<=28.8Kbps). The performance problems arise from two sources: (a) an application which is highly interactive requires frequently hitting the server across this low bandwidth line which can dramatically and, at times, unacceptably slow observed performance; and (b) requiring all computation to be done on the server increases the load on the server thereby reducing the observed performance of its clients..

Today, most users have pretty competent client machines, which are capable of accepting a larger share of the computational load than HTML allows. For example, an Internet-based interactive game or simulation can be a frustrating experience for users with low speed connections, and can overwhelm the server that hosts it. If you were the developer of such a game, you'd be inclined to push more of the functionality to the client, but, since HTML limits the possibilities, another route to supporting computation on the client must be found. The developer might make an executable client program available to users, which would be invoked via the HTML browser, but users might only be willing to accept such programs if they trust the source (e.g. a major vendor), as such programs are a potential safety concern. Also, users don't want to be continuously downloading client programs to be able to access web pages, so this solution has real practical limitations considering the size and dynamism of the Web. If safe powerful high performance programs could be automatically downloaded to client platforms, in much the same way as HTML pages, the problem would be solved.

When code is to be executed on a client, there are two main considerations: what gets shipped and what gets executed. There are three main alternatives for each of these: source code, a partially compiled intermediate format (e.g. byte code), and binary code. Because compilation can take place on the client, what is shipped is not necessarily what is executed.

Byte code, according to measurements presented at the JavaOne conference can be 2-3x smaller than comparable binary code, so its transfer can be considerably faster; especially noticeable over low speed lines. Since transfer time is significant in the Web, this is a major advantage. Source code is also compact. Execution performance clearly favors binary code over byte code, and byte code over source code. In general, binary code executes 10 - 100 times faster than byte code. Most Java VM developers are developing JIT (Just In Time) compilers to get the benefits of bytecode size and binary speed. Java bytecodes are downloaded over the net and compiled to native binary on the local platform. The binary is then executed, and, possibly, cached for later executions.

It should be clear that any combination of these strategies could be used in the implementation of any particular Web programming language, and there is in fact wide variation among the systems actually surveyed.

Platform Independence Given the diversity of operating systems and hardware platforms currently in use on the Web, a great efficiency results from only dealing with a single form of an application. The success of HTML has proven this, and Java has seconded it. The ability to deliver a platform-independent applications of great appeal to developers, who spend a large portion of their resources developing and maintaining versions of their products for the different hardware/software platform combinations. With Java, one set of sources and one byte-compiled executable, can be maintained for all hw/sw platforms.

While platform independence has long been a goal of language developers, the need to squeeze every last ounce of performance from software has often made this impractical to maintain, at least at the level of executable code. However, in the Web this concern becomes less important because transfer time is now a significant component of performance and can dominate execution time.

Platform independence can be achieved by shipping either byte code or source code. One advantage of shipping byte code over source code is that a plethora of source languages would require the client machines to maintain many compilers and/or interpreters for the source languages, while fewer byte codes formats would require fewer virtual machines.

Preserving intellectual property. Although not currently discussed much as an issue, the ability to download safe, portable applets in some form less than source code is an additional advantage to developers who wish to protect their intellectual property. Looking at someone else's script or source to see how they do something and just tweaking it a little or copying a piece of it to do the same thing in one's own program doesn't feel like stealing. But if one has to go to the effort of reverse engineering byte or binary code, it becomes more obvious that this code is someone else's intellectual property. For the vast majority of honest people on the Web, this subtle reminder may be enough. For some of the minority, the effort involved in reverse engineering may serve as a sufficient deterrent.

Safety. Viruses have proven that executing binary code acquired from an untrusted, or even moderately trusted, source is dangerous. Code that is downloaded or uploaded from random sites on the web should not be allowed to damage the user's local environment. Downloading binary code compiled from conventional languages is clearly unsafe, due to the power of the languages. Even if such languages were constrained to some ostensibly safe subset, there is no way to verify that only the safe subset was used or that the compiler used was trustworthy (after all, it is under someone else's control).

HTML proved that downloading source code in a safe language and executing it with a trusted interpreter was safe. You can't infect a client with a virus by fetching and displaying an HTML document (although you certainly can fetch a file with a virus in it, which could then be activated by executing the file, something which is not supported directly by HTML, although some browsers allow it). HTML is not sufficiently powerful. A middle ground is being sought in which the downloaded program is less limited in its capabilities than HTML and more limited than a conventional language. Even though HTML has limited power, the general idea behind HTML, that of a somewhat limited language interpreted by a trusted client-side interpreter, has been widely adopted with more powerful languages and interpreters.

Some languages achieve relative safety by executing byte-code compiled programs in a relatively safe runtime environment (a virtual machine). Yet other languages are fully interpreted on the client by an interpreter provided by the language developer. In either case relative safety can be achieved because the interpreter or virtual machine can make safety checks that are impossible to make statically at compile-time. Note that the interpreter or virtual machine can only provide safety, not by the language or the language's compiler.

This is not to say that lack of safety or platform-independence disqualify a language for a role in web application development, but for dynamic applications likely to be downloaded from untrusted sources with current browsers and executed locally on mainstream platforms, a safe and platform independent executable is highly desirable. At the other extreme, the interpreters and runtimes that execute such programs are likely to be developed using unsafe languages and their developers will distribute platform dependent executables. For programs intended for execution on servers, there is some value to safety and platform independence, but not to the same degree as on clients.