Electron.js is not a new technology, well... relatively. Everyone had at least one experience on using desktop applications built using Electron. Let it Visual Studio Code, Discord, Slack, Microsoft Teams, and many others. The sole fact that you can develop an entire application by using only Javascript as the main language is such a bait that most people have already taken before, mostly in the form of MERN stack (or anything full-stack using Node).

Previously I've tried other options. C# with WPF, not a pleasant experience with XAML. C++ with Qt or GTK, not even something great to remember. C# with Unity... is it even an option? The main hassle of developing desktop application is the existence of GUI elements that need to be handled thoroughly, with all the event handlers and listeners to deliver an at least okay-ish user experience. And it was such a steep cliff to go through. Having an option to build the GUI using the already (relatively) simple web-based technologies is such a blessing, at first. But then you remember that this is only the GUI, not the actual backend and the driver code. You realize that desktop app is basically doing full-stack development but "locally", and much more isolated. This concept is somehow delivered as the main separator from the processes that makes Electron works as a stack.

So, what did I learn when trying to build my own desktop app using Electron? Not much, but it was a weird experience.

Two Main Processes: Main and Renderer

The fact that we are essentially making a backend and frontend, but somehow shipping them into a single app is making a situation where there are actually two things need to handle quite separately. Everything that handles about the GUI, the "browser" stuff is being handled by renderer process, while the "backend" part is the main process. They work quite differently, where you got almost all the glory of browser API in the renderer process, and total freedom of Nodejs in the backend. It's like, having the best and the worst of both worlds at the same time.

This sounds quite amazing, but in practice it really gives a lot of hassle when trying to use a single bundler...transpiler...compiler?? or what you called a "build system" to make everything works. One really needs to take care on the compatibility of the code, as you might accidentally use browser API in Nodejs, and vice versa. This issue becomes apparent when using TypeScript, as we often work with a single tsconfig to handle just about everything. This might be just me with my skill issue, but I still haven't found a great configuration or environment where I can seamlessly compile my renderer code (that's using browser API) and my main process code (which is full Node.js). This might be the tradeoff.

One goal I have in mind is to actually have a repository inside repository, or some kind of Typescript black magic to isolate a certain directory, or to give special context when dealing with some directories. To have the src directory being transpiled using Nodejs in mind, while web directory using standard ES7 and browser API. A homework to further explore Typescript eh.

Unified Bundler? Don't

If you're like me who desperately trying to keep myself updated with the insane development of Javascript community, then you might have heard about Vite. It's kind of webpack but faster and simpler. At its heart, it's a bundler. Turn your source code into a single (or multiple) files that contains just about everything you need for your app to work. Sometimes also with additional features like minifier, obfuscator, tree shaker, you name it.

Most of the time you use bundler for those non-VanillaJS web applications. Either using React, Vue, Svelte, whatever, you gonna need a bundler to at least make your life easier a bit. It's not compulsory, but it's for your better well-being. And it's making me happy with anything frontend! It does it job just right.

But when you ask it for bundling Nodejs application, not only it's really not necessary, but it has tendency to translate the wrong directives. One that should be using Nodejs' filesystem module fs , instead trying to access browser API because they default to using the browser API. By default this shouldn't happen if the environment is configured correctly. But then again, you don't need bundler for the backend side.

So why would I use bundler? Remember those features that come with bundlers? Nowadays, your bundler is considered "not developer friendly" if it doesn't have Hot Module Reloading (HMR) support. And it really is a very useful feature as you don't need to refresh/reload to see your recent changes. This mainly works in browser side, where what matters really is the view of the application, then the functionality (ironically). Testing the functionality still require resetting the states (sometime), and do something procedurally. This process still takes time. But still faster. And I thought that it could be applied to the backend side. Like, you know, adding HMR to server-side.

It wasn't a great decision as I discovered that HMR is not really something that's compatible with backend development, and my attempt on using vite-electron-plugin ends up with many unnecessary restarts, adding more toil to the development process. Running the renderer process targeting an external web server is a lot better when in development mode, especially with how it's really just a browser bundled inside your "desktop app". A simple window.loadURL() function call is far more preferred. You can just start your electron app pointing at other server which is the Vite development server, and it will just be enough for starting. You might gonna duplicate codes for the interfaces, data, and other Typescript stuffs just trying to sync the backend and the frontend, but hey, ain't that basically how full-stack developer works? (ofc before Next.js/Remix.js/Nuxt.js was cool)

Lesson Learned

Electron.js is something that I wanted to try for a while, and after this attempt, I might want to try to make something more complex and go in-depth, but it all just feels like being a full-stack developer all over again. Same process, same pain, different flavor only. I believe my skill issue lies on what kind of application that I can develop using Nodejs. With only web server and web server and web server only, I think there are still much to improve and to explore. Not mentioning how WebAssemble has grown mature recently, and WebGPU has finally being shipped to Chrome. The Javascript realm is endless, but hell if it's not an exciting journey to dive into.

Loading...

There will be awesome contents here

Learning Electron.js in 3 days - What Did I Learn.