Formspider vs. Apex

Every product is built to solve a problem. Before its implementation, its creators ask a question and come up with an answer which is the product. How should we stick nails to a wall was the question the creator of the hammer asked.

This question can be asked pragmatically by looking back in time. For example, for centuries humans asked how can we travel faster and decided to breed faster horses. Then Henry Ford came along. He asked the same question, looking into the future and came up with the automobile.

Back to our case, Apex is first built in early 00’s looking back in time and asking the question: “How do people write web pages?”.

Formspider is first built in 2008, looking into the future and asking the question: ”How should we build applications?”.

These two are fundamentally different questions and as a result you get fundamentally different products.

The question it answers is engraved in the essence of the product. No matter what you do, you cannot escape it. You can change directions, play catch up to industry trends, add features, plugins, make up new concepts as you go along, yet the fundamental weaknesses in the architecture will always come back to haunt you. Case in point; this is why it is painful to build a three level master detail screen with Apex. This is why it is very hard to do version control, especially if more than one developer is working in the project. This is why it lacks a transaction management layer. This is why an Apex application is up to its gills with HTML/JavaScript; the assembly language of the Web. Working at that level of abstraction, or lack of it, is no less crazy than developing applications with Assembly code in the 90’s instead of Forms. However, if you look back in time and ask the wrong question, Apex is the only answer you are going to get.

Formspider has a fundamentally better architecture. For example, in Formspider, you don’t write web pages. The notion of a web page does not even exist in Formspider because the page paradigm is an archaic concept of the early Web. Formspider works in the application paradigm not in the web page paradigm. There are no page submits, no regions refreshes, no HTML, no JavaScript, no DOM manipulations. Formspider uses the browser as a canvas to draw applications UI. Formspider developers write code to respond to user events and inputs coming from the UI. This is why building a three (or more) level deep master detail screen is a matter of course in Formspider. For a long time, it did not even occur to us to put a demo to our web site to show off this capability because we did not think it would be an interesting one.

In Formspider, the entire application is defined without using client side technology. Therefore, Formspider architecture supports streaming applications to any device and platform that exists now or will exist in the future such as a browser, a Windows PC, a Mac, a mobile device that runs iOS, Windows Phone, Android or even Google Glasses as far as I am concerned.

Formspider has a world class transaction layer, that is fully controlled by the developer. A framework to build enterprise applications that has no transaction layer, but issues mandatory commits at certain times, is unimaginable to us. It’s ludicrous. It’s just bad design.

For a long time, PL/SQL developers could procrastinate making a decision or just go with Apex because there simply was no other choice. This is not true anymore. The ball is on your court now. As PL/SQL developers working at IT departments, ISV’s and system integrators, it is now your turn to ask the question:

Do you want a faster horse or do you want a car?

Yalim K. Gerger