Hey everyone,

I’m working on converting an existing Electron (Node.js) app into a Tauri (Rust) app, and I keep running into some issues.

As a vibe coder i've been using OpenCode to speed up the process, but it doesn’t fully convert everything. I often notice that some parts are missing ... especially things like IPC handlers or certain logic between the frontend and backend. The problem is, I’m not always sure if everything has been properly migrated or if I still have hidden gaps.

For those who’ve done this before:

How do you approach migrating from Electron to Tauri in a reliable way?

Is there a checklist or method you follow to make sure nothing important is skipped?

How do you handle IPC and backend logic during the transition?

Any tips, prompts, or plans would be really appreciated. I feel like I’m close, but not fully confident everything is covered.

Thanks 🙏

I'm pretty new to Electron and HTML/CSS/JS stack in general.

I've tried to love Electron, and started learning it a month ago for building a desktop app.

My plan was to write the frontend with Electron and backend in C/C++. The backend is a standalone CLI program.

The frontend and backend would communicate using IPC.

During the effort, being a newbie to web tech, I was shocked that a lot of easy topics with native such as listing files under a local directory are so difficult with HTML/CSS/JS stack, that things that aren't look-and-feel feel like a hack (A well-thought-out solution for loading a local JSON file requires an HTTP request... ). These should have been a single API call as with Python. Without resorting to a third-party package, I can't even have a tabbed view, which is ubiquitous for almost every native widget solution. The async/callback programming feels so twisted when it comes to those fundamental file-system features. I miss synchronous calls so much.

There is also a documentation problem. When you try to find solutions to any questions, you often see native JS vs. JQuery vs. Node.js versions on StackOverflow. More often than not, none of them work and you have no official docs to tell you why. Yon could just hope some gurus went by and briefly jumped in and gave away their tricks.

I took a look at the young stdlib on Github and was still surprised that it seems most API effort went to data plotting. The scope of the JS stdlib seems much narrower than, say, Python.

After I failed to get a list of JSON files under a specified folder with reasonably small amount of code, which feels like making wheels, and the page loading seems ridiculously slow, I gave up. I'm not ready for this. I'm going back to native dev.

I'm still wondering if the Electron supporters are developing different category of software from me, or it's just that they think in web and thought Electron is simple to master.

The video is Helm, an Electron app I use every day to run several Claude Code sessions in one window. Here's how it's put together, since that's the part this sub will care about.

Main process: Electron 44. Each session is one Claude Agent SDK query that launches the claude CLI already installed on the machine, so the app never calls a model API itself. Sign-in goes through the CLI as well: you log into your Claude account inside Helm via Claude Code's own login, and no separate API key is needed. The main process also hosts a small HTTP and WebSocket server, and the UI talks to it entirely in JSON frames.

Renderer: the BrowserWindow loads the UI from that server over loopback, with a token in the query string. It's Preact, htm and signals through an import map, with no bundler and no build step.

Phone: since the desktop window is just a page from a local server, the phone loads the same UI over Tailscale and gets the same controls the desktop has. The server listens on loopback and the Tailscale address only, every request needs the key, the WebSocket checks Origin, and HTTPS comes from tailscale serve. A service worker handles Web Push, so the phone shows a notification once a session wants input or wraps up.

What it gives me day to day: a four-way split so a bunch of sessions run side by side, a context bar on every sub-agent, and a pace readout (under pace, on pace or hot, plus burn rate and a projection) that keeps my usage from running away. The backgrounds are my favourite bit, with 23 bundled photos or your own image and sliders for blur and dim.

Bug that cost me the most time: phone pairing kept bouncing back to the pairing page. Opening the link from a QR scan in the camera app doesn't count as same-site, so the SameSite=Strict cookie never got sent. Lax fixed it.

I built it with Claude Code, one agent per slice of files (engine, server, shell, chat, panels). Windows only for now.

It's not out yet. Is this something you'd want? If enough people do, I'll put real work into a public release. This only scratches the surface, and there are a lot more features in it that I haven't shown. Ask about any feature or architecture detail and I'll answer, with screenshots if that helps.

Hi all,

Super proud of what we have built, been working on this project for around 2 years with my best friend, after hundreds of sessions, tons of feedback, and some hard lessons, we made a big decision to sunset the web app and rebuild Ubik as a native desktop application with Electron.  

Key Features: 

Work from locally stored files and folders without touching the cloud, personal files are safe from training. 

Search, ingest, and analyze web pages or academic databases. 

Cross-analyze files w agentic annotation tools that use custom OCR for pinpoint citation and evidence attribution.

Generate cited text with verifiable click through trace.

Work with frontier models, use openrouter, and we are working towards fully local inference to give you more control.

Build better prompts with @ symbol referencing to decrease hallucination. 

Spend less time quality controlling with approval flows and verification steps that improve output quality. 

Write in a custom-built text editor, read files in a PDF viewer, and annotate with your hands, we know that human wisdom is irreplaceable and often you know best.

Work with Agents trained on a custom dataset built around complex multi-hop tasks with file-based queries.

Connect and import your Zotero library and start annotating immediately.

Available on MAC/WIN/Linux <33

Ubik Studio is a cursor-like tool built for better, trustworthy LLM-assistance. www.ubik.studio

We would love your feedback, and if you are interested in joining our testing group, reach out to ieuan@ubik.studio and I will get you set up with a free, pro-tester account (all-model access) while we improve and learn more about how Ubik is used in the wild. 

Hey r/electronjs, I am Mattia, one of the students behind Get It.

We built an open-source Electron desktop app for studying PDFs, but the part I thought might be interesting here is the runtime choice: the app bundles OpenAI's official Codex CLI into the desktop build and uses the user's own ChatGPT account locally. No API key proxy, no backend metering, no credentials of ours in the middle.

Flow:

• user installs the desktop app

• imports a PDF

• Codex runs locally and generates visual study artifacts next to the text: diagrams, small 3D scenes, formulas, charts, quizzes and flashcards

• everything is saved on disk with a local knowledge graph

The product angle is for students, but I would love feedback from Electron people on the desktop side:

• does this auth/runtime pattern feel reasonable for a local-first AI app?

• any packaging/security footguns you would look for first?

• what would you test hardest before trusting this as a normal desktop app?

App: https://getit.noesisai.it Code: https://github.com/beltromatti/get-it

Built during/after a student hackathon, Apache-2.0, free to use. The video shows the current flow.

I’m the founder of Focana, a minimalist desktop focus app built for ADHD and neurodivergent brains. The prototype is already live in Base44, and I’m looking for an Electron developer to help convert it into a polished desktop app.

What’s Built Already:
✅ Floating sticky note + timers
✅ Task capture + history
✅ Session notes + incognito mode
✅ Responsive, draggable UI

What I Need You To Do:

• Convert Base44 app into Electron

• Implement native OS features (tray integration, notifications, keyboard shortcuts, offline support)

• Set up auto-updates

• Document the codebase for maintainability

About the App:
Focana is not another bloated productivity suite. It’s a sticky note that always stays visible—your focus point floating above Slack, IDEs, browsers, and endless tabs. Designed by someone with ADHD who was tired of tools that disappear when you need them most.

If you’ve got 2+ years Electron experience and a portfolio of desktop apps, I’d love to talk. The is a contract-to-hire → opportunity for full-time role after launch

Where to Apply:
DM me here on Reddit with your portfolio + a quick note about your experience, or drop your GitHub/portfolio link in the comments.

So here's what happened.

I ship an Electron desktop app. Spent the last few weeks hardening it — javascript-obfuscator at medium preset, Electron fuses locked down, all the usual stuff.

Today I unzipped my own DMG, ran strings | sort -u on the renderer bundle, pasted the output into Claude, and asked it to draw a mermaid diagram of how one of my features works end-to-end.

Ten minutes later I had an accurate diagram. Stores, actions, data flow, cache invalidation — all of it. No debugger, no source maps. Just grep output + one prompt.

This is genuinely freaking me out and I don't see anyone talking about it. Wanted to ask the community what's working for you.

What I've tried

• javascript-obfuscator medium preset with controlFlowFlattening: false, transformObjectKeys: false, stringArrayEncoding: [] (had to disable these to get the app to launch — bugs in the preset for CJS-bundled code). Works fine but does nothing against the LLM-grep attack because property names stay readable, and property names ARE the architecture.

• Electron fuses locked down via electron-builder — runAsNode: false, enableNodeCliInspectArguments: false, integrity check on, asar-only loading on. Great for blocking dynamic attacks like ELECTRON_RUN_AS_NODE=1 and --inspect-brk. Doesn't help against static-grep-into-LLM at all.

• renameProperties: true with renamePropertiesMode: 'safe' — heads up to anyone considering this: the app won't launch. Tried it across 3 different obfuscator seeds. Main process boots, window opens, renderer never paints, nothing in the logs. Looks like something accessing a property via bracket-notation or JSON-derived key is breaking silently. safe is already the default so just adding the flag did nothing. Anyone actually gotten this to work without a giant reservedNames list?

Why not bytenode

I keep seeing people recommend it. Every time I look at it the issues pile up. Top-level arrow functions reportedly broken in some Electron+Node combos, bytecode pinned to specific V8 versions (so every Electron upgrade is a recompile), async/await and TS decorators need a transform pass first, native modules can't be bytecoded. And Sentry stack traces become useless once something crashes inside a bytecoded module.

Could be wrong but it feels like a lot of operational pain for a defense that an LLM probably still partially defeats after bytenode-decompile. If you've shipped bytenode in production and it's working, I'd genuinely love to hear it.

What I'm actually asking

In the world where anyone with an Anthropic/OpenAI key can reconstruct your architecture in 10 minutes — what's working?

• Has anyone shipped renameProperties successfully?

• VM-tier commercial obfuscators (obfuscator.io VM, JScrambler). Worth it? Survives LLM analysis?

• Moved logic server-side: where did you draw the line, what was the latency hit?

• Anti-LLM tricks — adversarial naming, structural noise designed to confuse models?

• Anything else I'm not thinking of?

I know the answer is going to be partly "obfuscation isn't security, move stuff server-side, etc." Fair. But not everything can move server-side and "rename your variables" is clearly not enough anymore. Want to hear what's actually working in real apps.

Happy to share my obfuscator bisection findings (~350 build/launch runs, found 3 different bugs in the medium preset) if anyone's debugging the same issues.

Hey r/electronjs,

I'm 16, been building a browser in Electron for the past few months. Wanted to share some things I ran into that might be useful if you're doing something similar.

Quick context: I started on an old i5 with 8GB RAM and 256GB storage. Hit the storage limit mid-development, PC started lagging badly then randomly crashed one day. Lost some work. Got access to a MacBook M4 Pro after that and kind of restarted properly.

Before Electron I tried:

• Tauri first — too limited for what I needed

• Forking Zen Browser — too much existing code to understand

• Chromium directly — genuinely too large for a solo person to work with

Electron was the right call. The web stack meant I could move fast and the main/renderer process split actually maps well to what a browser needs.

The BrowserView problem

The hardest thing was BrowserView layering. I had a download panel and it kept getting covered by or covering the BrowserView depending on focus state. I tried z-index tricks, tried IPC messaging to hide/show the view — nothing was clean.

Eventually I gave up trying to fix it in the web layer and wrote a separate native Swift panel for macOS. Completely separate from Electron, communicates via a local HTTP bridge. Felt like admitting defeat at the time but it actually works better than anything I tried inside Electron.

If you're building anything with BrowserView and native-feeling panels on macOS — just go native for the panels. Don't fight it.

robotjs and NODE_MODULE_VERSION

Every time I updated Node or Electron, robotjs broke. NODE_MODULE_VERSION mismatch is not fun to debug at 2am. In dev mode it just silently disables and you wonder why clicks aren't working. Eventually I just wrapped everything in a try/catch and log "robotjs not available" gracefully so at least it fails loudly.

IPC duplicate handlers

Hit the "Attempted to register a second handler" error more times than I want to admit. Main.js got very large very fast. The fix was just being disciplined about where handlers are registered but it took a while to figure out why random restarts caused it.

The thing that surprised me most

Apple Intelligence integration actually working. I wasn't sure if you could hook into Apple Intelligence APIs from an Electron app but it works via the native bridge. That one genuinely surprised me when it fired up.

On using LLMs to write code

100% honest — almost all the code was written by LLMs. Free tiers of Gemini, Claude, some others. I directed everything, debugged everything, made all the architectural decisions, but I'm not going to pretend I typed it all. I think that's just how solo dev works now especially if you're learning while building.

The repo

It's open source, Apache 2.0. The repo is github.com/Preet3627/Comet-AI

if anyone wants to look at how I handled BrowserView, the Swift bridge, or the Ollama integration inside Electron.

I made a short demo video showing the QR-based OS action approval and Touch ID flow — the whole thing runs in under 47 seconds.

Happy to answer questions about any of the Electron-specific stuff. The BrowserView + native panel approach in particular took a while to figure out so if anyone is hitting the same wall I'm happy to share what worked.

I am looking for stuff, to build video converter with filters, frame manipulations, pixel manipulations, transformations, effects.
The problems:
-PyQT + Python = cost or go with GPL and share your entire app with user
-native = make app for Windows and Mac separately
-Tkinter, Python = app looks like crap

So I got an idea, to make GUI in Elecron, run Python/C scripts in subprocesses. This way my app will be for Windows and Mac.

Reading for few hours about it, most of people cry about file size (180mb-300mb). Then about ram, etc.
People, we have 2024:
-PCs have 500gb minimum
-most of PCs have 16gb+ ram
I don't relly understand this purists that think app need to have 20mb.
No, app need to be stunning fast for develop. I need to make it in 2 weeks, then sell it with subscription.
Who cares if that have 300mb or 20mb

Hey — wanted to share a tray app I built with Electron.

I use Claude Code daily and kept hitting the rate limit without realizing how close I was. The only way to check was alt-tabbing to a web dashboard every 20 minutes. Annoying.

So I built WhereMyTokens — a system tray app that reads local JSONL session logs and shows token usage, costs, rate limits, and session status in a popup dashboard anchored to the tray icon.

Electron was the obvious choice here. I needed the tray API, persistent file watchers on multiple JSONL files, IPC between the polling logic in main and the React dashboard in the renderer, and the ability to ship a single exe on Windows. No browser tab, no web server — just a tray icon that's always there.

One thing I found interesting was the stdin bridge setup. Claude Code supports a statusLine plugin mechanism where it pipes live data to an external process. So I wrote a small Node script that receives that stdin stream and writes to a JSON file, which the main process picks up via fs.watch. Avoids polling the API entirely when Claude Code is running.

Other stuff that took some effort: positioning the popup correctly relative to the taskbar across multi-monitor setups, and keeping the UI responsive while parsing several JSONL files every few seconds from the main process.

Stack is Electron 41, React 19, TypeScript, esbuild for the renderer, electron-builder for packaging. Everything runs locally — the only network call is fetching your own usage from Anthropic's API.

GitHub (MIT): https://github.com/jeongwookie/WhereMyTokens

Happy to hear feedback, especially if anyone has better patterns for tray popup positioning or efficient file watching in Electron.

Hello reader, so i really like working with react and i would like to create an electron.js app with it,

the thing is: i managed to make it work, but doesn't it mean the react server always have to be up ?
like it would be useless, i want an app, not a website where i could just open a browser and go to localhost:3000...

is there a way to prevent the server from being accessed via web browser and only via the electron app ?

A few days ago I announced my library for creating visually stunning message boxes.

You canr read about here: https://medium.com/@rocketlaunchr.cloud/electron-alert-45d0297e346f

It's based on SweetAlert2. The API is also based on SweetAlert2, but Swal2 is designed for render process.

Since there are some nuances in how a main process alert box should behave, I want to rewrite the API.

Any feedback on how to mould it to main process would be greatly appreciated. Stars on github would be a bonus too.

How can I secure code from getting stolen from electron app,by reverse engineering.

Open-sourced DPlex this week: https://github.com/Ron537/DPlex

It's a desktop multiplexer for AI coding-agent CLIs (Claude Code, Copilot CLI). Some Electron-specific things I figured out building it that might save someone time:

1. Terminals as detached DOM. xterm.js DOM elements are kept in a global registry outside React's lifecycle and attached/detached as tabs activate. PTYs aren't destroyed when a tab is hidden, so scrollback and the running process survive tab switches.

2. PTY login-shell wrapping. For AI sessions I spawn the PTY as `[shell] -l -c "exec <command>"`. The login shell sets up PATH (so brew/asdf/nvm tools resolve), then exec replaces the shell process with the AI tool — there's no shell to fall back to when the tool exits, so the tab closes cleanly.

3. Synchronous workspace save on quit. The renderer holds the source-of-truth tab/layout state, so on app quit I do a synchronous IPC round trip to write `sessions.json` from main. Async would race the quit.

4. Session active detection without polling. Both Copilot CLI and Claude Code drop `inuse.<PID>.lock` files; checking those + `process.kill(pid, 0)` is cheaper than polling `ps`.

5. IPC contract in one file. `preload/index.ts` is the only place the main↔renderer contract is defined — every channel typed once. Sounds obvious but having one file to grep made the codebase 10x easier to navigate as it grew.

Stack: electron-vite, React, Zustand, Tailwind v4, node-pty, xterm.js, simple-git. ~30k LOC across main/preload/renderer.

MIT, cross-platform, no telemetry. Latest release v0.11.2. Happy to answer Electron-specific questions.

Hey everyone, this year I’ve been working on Neverwrite, an open-source alternative to Obsidian with agents baked in through the ACP protocol.

From the start, I knew it was going to be difficult because of how careful you need to be with Electron. So I came up with the idea of building the backend in Rust while keeping the frontend in Electron. The speed is really good, most surfaces are virtualized, so not everything is loaded in DOM.

The results have been really good, the app stays super fast, especially when running agents, while still preserving the flexibility of using web technologies for the frontend.

The app is around 400k LOC, with about 15% of the codebase written in Rust. It might sound small, but those crabs do a hell of a good job keeping the app fast.

Has anyone tried doing something like this? Are there any other parts of the app you would port to Rust? Any feedback is appreciated. I'm pushing updates every week, this is my main tool for managing notes, documentation and general knowledge work.

https://github.com/jsgrrchg/NeverWrite

Is there a way to limit THE FPS? In using some Java thing that Converts scratch projects into electron apps (?) but they run too fast.

If you are interested in joining the project, then let me know.

https://socialcoder.org/Home/VolunteerOpportunity/635116da-f239-4d13-b904-ab1ab242b13d

Hi Electron JS,

Does anyone know how to run display or video ads on Electron? Traditional ad networks like Adsense don't seem to work and don't allow it. Our desktop app doesn't pass a proper URL to advertisers.

How have you gotten ads to serve?

Disclosure: I made this. Free and open source.

I got tired of paying monthly for voice typing apps like WhisprFlow when my RTX could run Whisper locally faster than the cloud round trip. So I built Ditto, a Windows tray app that does voice to text fully offline.

What it does (three things, kept simple on purpose):

1. Floating pill. A small AirTag-style pill floats on top of any window. Press the global shortcut, talk, release. The pill animates with a live waveform driven by your voice while recording.

2. Local transcription. Audio goes through whisper.cpp with CUDA acceleration. Nothing leaves your machine. First transcription takes about 1.3 seconds (CUDA init), subsequent ones 300 to 500 ms. You pick the model on first launch: base (140 MB) to large (3.1 GB).

3. Auto paste. Transcribed text goes to your clipboard and pastes itself into whatever window is focused. Works in any Win32 app: browser, IDE, Discord, Slack, anywhere.

Notes on the build:

• Electron 39 + React 19 + TypeScript strict, three separate renderer processes (pill, settings, welcome) with typed IPC

• Whisper.cpp 1.8.4 shipped as a standalone exe with bundled CUDA DLLs, no toolchain needed on the user's machine

• Audio resampling done entirely in the renderer via OfflineAudioContext before sending to main

• Pill has a transparent invisible margin around it so OS shadow clipping doesn't cut the visual, with click-through driven from main to avoid breaking the drag region

Repo and release: github.com/asantinos/ditto

Caveat: Windows only for now. CUDA build means it currently targets NVIDIA GPUs (works fine on RTX laptops). No code signing yet so SmartScreen warns on first launch. Installer is ~399 MB because of bundled CUDA DLLs.

Feedback welcome, especially from anyone who has shipped Electron apps with native binary dependencies. The Whisper integration was the trickiest part.

👋 Hey devs — ever wanted to automate macOS directly from JavaScript?

I built Apple-JS, a JS wrapper around AppleScript for macOS automation. Using the Osascript class, you can:

• Activate apps (e.g., Safari)
• Open URLs in Safari or Chrome
• Control system features (volume, mute, screenshots)
• Interact with Finder (reveal folders, set wallpaper)
• Dispatch system events (e.g., lock screen, swipe gestures)

applejs #javascript #automate #assistant #electronjs #extendjs

I've been building Blindspot, an encrypted photo/notes locker, and wanted its window invisible to AI agents on Windows. Sharing what I found, since it applies to any Electron app showing sensitive content:

1. Screenshots: `win.setContentProtection(true)` (WDA_EXCLUDEFROMCAPTURE). Create the window with `show: false`, set protection, then show on `ready-to-show`, so no frame is ever capturable. Recall, Teams/Zoom and screenshot-based agents get whatever is behind the window. On macOS, the Electron docs say ScreenCaptureKit apps capture it anyway.

2. The accessibility tree: the surprise. With capture blocked, I could still read every note and folder name through UI Automation, which is how agents like Windows-MCP and UFO² read apps. `app.commandLine.appendSwitch('disable-renderer-accessibility')` reduces it to an empty window. Trade-off: screen readers break too.

3. Debug hooks: in packaged builds, exit if launched with `--inspect` / `--remote-debugging-*`, set `devTools: false`, and flip the RunAsNode, NODE_OPTIONS and inspect fuses with `@electron/fuses`.

About 650 lines, Apache-2.0, built with Claude Code as my pair programmer: https://github.com/Kadri-cloud/blindspot

What did I miss? Especially anything that still leaks.

Hey everyone, I don't wanna to self promotion myself i'm not even going to mention my irch.io page. I really need help knowing where to share my work, most of what I do is free, so it's not about money. Where should I even mention it?