Articles Building native apps for Windows: why it matters?

[FireWind]

Building native apps for Windows: why it matters?

Spoiler: Content #1

[SHOWTOGROUPS=4,20]
Often JavaScript frameworks like Electron are used for Windows 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 explanations about native desktop development for Windows. Then we will discuss JavaScript framework-based solutions and we will compare them with Delphi and C++ Builder for Windows desktop development. Later we will check how these Electron and Node.js solutions and frameworks are working. In the end we will compare Delphi development with WinForms and WPF, solutions from Microsoft, and, of course, I will tell a couple of words about FMX framework also for Windows desktop development.

Why it matters? All the time techies are inventing something new. Each year you can hear about new revolutionary technologies are going to change the world. And you think what you have to do. Should you drop your favorite tool and start learning something new? And of course about web applications development you can hear things like: use web technologies for desktop development instead of proven technologies. And that's really great because we have to learn something new. But the end should justify the means. Bike to fulfill its main goal – to ride well, and development tools – to create an effective and productive applications. But in real life it doesn't work this way. I can also be under the effect of trends, and I am also thinking 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 a right choice for development desktop applications today, especially if talking about native Windows applications.

Each year you can hear from Microsoft or from other solutions and development tolls providers that now we 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 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 often bring massive overheat and lack some features necessary for desktop applications. Maybe we are just turning a blind eye to the obvious things?

Again, why we have to re-invent bicycle from the scratch, if we already have proven technologies? Right now we're talking about desktop development and especially about Windows desktop development. Of course, it's a joke, but mainly because of all these young people that are trying to be trendy, drink smoothies, and ride electric scooter. But now let's try to be more serious and let's discuss a 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, my arguments.


Each year we get new frameworks, they grow like mushrooms after the rain. 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 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 is this Node.js and how it works and why all these frameworks are based on Node.js. Maybe all these frameworks just came after this Node.js was developed and introduced?
[/SHOWTOGROUPS]

 

[FireWind]

Spoiler: Content #2

[SHOWTOGROUPS=4,20]

Here is a very easy schema which 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 browser. But Node.js is a little bit different engine. It is based on V8 engine solution for execution, it is engine which is written in C++ and it converts JavaScript code to low-level machine code and execution. It's faster than classic JavaScript idea with interpretation and it does not need a web browser for execution inside the browser it's different process which uses Google Chromium libraries.

Now let's compare RAD Studio with Electron for desktop 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 do we have under the hood. Here is also not very complicated schema what do we have for Electron. We have 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 packaging and distribution of your JavaScript application and distribution with the host application for Windows, this 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 do 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 which we have to use, and 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 explain our customers why our application works this way and has bugs in the Chromium Rendering library, it's also our problems.

Now let's discuss pros and cons of both technologies. I will start from pros. If you know only JavaScript and you need desktop development – 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. Of course you will have 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. Of course, single codebase for Windows, MacOS, and Linux. And 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 for building desktop applications. If you think that web developers can develop desktop application almost without any experience just if they know Node.js – maybe. And interesting that Electron has built-in update manager.

Now about cons. Performance matters of course. Applications will need more calculation resources, especially memory. You know that in our world sometimes instead of development effective applications we just don’t think about such things. We think that our computers are becoming faster and faster, and cost of development time is much higher than our computing resources time. During maybe last 10 years calculation resources of our computers were increased on ten or maybe fifty or hundred times! But finally we have the same applications. And, finally, with Electron we don't have native application for Windows, nor we have native UI. We have V8 bytecode for execution inside V8 engine. Maybe it's only my fears, but what we will have in the future? Maybe these revolutionary technologies again will be stopped and support will be stopped?

Also you will depend on Chromium and its updates and compatibility of V8 engine with Chromium, and it's not an easy question. 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 issue. And 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 which people are talking about. And one of the interesting things that when you're distributing your application, your package will have all the time a lot of extra resources. I even heard that desktop application can have a lot of modules which belong to mobile application, and your app will “eat” your computing resources.

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 for Windows desktop development. 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 small executable size and low memory use. And of course we will have native applications for Windows.
[/SHOWTOGROUPS]

 

[FireWind]

Spoiler: Content #2

[SHOWTOGROUPS=4,20]

Of course I have to provide a couple of cons. If somebody knows only JavaScript of course he has to study and learn from the scratch appropriate language. Maybe it will be Delphi Object Pascal or C++, or if we talking about other technologies it can be 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 be in five years from now with Windows?” Maybe in future 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 more disadvantages. Mostly the lie in marketing, trends, popularity and so. 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.

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

And interesting fact: during preparing 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, unfortunately, that's really strange and that is really food for thought. I mean I didn't find official benchmarks from the Electron community. You can Google something like Electron benchmark, and very interesting results will be on the first page. All that I found were some benchmarks from independent developers. Here are couple of links which you can find in 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.

I had no other choice. I have created 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 frameworks and tools combinations. The first one is Delphi. Delphi VCL application with Object Pascal. The second one is a recommend environment for development 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.

All three applications have similar and very easy functionality, they are 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. Also we will have some 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. I do not pretend on a verity. I really can do something incorrectly I am NOT an experienced Electron developer. I am the guy who is under the trends tries to use Electron for desktop and it's just an example for you.

I just created three Windows applications: Electron, TMS WEB Core and Delphi. What I can see is that 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 like with native Electron development tools. Under the hood they are working similar. Our VCL application is using the same resources, for Electron we have three processes, 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 but let's suggest the experienced in Electron people to provide their benchmarks.

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

Well, let's compare Delphi VCL, FireMonkey. VCL is only for Windows, win32 and win64 applications, and FireMonkey is a cross-platform framework with different number of classes inside Delphi. For Windows desktop development from Microsoft we have WinForms and WPF, and let's compare these two technologies with Delphi. If we 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 apps are still too weak, it's too hard to customize UI controls. For today I don't know people who start new development using WinForms, it seems to be almost obsolete framework. I think that Delphi and VCL are really more developer-friendly tool for building rich UI applications. It really has a huge set of UI components for building rich UI including native Windows applications and Windows 10 applications, it's really up-to-date. But of course world is changing and if you need something newer and more universal, with cross-platform capabilities, you can try FMX.

If we talking about WPF technology from Microsoft, it is really flexible and deep customizable framework if compared with their WinForms, it's very adaptable for building rich UI applications for Windows. But as for me WPF sometimes is not trivial for developing this rich UI apps using XAML. And it has to work faster but not on the obsolete computers. We need brand new computers. If compared with Delphi and VCL, I think it will be more correct to compare WPF with FMX, because FMX has its own and new generation framework for building applications, because we have new style-based development ideology for styling our applications. This is why I think that WPF is a little bit above VCL, but FMX is on the same layer.

If I already said about FMX, let's say couple of words about VCL and FMX. If we're talking about VCL and we still can use it and use for a brand-new development because it has deep Windows OS integration including Windows 10. And it is only for Windows for today and it will be in the future. It has a huge 3rd-party components 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. Most of migration 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 really have Windows native application with a single codebase and future possibility of adding support for Linux and MacOS, because for FMX it is building the same native application like for VCL. You're compiling your application to a low-level machine code, again, as I already said, FMX has new GUI concept based on styles. I think it's very interesting, and you can even try and 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. .

This is why RAD Studio, Delphi and C++ Builder come in as an original Rapid Application Development solution today. Using Delphi developers really get maximum productivity, get native desktop performance with less overhead, and 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 FireMonkey framework which will give you desktop application compatibility on Windows, Mac OS, and Linux, with the options to extend them to Android and iOS.
[/SHOWTOGROUPS]