Coder Legion - Recent posts tagged electron

Build an Electron app with local data storage — no SQLite bindings, no server

Sun, 09 Aug 2026 10:38:03 +0000

If you've shipped an Electron app that persists structured data, you've probably hit the wall at some point. You need something more than a flat JSON file, but a full database server is absurd for a desktop app. So you reach for better-sqlite3 — and then spend the next hour fighting native bindings.

The Electron storage problem

Electron bundles its own version of Node.js. That version almost never matches the one on your machine. Native Node modules — the ones that compile C++ bindings — need to be recompiled specifically for the Electron runtime, using electron-rebuild or equivalent tooling.

In practice this means:

Every Electron update potentially breaks your native dependencies
CI pipelines need platform-specific build steps for Windows, macOS and Linux
Code signing and notarization on macOS gets complicated by native binaries
End users on some machines encounter install failures you can't reproduce locally

better-sqlite3 is an excellent library. But it is a native module, and native modules in Electron are a tax you pay forever.

The alternatives people reach for have their own problems. lowdb and lokijs keep everything in memory and flush to disk — fine for small datasets, but you lose durability on crash and memory usage grows with your data. nedb hasn't been maintained in years. A remote database is obviously wrong for a local desktop app.

What you actually need

For most Electron apps, the storage requirements are modest but specific:

Structured documents, not just key-value pairs
Queries that go beyond "give me everything"
Writes that survive a crash
Zero native binaries — pure JavaScript, works everywhere Electron runs
No server process running alongside your app

That's exactly the gap pocket-db is designed to fill. It's a single-file embedded document store — the SQLite model applied to JSON documents, with a MongoDB-style API. Pure TypeScript, shipped as both ESM and CommonJS. No native bindings. No optional dependencies.

Building the example app

Let's build a small note-taking app: create, list, search and delete notes. Simple enough to follow in full, realistic enough to show the pattern.

Setup

We'll use electron-vite, which scaffolds the src/main / src/preload / src/renderer layout used below, with TypeScript and React ready to go:

npm create @quick-start/electron@latest my-notes -- --template react-ts
cd my-notes
npm install @axfab/pocket-db

No electron-rebuild. No postinstall scripts. That's the point.

Initialising the database

In Electron, database access belongs in the main process. You have access to the filesystem there, and it keeps your renderer process clean. Use app.getPath('userData') — Electron's standard location for app data, persisted across updates.

One thing to know: Electron creates the userData directory lazily, so on a first launch it may not exist yet — and open() does not create parent directories. Create it before opening:

// src/main/db.ts
import { app } from 'electron'
import { open } from '@axfab/pocket-db'
import { mkdirSync } from 'node:fs'
import path from 'node:path'

const dataDir = app.getPath('userData')
mkdirSync(dataDir, { recursive: true }) // may not exist on first launch

export const db = open({ path: path.join(dataDir, 'notes.pdb') })
export const notes = db.collection('notes')

One file, one call. The database is created if it doesn't exist. No migrations, no schema definition.

Exposing database operations via IPC

Electron's security model means the renderer can't touch Node APIs directly. You expose operations through IPC handlers in the main process and call them via contextBridge in the preload script.

Search deserves a moment of care: the search term comes from user input, and $regex compiles it as a regular expression. A term containing ( or [ would throw, and a raw pattern is case-sensitive. Escape the input and pass $options: 'i':

// src/main/index.ts
import { app, BrowserWindow, ipcMain } from 'electron'
import { db, notes } from './db'

/** Escapes regex metacharacters so user input is matched literally. */
const escapeRegex = (term: string) =>
  term.replace(/[.*+?^${}()|[\]\\]/g, '\\$&')

ipcMain.handle('notes:create', (_event, title: string, body: string) => {
  return notes.insertOne({ title, body, createdAt: Date.now() })
})

ipcMain.handle('notes:list', () => {
  return notes.find().sort({ createdAt: -1 }).toArray()
})

ipcMain.handle('notes:search', (_event, term: string) => {
  const pattern = escapeRegex(term)
  return notes.find({
    $or: [
      { title: { $regex: pattern, $options: 'i' } },
      { body:  { $regex: pattern, $options: 'i' } }
    ]
  }).toArray()
})

ipcMain.handle('notes:delete', (_event, id: string) => {
  return notes.deleteOne(id)
})

app.on('before-quit', () => db.close())

// src/preload/index.ts
// Note: keep the preload compiled to CommonJS (electron-vite's default) —
// sandboxed renderers don't load ESM preload scripts.
import { contextBridge, ipcRenderer } from 'electron'

contextBridge.exposeInMainWorld('notes', {
  create:  (title: string, body: string) => ipcRenderer.invoke('notes:create', title, body),
  list:    ()           => ipcRenderer.invoke('notes:list'),
  search:  (term: string) => ipcRenderer.invoke('notes:search', term),
  delete:  (id: string) => ipcRenderer.invoke('notes:delete', id),
})

Using it in the renderer

From the renderer, the API is just async function calls:

// src/renderer/src/App.tsx
const handleCreate = async () => {
  await window.notes.create(title, body)
  setNotes(await window.notes.list())
}

const handleSearch = async (term: string) => {
  const results = await window.notes.search(term)
  setNotes(results)
}

const handleDelete = async (id: string) => {
  await window.notes.delete(id)
  setNotes(await window.notes.list())
}

No database logic in the renderer. No connection strings. No async initialisation to wait for. The main process owns the database, the renderer just calls handlers.

Where indexes help — and where they don't

Two things to know about pocket-db's query planner in V1: $regex is never index-assisted (it's always evaluated against the documents), and $or queries bypass index planning entirely. So the regex search above is a full collection scan — perfectly fine for a notes app, but don't expect an index to speed it up.

Indexes shine on equality and range lookups. Say notes belong to notebooks:

// run once at startup, safe to call repeatedly
notes.createIndex('notebook', { type: 'string' })

Now a query like notes.find({ notebook: 'work' }) reads only the matching documents instead of scanning the collection — the planner picks the index up automatically, no change needed in your query code. The same goes for a number index on createdAt if you query by date range.

Periodic compaction

The append-only log accumulates dead records as notes are edited and deleted. Schedule compaction when the app is idle:

app.on('browser-window-blur', () => {
  db.compact()
})

compact() is fast and synchronous — it rewrites the file in a single forward pass. Calling it when the window loses focus means it runs during natural pauses without affecting responsiveness.

Packaging and distribution

This is where the native module problem usually surfaces. With pocket-db, there's nothing to rebuild. The electron-vite scaffold already wires up electron-builder; its config just works as-is:

# electron-builder.yml (generated by the scaffold)
mac:
  target: dmg
win:
  target: nsis
linux:
  target: AppImage

No electron-rebuild in your build pipeline. No platform-specific post-install hooks. The same config builds cleanly on all three platforms.

If you're using GitHub Actions to build releases:

# .github/workflows/release.yml
- name: Build
  run: npm run build && npx electron-builder
  # No electron-rebuild step needed

One fewer thing to maintain.

What about data migration?

pocket-db is schemaless — documents in the same collection can have different shapes. That means additive changes (adding a new field) require nothing: new documents have the field, old ones don't, and $exists lets you query for either.

For breaking changes, a one-time migration on startup is straightforward. Keep a version marker in a metadata collection — and remember that on a fresh database the marker doesn't exist yet:

const schema = db.collection('_meta')
const marker = schema.findOne({ key: 'version' })
const version = typeof marker?.value === 'number' ? marker.value : 0

if (version < 2) {
  // run migration
  notes.updateMany({}, { $set: { archived: false } })

  if (marker) {
    schema.replaceOne(marker._id as string, { key: 'version', value: 2 })
  } else {
    schema.insertOne({ key: 'version', value: 2 })
  }
}

Note the replaceOne(marker._id, …) call: the first argument is the document id. (Passing a full document as the only argument is a separate overload that replaces that document by itself — not what you want here.)

No migration framework needed for most desktop app scenarios.

The trade-offs to know

pocket-db is designed for single-process use. An Electron app fits that model perfectly — the main process is the only writer, and that's exactly the intended use case.

It is not the right choice if your Electron app spawns multiple Node worker processes that all need to write to the same database simultaneously. It is also not the right choice if you're storing hundreds of thousands of documents and need complex aggregation — at that scale, an actual database server starts making sense even in a desktop context.

For the common case — a desktop app storing user data, preferences, history, cached API responses, local task lists — it fits well.

Getting started

npm install @axfab/pocket-db

Full documentation at pocket-db.axfab.net. Source and issues at github.com/axfab/pocket-db. The complete example app from this article is in the repository of exemple, tests included.

If you've been putting up with native binding headaches in Electron, give it a try and let me know how it goes.

pocket-db is MIT licensed.

I Ported ComfyUI Desktop to Ubuntu 26.04 1 a day till I run out!

Wed, 15 Apr 2026 03:17:57 +0000

And Another One!

Another Desktop App ported to Linux That was not available. I will Keep going until release day or I run out of apps to port. Let me Know what one you would like to see next!

The official ComfyUI Desktop app ships for Windows and macOS.

I wanted it on Ubuntu 26.04.

So I ported it.

Not a web wrapper. Not a fake launcher. Not a shell script around a browser tab.

The actual desktop app.

The Goal

I had two requirements:

build the real app on Linux
make it usable on a machine that already runs ComfyUI normally

That second one mattered more than people think.

If a Linux user already has:

a real ~/ComfyUI install
a running server on 127.0.0.1:8188

then the desktop app should not pretend the machine is blank and try to push a fresh install into ~/Documents/ComfyUI.

That is bad product behavior, even if the package technically launches.

The Starting Point

The upstream repo is here:

https://github.com/Comfy-Org/desktop

At first glance it looks cross-platform enough:

Electron app
bundled frontend assets
uv bootstrap
asset build pipeline
electron-builder config with Linux bits already half-present

But “half-present” is the dangerous state.

That usually means:

some paths exist
some assets exist
some packaging config exists
and the app still does not actually ship on Linux

Which is exactly what was going on here.

The Real Problems

There were a few distinct failures.

1. Linux was gated out of asset/bootstrap flow

The app would build fine for supported platforms, but Linux was not being carried all the way through asset setup and build verification.

That meant some Linux artifacts were never properly prepared even though the source tree looked close.

2. Packaged builds were missing `desktop-ui`

This was the first hard packaging bug.

The app launched, then died with a file-not-found error because the packaged build did not contain the desktop onboarding UI bundle.

That is the kind of bug that makes a port look dead before you even get to runtime behavior.

3. AppImage hit Electron sandbox issues

This is the standard Linux Electron tax.

The AppImage mounted fine, but Chromium tripped over the sandbox helper and aborted before the app could become useful.

I did not waste time pretending AppImage was the right hill to die on.

For Ubuntu, .deb was the better target.

4. Linux runtime assumptions were wrong

The app still had platform checks and install behavior that were effectively “Windows/macOS first, Linux later.”

A Linux port cannot just compile. It has to stop acting like Linux is unsupported at runtime.

5. Existing Comfy installs were ignored

This was the most important UX issue.

On my machine, ComfyUI was already installed and already running in the browser.

The desktop app still tried to start from scratch and push a managed install path into Documents.

That is technically launchable, but functionally wrong.

So I fixed it.

What I Changed

I split the work into build fixes, runtime fixes, and “make it behave like a sane Linux app” fixes.

Build and packaging fixes

enabled Linux asset bootstrap
enabled Linux build verification
packaged the missing desktop-ui bundle
switched the Linux target to .deb

Runtime fixes

added Linux config/reset path handling
made Linux hardware validation non-fatal
added fallback behavior for missing compiled requirements
added Linux-safe Electron startup defaults

Existing-install behavior

This was the good part.

I changed the app so it now:

prefers an existing ~/ComfyUI directory as the default base path
detects a live local Comfy server on 127.0.0.1:8188
persists external-server mode into desktop config
skips the desktop-managed venv validation path when attaching to that external server
opens the frontend against the already-running instance instead of forcing first-run install flow

That last bit is what makes the port feel real instead of merely “bootable.”

Why `.deb` Won

I know someone will ask why I did not just ship AppImage.

Because Ubuntu users need something that works, not something ideologically pure.

The .deb route gave me:

stable installation under /opt/ComfyUI
normal desktop integration
no AppImage sandbox headache
a clean launcher path

On Linux, packaging format is not theology. It is operational reality.

What the App Does Now

On an Ubuntu 26.04 machine with an existing Comfy setup:

launch the desktop app
it detects ~/ComfyUI
it sees the live server on 127.0.0.1:8188
it stores that as the desktop install state
it attaches instead of onboarding

That is the behavior I wanted from the start.

Commands I Actually Used

Install dependencies:

corepack enable
corepack yarn install

Bootstrap app assets:

corepack yarn make:assets

Verify:

corepack yarn typecheck
corepack yarn vitest run

Build the package:

corepack yarn make

Install the package:

sudo apt install ./dist/ComfyUI-0.8.30-amd64.deb

The Nice Surprise

The upstream repo was not hopeless.

This was not one of those situations where “Linux support” secretly meant rewriting the app from scratch.

Most of the work was:

finishing incomplete Linux paths
fixing packaging omissions
picking the right distribution target
making startup logic respect an existing local Comfy workflow

That is still real work, but it is not fantasy.

The Useful Lesson

A port is not finished when the window appears.

A port is finished when the app behaves correctly on the target machine.

For this one, the difference was:

not just “ComfyUI Desktop launches on Ubuntu”
but “ComfyUI Desktop understands an Ubuntu user who already runs ComfyUI”

That is the difference between a demo and a port.

Upstream and Source

Upstream desktop app: https://github.com/Comfy-Org/desktop
ComfyUI core: https://github.com/comfyanonymous/ComfyUI

My Repo

https://github.com/johnohhh1/comfyui-desktop-port-linux.git

git clone https://github.com/johnohhh1/comfyui-desktop-port-linux.git

Cross-Platform Desktop Wars: Electron vs Tauri: How do you explain the tradeoffs to users?

Tue, 14 Apr 2026 07:12:44 +0000

Hello,

I am writing cause I wanted to get some opinions from folks here that have actually built and shipped with Electron (or Tauri).

Background: Building an API IDE on Electron. Not really “just an API client”, and not a(nother) thin wrapper around a webapp either. It’s a pretty original desktop tool with a lot of editor/IDE-like behavior - not the typical form centric behavior that postman or others have: local workflows, richer interactions, and some things that honestly would have been much harder for us to build and iterate on this quickly in a more constrained setup. Thats why Electron.

this is the tool:

https://github.com/VoidenHQ/voiden

Now, as adoption is growing, we are starting to get the usual questions about memory footprint and app size.

The (slightly) frustrating part is this:

When the app is actually being used, the app-side memory is often pretty reasonable. In many normal cases we are seeing something like 50–60 MB for the actual usage we care about (even added it in the app itself for people to check it out).

But then people open Activity Monitor, see all the Chromium/Electron-related processes, and the conversation immediately becomes:

“yeah but Tauri would use way less”

And then, without realizing, I suddenly end up talking and philosophizing about Electron, instead of discussing the tool itself (which is what I am passionate about :)

And of course, I get it. The broader footprint is real. Chromium is not free. Electron has overhead. Pretending otherwise would be foolish. So we are constantly optimizing what we can, and we will keep doing so…

At the same time, I do feel that a lot of these comparisons feel weirdly flattened. For example people often compare:

full Electron process footprint VS the smallest possible Tauri/native mental model

…without always accounting for development speed, cross-platform consistency, ecosystem maturity, plugin/runtime complexity, UI flexibility, and the fact that some apps are doing much more than others. Which is by the way the reason that we went with Electron.

So all this context to get to my real question, which is:

How do you explain this tradeoff to users in a way that feels honest and understandable, without sounding like you are making excuses for Electron?
And also, for those of you who have had this conversation a hundred times already:

What do you say when people reduce the whole discussion to “Electron bad, Tauri good”?

Have you found a good way to explain footprint in practical terms?

Where do you think optimization actually matters, vs where people are mostly reacting to the idea of Electron?

Mostly trying to learn how others think about this , especially those who have built more serious desktop products and had to answer these questions in the wild.

Would love your thoughts and advice!

Run the Real ChatGPT Desktop App on Ubuntu Linux (Not a Wrapper)

Thu, 09 Apr 2026 20:58:42 +0000

TL;DR: OpenAI ships a Windows MSIX binary. You can unpack it, patch three platform assumptions, and run the actual official app natively on Ubuntu — same binary Windows users get. No Electron wrapper, no web view in a box.

The Problem With Every Other Guide

Search "ChatGPT desktop Ubuntu" and you'll find two things:

Articles pointing you at lencx/ChatGPT — a third-party Electron wrapper that loads chatgpt.com in a window. It's not the real app.
Articles pointing you at other wrappers doing the same thing.

These work, but you're getting a community-built shell around a website — not the app itself. The real ChatGPT Desktop (the one in the Windows Store) has features, update hooks, and auth flows that wrapper apps can't replicate cleanly.

This guide unpacks the official binary and runs it on Ubuntu 26.04. Tested on kernel 7.0.0, RTX 5070, NVIDIA 580/CUDA 13.0, both X11 and Wayland via XWayland.

What the Script Actually Does

Extracts the x64 MSIX from the official .msixbundle
Pulls out the official app.asar (the real app logic)
Patches three platform assumptions so it boots on Linux:
- Routes the platform chooser through the macOS-style implementation (Linux is close enough)
- Disables macOS-only setVibrancy() calls
- Skips the macOS ioreg device ID path
Stages Linux Electron around the official app resources
Packages everything as a proper .deb — chatgpt-desktop-native

You end up with a system package you can install, update, and uninstall like anything else.

Prerequisites

System packages

sudo apt-get install -y dpkg-dev nodejs python3 file

Local Electron tooling

mkdir ~/chatgpt-windows-deb && cd ~/chatgpt-windows-deb
npm install electron @electron/asar --no-save

Get the Official MSIX Bundle

You need the official Windows package from OpenAI. Download OpenAI.ChatGPT-Desktop_<version>.Msixbundle from the Microsoft Store or OpenAI's distribution endpoint and drop it in your working directory.

The repo includes the version current at time of writing as an example payload.

Build

cd ~/chatgpt-windows-deb
git clone https://github.com/johnohhh1/chatgpt_desktop_ubuntu .
npm install electron @electron/asar --no-save
./build-chatgpt-native-deb.sh --exe ./OpenAI.ChatGPT-Desktop_2026.212.2039.0.Msixbundle

Output lands in dist/:

dist/chatgpt-desktop-native_2026.212.2039.0_amd64.deb

Install

sudo apt-get install ./dist/chatgpt-desktop-native_2026.212.2039.0_amd64.deb

Rebuilding without a version bump? Force refresh:

sudo apt-get install --reinstall ./dist/chatgpt-desktop-native_2026.212.2039.0_amd64.deb

Register Auth Callback Handlers

The package installs a helper that registers your desktop session as the handler for the chatgpt: and chatgpt-alt: URL schemes (used for the login flow):

chatgpt-desktop-native-register

Verify it took:

xdg-mime query default x-scheme-handler/chatgpt
xdg-mime query default x-scheme-handler/chatgpt-alt

Both should return chatgpt-desktop-native.desktop.

Launch

chatgpt-desktop-native

The desktop entry sets the WM class to electron so GNOME binds the running window to the ChatGPT icon instead of the generic gear icon.

Known Quirks

The terminal will print Electron/NVIDIA/VA-API noise. This is normal — ignore it.
The success signal is functional login and working chat, not a clean terminal.
If GNOME still shows the generic icon after first launch: close the app fully and relaunch once. Stubborn shell? Log out and back in.
If OpenAI updates the Windows app significantly, the patch targets in build-chatgpt-native-deb.sh may need updating. PR welcome.

Reproducing on Another Machine

Clone the repo to the target machine
Drop a real ChatGPT .msix, .msixbundle, .appx, or .appxbundle in the directory
npm install electron @electron/asar --no-save
./build-chatgpt-native-deb.sh --exe <your-payload>
Install the generated .deb
Run chatgpt-desktop-native-register
Launch chatgpt-desktop-native

Repo

github.com/johnohhh1/chatgpt_desktop_ubuntu

Issues and PRs open. If a new MSIX version breaks the patches, open an issue with the version string and I'll update the patch targets.

Tested on Ubuntu 26.04 "Noble" with kernel 7.0.0-10, RTX 5070, NVIDIA driver 580, CUDA 13.0.strong text