Initially released in October 2018, the Electron-React-TypeScript-Webpack (ERTW) Boilerplate is the most popular open source project I've created sonly by myself so far, also is one of the most used boilerplates in the early dates among the Electron community.
Different to most other boilerplates and create-react-app-like packages, the ERTW boilerplate gives you a ready-to-use Electron project template with React, Webpack and TypeScript seamlessly integrated, plus clean, easy to read and alter config files. Package, config file nor option, none of them is hidden under another package dependency or complex logic in the scripts, so you know exactly how your project is configured and what packages your project depends on.
Is the project still alive?
It may sound odd that I put this section up here before all others, but I think it's pretty much the question you'd have if you've seen, used, or you're one of those who star this boilerplate before. The short answer is yes, it's still alive, I'm still maintaining it, so you can stop worrying and keep reading.
The long answer is, throughout the past 4-ish years, I've seen daily visits, unique clones of this project from GitHub's insight, and projects being built on top of it. xiaoiver/a-simple-gltf-viewer is one of those, haven't dived into the code there but looks like a cool little app. Seeing my work getting used makes me feel good, so I want to keep it alive to help more of my fellow developers out there. Unfortunately, over the past few years, my day job has occupied a large amount of my time, which means there wasn't that much time I could spare on maintaining the project, thus you see the version updates were pretty much released randomly.
Recent traffic data. Feel nice seeing people using my work.
Fast forward to mid-2022, as you'd expect in TypeScript/JavaScript, the underlying packages this boilerplate depends on have changed quite a lot (Spectron got deprecated, React introduced a new API for the root component, etc). Therefore, to reduce the breaking changes I have to make in each release and keep the boilerplate as useful as it can be for the users, plus now that I have more control of my time, I've decided to maintain the project much more regularly.
Starting from v4.0.0, there'll be monthly updates for this project, keeping the package dependencies up-to-date, and more features will get integrated into the future versions. I'm not going to dive into the details here, if you're interested to know more, I've written everything in the README file.
So, why another boilerplate?
When I first started developing Electron apps with React in mid-2018, the TypeScript support isn't as good as nowadays, a lot of guides/tutorials/Stack Overflow answers I've found online tell people to use Webpack, and Babel with a list of plugins to transpile and bundle your code, which I always question why Babel in a TypeScript project?
My argument for Babel in TypeScript projects is that, with TypeScript, we've got tsc built-in. The tsconfig file alone takes care of the compile options, plus the TypeScript engine which VS Code and some other IDEs rely on tsconfig for TypeScript files. If we use Babel instead, there'll be one more config file to manage, which I consider very unnecessary, so why Babel? I simply don't agree with those who suggest using Babel in TypeScript projects.
Other than the Babel or not argument, Webpack alone takes time to configure too. There's a list of plugins you have to configure in Webpack just to make things work, especially before Webpack 5, for example, css-loader & style-loader were a must-have. If you want to fast-track to start working on the actual development part, you can opt to use one of the boilerplates available on GitHub, but that brings another question -- bugs!
I've tried a few React boilerplates at the beginning, with and without Electron, and I ended up using none of them. It was because those boilerplates either lack documentation or more importantly - buggy. In fact, one of my fellow developers who used my boilerplate commented about the bugs in many other boilerplates.
jkhaui mentioned bugs in many other boilerplates in an issue about documentation
After having encountered those issues, I just configured my Electron project manually. It took me quite some time to get everything configured correctly, so I was thinking now that I've done all the hard work and got things working together well, then someone could just start straightaway if I share my work with them. Hence, I took the project structure and configurations I used at work to release this boilerplate on GitHub.
How about Electron Forge?
Of course, we have to talk about Electron Forge. After all, it's kind of the "recommended" CLI tool for Electron projects these days. I've tried it in the past, didn't like it, and still don't like it.
Why? You may ask. The thing that bothers me the most with both Electron Forge and Create React App (CRA) is these CLI tools hide most of the package dependencies and config files under their own packages, and even worse is the way to configure the underlying packages (e.g. Webpack) is via their own interface!
Let's take a look at the pacakge.json generated using Electron Forge, with the "typescript-webpack" option, so you get a better idea of what I'm on about.
Starting from the "scripts" section, we can see there is every script other than "lint" uses "electron-forge [command]" for the corresponding tasks. We know under the hood that Electron Forge uses Webpack and electron-packager to transpile and package the app, but we don't know what exactly Electron Forge does with Webpack and electron-packager unless we dive into its' source code, because it chains all the processes in its' scripts. Here for the "scripts" section, since the script names explain what it does well enough, it's not a dealbreaker.
Then we look at the "config" section, this is the section to configure Electron Forge. You see, Electron Forge has its' own set of configurations. The way you configure Webpack in this Electron Forge generated project is via its' Webpack plugin, so one more plugin to learn. What makes the matter worse is there're 4 more Webpack config files and some config options are set there, including Webpack plugins. Remember, Webpack has a large set of options itself. Electron Forge can pass some options to Webpack, but it doesn't cover all the options available via its' interface. Therefore, now you have at least 2 sets of config to manage. This is where things get messy.
The dependency list is another section we can look at. As I've mentioned earlier, we know Webpack is being used under the hood, but we don't see it in the dependency list. Instead, we found "@electron-forge/plugin-webpack". Because Electron Forge has everything chained up inside its' scripts, you cannot just update Webpack yourself. You have to wait for the Electron Forge team to update the underlying Webpack package the plugin depends on. Or for whatever reason, one day you want to use Rollup instead, you simply can't, unless Electron Forge supports it, or you ditch Electron Forge.
To be fair, I'm not against Electron Forge. I agree it's a good starting point if you just started learning Electron or only developing a simple app yourself. However, if you're developing for any serious project, I think it's better that you get to see exactly what's happening behind the scenes. In this way, you know where to tweak doing optimisations, whether it's shrinking down the bundle sizes or optimising for your CI/CD pipelines, or at the very least, you know where to debug when something went wrong.
Sum Up
I hope this article can help you understand more about the idea behind the development of the ERTW Boilerplate and gives you more confidence that this project is not abandoned, so you can start your next Electron project with it.
Going into the future, as I've said above, there'll be monthly updates for this project, and new features will be developed/integrated. Things I've listed in Development Plan will be the ones I focus on first, but other things like hot module replacement may also be integrated into future versions.
That's it. Thanks for reading. Hope you have a bug-free day ahead 😉