Will there be a VCL for Ruby?

There has been nothing like Delphi since Delphi. For an all-too-brief, shining moment in the late 90’s, nothing could touch it. Its visual design tools made it simple to build attractive user interfaces. The Object Pascal language was powerful and clear and compiled in an instant into lightning-fast native executable files. A fraternity of developers supported each other in a variety of forums, including the hundreds who eventually joined my Delphi mailing list, my first, and most successful, foray into online community building.

Life was good.

What made Delphi even more remarkable was its component model in the form of the Visual Component Library. Originally authored to be a cross-platform widget library for Windows and OS/2, the VCL layered sanity on the Windows API, providing a clean and easily extended framework that made it dead simple to write your own components. Thousands were written, and they did everything. There were rich UI components for heirarcial data grids, tabs, and toolbars, components that wrapped all of the key Net protocols, native OCI (Oracle Call Interface) connectivity — and they all compiled right into your app. Under the unusual circumstances that a VCL component didn’t exist for your need, then you had the absolute pleasure of writing your own, using the same language and techniques that glues the rest of your app together.

For a programmer, the VCL had great feng shui — it just felt right. The message passing was elegant and easily extensible. The encapsulation was clean. You composed powerful hierarchies of objects into an application and it all just worked. No external DLL dependencies. No having your app break the users other apps or lack of support for OOP — both banes of the Visual Basic world at the time. I loved it.

But it was the work of the Devil, and by Devil, I mean, of course, Microsoft. Building Delphi apps meant developing under Windows and developing for Windows. We all knew the dirty tricks Redmond was up to as 2000 approached, and supporting their tools and technologies was both economically necessary and morally indefensible. With Microsoft using Borland as a weaning ground for the development staff of their own Tools Division — alternately beating then backing Borland like an abusive husband — and with the advent of the web and Java, the game changed. Delphi jobs became harder and harder to find, and the web emerged as non-evil alternative to Win32 hosted programs.

I took a step back in user interface capabilities to embrace the web, and to launder myself from the stain of Microsoft. I used Java, then embraced Ruby on Rails. I found a linguistic elegance in Ruby that far surpassed the strength and clarity of Object Pascal. Birds sang, and the sun shone like a golden orb floating on an azure sea. Life, again, seemed good.

Still, creating stateful user interfaces over stateless HTTP is a messy business. You store state in HTTP put and get parameters, in sessions, in cookies, in databases, in files — state, state, everywhere but elegant encapsulation and persistence nowhere to be found. The ringing clarity that the VCL provided is a fading memory in the general cacaphony of web development. There are echoes of it in the syntax of Ruby, and in edge frameworks like the Smalltalk-based Seaside. But there is nothing to do for the web what the VCL did for GUI development.

Or maybe there is.

Recently, CodeGear, the erstwhile developer tools group at Borland (the ones that have not left for Microsoft to create .NET and Visual Studio) has come out with Delphi for PHP. Yes, Delphi for PHP, which has got to be the bizarro marriage of the year. It is hard to know who their target audience is for that product — people who strive for elegance run screaming from PHP, and Borland’s tools are all about elegance in execution. This Windows-based IDE for PHP is unremarkable from my perspective, but the technology underlying it could change everything. Specifically, the open source VCL for PHP.

If the VCL for PHP does for web development what it did for Windows development, then the end of conceptually clumsy web apps could be in sight. Rails answers the need for good-enough object persistence, dispatching and page rendering, but it does not rise above the mire of the HTTP request cycle. It does not solve the statefulness impedance mismatch that makes web development harder than it needs to be. When applications are composed of well-encapsulated components, then the word “components” will not be uttered through gritted teeth in the Rails community, as it currently is due to the fundamentally broken nature of components as currently implemented in Rails.

Imagine the power of the VCL with the expressiveness of Ruby and the beauty of Rails. Rails could become a Domain Specific Language for building visually rich and powerful web apps, typified by Avi Bryant’s Seaside-based DabbleDB — applications that easily rival desktop apps (finally!) in flexibility and fuctionality.

It is great to see that Borland finally “gets” dynamic languages. It would be even greater for them to get the best of them, Ruby, and to find their way into relevance again by marrying their potent VCL to Rails. We would all have bigger and better blocks to build with — blocks to build a richer, more interactive web for tomorrow.

Update: Be sure to check out the follow-up to this story.