Optional hybrid approach: supporting both the desktop and the browser
On the other end of the spectrum, you can still follow a hybrid approach. I wrote my chess demo as an Angular2 web application, but it took very little effort to add the option to publish it as an Electron application. To do so, I used an Electron-and-Angular2 seed project supporting Electron well enough. However, it doesn’t support developing the application as well as developing a web application. More to the point, hot reloading (or in Java terms: hot code replacement) isn’t supported in the Electron version. So the preferred way to develop your application is using
ng serve and testing and debugging the application in the browser. After finishing a task, you package the whole thing as an Electron application and test it again.
At this point, I should add that it’s possible to support Electron developers considerably better. I just happened to choose an Electron seed project that doesn’t support interactive developing. There are several projects out there adding hot reloading to Electron projects. I didn’t try them yet, but only because I was happy with the hybrid approach.
Benefits of going native
What in store for you? Why should you wrap your HTML5 application into an Electron application?
As it turns out, there are many benefits:
- First of all, you can publish and sell your application in the app stores of Google, Apple, and Microsoft. That alone sounds like a killer feature to me.
- Of course, this also means that you have to worry about software updates. Electron offers support for that, too.
- Your user’s aren’t molested by all those features of your browser. Browsers are optimized for a pleasant user experience while browsing the internet. That’s not the same use case as doing your daily chore at work. Just to name a few pain points: the back button, or the browser history in general, access to HTML5 source code, and hijacking common keyboard shortcuts such as F1, CTRL+S, and CTRL+N. In my eyes, F1 is the natural choice to open your application’s help. Instead, browsers open their own help. Electron does not. Neither does it offer you to store the HTML source code when you hit CTRL+S. So you can save your application’s state when the user hits CTRL+S in Electron.
- As a bonus, your applications run a bit faster because they don’t have to support the browser’s features and because they run in a separate thread.
- Last not least, you know the exact target platform of your application. Countless web programmers had to deal with browser sniffing. Electron programmers know they are targeting Chromium, which usually is pretty fast to support new HTML5 or ECMAScript features.
What is Electron?
Now that you know what you can use Electron for, I should tell you what Electron is. Basically, it’s just a browser in disguise. Electron is an application framework based on Chromium. More precisely, Electron uses only a part of the Chromium runtime, which – according to the project team – makes it easier to update Electron to new version of Chromium.
Getting your feet wet
I tried to different starter projects to get familiar with Electron. The first one of them is referenced from the Electron project page. It’s a very simple starter project showing you how simple it is to write desktop applications with Electron. The project only consists of a “hello world” message” and opens Chrome’s debugger in the application window. Basically, the project only consists of an
main.js and a
package.json. There are no surprises here, so I won’t print any source code.
The second project is a bit more demanding in that it’s an Electron starter kit for both TypeScript (i.e. a different programming language) and Angular2. I’m talking about the Angular2 electron starter project. Porting my chess demo basically was a matter of copying the source code to the
/src/app folder and correcting the license files. Again, no surprises here, so I won’t print any source codes here. Suffice it to point you to my GitHub repository.
The principal difference to a traditional Angular2 project is the subfolder
electron, which contains platform-specific code. Among other things, this is the place where you deactivate the debugger window which is shown by default when the application starts.
The other difference is the Node.js script
npm run electron, which starts the application in an electron window, and
npm run package, which creates native binary for your target platform. Using Windows, that’s an *.exe file. On a Mac, that’s an *.app file you can copy to the program folder or upload to Apple’s Appstore.
There’s at least one alternative to Electron. NW.js seems to be a similar project which has been around a bit longer than Electron. I didn’t try it yet, so suffice it to point you to this comparison between Electron, NW.js, which also mentions a third contender, Tint2.
Wrapping it up
One thing making Electron particularly interesting is the option to follow a hybrid approach. If you’re careful, you can exploit the full range of features of a desktop application without sacrificing the ability to run in the browser.