Over the last few weeks, I was quite busy, but collected many posts regarding the VCL and its future. Some of them relate with the recently published Delphi roadmap, but not all of them do. This is a long post... hope it is also useful to get the bigger picture. I was certainly pushed to write this by several posts including:

Between the Lines of the Roadmap

I already posted about the Delphi roadmap, but it was updated and some more information became available for those good enough to read between the lines. First, the role of generics in Highlander has been clarified: they will be there in full mode. Second, as first reported by Julian, the C# support will be downplayed and the WinForms designer removed. Third, the 64-bit version of Delphi has a code name a a more precise time frame. There is more info in this thread.

As Nick stated many times, the roadmap is a work in progress. The plan is constantly updated reacting to users feedback, but also with further exploration by the R&D team. This is positive, as plans should guide users but not set in stone.

VCL and API wars

A relevant blog exchange related with the VCL is the one that took place between Steve Teixeira (of Delphi books fame but now working at Microsoft on Visual C++) and Steve Trefethen (at the time still a "full" CodeGear employee). I find it very interesting that Microsoft is now more serious on Win32 and native development than a few years back. Maybe not every application is moving to .NET, after all.

In a very well written post (over one month old) Trefethen considers that while Microsoft is all for .NET, their main products like Office and Vista are native applications. Of course, the OS must be native, but all the system utilities and tools are native as well. This is odd. If Win32 is dead, why add thousands of native APIs? The fact that Visual Studio support for Vista is more limited than Delphi's one is quite amusing. Question: will VCL.NET have full Vista support sooner than WinForms? What WinForms offers in that respect is a set of shallow add-in classes to call the native API.

Teixeira replied to this post with an interesting piece. He claims you can build "cool looking Vista apps in straight Win32, but the point is that it requires more effort than some of the alternatives". Well, with better native class libraries we could probably reduce the effort, even without having to move to WPF. Not that I dislike WPF. It is much better than some of the web-related alternatives, but I don't see many users looking forward to animations and nice effects in their accounting software. Anyway, you have to read the long post, here I'm giving you only another small quote: "We [the Visual C++ team] have some very aggressive post-Orcas plans for advancing the state of the art of native development!".

With the advent of Vista and a little more stability in the CodeGear camp, I'm getting many consulting requests from companies who use DelphiX (5 to 7, in equal percentage) and want to move to Delphi 2007. Vista support is certainly a reason. Having to drop the BDE (!) another. Looking for a more powerful IDE and better language/libraries a distant third. The amount of investment in Delphi code is huge, and there is no compelling reason for most of these companies to move away from native Windows VCL applications. Maybe Europe is different from the US in this perspective...

What I find very interesting is that CodeGear is investing on the VCL again. Unicode support is finally official (even if late, I agree). The developer team was looking for input and got some. They mention a "Ribbon-like UI", better multi-threading, and several other features. The VCL has been growing a little over the last year (after a long stop), but I want more! I know that the VCL for .NET lacks third-party support, and this is why it is not as much used, and this is why there are not many third parties... and so on forever. CodeGear should try to break this negative loop, but that's not easy.

WinForms, WPF, and the Future

Beside the ASP.NET world, the status of the user interface libraries on .NET is in a flux. WinForms is stable, but hardly pushed by Microsoft and its use is far from widespread. WPF (including its variations, like Silverlight) is taking off, but I don't see it well suited for classic client/server programs. Many Microsoft evangelists I spoke with agree with me. Is WinForms a central piece of the .NET technology and is it silly for CodeGear to drop its support? If WinForms is not heavily used (I remember a 88% to 12% ratio between ASP.NET and WinForms from a Microsoft source a couple of years back, with WPF still out of the picture) it is marginally used by Delphi developers: only a few of the few on Delphi .NET use it!

I've used WinForms mainly for CF projects. I decided not to use the form designer anyway (because of the CF compatibility issues), so I won't miss it! I'm among the developers who prefer VCL.NET to WinForms. Not only because I know it. Not only because I have the source code. But because my code is portable, the library is rich (can I say more rich?), I feel at home, my data access code still works, it is Delphi. Truly Delphi is the language plus the library, keep half of it (the Object Pascal language alone) and it is not Delphi any more. I'd love CodeGear to support every technology out there. But having to choose between a better VCL (including a better VCL.NET) and WinForms support I'll vote the former. And having to choose between WinForms (something similar to VCL.NET) and WPF (something totally different and quite cool), I'd vote for the latter. The mistake was probably to redo the entire IDE for supporting the WinForms designer, but that's another story!

Summary: Delphi is the VCL

If you've read the entire post, you should know what I think. For me, Delphi "is" the VCL. So any advance for Delphi should be bound to an advance to the VCL. For example, now we have overloaded operators, but the VCL is not using them... so you don't end up using them often! On the other hand, the for..in loop is a hit because of the VCL support for it. This is a double-edged sword. CodeGear must put a lot of effort to keep the VCL growing much much faster than in the past, with Unicode and all. And moving to 64bit and multicore support. And adding nice graphical features to it. And look for a smooth support of XAML...

Nick states that CodeGear wants to be different, not play catch up with Microsoft feature by feature. I fully agree. If Delphi is the VCL, CodeGear is leading!