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.
Reduce development time and get to market faster with RAD Studio, Delphi, or C++Builder. Design. Code. Compile. Deploy.
Start Free Trial
Free Delphi Community Edition
Free C++Builder Community Edition
> Here, I just want to share the other side of UWP story which is happening positively.Interesting, I wasn't aware. My reference to "UWP not existing any more" is to be read "as originally planned and promoted by Microsoft as the unifying technology.... etc etc". Some of the elements of UWP and WinRT and specific technologies are there to stay. I don't thing the "vision" is the same it was...
Marco, The statement from you "UWP doesn't really exist anymore", is not so...I remembered we discussed this before, VCL has been part of programming life for years, I am ok with legacy stuffs and even UWP is totally dead on Windows, I am still developing for Xbox One using UWP C++ WinRT as there is not many programming options available for Xbox One platform. Initially I found it very difficult to learn, slowly once get use to it, I managed to work with Gamepad controllers, Audio, Async thread, Timer, Animation, XAML form components, all working fine in Xbox One console though ( yes, you can create application or games in Xbox One console ).In fact, I starts to fall in love with UWP C++ WinRT.Here, I just want to share the other side of UWP story which is happening positively.
With FMX we put a lot of care to provide a very high degree of platform fidelity, so that an application is not significantly different from one built with native tools. I don't see that much with Electron apps. QT is somehow similar to FMX, from what I know. I think the UI is a bit less platform specific.
"We will never write an iOS application that does not look iOS. Why should we write a Windows application that looks completely extraneous to the platform, completely different from the platform?"
What about Self drawn FMK? And what about QT? And how about VS code?
Sure, Delphi and C++ Builder share the same library -- so almost everything in the text above referring to Delphi applies to C++Builder. This is the transcript of a conversation, we didn't want to edit too much to keep it "fresh" so there are some inaccuracies
Marco, you aren't quite correct here: "Delphi and VCL are the only true visual development options dedicated to Windows today" - what about Embarcadero C++ and VCL - this too is a true visual development options dedicated to Windows!.