That said, Electron comes with some significant shortcomings, and as the scope has matured, those shortcomings have become more apparent. Because of this, I spent some time exploring Tauri, a new framework that supports a similar web-to-desktop use case to Electron. In this article, we will discuss how well Electron and Tauri integrate with Workbench, and consider some pros and cons between both frameworks.
Next.js Support#
Next.js doesn’t translate very clearly into the desktop application context. This is primarily due to the framework’s architecture around server-side rendering and API routing features. In desktop apps, there is no application server interacting with the client; All we need to do is render HTML, CSS and JavaScript in one window. For these reasons, Electron only supports Next.js applications. This doesn’t mean that you can’t build an Electron app with Next.js, but it does require some workarounds to get it working properly. One of the more popular workarounds is a project called Nextron, which aims to connect Next.js applications to the Electron framework and streamline the build process. This is the project we use for the workspace. The point is that, at the time of writing, it appears that Nextron is no longer being maintained, and we’ve started hitting some bugs in it.
Tauri is largely frontend-framework agnostic. For Nextel, specifically, you still can’t use server-side features, but Torii greatly simplifies the integration process by relying on Nextel’s static-site generation capabilities. To make the Next app work with Tauri, you just need to set up output: 'export' In your next configuration file, and Tauri handles the rest.
webview#
The biggest difference between Electron and Tauri comes from how they present the UI. The Electron Framework comes with the full Chromium browser engine bundled into your application, which is the same engine that powers Google Chrome. This is useful because it means you don’t have to worry about browser compatibility issues. Regardless of the end user’s machine or architecture, the same Chromium instance renders your application UI. This results in a very standardized experience that ensures your app will look the same no matter where it’s running. However, it also results in a fair amount of inflammation. For most desktop apps, a full Chromium browser engine is overkill. Even the simplest “Hello World” applications using Electron can run you up to 150 megabytes of disk space.
Tauri solves this problem by taking advantage of the system’s native WebView. Rather than bundling a full browser engine, Tauri uses a library called WRY, which provides a cross-platform interface to WebViews appropriate for the operating system. As you would expect, this makes Tauri apps far more lightweight. The downside here is that you no longer have any hard guarantees on compatibility. However, from what I can tell, this mostly doesn’t seem to be an issue. Compatibility issues with System WebView are extremely rare, especially for major operating systems.
Node.js vs Rust#
Another big difference between the two frameworks is how they handle the “main” process. It refers to the backend process that organizes application windows, menus, and other components of a desktop app that require interaction with system APIs. In Electron, the main process runs in the Node.js environment. This means you get access to all the specific Node APIs, you can import things like normal, and, perhaps most importantly, you can write your Electron-specific code in pure JavaScript. This is a huge bonus for Electron’s target audience: web developers.
Torey, on the other hand, uses Rust. All framework code and main process entry points are written in Rust. Obviously, this makes it a little less accessible to the average web developer. That said, Tauri provides a fairly robust set of JavaScript APIs for interacting with the Rust layer. For most applications, these APIs will be enough to do what you need to do. In terms of scope, I was able to completely replicate the functionality of the Electron version using the JavaScript API and some minimal Rust code.
In my experience, I found that the Tauri API fit more naturally into our application code. With Electron, if you need the main process to do something, you should always use inter-process communication, even for the simplest tasks. For example, if you want to write a file on the host machine, your frontend needs to send a signal to the Electron main process, which will then spawn a new process and run the function you wrote that does the writing. With Torry, you can use Torry’s file system API directly in your application code. Under the hood, the same kind of IPC pattern is happening, but I think the Tauri abstraction is a little nicer.
sidecar#
Since Electron runs on Node.js, it also bundles the full Node.js runtime with your application. It comes with some advantages and disadvantages. For Workbench, in particular, this is beneficial because the GraphQL layer itself is a separate Node.js application that needs to run with a frontend. Since Electron comes with Node.js, this means we can spin up a GraphQL server directly from the Electron main process using the Node runtime. This eliminates a lot of the headaches associated with bundling and running a typical sidecar process. For example, our app also comes with a copy of Dolt, which allows users to start a local Dolt server directly from the workspace. To make this work, we need to bundle the appropriate dolt binary with each workspace release that matches the correct architecture. Without the Node runtime, we would have to do something similar for the GraphQL layer.
With Tauri, we face exactly the same problem. To get around this, we need to compile the GraphQL server into a binary using a tool like pkgThen drive it as a sidecar the same way we drive the Dolt. Thankfully, this seems to be a fairly common use case for Tauri Applications, and they have a useful guide on how to run Node.js apps as sidecars.
It’s also worth mentioning that the full Node.js runtime is quite heavy, which also contributes to the bloated Electron app size. After building the scope using both Electron and Tauri, there was a substantial difference in size. The left is the electron version and the right is the Tauri:
boundaries#
After replicating the Workbench functionality in Tauri, we are avoiding making a complete change for a few reasons:
- Lacks support for .appx and .msix bundles on Windows – Currently, Tauri only supports .exe and .msi bundles on Windows. This means that your Microsoft Store listing will only link to the unpacked application. Workspaces are currently bundled and published using the .appx format. To address this, we need to remove Workbench completely from the Microsoft Store and create a new application that uses the .exe format.
- Problems with MacOS Universal Binaries – This is more of an annoyance than a bug, but I encountered some issues related to coding universal binaries for MacOS. That is, Torii does not seem to be able to create Mac universal binaries from its Arm64 and x64 subcomponents. Looks like it’s codesigning the Mac build twice.
None of these are drastic blockers, but they are annoying enough that I am holding off on migration until they are resolved or our issues with Nextron become more problematic. For now, I’m leaving my branch with the migration and will hopefully be back soon. If you’re on the Tauri team, let us know if you have a solution!
conclusion#
Overall, I’m impressed with Tauri. It eliminates most of the classic Electron bloat and integrates naturally with our existing codebase. If you’re curious about Tauri or Dolt Workbench, let us know on Discord.
<a href