Forem: Hopp

Sentry Errors Are Unreadable by Default. Here's How to Fix It with Source Maps

Iason Paraskevopoulos — Tue, 14 Oct 2025 11:06:00 +0000

At Hopp, we’re building a cross-platform remote pair-programming application using Tauri and React. Like any production app, Hopp can encounter JavaScript errors in the front-end.

We use Sentry for error tracking, but we initially ran into a frustrating issue: the error stack traces captured from our Tauri app were practically gibberish due to code minification and transpilation. In this post, I’ll explain how we solved this by leveraging source maps with Sentry, turning cryptic errors into human-readable ones.

What Is The Actual Problem

By default, our production JavaScript is bundled and minified (compressed and optimized). When an error occurs, Sentry would report it with a stack trace referencing the minified code (often a single line of obfuscated code). This made debugging nearly impossible, as we couldn’t directly see what part of our source code caused the issue.

In the sections below, I’ll walk through why this problem occurs and how using source maps (and Sentry’s build integration) can fix it.

Why Error Stack Traces Break in Production

When we build our Tauri app’s front-end, Vite produces optimized JavaScript. This involves two things:

Transpilation: Converting modern JSX/TypeScript into plain JavaScript that browsers (or the WebView in Tauri) can run.
Minification: Removing whitespace and shortening variable names to reduce file size.

Both are great for performance, but terrible for readability of errors. Let’s look at a quick example. Suppose our React component source looks like this (in TypeScript/JSX):

import { useState } from "react";

const HelloWorld = ({ title }: { title: string }) => {
  const [state, updateState] = useState<string>("wow");
  return <div>{title}</div>;
};

After the transpilation process, the transpiled output might resemble:

import { jsx as _jsx } from "react/jsx-runtime";
import { useState } from "react";
const HelloWorld = ({ title }) => {
  const [state, updateState] = useState("wow");
  return _jsx("div", { children: title });
};

Even without full minification, you can see the code has been transformed (e.g. our JSX turned into a _jsx function call). In a fully minified bundle, this could be squeezed into one line, with variable names like a and b. Now imagine an error occurs in this component – the stack trace will refer to something like HelloWorld.js:1:12345, pointing to the minified code. Debugging from that is extremely difficult.

We attempted a build with no minification, which made the code slightly more readable and only increased our bundle from ~12 MB to ~14 MB. However, the code was still transpiled (not identical to our source), so line numbers and function names didn’t match exactly. The real solution was to utilize source maps.

What Are Source Maps (and Why We Need Them)

Source maps are files that map the transpiled code back to the original source code.

To understand better how they work, there is an amazing website, source-map-explorer, where you can play around with your source maps or we the pre-built examples.

A source map allows debugging tools to translate from the location in a minified file to the corresponding location in your original, untransformed code. For example, if an error occurs at column 5000 of bundle.js, a source map can tell us it corresponds to, say, line 42 of HelloWorld.tsx in our source.

In practice, source maps are usually .map files generated alongside your JS bundles. They contain a JSON mapping of every symbol and line from the minified file to the original file. When enabled, tools like browser DevTools or Sentry can use them to display stack traces and code in terms of your original source.

And then the benefit of using source maps with Sentry is that error report can show us the actual line of our React component that failed, instead of an unreadable blob of minified code.

Why Not Ship Source Maps in the App?

It might sound tempting to just include the source maps with our application bundle. Then Sentry (or even end-users in DevTools) would automatically get the decoded errors. However, there are two major drawbacks to embedding source maps in a production app:
1. Huge file size increase: Source map files can be massive. In our case, the production bundle jumped from ~12 MB (minified) to ~47 MB when we included source maps! 🔼 This 4x size bloat is unacceptable to ship to every user.
For comparison:

Build Type	File Size
Without minification	~14 MB
With minification	~12 MB
With source maps included	~47 MB 😱

2.  Potentially exposing source code: Source maps essentially contain your original source. If you include them publicly, savvy users could reconstruct a lot of your source code. This might be fine for open-source projects, but not ideal for a proprietary app.

So, directly shipping source maps inside the app was a non-starter. We needed a way to get the benefits of source maps without burdening our users with large binary files. This is where Sentry’s integration comes in.

Uploading Source Maps to Sentry (Using the Sentry Vite Plugin)

Fortunately, Sentry provides tools to handle source maps on their side. The idea is:

Generate source maps during your build (but do not bundle them with the app distributed to users).
Upload those source maps to Sentry’s server.
When an error occurs, Sentry will use the uploaded source maps to de-minify the stack trace, showing you the original code context in the Sentry dashboard.

This way, end-users never download the .map files, only Sentry has them. We get the best of both worlds: small app size and meaningful error debugging.

Sentry has official plugins for popular build tools (Webpack, Vite, etc.) to streamline this. In our case (using Vite), we leveraged the @sentry/vite-plugin. This plugin automates the release setup and source map upload as part of the build process.

Here’s how we integrated it into our Tauri app’s build:

Install Sentry SDK and Vite plugin: (e.g. npm install @sentry/react @sentry/vite-plugin). We also set up Sentry in our app code with Sentry.init(...) including our DSN, as usual.
Configure Vite to produce source maps: In vite.config.ts, ensure the build is configured with sourcemap: true for production. Vite doesn’t output source maps for production builds unless you enable this.
Add the Sentry Vite plugin in vite.config.ts: We include the plugin with our Sentry project details. For example:

// vite.config.ts
import { defineConfig } from 'vite';
import { sentryVitePlugin } from "@sentry/vite-plugin";

export default defineConfig({
  plugins: [
    // ...
    // Enable Sentry plugin only if SENTRY_AUTH_TOKEN is present
    process.env.SENTRY_AUTH_TOKEN ?
      sentryVitePlugin({
        org: "Hopp",              // Sentry organization slug
        project: "tauri-app",       // Sentry project name
        authToken: process.env.SENTRY_AUTH_TOKEN, // Auth token with proper scopes
      })
      : undefined,
  ],
  // ... other config (e.g., resolve.alias, etc.)
  build: {
    sourcemap: true,  // crucial: generate source map files for production
  },
});

A crucial step is to ignore the source-map files in the built app. In our case we utilized the beforeBuild hook to exclude them from the final bundle. It looks like this: "beforeBuildCommand": "yarn build && rm -rf ./dist/assets/*.js.map"

With this setup, here’s what happens when we build our app:
1. Vite generates the JavaScript bundles and the corresponding .map files (thanks to sourcemap: true).
2. The Sentry Vite plugin kicks in at the end of the build, uploading those .map files to Sentry.
3. We remove the source-map files from the build directory.
3. We publish our app without including the .map files in the bundle (the end-user package stays ~12 MB, no increase).

Verifying It Works (Readable Errors at Last!)

With our code deployed using this new setup, we wanted to make sure everything was working correctly. To test it, we added a little snippet in our app that intentionally throws an error when a button is clicked:

<Button onClick={toggleSound}>
  {isPlaying ? "Stop call sound" : "Play call sound"}
</Button>

<Button onClick={() => { throw new Error("Oh no an error"); }}>
  Test Sentry Error
</Button>

When we run the app and click the Test Sentry Error button, it triggers an error ("Oh no an error"). This error is reported to Sentry by our configured Sentry React SDK. Now comes the moment of truth: checking Sentry’s dashboard for this error.

Notice in the screenshot how Sentry provides the function name and source code snippet where the error occurred. This is possible only because Sentry could map the minified code back to our original TypeScript/JSX, thanks to the uploaded source map. Without the source map, we would have just seen something like Error: Oh no an error at app.bundle.js:1:10567, which is not actionable.

Conclusion

By integrating source maps with Sentry, we’ve drastically improved our debugging experience in production. Instead of cryptic stack traces, we get clear insights into errors as if we were running the app in development. The Sentry Vite plugin made this fairly straightforward to set up, handling the heavy lifting of uploading maps and associating them with releases.

In our case, this setup has already paid off. We can track down issues in Hopp’s app much faster now, because the errors tell us exactly where to look. If you’re using Sentry for a JavaScript app, take advantage of source maps and your future self debugging a production issue will thank you!

If you have questions or want to discuss source-maps and debugging further, feel free to reach out on X/Twitter or email me directly at costa@gethopp.app.

Tauri vs. Electron: performance, bundle size, and the real trade-offs

Iason Paraskevopoulos — Mon, 07 Jul 2025 14:18:22 +0000

Intro

At Hopp, we're building a cross-platform remote control application designed for a low-latency remote pair programming experience. Providing the best possible user experience is our top priority.

Early in the development journey, the decision came to use either Tauri or Electron to build the app. Using one of these frameworks offered a promising way to avoid writing native code for each platform (Windows, macOS, Linux). This meant a crucial choice needed consideration.

Both Tauri and Electron offer robust frameworks with fundamental differences. We needed to carefully consider these differences to decide which framework would best serve Hopp long-term.

If you currently weigh Tauri against Electron for your project, this post might help.

What this post covers:

The core differences between Tauri and Electron under the hood.
The advantages and limitations associated with each framework.
A benchmark comparing app size, startup time, and memory usage.
The reasoning behind choosing Tauri for Hopp.

The main differences between Tauri and Electron

When developers first research Tauri, they often encounter articles describing it as a "lighter Electron" or emphasizing the need to "learn Rust." While truth exists in these points, they don't capture the full picture. These two leading cross-platform frameworks have architectural differences that impact development and performance.

Let's dive into how Tauri and Electron operate behind the scenes.

Electron's main process

Electron's main process runs as a NodeJS process. This architecture necessitates shipping a Node.js runtime with your app to ensure it runs correctly on any user's machine.

As a result, your app's event handling relies on the Node.js event loop. For higher performance tasks or deeper OS-level interactions, you typically must spawn a separate process and establish communication via Inter-Process Communication (IPC) or another protocol like Unix Sockets.

Electron's renderer process

Think of the renderer process as a single browser tab spawned by the main process. In practice, every window you open in an Electron app creates a new renderer process.

This means an app with many windows will run numerous renderer processes concurrently. Developers must account for the cumulative memory and CPU usage of these processes—akin to running mini-Chromium instances in the background.

The Electron team offers a helpful analogy:

Tauri main process

Tauri leverages Rust for its backend. A key advantage comes from Rust compiling to a native binary, eliminating the need to bundle a runtime (like Node.js) with the app. This contributes to a more lightweight app, though it involves trade-offs discussed later.

Tauri WebView process

Instead of bundling the entire Chromium engine, Tauri uses the operating system's native WebView component to render the UI. This component generally weighs less than a full browser engine. Currently, Tauri uses:

WebView2 on Windows (based on Microsoft Edge/Chromium)
WKWebView on macOS (based on Safari/WebKit)
WebKitGTK on Linux

By relying on the system's WebView, Tauri creates smaller app bundles, but this comes at a cost.

Developers using Tauri face potential challenges with cross-platform UI consistency. Browser-specific quirks can appear—issues in Safari but not Chrome, or Firefox behaving differently across operating systems. Since Tauri uses different underlying web engines on each OS, these platform variations become factors developers must manage during app development.

Features comparison

Below is a comparison table highlighting key aspects of Tauri and Electron, with a slight emphasis on factors important to us at Hopp. Following the table, I'll detail a simple benchmark comparing size, startup time, and memory usage.

Feature	Tauri 🦀	Electron ⚛️
Startup time	🏎️ Fast	🏎️ Fast
Memory Usage (Benchmark)	`172 MB`	`409 MB`
Browser technology	`WebView`	`Chromium`
Backend language	`Rust`	`JavaScript`
Build time (Initial)	🐢 Slow	🏎️ Fast
Bundle size (Benchmark)	`8.6 MiB`	`244 MiB`

App benchmark

To illustrate the practical differences, this benchmark compares two apps using each framework. Their function:

Display a main window with a button to open a new window.
Open 6 windows simultaneously to observe resource usage.

The following commands scaffolded the apps:

# For Electron
npx create-electron-app@latest electron-demo-app --template=vite-typescript

# For Tauri (selected TypeScript with Vite and React)
yarn create tauri-app

The resulting applications looked like this:

🚧 Disclaimer: This is a basic benchmark performed on my MacBook Pro with a single run (N=1). Take the following numbers with a grain of salt.

Build time

The initial build time was significantly slower for Tauri, primarily due to the Rust compilation step. Subsequent builds are typically much faster.

# Electron
❯ time yarn make
...[LOGS]...
yarn make  13.23s user 1.55s system 93% cpu 15.818 total

# Tauri
❯ time yarn tauri build
...[LOGS]....
yarn tauri build  380.11s user 28.37s system 504% cpu 1:20.94 total

Bundle size

As expected from the architectural differences, Tauri produces a smaller app bundle. This occurs because:

Tauri doesn't bundle a JavaScript runtime (Node.js).
Tauri uses the system's WebView instead of bundling Chromium.

The difference shows clearly below, from 8.6MiB for Tauri to 244MiB for Electron:

❯ du -h -d 1 .
8.6M    ./tauri-demo-app.app
244M    ./electron-demo-app.app

Memory usage

This area highlights Tauri's "lighter" reputation. The difference stems from two main areas:

Electron's Main Process: The Node.js runtime inherently consumes memory.
Renderer Processes: On macOS, Electron's Chromium-based renderer processes consumed roughly double the memory of Tauri's WKWebView processes for the same window.

After opening 6 windows in each app, the approximate memory usage measured:

Tauri: ~172 MB
Electron: ~409 MB

Startup time

Startup time is another common consideration. In this simple benchmark, the difference was negligible. Honestly, basing a framework decision solely on a startup time difference of less than even 1 500 ms is likely overthinking it for most applications.

For more detailed benchmark data across frameworks, check out the Web to Desktop Framework Comparison repository.

Why we chose Tauri for Hopp

The comparison above presents the trade-offs between Tauri and Electron. For Hopp, the decision tilted towards Tauri for these key reasons:

1. Backend performance

Hopp relies on a customized version of WebRTC to achieve ultra-low latency screen sharing. The app needs to stream video directly from a backend process, not using the browser's standard screen-sharing Application Programming Interfaces.

Rust's performance suits this intensive task exceptionally well. Implementing this in Electron would require managing a separate process for the video stream, complicating the architecture.

2. Sidecar support

While Tauri's main process uses Rust, Hopp needs a separate process (a "sidecar") for handling screen streaming and remote control input (clicks, typing). This allows for developing and testing this component separately from the rest of the app.

Tauri's built-in Sidecar concept simplifies managing the lifecycle of this external binary. Achieving the same in Electron would involve manually spawning, monitoring, and communicating with an external process, adding complexity.

Note: Tauri's Sidecar differs conceptually from the Kubernetes pattern but serves a similar purpose of managing a companion process.

We also utilize the sidebar process to draw the controller's cursor. In the future, we could swap to use Tauri egui.

3. Feature parity:

Although Tauri is newer than Electron, it's rapidly evolving. Tauri v2, in particular, is closing the feature gap, incorporating essential functionalities like a built-in updater as a first-class citizen. The project's momentum and focus on performance and security aligned well with our needs.

Conclusion

I hope this comparison has been insightful, especially if you're navigating the choice between Tauri and Electron for your next project.

Ultimately, there's no single "right" answer. The best choice depends entirely on your specific use case, team expertise, and project requirements. Both frameworks are powerful tools capable of building excellent desktop applications, each with its distinct strengths and weaknesses.

If you have questions or want to discuss this further, feel free to reach out on X/Twitter or email me directly at costa@gethopp.app.