Benefits of Formspider: Great Performance without Great Effort

A reasonable developer should not have any trouble building an application with excellent performance.

Back in the Oracle Forms days, the only way you could make an application perform poorly was to do something that an experienced developer could easily avoid or fix when discovered, such as write a bad query. In JavaEE environments, you must be an expert in every one of the component technologies, or applications that appear to work well in development will fail in test or production.

Large enterprise applications built with Web 2.0 technologies such as AJAX and JavaScript libraries, often create too many objects in the DOM and load too much code for the browser to perform adequately. This problem is usually detected very late in the development process and may have its roots deep in the architecture, with the result that correcting the problem in time may be an impossible task. Development teams are expected to adhere to a certain set of rules and manage the load they are putting on the browser.

This is a new problem in Web 2.0 development that did not exist in the early days, when the application was divided into many pages. Users called pages from the server as needed. Even if the actual application consisted of thousands of pages, the user accessed them one at a time. With the emergence of AJAX and JavaScript libraries, an entire application can be loaded to the browser all at once. However, this doesn’t mean that it should be. The architects are faced with the problem of web pages taking too long to load. For example, an entire finance system might need to be loaded to the user’s screen even though the only operation needed was looking up an account code.

The solution to this problem is obviously to load the necessary code and screens only when they are needed. However, there is no mechanism to do this automatically. Development teams are forced to choose between two evils. They either have to manage the deployment of the code to the browser manually, or just forward the user to a new web page. The first option causes a lot of “plumbing” for the developer to manage. Naturally, this process is very error prone. The second option sacrifices the user experience. It also divides the application into arbitrary page groups. Probably, the worst effect of the second option is that it involves server-side coding which means adding another programming language and framework to the complexity of the application.

Formspider applications run in the database and load only a small (300KB) JavaScript library to the client that has been extensively tuned. Each Formspider application uses the same library. The screens of the application are loaded to the browser only when they are accessed by the user and cached for the duration of his session. This provides an environment that “by design” is going to run quickly end efficiently. You have to work hard to make a Formspider application perform poorly. Any performance problems can easily be discovered by an experienced PL/SQL developer.