Desktop Software Development Framework Awards

*This article is based on the reorganization of content shared by Hikvision's desktop technology expert Liu Xiaolun in the event " RTC Dev Meetup • Hangzhou Station丨Business Architecture and Cross-End Practice in the Big Front-End Era ".

The following text:

Today, I want to share with you 19 desktop software development frameworks. I divided them into four categories, and then introduced each category accordingly. I hope that through today's sharing, I will help you to avoid some detours in the development process.

01 Traditional desktop software development framework

First, let's talk about traditional desktop software development frameworks. This category includes the familiar Qt, wxWidgets, GTK, FLTK, Swing and JavaFX. These six frameworks have some things in common: they all have a long history, many developers use them, and the corresponding communities are mature and rich in material. In addition, they are all powerful, with a large number of mature cases, and the framework is stable.

However, they all use relatively mature technologies, so there is still a gap between them and emerging technologies, so it is more difficult to use.

1. Qt

The advantages of Qt can be seen on the official website, and I won't repeat them here. One of them is that Qt has done a perfect package for each operating system, such as network, file clipboard, etc. If you want to use system-level API , the very rich API that Qt can provide.

Regarding the Qt problem, I will introduce my feelings here. I think the current problem of Qt is that the development direction is not very specific, and it cannot provide some larger modules . During the development process, it may gradually find that the modules used are not suitable, and then Deprecated this module, including many APIs, the Qt script I used before has now been marked as deprecated.

Also, Qt's commercial licensing is not very friendly . If you want to develop a commercial application, you may have to pay attention here. There are many domestic companies who have received Qt's lawyer's letter requesting fees. Qt also provides a lot of components, some of which are complex components that are difficult to control the details of the UI, so I won't give examples here.

Qt also has many dynamic link libraries. It is difficult to do static linking. Of course, the community provides a way to compile Qt source code for static linking, but this involves copyright issues.

2. GTK

The GTK framework is more partial to Linux. Many desktop applications in Linux are developed with GTK. There are relatively few GTKs under Windows, and static linking under Windows is also more difficult, and even the environment is better than under Linux. Much harder.

In addition, GTK also encapsulates the system API under Windows, but the encapsulation under Windows is less than that under Linux. That is to say, some APIs can be used under Linux, but cannot be used under Windows, and there are many such APIs. Finally , the commercial licensing of GTK is very friendly.

3. FLTK

The FLTK framework is recommended by the father of C++. It is a very lightweight GUI framework, but its lightness means that its functions are insufficient. It has few functions and almost does not encapsulate system APIs . Most of them require developers Write it yourself in C++. This causes developers to rewrite on each platform. For example, to open a cross-platform image application, then some system-level APIs are called for implementation under Windows, and it may be implemented again under Mac.

The advantage of FLTK is that its product is small, so it compiles things that can be small, and the performance is very good (better than the first two). The commercial license of FLTK is also very friendly and can support static linking. But FLTK has some shortcomings, because it is a GUI framework, so it is not very good at drawing GUI components.

When I used FLTK, I found that I would encounter problems when doing animation control and component overlay (when absolute positioning is used at this time, it is necessary to control the level of components). In addition, when drawing rounded corners, although FLTK provides related functions, the user also needs to control the special size of the rounded corners, the appearance of a certain rounded corner, etc., which requires writing very complex codes.

4. wxWidgets

wxWidgets is different from the previous three frameworks. It is based on the API of the operating system to make desktop applications. That is to say, when developing a desktop application under Windows, it looks like the style of traditional Windows desktop software. Under Mac is the style of Mac, and the first three have their own self-drawing engines.

That is to say, to make a button in the first three frames, no matter what drawing method is used, the performance is the same on the three platforms, but wxWidgets on the three platforms is based on the API of the three platforms. draw this button. wxWidgets provides a lot of operating system APIs, and can be statically linked, but there are many small problems.

5. Swing/JavaFX

Swing/JavaFX is based on the Java technology stack for desktop applications. Because it depends on the JVM, there are more system APIs, but the performance will be average. These two frameworks may be used relatively less.

If you choose among these desktop software frameworks, I personally recommend using Qt.

02 Emerging desktop software development framework

Some of the frameworks we mentioned just now may use outdated technologies, which are more troublesome for everyone to develop. Emerging frameworks, such as Microsoft's MAUI, Google's Flutter Desktop, and JetBrains' Compose Multiplatform, are made with very new technologies, which are easy to develop and have a very good development experience.

However, because these frameworks are relatively new, and they are basically the official version released this year (first released by Compose Multiplatform, then lutter Desktop and MAUI), the community is relatively less mature than the previous frameworks, and the information and There are also relatively few successful cases .

1. MAUI

MAUI uses XAML to write the interface and logic. If you have written software with WPF, you should be familiar with this technology. MAUI uses C# to write business logic and is only compatible with Windows and Mac operating systems. MAUI is a support system provided by the community under Linux, and there may be some problems. In addition, MAUI relies on the .NET framework, has many APIs, and supports the mobile terminal (the three frameworks support the mobile terminal, and the emerging development frameworks are compatible with the development of the mobile terminal).

2. Flutter Desktop

Flutter Desktop uses dart to write interface logic. It has rich components and supports the Win 10 operating system (the previous operating system does not support it very much). The API is relatively small, and developers need to write it themselves.

3. Compose Multiplatform

Compose Multiplatform relies on the JVM, and uses Kotlin to write the interface and logic of the logic. It is reported that Kotlin/native* may be launched in the future, so that the JVM can be eliminated, but this may be a distant thing. The components of Compose Multiplatform are also relatively rich. Everyone knows that there are many frameworks, modules, etc. in the Java community that can be used, and also support the application side.

Among these types of frameworks, I recommend that you use Flutter Desktop, although they are all emerging frameworks, so it is difficult to say which one will be more popular in the future, but according to their common points (more modern technology, easier to use, more information Few, immature community, fewer successful cases, fewer users, unstable), I still recommend Flutter Desktop.

03 Browser-based desktop software development framework

There are relatively many browser-based desktop software development frameworks, such as Electron, NW.js, CEF, Sciter, WebView2, webview and TAURI. Among them, Electron is used more and it is very mature. What they have in common is that they can reuse browser technologies, such as html, JS, and CSS, and a series of ecological components.

In addition, they can also make very beautiful interfaces, because the development of Web technology for so many years, CSS, html and other technologies in marking and controlling interface features are very mature, unlike the FLTK just mentioned to do superimposed animation The effect is very difficult, and if you use these technologies to make these interfaces, it will be very calm. But the functions of these frameworks are also strong and weak.

1. Electron/NW.js

The two frameworks Electron and NW.js are very similar technologies. They both integrate Chromium with Node.js, allowing developers to develop desktop applications using only front-end technologies. If you want to access the API of the system, use the API provided by Node.js. Of course, there are also some special APIs, such as creating desktop icons, accessing the clipboard, controlling the size of the window, etc., which are provided by the Electron framework itself, not by Node.js It is not provided by the traditional HTML system, and some additional operations are done in it. Of course, NW.js also has it.

The authors of these two frameworks have deep roots, so I won't go into details here. Personally, I think NW.js is relatively ingeniously implemented and friendly to developers, while Electron is better maintained and the community is huge.

2. CEF/WebView2

Both the CEF and WebView2 frameworks are directly based on Chromium. CEF has a long history and is more flexible. You can freely control it through this framework, and there are more APIs.

WebView2 is a framework provided by Microsoft's short-term team. This framework is also directly based on Chromium-based encapsulation. It provides APIs of .NET and C++. You can use .NET, C++ or C# to operate this framework. Support for MAC (maybe in the future).

Relatively speaking, CEF is more like the author's personal maintenance, and WebView2 is more like a team, but because WebView2 is not open source, it cannot participate.

3. webview/TAURI

webview and TAURI use the browser core configured in the operating system. For example, if it should be deployed under Windows, then use WebView2; if it is deployed under Mac, use WKWebView; if it is deployed under Linux, use webkitgtk for rendering, so here There may be some compatibility issues.

When working on the front end, we often encounter some compatibility problems, but at present, because they are all relatively modern browser cores, this problem is not so obvious. In addition, TAURI is developed in Rust, and if you want to choose this framework, you may have to be familiar with the Rust language.

4. Sciter

Sciter is a relatively special framework, which is listed here. Sciter has made a lot of cuts, which can reduce the size of the product to less than 10M. The previous frameworks basically only need to distribute the browser core to users, even after compression. Got 60M.

Sciter used to have its own script called TIscript, and now it uses QuickJS, which is very powerful and integrates the core version of skia. I don't know if you have paid attention to a project called rustdesk. Before, it chose the Sciter framework. Of course, there are many small problems with this framework.

If you choose this type of framework, I recommend the Electron/CEF framework. Choose Electron if you don't have C++ developers on your team, or it's not easy to develop applications using C++; choose CEF if you have C++ developers and your application is performance-conscious.

04 Instant rendering desktop software development framework

The relative application of instant rendering is the desktop application framework that maintains the mode. Generally, the desktop application is updated wherever it needs to be updated, and the framework will render. But real-time rendering is different. It updates the displayed content every time a frame is refreshed, which means that every frame will be updated all over again.

Therefore , these types of frameworks have a common feature, that is, they consume CPU and GPU resources . The configuration of traditional frameworks is in retention mode, and rendering will not be done if they are not updated. In addition, this framework can be seamlessly connected to game applications, but there are few traditional application cases, many small problems, and are still in development.

1. Dear ImGui

In the instant rendering desktop software development framework, Dear ImGui is more popular. Recently, the author is developing the Dock mode. It is estimated that it may be launched this year. When that time comes, you can try it.

Its development method is quite special, that is, every cycle is doing rendering. For example, when using Dear ImGui for event development, a variable will be set to true or false. In this round of rendering, it is true. In the next round of rendering, I find that it becomes false, so we think An event was triggered. Rather than in the web development world, when an event occurs, another component can receive it.

2. Nuklear

Nuklear is developed in C language, which is closer to the habits of C developers, with fewer users and more minor problems than Dear ImGui.

3. RmIui

RmlUi is special. It is not a real-time rendering framework, but it has a common problem with real-time rendering frameworks. After developing applications with it, it will continue to consume CPU and GPU resources. It can use HTML and CSS to describe the interface. It is relatively difficult to get started, and the development is very flexible. , the interface is also very flexible, and the resource consumption is relatively more.

I've been using this framework recently and have had in-depth discussions with the author. The application developed by this framework can do about 2M, it can parse your HTML, do some very special effects, such as animations such as shadows, gradients, etc., but it is very small, not like a browser, even if compressed Get more than 60 megabytes, which is also its advantage.

Among these types of frameworks, I personally recommend RmlUi. If you ask questions in the author's project, he will basically reply the next day.

05 Summary

Before making a conclusion, let me briefly describe the comparison of these frameworks.

In fact, when we introduced the traditional desktop development framework, the built-in components of Qt and wxWidgets are also browser-based, namely QWebEngin and wxWebView. QWebEngin encapsulates the core of Chromium, which is actually quite similar to CEF and QWebEngin, but many people When using Qt, CEF is integrated into Qt instead of QWebEngin.

The view they insist is that QWebEngin is immature, its performance is relatively weak, and it is not as good as CEF, but at present, I personally think that after Qt 6.2 and Qt 6.3, QWebEngin will have more APIs, and the needs of applications will be easier to meet .

wxWebView is more like webview and TAURI, and it is also the browser core of the operating system that uses the operating system on different operating systems, so I won't talk about it here.

Take another look at the comparison of RmlUi and Sciter. RmlUi can use html and CSS, Sciter can also use html and CSS, because Sciter integrates QuickJS, so it can also write JS code (but it also has to write C++, because you can't use the API of the operating system, but its C++ may will be much less C++ code than RmlUi). Neither framework supports the full html and CSS specifications.

If you want to choose a desktop software development framework, you should confirm which capabilities to focus on. I think there are three capabilities that need to be paid attention to:

• Interface description capabilities : such as layout, element positioning, rounded corners, shadows, gradients
• Event processing capabilities : such as mouse events, keyboard events, touch screen events, media playback end, network status changes, etc.
• Asynchronous processing capability : When processing business logic, interface rendering cannot be suspended

In addition, desktop software development frameworks have their own advantages. For example, software development logic is very complex and needs to be completed quickly, then BrowserCore may be a good way, because it is faster to write with front-end technology, but if the software requires less resource consumption and faster running speed, then you need to consider the Native method.

Finally, to do desktop application development, you need to understand some underlying knowledge, such as multi-threading and multi-process control; various communication protocols; log collection; version control; design patterns and architectural principles; local data control; operating system.

06 Q&A session

1. How to deal with crash with Electron?

Electron also has many problems, it also crashes, and there is a way to collect crash reports. After collecting these reports, we need to analyze them. However, the analyzed crash reports cannot clearly reflect which line of code and which segment of business it is. Something went wrong. In many cases, the crash report may indicate that there is a problem with the memory pointed to by a pointer. In this case, one method is to contact the user to reproduce the problem as much as possible; the second method is to do a large number of automated tests to narrow the scope of the problem. Limit it to a certain range and then refine it; the third way is to do AB testing.

2. Is there a good solution to the problem that the application installation package developed by Electron is too large? Also, how should developers develop daemons for Electron applications.

Here are two questions. The first problem is that the package is too large. This is actually quite difficult to solve. Before setting up the project, you should communicate the requirements with the team leader. Is it for rapid business development, or higher performance and smaller size? If you want a smaller size, then give up business development efficiency. Some work can be done in C++, it just takes longer and takes more resources. When packaging, you must first confirm whether the LZMA compression format is used. This format can be compressed a little bit smaller, but it is not much smaller, and the minimum may be more than 60 megabytes.

As for how to make a daemon process, there are two ways to solve this problem. One is to write an independent application, and the application can be started when Electron starts, and then it guards the Electron process. If the Electron process crashes, it will start the Electron process.

Another method is to analyze why the application crashes, whether the main process crashes, or when rendering crashes. If the main process crashes, try to find the reason for the crash, because once the main process crashes, all rendering will fail. ; If the rendering process crashes, you can open another process in the main process to ensure that the rendering crash notification is sent to the user, and the user restarts the rendering process, or restarts automatically.