Rapid development integrated application development solutions attempt to create an environment where the developer will not have to write HTML. Ideally, the developer has a library of user interface components that can be visually dragged and dropped onto their "canvas" and then hooked up to some kind of data interface.

These kinds of rapid application development (RAD) environments have existed for desktop application development for over 20 years, examples being Visual Basic, Delphi, and Powerbuilder. This really makes one wonder why a dominant and successful equivalent has not leaped to the forefront of web application development.

Unfortunately, the architectural difference between the way a web browser interacts with a server and the way a native computer application interacts with its environment makes RAD development a real challenge. Native applications operate in a memory hierarchy to display themselves, meaning each object displayed, whether it is a button or an input, is a memory object holding a reference to its parent object. Any RAD tool, running on a desktop, is also going to represent itself in this way.

Now, how can this memory representation be related across the internet to a browser? The answer is that it can't be done using standard HTML. Only the appearance of the objects can be translated to HTML but the actual relationship between the objects cannot be directly transformed. It is easy to imagine a tool generating HTML to make a web page display the objects as they would appear in a desktop application, but how are the objects actually related to each other? When a user drags one object on a web page, do other objects get dragged along with it? HTML has no way of relaying this kind of information to the browser.

So, in order to make a rich user interface the developer ends up having to write javascript to implement complex relationships between DOM objects without the help of a RAD tool. So, the main purpose of the RAD tool then becomes only to map DOM elements on the page to memory objects on the server. This is already easily done without the help of a RAD tool, by using formbeans and form parameters, so the benefit of a tool that creates a tight coupling between layout and server memory objects starts to become questionable.

In fact, tight couplings between memory objects on the server and DOM objects on the browser are not always necessary or desirable. Maybe an input is only used temporary on the browser and never actually submits to the server. Why would one want an object on the server waiting for input from it then? Furthermore, an object that wraps a bunch of functionality is going to be much larger than an object that just wraps a placeholder for data, so a user's session on the server is going to be much larger.

Also, any kind of tight coupling is going to limit the number of layout options developers have. Is it possible for a drag and drop development tool to cover all of the things that are possible with HTML and CSS? With HTML5 the things that can be done with CSS became even more interesting, so the importance of hiring a good web designer went up once again.

Interestingly, new JSON frameworks such as Angular are also selling the idea of tight coupling, refered to as "two way data binding". However,once a developer starts working in this environment they find themselves questioning why this is necessary. For example, if an entire table of data is rendered browser side, the entire table will be tightly coupled to a json data object. Typically, selecting a row in this table only results in a single identifier for that row being sent back to the server. So what is the value of binding the entire table? The answer is that there is no value to it, and it ends up creating a mess of complicated relationships that have to be maintained in the code.

Until a really great RAD tool for web application development is created, it is best to keep the DOM objects decoupled from the server memory objects. WebRocketX accomplishes this by only giving the developer a client side javascript API through which they retrieve HTML from the server. No server side components are specified or created. The developer is free to use whatever framework on the server side that they desire.

References On The Web:

Frustrations with JSF, a RAD Web App Development Tool