Why Electron is the best development platform?
- The arrow functions with correct semantics of
- Destructuring is a huge bonus. ES6 has gone further in incorporating destructuring in number of places - declarations, assignment, function arguments. I remember discovering some of these things without knowing that they are actually supported by the new syntax. When I tried and saw them working, it felt like magic. That’s the definition of intuitive syntax.
- Finally there’s support for
classin the language syntax with ES6
- ES6 modules make your code organization easy. You have to use WebPack-Babel though, if you want to use them.
When you use Electron you can use ES6 for development without worrying about browser support, because you ship your browser+node environment with your app itself. (Pro tip: Use
babili to minify your ES6 without compiling).
C++ 11 also has friendlier syntax with lambda functions,
The biggest downside of using Python for desktop apps is GUI framework. The most mature option is PyQt. It’s mature because it has been around for a while, but that also makes it rigid. You have to learn traditional View framework of GUI widgets. It’s a far cry from the fluidity of HTML DOM. Although the DOM wasn’t designed for desktop apps, it has evolved and now offers the best of both worlds. If you don’t want to reinvent the wheel then you can use built-in widgets, or various jQuery UI plugins for more customizable ones. But if you want to try something new, say a different layout or animated panels you can totally do it. That’s very hard to do in frameworks like PyQt (that’s why Qt has also adopted some form of DOM in its framework, but then that defeats the point of using Python). Moreover, PyQt is developed by a relatively obscure company with some not-so-clear licensing options for commercial usage.
Debugging GUI written over DOM is also tremendously easy, thanks to Chrome DevTools that is incidentally part of Electron. (more on that later)
Technically, it’s the node.js environment that provides the add-on functionality. I’ve written many add-ons or plugins for Python and Node.js environment in past few years. I’ll say it’s not without pain in both cases. However it has gotten a lot better with node.js in past few years. I doubt there are any recent improvements in writing Python native modules (although Cython and cffi give good alternatives), but back when I used to write them I remember switching between Swig or hand-written C structures with function pointers. It wasn’t fun.
Node.js addon development on the other hand is well documented. You basically have to deal with v8 data structures, which have one-stop documentation. They are a bit awkward many times, where you have to write code whose purpose is not exactly clear. However you start identifying boilerplate patterns in the code and can easily macro-fy them. In fact the nodejs developers made this official with the Nan library, which is a must if you are writing node addons today. Electron embraces all this by design, because nodejs is part of it.
There is still some room for improvement in node.js addon development. One of them being node-gyp. It’s a non-standard build system, with awkward declarative syntax. They really should use CMake. (I know there’s a solution, but cmake should be the native build mechanism for node addons)
I started my career while debugging operating systems. So print statements have been the best way of debugging for me. Although I’ve tried all kinds of debuggers (Eclipse Java, Visual Studio, GDB, PDB, Vim with debugger plugins), they could never beat the simplicity and pervasive applicability of print statements when it came to debugging. However my experience with Chrome DevTools for the past 6 years, makes me name it the best Debugger I’ve ever used. Again, it’s part of the package when you use Electron.
In addition you have a REPL in the form of Console which is indispensable. You can inspect the network activity (although it’s not so frequently used in desktop app development, but that depends on use case), do performance analysis. There’s also an Electron extension to Chrome Devtools - Devtron - but I don’t have much experience with it.
NPM eco system
Node.js has a vast community of developers who have written libraries for all sorts of things and published them on NPM. Between npm cli tool, package.json choices and ability to install packages from file system or github repo URLs; Electron offers the most accessible dependency fulfillment eco system (via npm). Most of the functionality your application needs is probably implemented by someone and is available as NPM package.
Cross platform integration
Node.js and Chrome being already available on the big three desktop platforms, makes Electron the most appealing write-once-run-anywhere solution. However that’s just the beginning.
The Electron developers have taken the cross-platform notion beyond just the runnability of code. They have incorporated support for all the native aspects of the desktop environments on all platforms. Wherever possible they have created common abstractions that automatically adapt to the right environment, for example application menus or desktop notifications. But Electron also supports the features that only available on Windows or OSX or Ubuntu Unity. And they have all these methods well documented complete with example code. I was once quite surprised to find how easy it’s with Electron to create a headless application that only shows an icon in the tray.
I’ve never before created package installers in my life (maybe I’ve, but that was back in last millenium I think, so that’s too old to count). So that was one thing I was dreading when I decided to develop Zector tools as desktop applications instead of Web apps. But I needn’t have worried. Electron has very good packaging solution that creates platform specific installers for you. I use electron-builder, although there are other solutions too. Electron-builder is well documented and I use it to build NullSoft installer on Windows and DMG installer on Mac for Zector Trace. It also supports platform specific code signing mechanisms (although I haven’t tried them yet). There are some rough edges yet, but I think they will even out with time.