The Future of application development

It is becoming clear to me that application development is under-going another paradigm shift with a new standard or dominant architecture emerging.

Mid 90's Client Server Architecture

In the 90's the approach to application development, at least in the pc world, was for client server applications with the client being "fat". A lot of business logic sat on the client side and the database and maybe some business logic sat on the server side. In most cases the servers where just database servers with little or no application server or business logic in place.

The advantages of this approach were:

  • a rich user experience

But the cons included:

  • Difficulty deploying and updating the client, (have you ever tried to upgrade all your workstation in your office?) ,
  • The length of time to patch the client application,
  • Operating system incompatibilities and,
  • The realization that perhaps it wasn't a good idea to have lowly pc's doing a lot of cpu intensive stuff that should be done on the server.

Late 90 - Mid 00's Web Application Architecture

Several things happened in the 90 with the development of "application servers" along with the emergence of software platforms such as Java but most notably the web. (Before Java most languages consisted of a syntax and not much else. Although libraries were available they weren't part of the standard language and you had to roll your own for things we take for granted today. How many people had to write their own C++ string class?)

This lead to a new architecture which included an central application server with business logic, a web server for serving UI pages to browsers. In most cases applications have the business logic sitting in the web application rather than a separate layer.

The pros of this approach are:

  • Short time periods to update business logic,
  • Easy update of the client,
  • PC's don't need to do any heavy lifting,
  • You don't have to worry about what OS the client is running, as long as they got a browser. (Browser incomparability has tarnished this some-what. Thanks Bill.)

The cons are:

  • Poor user experience,
  • Slow applications that decrease productivity

Clearly this is a vast improvement over the previous paradigm but, as it turns out, user experience is quiet important. Over the last three years several new approaches have started to emerge. The most notable of these is AJAX aka Web2.0.

Mid 00's - AJAX/WEB2.0 Architecture

AJAX is an attempt to patch web applications. Personally I think AJAX is a very bad idea. It attempts to solve a fundamental problem with browsers using a technology not really intended for the purpose. Just thinking of all the potential security issues is enough to make me break out in a cold sweat. (I hate it when a technology that fulfills a need get used in areas that it shouldn't. XML is a good example of this like XML configuration files.)

The only way to be productive with AJAX to use a toolkit of some kind. Now this is ok as all modern languages make use of libraries and frameworks. The problem with AJAX is that if you need to extend the framework you on your own and have to deal with all the javascript oddities and cross browser issues that exist. I am hoping that AJAX is just hype and dies as better alternatives become available.

Late 00's - Rich Internat Application Architecture

So what can give users the experience they crave, leverage existing skills and infrastructure, be easy to use and secure. This is the emerging area of "Rich Internet Applications"

RIA's, in my opinion, differ from Web2.0 applications in that they don't try and patch the browser but rather use the browser to launch some client side technology to run the client application in or, in some cases, by-pass the browser completely such as Eclipse's RCP or XUI Running in the browser can be done by embedding some kind of virtual machine, such as Flash or Java. With RIA's browsers are a uniform way to push updates down to the client and to launch the application.

There are two approaches to RIA's frameworks:

Of these approaches the XML UI + scripting language approach holds the most promise. These frameworks use XML to define the user UI and expect data to be received and sent in XML format and have some scripting language for the user interaction and event handling. The advantage of using XML for the front-end is that everyone is already familiar with XML and it is standards based.

The benefits of using XML for the data transfer between client and servers is that there already exists a functioning technology for sending and receiving XML data in the form of Web Services and the SOA pattern.

Also it allows for the true independence of the UI from the technology that the business logic is implemented in. With web application one has to make sure that the language used for the web interface integrates with the language used on the business logic tier. EG Struts/Tapestry for Java ASP.Net for .Net etc. This also means it is easier to develop multiple front-ends to the same services!

I don't like the â??fatâ? client approach of defining UI using language or platform specific code because it is slow to implement and unnecessarily complex. The recently announced JavaFX seems to fall somewhere between the two approaches outlined above. I haven't had a chance to play with the technology yet so can't give a considered opinion on it.

Of course the danger with this approach is the loss of the cross-platform principle. I am sure Microsoft would like nothing more than to lock everyone into Internet Explorer again.

10's The future

So in my opinion the future is:

  • XML based front-ends,

  • Scripting languages for front-end development,

  • Data transfers in XML with web services and SOA and

  • A much richer user experience.