Choosing Electron for Desktop Software Development

March 3, 2016 ยท 4 minute read

Back when I started my job, I was given the task of building our desktop software, with the only requirement (aside from the actual functionality) was that it had to be cross-platform.

Windows, OS X, Linux.

While it had been a few years since I had written anything that didn’t exist on just the web or for a single platform, I am glad that solutions exist today that provide a very solid path for creating cross-platform desktop software.

We were looking at Qt, but I happened to hear about Electron, which piqued my curiosity.

Electron - Cross Platform Desktop Apps

If you’re unfamiliar, Electron is a way to wrap JavaScript, HTML, and CSS into a desktop executable, with Node integration to provide access to the low level system. There are also packages on npm that make the process of building distributables much easier.

After some poking around and testing, I had settled on Electron because of the following:

  • Speed of development. I’m building in JavaScript and essentially building a web app (with some differences, of course) without having to worry about cross-compilation. (More on cross-compilation later.)
  • Lots of existing libraries. Tapping into the world of Node.js gives us access to all of the fantastic libraries and packages that people have already written for Node, decreasing development time and really making our software capable in a much shorter amount of time.
  • We can offer a web app, too. If we decided to move towards an online version of our software, we could easily do that by transforming our work in Electron, which is based on Node anyway, into a standalone Node app.

And the development process has been great! We have software that can visualize multi-tool 3D prints, using Three.js, we use node streams to read large text (.gcode) files, process the data that we parsed from those text files, and then using node streams again for writing to a new file.

For a bit of background on our app: our product, The Palette, is a way for people to create multi-colour 3D prints without modifying your existing 3D printer. We combine up to four different filaments into a single one that can be fed into your printer. Our software basically takes .gcode files meant for multiple extruders and does some processing in order to turn it into a single-extruder print and also the file that our product needs to create the single filament with multiple colours.

With that out of the way, we are about four months into developing our software with Electron, and of course, it has had its fair share of development issues:

  • Native modules need to be built on their respective platforms. I chose to use node-serialport to be able to communicate with our product, and our automated build process (for distributables) has essentially been eradicated as a result. Nothing that I have done (so far) has made it possible to compile native modules for other platforms. I’m currently working on solutions, but they certainly aren’t pretty!
  • Releases are huge. No, really. Back when we started the app, and it could only really parse and process large text files, a distributable would clock in at around ~140MB. That’s huge, and can probably be attributed to the fact that Electron wraps around a Chrome window, but I will admit that our packaging process can be optimized for the better.
  • Visualizing 3D models is rough on slower computers. Not only is it a client-side JavaScript library doing the visualization (with WebGL), which can be a relatively memory intensive process, but Chrome itself is pretty demanding on memory. This leads to a lot of chugging on slower computers. Sorry to everyone that still runs on Pentium 3s.

These shortcomings aside, I’m pretty darn happy with our choice in Electron. Its flexibility and capabilities (especially with other Node packages) has been invaluable in our pursuit of changing the landscape of 3D printing.

I can’t wait to release it into the wild!