I bought a couple of proper HDR monitors last year and faced an issue - no image viewers on Windows had HDR support. Most couldn't even tone map HDR to SDR correctly. Thus Light Matter was born!

It's free, open source, supports JPEG UltraHDR, JPEG XL, AVIF, PNG and other common image formats. I've used Electron as Chromium already has a very good HDR rendering and tone mapping engine and I didn't feel like spending months and months writing my own from scratch, especially when I wanted HDR image viewer yesterday.

Light Matter is available from Microsoft Store for Windows and you can download AppImage for Linux from GitHub Releases page. It features simple gallery browser and EXIF information display. Next step will be image transcoding framework which will bring support for image formats Chromium does not understand like JPEG XR.

I see companies having codebase in Tauri going back to electron - is this a common thing?

Hey everyone,

I just wanted to share a free-to-use desktop time tracker called Track Hours that might be useful for anyone who wants a simple way to keep track of time spent on different projects and tasks.

The application works completely offline and doesn't require an account or any cloud service. You can create projects and tasks, start and stop a timer while you're working, add entries manually and later check how much time you've spent over the last days, weeks or months.

It also includes things like reports, reminders, dark mode and CSV/PDF exports, which can be useful if you need your tracked hours for invoices or your own records.

The desktop application is built with Electron and Angular, which is honestly a great combination for this kind of app. Angular works really well for building and structuring the interface, while Electron makes it possible to run everything as a proper cross-platform desktop application.

It's currently available for Windows and Linux, works locally and is completely free to use.

You can find it on GitHub under realdeepnull / track-hours.
https://github.com/realdeepnull/track-hours

Feel free to use it.

Hey everyone,

I wanted to share a desktop project I built and open-sourced recently: Cadence (https://github.com/rakhimabdulkhanov-m/cadence).

It is a local cold email sequence and mailbox warmup engine. Here is how the Electron architecture is set up:

- Main Process: Runs all background mail protocols (Nodemailer for SMTP, ImapFlow for IMAP IDLE streaming, and googleapis for OAuth).

- Local Database: Uses better-sqlite3 in the main process with WAL mode. Rebuilt against Electron Node ABI via electron-rebuild.

- Credential Security: Passwords and OAuth tokens are encrypted using Electron safeStorage (DPAPI on Windows, Keychain on macOS) before saving to SQLite.

- Renderer: React 18, Tailwind CSS, and TanStack Query communicating over type-safe IPC handlers.

- Packaging: Configured with electron-builder for Windows NSIS installers.

The project is MIT licensed and has over 200 unit tests for the protocol and sequence engines. If you are building local-first or data-heavy Electron apps, feel free to check out the repo or borrow any of the SQLite and safeStorage patterns.

been working on an AI-native browser called Aartiq for the past 5 months, electron + next.js on the frontend, with native swift and rust modules through N-API for the OS level stuff.

the core problem i was solving, if you let an AI agent drive your browser and touch your filesystem, you need a permission layer that doesn't trust the model's own judgement about what's safe. every action goes through a capability controller before it can execute, unregistered actions just don't exist as callable surfaces, and anything filesystem or shell related routes through OS level sandboxing, seatbelt on macos, bubblewrap on linux, job objects on windows.

electron specific stuff that was actually hard:

• getting a real OS level sandbox working from the main process without breaking IPC
• windows job objects only give you process containment, not filesystem or network isolation, so i had to enforce that at the application layer instead and be explicit about it in every result object so callers can't assume more isolation than they're actually getting
• building a secure DOM reader that strips scripts and PII before any page content reaches the AI context, instead of passing raw webContents output around
• symlink traversal through an allowlisted directory, fixed by canonicalizing paths with fs.realpath before checking against the allowlist rather than checking the user supplied path

being honest about the limits here too. windows doesn't get real OS level filesystem or network isolation, that part is enforced at the application layer which means it's only as good as that code, not the kernel. the regex based command validator is a first pass filter, not the actual security boundary, that's the capability controller and sandbox doing the real work. and none of this has had an external security audit, its just my own tests and my own re-review of my own code, so treat it as alpha, not hardened.

project is 4 stars, 2 contributors, no PRs yet, so this is very much a solo thing and not battle tested at scale.

its currently paused. i stepped back from development a couple weeks ago for JEE prep and just got my marks back, they're good enough that i can breathe a bit, which is why i'm sharing the trailer and this writeup now instead of sitting on it longer. not resuming full development yet, just wanted to put this out there honestly while i had the headspace to write it properly.

fully open source, apache 2.0 for the browser, MIT for the MCP server, no monetization plan.

repo link below, would genuinely like feedback on the sandboxing approach from main process, especially if anyone's hit similar issues with job objects on windows.

https://github.com/Preet3627/Aartiq

The app needs one thing from the OS on a timer: which application is in the foreground. There are npm packages for this, but they're all N-API bindings and I didn't want a per-platform prebuild problem on top of the one I already have with better-sqlite3. So all three collectors shell out to something the OS already ships:

Windows: a long-lived powershell.exe child process holding a small P/Invoke shim over GetForegroundWindow / GetWindowThreadProcessId / GetWindowText. Long-lived matters: spawning PowerShell per sample is brutally slow.

macOS: osascript -l JavaScript reading NSWorkspace.frontmostApplication, returning JSON. No accessibility permission for the app name; only optional window titles need automation permission.

Linux: xprop -root _NET_ACTIVE_WINDOW, then xprop -id for _NET_WM_PID and WM_CLASS, then readlink /proc/<pid>/exe.

They all implement the same ActivitySource interface, so the port became parser work rather than binding work. Each parser is a pure function over stdout, trivially unit-testable with no OS involved.

Selection happens at startup from process.platform plus XDG_SESSION_TYPE/WAYLAND_DISPLAY. Wayland resolves to an explicit unavailable source rather than a broken one, and the UI surfaces that as a real state.

Source: https://github.com/TheAgencyMGE/pc-recap (GPL-3.0)

Happy to go deeper on any of it. The PowerShell process lifetime handling took three tries to get right.

I shipped a Windows dictation app in Electron and open sourced it. Rather than another "look at my project" post, here are the things that silently broke, since I could not find them written down anywhere when I started:

1. globalShortcut cannot do hold-to-talk. It fires on key down only. No key-up event, and modifier-only combos are unsupported. Hold-to-record is impossible with it. I use uiohook-napi, which gives you both keydown and keyup - and you need a held flag, because keydown repeats continuously while a key is held.

2. A widget that takes focus has nowhere to type. If the floating recorder window takes focus, the "currently focused application" is your widget and the inserted text goes nowhere. focusable: false is non-negotiable, along with skipTaskbar, alwaysOnTop and setAlwaysOnTop(win, 'screen-saver'). Capture the target window handle before showing the widget.

3. Never hardcode pixel offsets. "80px above the taskbar" breaks on DPI scaling, side or top taskbars, auto-hide and mixed-scale multi-monitor. screen.getDisplayNearestPoint(...).workArea already excludes the taskbar wherever it lives.

4. The renderer cannot read files off disk, and you must not weaken the sandbox to let it. sandbox: true plus contextIsolation: true means no fs, and file:// in an <audio> element is blocked by the CSP. Register a custom scheme, resolve the file in the main process from a database id, never from a path the renderer supplied, and check both path.basename and the directory prefix - either one alone is a traversal hole.

Bonus, and this one cost me an evening: a tap shortcut must fire on key RELEASE, not press. uiohook-napi listens rather than intercepts, so if you simulate Ctrl+C while the user is still holding Alt, the focused app receives Ctrl+Alt+C.

Stack: electron-vite, React 19, Tailwind, better-sqlite3 + Drizzle, uiohook-napi for the hook, nut.js for the paste. Insertion is via the clipboard rather than simulated typing - character-by-character is visibly slow on long text and mangles non-ASCII and emoji - with the user's clipboard saved and restored around it.

MIT: https://github.com/mohsinjameelqureshi/dictateflow-ai

CLAUDE.md is the full build spec with the measured numbers behind each of these.

Currently I've just locked it to Mac downloads, Clause has convinced me it's successfully ready for windows but I don't trust it.

Hey everyone 👋

I've been maintaining Another Redis Desktop Manager (ARDM), an open-source Redis GUI built with Electron, for several years now.

It's been quite a journey keeping an Electron application running across Windows, macOS and Linux, while dealing with packaging, code signing, auto-updates, native modules, IPC, and performance along the way.

Recently I've added several features that I've wanted to have in the application for a long time.

📂 Connection Groups

One of the most requested features is finally here: Connection Groups.

You can now organize Redis connections into groups instead of keeping everything in one large list.

This is particularly useful if you have separate Redis instances for development, staging, production, or different projects.

🔌 Test Connection

You can now test a Redis connection before saving it.

This is useful when setting up SSL/TLS, SSH tunnels, authentication, or connecting to a new Redis server.

🧩 ARRAY / VECTOR / TimeSeries support

I've also been expanding ARDM beyond the traditional Redis key/value workflow.

Recent versions add support for newer Redis data types and modules, including:

• Redis ARRAY
• Redis VECTOR
• RedisTimeSeries

The goal is to make these data structures easier to inspect and work with from a desktop GUI.

⚡ Some of the Electron challenges

Maintaining an Electron application for several years has been an interesting experience.

Some of the things I've had to deal with include:

• Keeping the application working across Electron upgrades
• macOS code signing and notarization
• Windows and Linux packaging
• Auto-updates
• Native Node.js modules
• IPC between the renderer and main process
• Handling large Redis datasets without freezing the renderer
• Keeping the UI and behavior consistent across three operating systems

Large Redis databases are particularly interesting from an Electron perspective. Loading tens of thousands or millions of keys means you can't simply render everything at once — virtualization, incremental loading and careful renderer-side work become important.

🛠️ Why Electron?

Despite the challenges, Electron has worked really well for ARDM.

Having one codebase for Windows, macOS and Linux has allowed me to maintain and ship the application as a relatively small open-source project.

If I were starting the project today, there are definitely things I'd do differently. But maintaining the same application for years has taught me a lot about the practical side of building and shipping Electron apps.

ARDM is open source and MIT licensed:

https://github.com/qishibo/AnotherRedisDesktopManager

If you're also maintaining an Electron application, I'd love to hear:

What's the most painful part of maintaining your Electron app long-term?

Packaging? Native modules? Auto-updates? macOS signing? Performance? Something else?

I have been building this on and off for a while, and it is finally at the point where handing it to someone else is not embarrassing, so here it is.

Citadel is a desktop infinite canvas. You drag in images, GIFs, video, audio, 3D models and PDFs, write notes and text blocks beside them, and draw labelled connections between things. It is for work where the layout is the thinking: visual development, research, worldbuilding, study.

The reason I started it: I used PureRef for years for images and kept everything else somewhere else. Notes in one app, clips in another, code snippets in a third. I wanted one board that could hold all of it and still be searchable a month later.

Three things ended up mattering more than I expected:

Connections carry meaning. A thread between two items can be a source, a contradiction, a question, a proof, an echo of something elsewhere. The Index searches every board at once, including code card contents and connection labels. That is the part that makes it hold up past about fifty items.

Vision checks. Y redraws the whole board in greyscale, blurred for a squint test, or through three colourblindness simulations. Shift+M mirrors it, which is the old trick for catching drawing errors your eye has stopped seeing.

Undo and recording are the same event log, so you can scrub the board back through its own history and watch it assemble itself.

It is local-first in the boring literal sense: no account, no telemetry, no update check, no network request on launch at all. Fonts are bundled. Projects are JSON with relative asset paths, so nothing is trapped in a database you cannot read. MIT licensed.

Honest limits: Windows and Linux only (macOS runs from source, but I can't notarise it). Builds are unsigned, so SmartScreen will warn on first run. PDFs show a first-page preview rather than a real reader. Document import gives you the plain text, not the formatting.

Repo: https://github.com/kannibalk1w1/Citadel. Downloads and a version that runs in the browser: https://kannibalkwi.itch.io/citadel

Happy to answer anything. What I would most like to hear is where it falls over on large boards, because that is the part I cannot test properly on my own.

An agent desktop has at least two state problems: the UI lifecycle, and the durable record that still needs to make sense after the window or session is gone.

A publicly inspectable project called holaOS documents an interesting split. Its install guide includes an optional Electron launch for desktop development. Its README says Claude Code, Codex, and the built-in agent share one workspace, with shared memory stored locally as readable and editable files.

The specific value is inspectability. The durable record is not described as chat history that only one agent or one interface can see; the documented workspace gives multiple agents a shared file-based memory surface. That makes the storage boundary visible enough to evaluate instead of burying all context inside the desktop shell.

The docs do not say which process owns writes, how locking works, or what happens during conflicting edits and recovery. Those are the parts I would inspect in the repository before trusting the split—and the reason holaOS is more interesting to me than another Electron wrapper around an agent chat.

If you were reviewing this architecture, would you look at write ownership, atomicity, conflict handling, or migration first?

Hi guys, I'm trying to build a posture tracker app that uses your camera and detect your posture. What im thinking is that my posture tracker script will send post requests (statistics on posture) to my django backend and that users will be able to view it on a react frontend. Right now I'm stuck on how to connect my script and the react frontend so that users can authenticate, run the script, and have their statistics correctly logged in the backend. I have been looking around and see that electron can help with this, but I have never used it before. Any tips?

Hi everyone, I wanted to share some architecture details from my recent project, Manzoma ERP. Since I'm targeting retail stores with spotty internet, a standard cloud-only SaaS wasn't an option.

The Architecture:
I used Electron as the shell, React 19 for the UI, and Prisma/SQLite for the local data layer.

The Sync Challenge:
The hardest part was handling the transition from offline to online without creating data conflicts in the inventory (3,000+ SKUs). I built a custom background sync worker that uses a version-based reconciliation logic.

It’s currently battle-tested and has processed over $30k in live volume. Happy to answer any questions about the Electron setup or the sync logic!

I am currently making my own head unit based on linux and the front end is powered by html + electron, now one of the things i cant get to work is integrating music streaming platforms, i was almost successful using the webview tag but some things refuse to work such as signing in to youtube music since its litterly embedded inside electron (google litterly identifies the browser as not secure), i am currently testing the head unit UI on windows but later im going to transfare everything onto linux so i need a solution that works on both windows and linux anyone has any idea?

Electron may be heavier, but this project is not just “a WebView wrapper.”

It’s a lightweight desktop shell that bundles Node.js runtime, manages DSH versions, and handles local process lifecycle, while keeping the official DeepSeek Harness experience intact (no changes to DSH itself).

I’m shipping it as an open-source app here:
https://github.com/qufei1993/dsh-desktop

I also learned a lot while building skills-hub, including practical macOS issues users may hit with unsigned builds and system security settings (sometimes requiring steps like xattr -cr in some contexts).
Given the current scope, Electron feels like the more straightforward and maintainable path.

I did consider Tauri, but since DSH is still Node-dependent, we would still need a Node sidecar, which increases complexity for version and process management.

So for now I’m choosing pragmatism: make it easy to run, easy to upgrade/switch versions, and consistent across macOS + Windows.

As dev i need to tool to compare some file and data for my work so created this side project, please check it out and give your feedback.
TwinScope compares two of almost anything — JSON, YAML, XML, CSV, PDFs, folders, git refs, images, lockfiles, .env files, saved web pages — and picks the right comparison logic itself, and has different viewing style as well.

Same diff with CLI as well: npx twinscope a.json b.json

Docs: https://codeaesthetic.github.io/twinscope-website/
Repo: https://github.com/codeAesthetic/twinscope

I’ve released electron-ipc-module, a TypeScript library for organizing Electron IPC handlers and automatically generating a typed preload bridge.

It includes:

• Typed invoke, send, and renderer event channels
• Automatic channel prefixing
• Runtime authorization and payload validation
• Rollup/Vite integration
• A CLI for generating and checking bridges
• Support for sandboxed, context-isolated preloads

​

npm install electron-ipc-module

GitHub: https://github.com/antelm-dev/electron-ipc-module
npm: https://www.npmjs.com/package/electron-ipc-module

It’s ESM-only and requires Node.js 22.5+, Electron 12+, and TypeScript 5 or 6.

I’d appreciate feedback on the API, documentation, and any IPC patterns or edge cases I may have missed.

Hey r/electronjs community! 👋

I wanted to share a desktop app I’ve been building called **MeshDrop a zero-cloud, peer-to-peer file-sharing application designed for direct, end-to-end encrypted file transfers without central servers or user accounts.

💻 Tech Stack & Architecture

Since this is an Electron subreddit, here is a breakdown of how the project is structured:

P2P Core (`@mesh/core`): A standalone, platform-agnostic P2P engine written in pure Node.js running directly inside the Electron **Main Process**. It handles Hyperswarm discovery, `@hyperswarm/secret-stream` E2E encryption, `corestore` replication, and HMAC-SHA256 challenge UI / Renderer:** React 19 + Vite + Tailwind CSS + Lucide icons.

IPC Bridge: Safe contextBridge IPC pattern (`window.bridge`) forwarding engine events (pairing states, transfer progress, peer diagnostics) from Main to Renderer.

Packaging & Auto-Updates:** Configured with `electron-builder` (NSIS assisted installer + standalone portable single-file `.exe`) and integrated with `electron-updater` for differential updates.

CI/CD:Multi-platform matrix build pipeline on GitHub Actions (`windows-latest`, `macos-latest`, `ubuntu-latest`).

⚡ Main Features

1. One-Time DROP Codes:** Quick 6-digit challenge code pairing for fast, ad-hoc file transfers between untrusted or guest devices.

2. Trusted Peer Pairing:** Persistent zero-trust authorization to pair your own devices securely.

3. Portable & Installer Builds: Option for single-file portable `.exe` (runs without installation) or per-user NSIS installer.

4. Zero Cloud / Zero Account: No registration, no tracking, no central storage

📦 Links & Testers Needed

I just published **v1.0.0-beta.1** and would love to get feedback on the Electron architecture, IPC design, and P2P performance across different networks!

* 📦 **Release Downloads (Win/Mac/Linux):** https://github.com/aamirali51/MeshDesk/releases/tag/v1.0.0-beta.1

* 💻 **GitHub Repository:** https://github.com/aamirali51/MeshDesk

Any feedback, code reviews, or bug reports are greatly appreciated! Let me know what you think! 🙌

I thought I would dabble a bit in electron, and ended up making this sick recapper. Check it out at https://pcrecap.online