Atanas Popov (General Manager of Embarcadero) and Marco Cantu (RAD Studio Product Manager at Embarcadero) have had a conversation about the role of VCL for Windows client development. This is an un-edited transcript of the recording of the chat.
Atanas: Hi Marco, I wanted to take this opportunity to ask you a couple of questions about VCL. As the interest in upgrading to Windows 10 grows and companies consider modernization options, people are always asking, "Well, do I go VCL? Do I go FireMonkey? Do I go Web?" While we have a lot of information on VCL, it's either too technical or it is too high level. It appears that we can't get the right balance to communicate clearly why VCL is such a great choice. So given that you are one of the foremost experts on the subject, I thought that I can ask you a few questions on VCL. To start with, can you give us your definition of VCL?
Marco: VCL is, as the name implies, a Visual Component Library. It's a class library representing both in-memory objects and visual objects that you can use on your application. It is both visual and component-based, meaning you have the ability to drag and drop components in a designer and immediately preview and get a feeling of how the application is going to look like and behave. I believe that early on, it borrowed some concepts from Visual Basic, which is one of the other early tools in this space.
However, differently from other tools in that space, especially at the time, it was fully object oriented. So anything you do in the designer, like creating a button, you can achieve at run time. In fact, the designer is the run time, it uses the library itself. That was very unique and powerful. While it has been replicated by some other IDEs recently, few can achieve that, especially for Windows. It remains one of the key tenets of RAD Studio, this dual nature, very easy to use and very fast for developers to create the UI and also add logical components like a database table with a query and a SQL statement, then connect it to your data grid or visual component. So everything can be done very smoothly. When the application grows, you can move most of this to the application logic to have a nicer and more robust architecture.
Marco: VCL started as a wrapper on top of the Windows API, but it is very high-level of a wrapper. It is a thick layer. It adds a lot of concepts on top of the APIs, but still most of the VCL control have a Windows handle. So, they map closely to the API and the mapping is very strict. For example, Delphi is the only language that has a keyword message that lets you map to a Windows message. By comparison, other languages in the Microsoft space use more complex code to go around and do this mapping. For us, this is a language feature, which is really unique.
The only library that gets similar to what we do is WinForms for C# and.NET. However, WinForms is much smaller in terms of library scope and has fewer components. It is also .NET, which means that every time you are using a component, there is a call from.NET, a marshaling call to the native and then back, while Delphi being native, everything is compiled, everything is a direct API call, therefore faster and smoother. The layer has more complex actions and the action manager concept abstracts the UI. In WinForms this is available through third-party add-ons, but not as a native feature. Unfortunately, WinForms development stopped quite some time ago while VCL continues to have full integration with not just the Windows API, but COM and now integration with WinRT. Because these are all platform layers, they are all native, all written in C++ ultimately, but we can interface directly with Delphi.
The other alternative is Visual C++, but Visual C++ is really a thin layer on top of the API. There is very little productivity advantage and it's not visual. You don't drop components. You do that only for dialogue boxes, but it's not how visualization is generally understood. Yes, it's good, you can call an API as natively as Delphi, but the library is limited and you end up having to write way more code than you do on the Delphi side. Plus C++ is a difficult codebase to maintain and upgrade.
Atanas: I think Microsoft has done a really nice job with Windows 10, and if you look at just the look and feel on the platform, it is so modern and the applications are powerful and fast. So, for the same reason that people build native application for iOS or Android, I see no reason not doing this for Microsoft. You have a much bigger screen with a lot more UX options, so you really should take full advantage of the OS.
Marco: And the other important thing to note is that, 10 years back, doing native felt you're at risk. Microsoft just kept saying, "Oh, eventually, there will be.NET only running on Windows." And so a lot of our customers were scared, saying, "Oh, what's happening here? Because in the future, I won't be able to run my application." That didn't happen. Five years ago there was another scare, "Oh, you need to move to Universal Windows Platform, because if it's not Universal Windows Platform (UWP), it's not going to run on Windows." All of our customers got worried. Then, we had the desktop bridge, and we were able to support the Universal Windows Platform seamlessly through Centennial. Your VCL application can be easily deployed to the Windows store. Today Microsoft has completely reversed the position. UWP doesn't really exist anymore, and the new platform component on Windows are native. So the new Edge control for embedding the Edge Chromium web browser is a native control. The new WinUI version 3 has a bunch of native controls. So Microsoft is kind of giving up on trying to push everybody on UWP and say, "Okay, go native," and then for protection and security, they are going to use MSIX, which is a technology that's very friendly to the native compiled application. So, that's great for us because it provides even more APIs we can embed, encapsulate and support from the Delphi and C++ VCL applications.
Atanas: I do think that Microsoft with Surface strategy and other moves, have done well to energize the Windows platform in general. So they are more confident in that path, which is excellent for us, excellent for Microsoft. Any last comments related to building a Windows application today — or any other advice for customers?
Marco: There are few things that are important. First is start considering today's hardware and architecture and not yesterday's. Start to build applications that really have the Windows 10 UI, and not the Windows XP UI or something like that. Using styling is relevant. If you use styling, it is a little extra effort, but using styles allows you to have an application that feels native, and you have the flexibility of adapting to whatever is native like today or tomorrow or the day after tomorrow, without having to rewrite anything in your code. So the fact that the application can look Windows 7 or Windows 10 just by changing a flag, provides a lot of additional value because there's no rewrite.
If you consider Microsoft, they're saying, "If you want to embrace the new modern UI, rewrite your UI from scratch." And honestly, it's difficult for a company that invested years in building the UI to rewrite. We say, "No, just apply a level of styles on top of UI. It will still become a very nice application. There is some work, it's not completely free, but it's a small percentage of your development effort. And we are focused on making sure that styles work perfectly on all scenarios. There's still some hiccups on 4K monitors, but that is one of the areas we are focused on fixing. For example, we now have support for having images in your application that have multiple DPIs, so you can have high-quality crisp image even on a 4K monitor. There aren't many other Windows UI libraries that offer this capability. In most other windows UI libraries, you're on your own in terms of supporting a high DPI monitor. There's no ready-to-use components. So it's important to start thinking about 4K monitors from the beginning, start thinking about styles, and start thinking about UI. "Okay, I shouldn't use a check box, I should use a modern component replacing it via a toggle because that's the modern look and feel and the modern style." The good news is that all of these things are parts of VCL, so you don't really need to do much extra effort rather than rethink your UI a bit, learn about these new components that we provide, and embrace them.
Atanas: Very cool. Well, thank you, Marco. This is much appreciated. We need to do a lot more to communicate what VCL is all about. There are so many wonderful VCL case studies out there. However, our customers are busy, they don't always share those, so the more we explain, the more our customers will be confident in building new powerful apps incorporating these features.
Marco: Sure. I want to say that Delphi and VCL are the only true visual development options dedicated to Windows today. And that commitment has been true for many years. You can take a 24 years old Delphi application, rebuild it and within a relatively limited effort make it a first class Windows 10 citizen. The other options, like Visual Basic (and maybe Visual FoxPro) have come and are gone. Your investment in VCL is still here today, and it's going to be there in the future.