• Blog
  • Building native apps for Windows: What should you know?

Building native apps for Windows: What should you know?

JavaScript framework-based solutions and we will compare them with Delphi and C++ Builder for creating desktop applications for Windows

Publish date:
Discover more of what matters to you

Often JavaScript frameworks like Electron are used for Windows desktop application development because of rapid productivity, low barrier of entry, and getting up and running quickly. Unfortunately, they often bring massive overhead and lack some features necessary for desktop applications. That is where RAD Studio, Delphi, and C++ Builder come in as the original Rapid Application Development solution.

What will we discuss today? In the beginning – a couple of words about native desktop app development for Windows. Then we will discuss JavaScript framework-based solutions and we will compare them with Delphi and C++ Builder for Windows native app development. Later we will check how these Electron and Node.js solutions and frameworks are working. In the end, we will compare Delphi desktop apps development with WinForms and WPF, solutions from Microsoft, and, of course, I will tell a couple of words about the FMX framework also for Windows desktop software development.

Why should we talk about desktop application development today?

Building native apps for Windows: why does it matter?

Why does it matter? All the time techies are inventing something new. Each year you can hear about new revolutionary technologies that are going to change the world. And you think about what you have to do. Should you drop your favorite tool and start learning something new? When it comes to web application development you can hear things like the use of web technologies for desktop software development instead of proven technologies. And that’s really great because we have to learn something new. But the outcomes should justify the means. A bike is required to fulfill its main goal – to ride well, and development tools are needed to create effective and productive applications. But in real life, it doesn’t work this way. I can also be influenced by trends, and I am also thinking about what I have to do. When you see different new technologies from Google, Apple, Microsoft, of course, we are under the marketing influence, trends and news. This is why we are trying to change something, to get something new. And that’s why I want to explain why it’s so important to make the right choice for desktop apps development today, especially when talking about Windows native apps.

Is Java a good choice for building desktop applications?

JavaScript for desktop

Each year you can hear from Microsoft or from providers of other solutions and development tools that now we finally have some new stable innovative development tool. Let’s start using it! This is what I can hear around me: we are planning to use JavaScript frameworks like Electron for Windows desktop application development because of rapid productivity, low barrier of entry, getting up and running quickly. 

I think the reason is that these guys just know JavaScript and they believe that JavaScript is the only way to make their app for different platforms. Because we have JavaScript for desktop, for web, for mobile, of course, and right now there is a trend that people are trying to develop everything using JavaScript. But you know that we cannot have something 100% universal. And, unfortunately, some JavaScript frameworks for desktop software development often bring massive overheat and lack some features necessary for Windows native apps. Maybe we are just turning a blind eye to the obvious things?

JavaScript for desktop vs Delphi

Again, why do we have to re-invent bicycles from scratch, if we already have proven technologies? Right now we’re talking about desktop apps development and especially about native Windows development. Of course, it’s a joke, but mainly because of all these young people who are trying to be trendy, drink smoothies, and ride electric scooters. But now let’s try to be more serious and let’s discuss the technical side of the question. I won’t try to put JavaScript for desktop only in a bad light and RAD Studio only in a positive light. I will try to give only the facts honestly and not one-sidedly. But I have to add that I also want to protect RAD Studio from Node.js one-sided influencers and provide other facts. I can hear a lot of informational noise from JavaScript influencers, and I have to provide my point of view, my position, and my arguments.

Java alternatives for creating desktop applications

Each year we get new frameworks, they grow like mushrooms after the rain. The most popular for today are Electron, NW.js, Meteor, and Proton Native. And all these frameworks are based on Node.js. Let’s take Electron as an example. We will look at how it works. Nowadays it’s the most popular and up-to-date framework. I think that if you ask somebody and try to Google such technology, the first thing which you will hear will be Electron. But first I propose to clarify what it is and how it works and why all these frameworks are based on Node.js. Maybe all these frameworks just came after Node.js was developed and introduced?

The most popular frameworks

Here is a very easy schema that shows us what’s the difference between JavaScript and Node.js. You know that JavaScript works on Java Runtime Environment. We have Java Virtual Machine and library classes. And usually, it works on a browser. But Node.js is a little bit different engine. It is based on a V8 engine solution for execution, it is an engine that is written in C++ and it converts JavaScript code to low-level machine code and execution. It’s faster than the classic JavaScript idea with interpretation and it does not need a web browser for execution inside the browser it’s a different process that uses the Google Chromium libraries.

What is it?

Now let’s compare RAD Studio with Electron for desktop application development. I will provide examples more related to Delphi and object Pascal and, of course, Electron and JavaScript. But before we start, let’s check what we have under the hood. Here is also a not very complicated schema that we have for Electron. We have a JavaScript programming language and we have this Node.js execution environment: V8 engine, all their modules, and APIs – this is Node.js which you are installing on your local machine. 

The next layer is a Chromium Rendering Library. The next layer when you’re developing your applications is the packaging and distribution of your JavaScript application and distribution with the host application for Windows, is electron.exe. You can rename this file. After you go through all these layers, you can start this Electron host application which will run your environment, and run your JavaScript code, which will be transferred to machine low-level code. It will be executed on the low-level machine code execution. On the right side, there is our Object Pascal or C++ for Delphi or C++ Builder, and when we are developing our application, we just compile it to win32 or 64 binary, and it’s already ready for execution on the low-level machine code. You can see how many levels we have on the left side and what is on the right side. 

And this is why when we are talking about all these additional resources that we have to use, we have to think, and we have to be responsible for them because when we are distributing any Electron or JavaScript-based framework application, we have to think and we will be responsible for the quality of Chromium Rendering library, how Node.js is working because we want to explain to our customers why our application works this way and has bugs in the Chromium Rendering library, it’s also our problems.

Architectures. Only Facts

Now let’s discuss the pros and cons of both technologies. I will start from the pros. Of course, for a Windows app Javascript can be a good option but there is a row of limitations.  If you know only JavaScript and you need to make Windows applications – Electron is a compromise for you. This is the first argument I hear from JavaScript developers. Electron with Node.js is faster than classic JavaScript with interpretation and Java Virtual Machine. You will have a single code base for client apps and server-side applications with some limitations when you can use for example the same JavaScript classes for your client application and your web application. It will be a single codebase for Windows, MacOS, and Linux. 

Maybe Electron is easy to start and use, but it’s only if you have web developers and you think that their knowledge is enough to build Windows applications. If you think that web developers are ready for creating desktop applications almost without any experience just when they know Node.js – maybe. And it is interesting that Electron has a built-in update manager.


Now about the cons. Performance matters of course. Applications will need more calculation resources, especially memory. You know that in our world sometimes instead of developing effective applications we just don’t think about such things. We think that our computers are becoming faster and faster, and the cost of development time is much higher than our computing resources time. 

During the last 10 years, the calculation resources of our computers have increased by ten or maybe fifty or hundred times! But finally, we have the same applications. And with Electron we don’t have Windows native apps, and we won’t have native UI. We have a V8 bytecode for execution inside the V8 engine. Maybe it’s only my fears, but what will we have in the future? Maybe these revolutionary technologies will be rejected and support will be stopped?


Also, you will depend on Chromium and its updates and compatibility of the V8 engine with Chromium, and it’s not an easy question. The Github community should keep it up-to-date. Not all enterprise developers are ready to use open-source solutions. Also, you have to think about source code protection issues. That’s what I hear from different developers, and it’s not only my opinion, you can google Stack Overflow most popular questions about Electron and check all these cons that people are talking about. And one of the interesting things is that when you’re distributing your application, your package will always have a lot of extra resources. I even heard that a native desktop app can have a lot of modules that belong to a mobile application, and your app will “eat” your computing resources.


Benefits of RAD Studio for desktop software development

Now let’s return to RAD Studio. We have the best performance for VCL and FMX because of low-level execution without any packages. In the end, we have binary which is ready-to-use machine code which can be executed immediately. It’s a really proven tool that you can use to create Windows desktop application. We don’t have any dependencies and layers like Chromium for UI or Node.js for execution. We have everything that we need. We have a small executable size and low memory use. And of course, we will have Windows native apps.

Pros RAD Studio / Object Pascal or C++

I have to provide a couple of cons. If somebody knows only JavaScript, this person has to study and learn the appropriate language from scratch. Maybe it will be Delphi Object Pascal or C++, or if we are talking about other technologies it can be a different language. I don’t know if it is really a disadvantage, I don’t think so. VCL is based on Win32 and 64 compilers and, again, what I hear from others is “What will happen to Windows five years from now?” Maybe in future, there will be something different, but I feel confident that these technologies are here to stay and we will be able to use and develop wind 32 and 64 applications for a long time and this support will never stop.

 I don’t know if we have any other disadvantages. Mostly they are related marketing, trends, popularity, and so on. You can hear something negative because of some marketing materials from other technologies, but I think that we know how to filter all this negative informational noise.

Cons RAD Studio / Object Pascal or C++

Interesting but if you want to try Electron and at the same time you like Delphi, I can tell you a small secret: you can develop an Electron application using your favorite tool. This solution is called TMS WEB Core.

if you so like Electron and Delphi

Comparaison of different technologies for desktop apps development

An interesting fact: during my preparation for the webinar I tried to find any benchmarks for JavaScript and compare for example this Electron or other JavaScript-based solutions and native desktop applications, and I didn’t find official benchmarks from the Electron community. You can google something like Electron benchmark, and you will see very interesting results on the first page. All that I found were some benchmarks from independent developers. Here are a couple of links which you can find on the internet. But maybe Electron is not here to compete with anyone, you just want to love it and don’t think about anything else.

about benchmarks

I had no other choice. I had to create my own three applications to have an example. They have the same functionality because I wanted to compare these three not even technologies but three different combinations of frameworks and tools. The first one is Delphi. Delphi VCL application with Object Pascal. The second one is a recommended environment for the development of native Electron applications. I’m not talking about native applications from Windows, I’m talking about native tools for developing Electron applications. The third example is Delphi with TMS WEB Core.

about benchmarks 2

All three applications have similar and very easy functionality, they are built for Windows and have only one main form. I implemented local storage interactions because for Electron it is a main difference from regular JavaScript and Chrome-based applications. What will applications do? Each 250 milliseconds they load an image from the local storage and show it to the image component. We will have a PageControl component with three tabs which are switched also every 250 milliseconds. The aim was to compare UI because if we are talking about any calculations I don’t think that it will have a lot of differences. I think the main differences are in the UI especially if we are talking about cross-platform apps. I need to admit that I can do something incorrectly. I am NOT an experienced Electron developer. I am the guy who is under the trends trying to use Electron for desktop and it’s just an example for you.

about benchmarks 3

I just created three Windows native apps for PC: with Electron, TMS WEB Core, and Delphi. What I can see is that the Electron native application and Delphi and TMS WEB Core applications are the same. I mean that using TMS WEB Core you can create the same application as with native Electron development tools. Under the hood, they are working similarly. 

Our VCL application is using the same resources, for Electron we have three processes, the CPU is the same, but memory is increasing, I don’t know why. In this case, I can say that TMS WEB Core and native Electron tools are almost the same, you can use Delphi to write Electron applications. As for the memory, you can see that memory is increasing. And again maybe my benchmark was not very correct and it will be a good idea to ask Electron experts to provide their benchmarks.

How to build a desktop app for Windows with Microsoft tools?

Ok, we discussed JavaScript-based development, and what else do we have for Windows desktop application development besides JavaScript? Let’s start with what we have from Microsoft. It’s a really interesting question. During my development career, I tried a lot of solutions for creating desktop applications for Windows, not just tried – I developed huge systems and solutions using Microsoft technologies. I can ask myself if it is possible that Microsoft solutions can not be the best tool for building a native Windows app.

Solutions from Microsoft

Well, let’s compare Delphi VCL, FireMonkey. VCL is only for Windows, win32 and win64 applications, and FireMonkey is a cross-platform framework with a different number of classes inside Delphi. For native Windows application development, from Microsoft, we have WinForms and WPF, and let’s compare these two technologies with Delphi. 

If we are talking about WinForms, it is really the first developer-friendly framework for Windows after Visual Studio 6 it was a 2003 version when the C# and .NET were introduced and for me, it is just a little copy of Delphi. The concept was very similar. WinForms UI capabilities for Windows native app development are still too weak, it’s too hard to customize UI controls. For today I don’t know people who start new desktop software development using WinForms, it seems to be an almost obsolete framework. I think that Delphi and VCL are really more developer-friendly tools for building rich UI applications. There is a huge set of UI components for building rich UI including Windows native apps and Windows 10 applications. But of course, the world is changing and if you need something newer and more universal, with cross-platform capabilities, you can try FMX.

WinForms vs Delphi

If we are talking about WPF technology from Microsoft, it is a really flexible and deeply customizable framework if compared with their WinForms. It’s very adaptable for building rich UI Windows native apps. But as for me WPF sometimes is not trivial for developing rich UI apps using XAML. And it has to work faster but not on the obsolete computers. We need to have modern powerful devices.

I think it will be more correct to compare WPF with FMX, because FMX has its own and new generation framework for building applications and because we have a new style-based development ideology for styling our products when we make Windows applications. This is why I think that WPF is a little bit above VCL, but FMX is on the same level.

WPF vs Delphi

If I have already mentioned FMX, let me also speak about VCL and FMX. If we’re talking about VCL, we still can use it for brand-new development because it has deep Windows OS integration including Windows 10. It is only for Windows today and it will stay the same in the future. It has a huge  3rd-party component availability, especially for Windows. If we think about cross-platform or we have some requirements, maybe in the future we will have something multi-platform, theoretically, we can start from VCL and then just migrate VCL to FMX. How to modernize your desktop apps? Most of the modernization tasks will be in the field of migration of user interface because FMX has totally different components, structure, and ideology. 

But if we choose FMX for brand new development, we will have a Windows native application with a single codebase and the future possibility of adding support for Linux and MacOS, because for FMX it is building the same native application as for VCL. When you’re compiling your application to a low-level machine code, FMX has a new GUI concept based on styles. I think it’s very interesting, and you can even try to check FMX samples from the GetIT package manager and check how they work. Each cross-platform technology has its limitations, and, as I said, in the end, you will have the same executive as for VCL. The decision is up to you, you can check and you can think.

Cross-platform native Apps with Single Code Base with RAD Studio

This is why RAD Studio, Delphi, and C++ Builder come in as an original Rapid Application Development solution today. Using it Delphi developers can achieve maximum productivity, ensure native desktop performance with less overhead, and get access to all platform features without any limitations, additions, and so on. But if multi-platform is a requirement for you, then you can try the FireMonkey framework which will give you desktop application compatibility for Windows, Mac OS, and Linux, with the option to extend them to Android and iOS.

Subscribe to our newsletter and get amazing content right in your inbox.

This field is required
This field is required Invalid email address
By submitting data, I agree to the Privacy Policy

Thank you for subscribing!
See you soon... in your inbox!

confirm your subscription, make sure to check your promotions/spam folder

Subscribe to our newsletter and get amazing content right in your inbox.

You can unsubscribe from the newsletter at any time

This field is required
This field is required Invalid email address

You're almost there...

A confirmation was sent to your email

confirm your subscription, make sure to check
your promotions/spam folder