Performance-wise: Is a WPF application better than an Electron one coded wisely?

Mihai picture Mihai · Jun 25, 2017 · Viewed 12.5k times · Source

Recently, I have been reading about Electron and I got curious about its potential when compared to something already established in the market of building Windows 7 desktop applications (i.e., WPF).

So far, I noticed that those who lean towards Electron discuss the fact that it provides:

  • fast-development cycles: one familiar with HTML5, CSS3, JS, and some Node.js, is all set to jump right into building a desktop application.
  • cross-platform compatibility: being based on Chromium and Node.js, both cross-platform, the application can run anywhere where these two are supported.
  • beautiful and interactive GUI design: the combination of HTML5, CSS3 and JS has proven what is capable of achieving over the years.
  • straightforward and cost-effective web recycling: a web application can be relatively easy converted to a desktop application by the same developers who created it in the first place (i.e., saving costs).

When it comes to WPF, its supporters discuss the following favoring arguments:

  • access to native APIs: WPF fits well into the .NET framework giving the developer access to all native Windows functionality.
  • powerful XAML markup language: it is argued that the XAML allows efficient rendering of sophisticated UI elements, supports two-way data binding, and knowing it may be useful in other contexts (i.e., with appropriate adjustments, e.g., Android development).
  • high-performance and memory-efficiency: mainly due to the compiled nature of the language and, perhaps, other JIT idiosyncrasies.

If we take these arguments separately, we can agree that both technologies are respectable. However, when you ask developers for help choosing the right framework for your the project, things get a bit biased. I assume that the bias may be either because the questions are too unspecific, or because some are more familiar with one framework than the other and, thus, the comfort zone kicks in.

Hence, keeping in mind that both are just means to an end, and not life philosophies, when compared, it usually boils down to the following ideas. Please note that these are not my ideas, but what I collected from various discussion groups around the web.

  • DOM manipulation is an expensive operation, whereas XAML rendering is blazingly fast.
  • Electron gives you access to just a few native OS functionality through its APIs, whereas WPF gives you access to all since it lives on the .NET.
  • Electron is slower compared to WPF because JS is interpreted, whereas, say C#, is compiled.
  • WPF works well with the MVVM pattern, whereas something similar is harder to achieve in Electron.
  • Electron is fast to get started with, whereas WPF has a steep learning curve (but it looks more professional they say).
  • Electron is cross-platform, whereas WPF is tied to the .NET. Not sure whether the Xamarin/ .NET Core was taken into account.
  • Electron application size is large as it has to ship with Chromium and Node.js to accomplish its goals.
  • WPF is less actively improved compared to Electron (i.e., Electron is an open-source project).
  • Electron handles the application updates for you, whereas the same thing requires more work in WPF.

On one side, it seems that software engineers (i.e., especially those who work in the corporate world) tend to favor WPF. On the other side, web developers are excited about what Electron brings to the table. In my opinion, this is bias, and the fact that you work more with a technology than the other does not say anything about how suitable the technology is in itself.

Therefore, to avoid this bias and, perhaps, other nagging answers, I want to provide you with the following case study.

Let us say one is interested in building a Windows 7 desktop application with Electron. The goal of the application is to allow the users to configure and run an extremely computational-intensive statistical analysis on a large XLSX file (i.e., 1e5 rows). In short, the user fills in a form, a special syntax file is generated (i.e., json, xml, or txt), the application reads that file and performs the analysis with the parameters specified there. At the end, a pdf file with graphs and tables is provided to the user. Now, let us assume the following about this project:

  • the DOM is not directly manipulated. Rather, Vue.js or React are used because they implement a virtual DOM which is faster.
  • the application does not need access to all the native OS functionality. The application only requires to read/ write files to disk and, perhaps, send some notifications.
  • because JS is too slow to run the statistical analysis, a C++-based Node.js addon is written and called from JS. Behind the scenes, the C++ code constructs the objects and makes the computations. At the end, the resulting matrices and vectors are be exposed to the JS.
  • the developer cares to structure the application properly and separates the concerns as much as possible. To avoid unnecessary renderings, Vue.js or React components may be used.
  • the developer does not consider problematic the additional ~50MB in size added to the package by the Chromium and Node.js.
  • the application is hosted on a central repository and the updates are pushed to the end users.

Keeping these assumptions in mind, my questions to you are:

  1. To what extent is a WPF application more efficient than an Electron application, given that the heavy computations are implemented in C++ or C# and packaged as a .dll? If it is, what causes these differences?
  2. Is XAML more efficient for rendering interactive UI elements compared to Vue.js or React in combination with HTML5 and CSS3?

Disclaimer: I am bias towards Electron because I think it enables me to build the GUI faster than XAML. I may be wrong because I am not entirely familiar with what XAML has to offer.


Note: Please do not mark this question as inappropriate. It is specific enough and well documented, and it might help others facing the same decision.

Answer