.lg 1
.PH "''\fBWhy Web Applications are Broken and Always Will Be\fP'Andre Masella'"

.P 1
A popular development method, currently, is to develop, so called ``web applications''. These web applications suffer from fundamental design problems because of the technologies they are based on. The very concept of a web application is flawed and should be avoided.
.P 1
A web application is a piece of software, that runs on a \s-2HTTP\s+2 (web) server and is written in \s-2PHP\s+2, \s-2ASP\s+2 and to a lesser degree, P\s-2ERL\s+2 and transmits an \s-2HTML\s+2 page to a user via a web browser. What separates a web application from a simple \s-2CGI\s+2 program is that a web application is usually integrated with a database (especially a \s-2SQL\s+2-based database) and a web application performs many functions while a \s-2CGI\s+2 usually has a simple data collection or extraction function. Popular web applications include on-line banking, \fIwebmail\fP, forums and various company-specific applications deployed on corporate Intranets.
.P 1
The first problem the infrastructure on which the applications are based. The \s-2HTTP\s+2 protocol was designed for the request of static documents from servers over the Internet. The original method of requesting documents based on the \FCGET\FT method which was basically an accepted convention that any data after the question mark in a file name is not part of the file name, but command line parameters to that program. The protocol was later expanded to include a \FCPOST\FT method to transmit more complicated data. Although, this provides a reasonable method by which to communicate with a server, it is awkward for large quantities of binary data and slower than native applications. If it were simply these infrastructure problems, there would be not a severe impairment. The real problem is that \s-2HTTP\s+2 is designed to be stateless. Each request is completely independent of any previous or subsequent request from the server. Any kind of connections between these requests must be assumed by the server or client though some kind of token exchange. Since the system was not designed for this, there are many gaps in this kind of programming logic. These session are error prone and, in some, there is no way to forcibly expire a session and can expire erroneously. The underlying infrastructure was never designed to support web applications in anyway and the additions are less than satisfactory.
.P 1
Because of the way the web evolved, a programmer cannot guarantee how the user's web browser will render the resulting page. This is a more general problem with the web. Although the World Wide Web Consortium (\s-2W3C\s+2) has created a series of standards to ensure that pages will render similarly under different browsers on different platforms; unfortunately, no browser actually compiles with the \s-2W3C\s+2's specifications. Although even browsers has faults, Microsoft's \fIInternet Explorer\fP is the least compliant, yet is the most popular browser leaving programmers with the dilemma either to write non-compliant pages that will render correctly on Internet Explorer with it's some 95% of the market share or to write \s-2W3C\s+2 compliant pages that will not work correctly under Internet Explorer. Most programmers choose to either work only with Internet Explorer, write a page that is almost compliant so that it will mostly work under most browsers or try to detect the browser and maintain several copies of the page for different browsers. This is absolute foolishness. A \s-2C\s+2 programmer would be out-raged and refuse to program if the programming libraries to output data was different on different systems. Each browser also has unique interpretation of the \s-2JavaScript\s+2 language that can be embedded in \s-2HTML\s+2 pages. Again, the \s-2W3C\s+2 has created a standardised ``\s-2ECMA\s+2 script'', but again, it has been promptly ignored.
.P 1
It is a pity that \s-2JavaScript\s+2 is so paralysed because it is the only part of a web application that can dynamically interact with the user. Because the standard was designed to fetch static pages from a remote system, the page cannot interact bidirectionally with the server, it can, at best, request another page. This leaves the user with awkwardly designed pages that either constantly need to fetch new copies from the server or large pages that must download all relevant data and have \s-2JavaScript\s+2 do much of the processing. In either case this leads to programs which are non-intuitive and have illogical flows relative to programs designed using standard widget toolkits.
.P 1
In sort, the foundation on which web application are built was never designed to support them which results in programs of poor quality. I realise that web applications cannot be removed completely since some functions, like on-line banking and webmail, have no alternative means to be implemented. However, companies should do everything possible to avoid creating and using web applications.