An Introduction to Electron
The web environment has seen many advancements within the last few years. We've seen advancements in rendering (react), significant improvements in serving assets quickly (service worker), and near native performance (WebAssembly). The web has seen improvements at such a rapid pace and Electron is what is brining these improvements to cross-platform desktop apps. It was only two years ago that electron had really started catching on. Electron is a derivative of the chromium project that embeds the node.js runtime.
Out of the box, Electron doesn't do much other than provide the API's. And because Electron is solely a library, does not have the responsibility of setting up infrastructure around electron apps. Infrastructure decisions are let to the developer. But it is rarely the case that new developers to electron know the ins and outs of Electron specific infrastructure.
Enter electron-react-boilerplate (ERB). ERB provides solutions for the following infrastructure around Electron apps:
- Auto Updates: Allowing developers to publish updates to their apps
- Asset Optimization: Optimizing JS, CSS, images, and other assets
- DevTools Integration: Support for React, Redux, and Devtron DevTools
- Packaging: Out of the box support for packaging apps to Windows, Mac, and Linux
- Compilation: Out of the box support for Babel and Webpack
- Code Analysis: ESLint and Flow integration out of the box (TypeScript support planned)
- Hot Module Replacement: Saved changes to app are reflected instantaneously without refreshing the app
- State Management and Routing: Comes with Redux and react-router support out of the box
There is a balancing act when it comes to creating a boilerplate: adding too many features and configurations would intimidate newcomers and too little would not fulfill the demands of more mature developers with requirements.
We think ERB will add value to developers who are new to the Electron ecosystem and are trying to quickly scaffold Electron apps without worrying about the infrastructure. The base of the app is kept simple in order to ease the entry of newcomers.
Mature Electron Devs
While the base is kept simple, we also wanted to make sure that it could be extended as well. For example, all of our WebPack configs are exposed to the user of the boilerplate and therefore can be easily extended. If mature devs want a slight permutation of the infrastructure, we offer examples of configuring ERB for the configuration they want. For example, if a user preferred TypeScript over Flow, they can refer to examples of ERB that are configured with TypeScript instead of the default, which is Flow.
Future of electron-react-boilerplate
Since the creation of ERB, a number of new projects in the JS and Electron ecosystems have emerged and influenced the direction of ERB.
Flow was the initial choice for ERB a couple of years ago. Much has changed since then: TypeScript has thrived in the ecosystem and has proven itself to be a significant competitor to Flow. It previously presented compatibility issues with our with our existing infrastructure. Babel, ESLint, and React integration with TypeScript presented a number of issues and Flow could be implemented with much less friction to existing JS infrastructure. But with TypeScript embracing compatibility with existing JS infra, we are considering migrating to TypeScript from.
The explosion of new React apps created with create-react-app (CRA) was hard for anyone in the JS ecosystem to ignore. CRA was a breakthrough in infrastructure because it removed the tight coupling between infrastructure of React apps and the source code of the apps themselves. The infrastructure of CRA apps are encapsulated in a single package:
react-scripts. I believe ERB should go down this direction as well and embrace the separation from infrastructure and apps. Here's what I imagine creating apps with ERB will look like in the future:
# With npm $ npx create-erb-app my-app # With yarn $ yarn create erb-app my-app cd my-app # Some examples of commands that can be run yarn start yarn package yarn build yarn publish yarn lint
All the infrastructure would be configured with a few simple scripts which would be our equivalent of
Many electron apps rely on native dependencies, which are dependencies which interoperate with C and C++ code. These modules interoperate with C and C++ for performance increases and for simply having a way to bind to those languages. But native compilation requires recompiling those modules on a machine each time they are installed. More complications are introduced when the user does not have the dependencies to build these modules installed on their machine. These issues can be solved by compiling native modules to WebAssembly. Library authors can compile the C/C++ on their machines and distribute the compiled WebAssembly. Adding WebAssembly support to ERB can dramatically simplify the process of using native dependencies with Electron.