43

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.

Edit 1. Please provide arguments for downvoting/ flagging the question for closing. Perhaps, if you offer some constructive feedback the question can be improved.

Mihai
  • 2,807
  • 4
  • 28
  • 53
  • 8
    WPF is extremely good at rendering. So it boils down to app you're building. As far as I understood it is a thin client, thus I would suggest going Electron given your context and technologies you're familiar with. And this is coming from WPF Dev :) – Karolis Kajenas Jun 25 '17 at 07:24
  • 5
    If this question doesn't fall into "Too Broad" I don't know what does... there are several major comparison points just for the "efficiency" question and the second question is opinion based. – Meirion Hughes Jun 25 '17 at 08:55
  • 1
    That is certainly not an easy question. As a very good example of a well-made electron app you can consider vs code. AFAIK visual studio has a WPF frontend, but it is a huge piece of software, makes it hard to extrapolate the "goodness" in it. – flq Jun 25 '17 at 08:56
  • To me this application has little GUI and big logic. Don't start thinking/designing your application from GUI...it really looks like a small thing. Do you really need C++ for analysis or it's because of node.js? Does C# fit? Also remember that analysis and user interface might be unrelated and separated. You may think we have everything we need to give a good advice but reality is that these decisions involve hundreds factors. – Adriano Repetti Jun 25 '17 at 09:09
  • @AdrianoRepetti Thanks for your mention and question. I thought of `C++` because of the heavy nature of the computations. `C#` would also work well I guess. – Mihai Jun 25 '17 at 09:12
  • 1
    Agree, C++ is an option but language choice is driven by many factors. Your C++ knowledge, development efficiency and deployment. Using Electron you MAY need to write logic in another language. Using WPF you may use just one language (and you may be more proficient in C#) with also the benefits of an easy deployment (BTW automatic updates aren't something you need to do by hand). – Adriano Repetti Jun 25 '17 at 09:19
  • Note that if you never used WPF then I really suggest you pick something you know. MVVM approach isn't easy to start with (I honestly saw too many _failed_ projects because they underestimated this aspect) – Adriano Repetti Jun 25 '17 at 09:21
  • To me the application is something like a tool or utility. In the end it generates a .pfd where all the charts and tables are. If you would wanted those in your app it would make more sense to think about the better tool to build it but to me it seems like the people using your app are not so much interested in the UI as well in the fastest result possible to process the data. They are probably used to excel like interfaces so they care more about the resulting pdf than the look of the app that only seems to need some basic input and perhaps a progress indicator. – Peter Bons Jun 25 '17 at 09:41
  • 3
    Shameless plug, but still, [the big mvvm template](https://www.codeproject.com/Articles/768427/The-big-MVVM-Template), it'll give you start jump with MVVM if you're new to it – Noctis Jun 25 '17 at 09:42
  • 7
    Furthermore. Your title says you want a performance comparison yet you are mention a lot of other things that don't involve performance like auto updates and deployment size. To me it seems like, given the case, the users won't see much of a performance problem anyway as it is not a realtime chart rendering app or something alike you are building. I would focus on the best tool to process the data in the fastest way possible and I would prefer c# over js for that. – Peter Bons Jun 25 '17 at 09:47
  • @PeterBons I agree with you comments. In the end the focus is on the results of the analysis, not real-time feedback. I think that the analysis will perform well as well as it is compiled (either C# or C++). The other aspects I mentioned were mentioned because I tried to provide a summary on how others dealt with this decision before. My intuition is that as long as the analysis is compiled, the way the `GUI` is built won't make that much of a difference in terms of rendering performance (i.e., user-experienced lag). Also, the requirement is that the `GUI` should be *modern* and interactive. – Mihai Jun 25 '17 at 09:55
  • 1
    *modern* ? pick a tool, wait half a year, you've chosen the wrong one. Stick with well built, and does the job. (I'm not suggesting Assembler BTW, i'm just saying that modern seems to be changing every couple of months these days) – Noctis Jun 25 '17 at 10:02
  • @Noctis This is exactly is my concern. When I've been told *modern*, to me, the definition provided sounded like the type of `js` interactivity you find on the web. Do you think `XMAL` can provide the same look and feel you experience on `JS`-based websites? – Mihai Jun 25 '17 at 10:06
  • 1
    sadly haven't played with WPF for over a year now. As i've said, a bit of a steep learning curve, but once you're over it's quite powerful and you can do lots of things. it's been around for a looooong time, but i would have a look online to see if you can find MS roadmap for it, to make sure it's not at the end of the road (like silverlight? adobe flash? etc etc). – Noctis Jun 25 '17 at 21:40

0 Answers0