Web development is quite complex and multi-faced, which is why this post cannot be short. Before I start getting to the core let me underline three relevant features of modern web solutions (please, don't make me call them Web 2.0 solutions): (i) separation of code and content, (ii) flexibility in deployment and updates, and (iii) the use of HTML, CSS, and open standards.

Warning 1: I've not provided links to the various technologies mentioned (would have taken hours), Google can help you find out more. Warning 2: I know this post is confused and too dense and skips too many details... but I found no other option.

Many Alternative Options, No Outstanding Solution

The way I see it is that there are many different solutions. None gets close to a perfect, from what I've seen. Here is a categorisation, useful for the following discussion:

1. pure scripting (for example php or asp), where the pages include HTML tags, the script, possibly SQL statements for accessing a database and the like.

2. scripting with a database access layer, providing a clear separation of the database access code. The script creates pages using “server side objects” (java, php plug-in, COM objects) for data processing and database access.

3. scripting with a full component layer, mostly to simplify the generation of the HTML and user interface management (for example, asp.net). In this model not only data access, but also HTML generation is based on server side objects, often compiled. The development tool helps creating pages, but separating the programmer's work from the designer's work becomes more problematic. An alternative option is to have a more traditionally compiled application.

4. scripting with an integrated management of the user interface and of the database access layer (like ruby on rails and its various “clones” written in other scripting languages). The idea is to match the database structure, possibly an object persistent framework, with an MVC like user interface architecture.

5. script (or other solutions) that generate xml data structures: a common solution in the past was to use xslt or a similar layer to generate the user interface, but another option these days is to separate the AJAX/JavaScript driven UI from the REST-based backend.

Where Does Delphi fit? Delphi can be used (at least partially) in many of these scenarios. You can write server side objects for models 2 (asp, php) and 3 (asp.net). You can also create complete stand alone applications, with IntraWeb or WebSnap, still part of model 3. It seems to me that Delphi fits best in both scenarios of model 5.

Which is the Best Approach?

I don't think there is a clear-cut answer. In the first model the code easily becomes unmanageable. Most of the models lack a clear cut separation of content from code (with, in my opinion, 2 and 3 being particularly troublesome in this respect). If scripting requires compiled objects, their upgrade and deployment might become far from trivial. Using xslt makes data entry complex and requires a super-expert graphic designer (as most tools cannot even manage correct XHTML).

What about performance? I've been told Ruby and other scripting solutions suffer, and make sites not so scalable on average hardware. But I don't know much in this respect.

What can Delphi Offer?

Delphi's strong point are well known:

• Multiple very good data access layers.
  
• Good integration with other web protocols and web services of various types (this is very handy for intergrating multiple sources of information, creating mashups).
  
• Optimized compiled code for Win32, .NET, and Linux.
  
• Object/relational mapping libraries, including Instant Objects and ECO.
  
• Excellent computing power, XML and string processing capabilities, and memory management.

But how can Delphi offer these features? Purely compiled code seems too troublesome to me. I think Delphi needs a client side layer (AJAX) or a server side scripting layer to be used for assembling different commands. There are multiple scenarios I can see:

1. Create Delphi objects that provide services to other solutions (asp.net, php) putting Delphi in a very limited role.

2. Define a native scripting layer (not necessarily in a Pascal dialect) or a configuration layer that calls into Delphi objects for the processing and produces either plain XML (for REST/AJAX solutions) or goes through an XSLT layer for direct HTML (or PDF) generation.

I can say I like solution 2, because it is very close to what I'm using for creating tens of different web sites these days (including this blog). Our choice was to implement (in Delphi/Kylix) an XML-based scripting language, a decision I don't regret. At the moment our architecture is not open enough for direct use by Delphi developers, but this could be a possible outcome of our work: we only need to allow dynamically loaded packages with extra commands provided by users.

AJAX and Delphi

A specific area, part of the second approach above, would be the use of AJAX, CSS, HTML, to define the front end of a Delphi-powered application. Delphi's classic Internet Express (do you remember it, it was way ahead of time!), is an interesting example of database and JavaScript driven pages. In any case, creating JavaScript client UIs and writing server side applications to provide the proper XML (using a REST approach) makes a lot of sense. What is lacking, though, is a proper graphical/RAD tool. Even better, you'd need a tool (an IDE, a wixard...) binding the client side code and the server side architecture. If CodeGear will invest on AJAX, I hope they do this with (also) a Delphi backend in mind. This can easily beat Ruby on Rails and similar approaches, and would be better than directly cloning them...

So why not add to the roadmap a new BDS personality, JavaScript, and make it the UI generator for the server side processing code, to be compiled with Delphi for Win32 or with Delphi for Linux (even with a cross-compiler...). This vision, properly executed, could make Delphi stand out as one of the best web development tools. The current scenario is far from being stable (if you think so, notice how AJAX and Ruby on Rails turned the tables over) and is still open for new ideas and proposals. I hope CodeGear has one. I hope they keep Delphi in the picture. If not, let's try to build something ourselves...