Visual Components Library (VCL): The Best Choice for Windows Applications

[DP News-Robot]

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.

Atanas: We've seen some similar things develop in JavaScript. It is a space where there are a lot of drag and drop options, but it seems like a lot of them have much harder time connecting the design time process with actually deployment and keeping them in sync. But in terms of Windows development, what in your mind are the alternatives and how does VCL compare to them?

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: This sound pretty clear. What about some of the new tools that are out there that come from web or mobile. For example, Electron provides nice JavaScript wrappers to build native applications. What is your opinion on that approach when it comes to building Windows apps?

Marco: I can understand the desire having a single language like JavaScript that you can use on mobile and desktop. However, what we are seeing is a new set of applications that are really, really memory hogs. They consume a lot of memory and are generally quite slow. I have Windows clients for some of my chat applications or social applications and all of these are really slow. If you're just browsing messages on a social network, it should not take a gigabyte of memory. That's illogical. It cannot take minutes to boot, and it's not the connection - it's the rendering; it's the processing. A lot of them are written with Electron. They encapsulate the application like a full web server, node JS as an engine, a full browser for the rendering. And the other thing, they don't look Windows in any way. And a Windows UI is Windows UI. We should respect the environment. 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? I understand the advantage of using a single language, but in terms of performance, quality, I am not sure that the efficiency is worth it.

Another thing, the code is JavaScript, so reverse engineering and analyzing the code is more cumbersome than Delphi. Because you're relying on many more third-party components, you need to keep updating those components. You have dependencies, you have dependencies that have potential security holes, like a browser and a web server. So you need to keep continuously updating all of these modules in your system. More dependencies means less control, like recently we learned that Apple iOS has been rejecting application because the user under-commented APIs. Using a lot of open source, also presents risks. There are some advantages of course. JavaScript is a common language with many developers, but quality, performance, stability, platform integration, these are all weaknesses compared to building a native application with Delphi or C++ or another direct language.

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.



Weiterlesen...