Before you pack your webapp in Electron

Sep 7, 2020

Electron has changed the way we create desktop applications. It become very popular among start-ups and enterprises because the “easiness” of “packaging” a webapp into an “application”. But the fancy dock icon for your webapp doesn’t come free of challenges, And before you go for this solution you better know a few issues you might encounter, from my experience of 2 years building a shared codebase between a webapp and an Electron app (including native extensions).

Do you really need it? (In my case I needed). Electron is really great if you don’t need to share its code with another application (or webapp), and especially if your application uses one main window with some Electron magic of missing browser APIs.

Security in Electron

In Electron XSS means there is a chance attackers can do pretty much what ever they want in the client computer. There is a famous Slack security bug, but the bug they had, relevant to every Electron application. Which means you need to be extra careful every time you allow Electron API to run in ”browser” context.

Multi window applications might be painful

Electron and JavaScript don’t give an easy way to communicate between threads/processes and when you need to share logic between multi-windows or even communicating with tray icon or file menu you’ll find your self with lots of wiring using IPC. And if you ask? Yes, you can make synchronous calls, but you can easily halt your application or crash it. So if you don’t must, async it is, and with all the issues it comes with.

Making Electron app is not just “Run my webapp in Electron”. Even if you go on minimal approach of only bundling for Electron you find Apple will make your life hard even out of Mac App Store. And don’t get me wrong, Microsoft bring their own issues. Moreover, usually everything related of using Electron capabilities will need to wire at least a “preload” script (a script that run in the browser before the actual application to allow access to Electron API in provision way). Because usually as in “desktop applications” you’ll want to have more than just a “browser window” you’ll find yourself wiring at least 2 process, which aren’t easy to maintain in JS app. All the modifications will bring your codebase more ifs from time to time and 2 sets of implementations for mostly the same services. And from Electron side, these services will need a “main process” (or a “Node process”) glue too. By the way, I found many projects that build using webpack and even let you some control over webpack configuration, can’t say even one of them could handle multi bundling for Electron and multi webapps in a shared codebase as I needed without more extra work than writing it by myself. I can’t tell if these projects could fit your ecosystem or not. I personally would avoid them.

Testing

Testing in Electron is a nightmare, you can pretty much choose between fully integration tests and mock too many parts of Electron API for “unit” tests.

Bugs bugs bugs 🐞

Don’t get me wrong, Electron maintainers are awesome! Really, they do fix bugs as fast as they can. And Electron repo is one of the most responsive repos I know! And still, usually Electron has some nasty bugs, And I won’t blame anyone because all these projects are super hard to maintain. But, you should be ready to surprises. Like the time cancel printing would make application non-responsive or async native function would crash the application. But you might say: “Native APIs of Windows and macOS also have nasty bugs” and you right, but my point of view if the effort of packaging webapp to Electron application is worth it. And because some bundlers bug, Where I work we use 2 bundlers for 2 versions and in another version we use one of the bundlers but manually sign the application.

Code signing

Technically it’s not an Electron issue, but from my experience. Building and code-signing in a native application IDE, for example in XCode, is almost transparent process, which sadly isn’t the story with Electron application. First you have the hell of Apple certification process and endless meaning less errors because the application won’t start, And after endless searches you can barely guess why. Was it wrong configuration? Was it wrong certificate? Maybe a bug in the bundler? Have you succeeded? Congratulation, now you got even bigger hell of Windows certification process.

Conclusion

Don’t get me wrong. Electron would probably be your best match, but you can’t think about Electron as a magic to convert webapp to Electron application. Resources will need to be sacrifice, and you better know what you getting into.