HTML forms for creating interactive Web pages were introduced in 1993. The addition of a handful of simple markup constructs that allowed HTML authors to create input fields and other user interaction elements enabled Web sites to deploy Web pages that could collect user input as simple name -value pairs. The values input by the user were transmitted via HTTP and processed on the server via Common Gateway Interface (CGI) scripts. This new innovation spawned a multitude of interactive Web sites that experimented with these constructs to create interfaces ranging from simple user surveys to prototype shopping applications.
As electronic commerce on the Web gained momentum during the mid-90s, Web developers moved from experimenting with HTML forms to deploying real end-user applications to the Web. These forms- powered HTML pages provided a Web interface to standard transaction oriented applications. In this programming model, the Web developer authored a user interface in HTML and created corresponding server-side logic as CGI scripts that processed the submitted data before communicating it to the actual application. The combination of the HTML user interface and the server-side logic used to process the submitted data is called the Web application . The Web application in turn communicates user input to the application, receives results, and embeds these results in an HTML page to create a user interface to be delivered as a server response to the user's Web browser.
As the e commerce Web matured, vendors rushed to deploy server-side middleware and developer tools to aid in the authoring and deployment of interactive Web applications. By this time, such tools were almost mandatory, since the essential simplicity of HTML forms resulted in scalability problems when developing complex Web applications.
Using this programming model, developing, deploying, and maintaining a simple shopping application on the Web require authoring content in a variety of languages at several different levels of abstraction. Once developed, such Web applications remain expensive to maintain and update. Notice that the move from experimenting with Web interaction technologies to deploying real-world applications to the Web brings with it a significant change; in most real-world scenarios, the application to be deployed to the Web already exists. Even in the case of new applications, only a portion of the application in question gets deployed to the Web. As an example, only the electronic storefront of a shopping site gets deployed to the Web; such shopping sites are backed by software that manages customer information, product catalogs, and other business objects making up an electronic store. Thus, deploying complex interactive sites involves creating the business logic and then exposing relevant portions of this application to a Web application that creates a user interface accessible via a Web browser.
One way of simplifying this development process is to make business applications themselves aware of the need to deliver a Web user interface. This approach is followed by many of today's popular middleware solutions, with some commercial database engines going so far as to incorporate a Web server into the database. However, making back-end business applications aware of the details of the user interface markup can make systems difficult to evolve and maintain. The resulting lack of separation of concerns ties Web applications to a particular back-end system.
As we deploy Web access to software at all levels of complexity ranging from business applications to electronic transactions, the problems outlined earlier can be better addressed by revisiting the essential underpinnings of the transactional Web. Today, Web applications need to be accessible from a variety of access devices and interaction modalities ”Web applications may be accessed from a variety of clients ranging from desktop browsers to smart phones capable of delivering multimodal  interaction. Thus, a travel application that is being deployed to the Web needs to be usable from within a desktop browser, a Personal Digital Assistant (PDA), and a cell phone equipped with a small display. Thus, the interface needs to be usable when interacting via a graphical or speech interface.
Notice that the problems with HTML forms outlined earlier become even more serious when confronted with the need to perform electronic transactions with a variety of different end-user devices and user interaction modalities.  W3C XForms  ”a revision to the existing HTML forms technology from 1993 ”builds on the advantages of XML to create a powerful forms module that can stand the Web in good stead for the next decade .