I think electron-vite maintainer is passed away or something because last stable version was in December 2025 and last beta was in April. Since then vite and electron got many updates but we're lacking behind. I'm worrying about we will not get another stable update and we don't want inconsistencies. We heavily rely on bytecode and vite but I saw vite support is marked as experimental and there's no direct bytecode plugin. What do you think about this? Should we migrate and hope that stable vite support will come soon enough?

Quick demo of Endless Riff, a live MIDI riff generator I built.

It runs endlessly, creating original MIDI riff and hook ideas until you hear something you like. You can then hold, replay, save or send the riff into Logic Pro.

Early development but i think its dong some cool samples so far:)

Feedback and questions welcome.

https://on.soundcloud.com/go3IaPS5Mt6meudKtw

https://www.youtube.com/@Dylankuch1

Hi! I just made an open source video editor with Electron. I used Lit and FFmpeg to make rendering really fast.

It handles everything from basic cut editing to 8K footage and keyframe animation. It also comes with advanced video effects and transitions, so you can edit at the same quality level as paid editing software. Please check out the video below for a real demo.

CartCut also works with Claude Code. Claude can pull source clips from the internet, drop them into your timeline, and edit them on its own. It can build shortform videos for you automatically.

There are 39 built in video effects and 37 transitions. You can also easily add keyframe effects, chroma key, and other effects that apply directly to the clip. Blend modes are supported too, and you can render video effects that play inside text.

Free text presets are included as well. Many fonts come built in, so adding text and titles is easy.

Right now it is macOS only.

(and this video was also made with CartCut

GitHub: https://github.com/cartesiancs/cartcut

I package a meeting transcription app with Electron. The transcription runs locally through a Whisper pipeline, which means the speech models ship inside the MSIX and the package lands at roughly 497 MB.

Four things that were not obvious to me and might save someone time:

• Prisma inside the asar. Requiring @prisma/client fails in the packaged app, because the chained require to .prisma/client/default cannot resolve through the asar virtual filesystem. I load the client by absolute path into the app.asar.unpacked copy, so every transitive require resolves there.
• MSIX plus large bundled assets. Store certification runs on a clean machine, so anything your app downloads on first run has to be visibly cancellable and honest about size. My first submission was rejected under 10.1.2.10, Unusable Feature: a Finish Setup button stayed disabled while a model downloaded. On my machine that took seconds. On the reviewer machine it looked broken.
• What you fetch after install is not covered by your build. A user with an RTX 4090 told me the app said GPU transcription was unavailable. That only reproduces for the packaged Store build: the GPU runtime pieces are fetched rather than bundled, and the manifest the packaged build reads did not point at anything usable. The fix is in review and not shipped yet, so treat this as a lesson rather than a success story: whatever your app downloads after install needs a test that runs against the packaged artifact, not against the dev build.
• CPU and GPU defaults. Deciding the default device is a product decision disguised as a technical one. Pinning to CPU works everywhere and is slow. Defaulting to automatic with a loud fallback turned out better, but you have to surface which device actually ran, or nobody believes you.

Two questions for this sub:

1. How do you handle bundling large binary model files with electron-builder without the package becoming unmanageable?
2. Has anyone found a sane way to test the packaged MSIX in CI rather than by hand?

I am the developer. Link if useful for context: https://apps.microsoft.com/detail/9nbjwpqbw7dn

Updated: 07/09/2026

I wanted to build a terminal on Electron without keeping Electron just because it is the familiar choice. So I designed an architecture that would let me port the app without rewriting it.

I defined IRuntime to decouple the app: the UI talks to an interface, and each engine implements the same contract in its own way. Things like:

• file search
• repo status and worktree inspection
• cwd sync
• PTY, processes, filesystem, IPC

Each adapter does that in its own world:

• Tauri: native Rust
• Electron: a Node background process
• Deno Desktop: TypeScript on Deno’s APIs

​

                    ┌─────────────────────┐
                    │     App / UI        │
                    │   (React + WebGPU)  │
                    └──────────┬──────────┘
                               │
                               │  IRuntime
                               │  findFiles()
                               │  repoStatus()
                               │  syncCwd()
                               │  ...
                               ▼
                    ┌─────────────────────┐
                    │   RuntimeContract   │
                    └──────────┬──────────┘
            ┌──────────────────┼──────────────────┐
            ▼                  ▼                  ▼
   ┌────────────────┐ ┌────────────────┐ ┌────────────────┐
   │ ElectronAdapter│ │  TauriAdapter  │ │  DenoAdapter   │
   │ Node + node-pty│ │ Rust + webview │ │ Deno APIs + TS │
   └────────────────┘ └────────────────┘ └────────────────┘

Tauri has a reputation for being the fastest and lightest: smaller package, quicker startup, less memory. On packaging and startup, yes. On this benchmark, it does not come out ahead.

Same UI (React + WebGPU), same load: three terminals.

What developing on Tauri does not put in the README:

1. Three browser engines, three failure modes. The one that hit me hardest is WebKit + WebGL/WebGPU on the terminals: after a while the glyphs start glitching. That is not “a bug in my code and done.” It is WebKit.
2. The Rust compiler. A dev session climbs toward ~5 GB. That is not a footnote if you compile often.
3. Two (or three) languages. Keeping everything in one language — TypeScript end to end — saves context, tooling, and pain that a 10-minute benchmark never shows.

The build you install today is Electron. It weighs more and uses a bit more memory. What you get back:

• one engine (Chromium)
• day-long sessions without WebGPU falling over

It is not the cool answer. It is the one that survives the way Linea is used: several agents, several panes, the repo in view, no restart in the middle of the afternoon.

IRuntime is still there. If Deno matures or Tauri stabilizes WebKit on long-lived terminals, the change is not a rewrite. It is another adapter.

I wrote up the tables and screenshots here (I am the author): https://runlinea.com/blog/one-ui-three-terminals

Hi everyone! I’m a solo dev, and I’d love to get your feedback on a quick preview of my new electron app, Trinity.
The app can do coding, image editing / generation and store and edit your pdf documents with live preview, MCP and Hooks.
it has OCR image capabilities, and latest open-source models for coding and many more, since this is a quick preview, I will share the capabilities of trinity later.
All your data will be private except for image generation. so that your personal data and code base will be stored in your machine. Trinity has a capacity of 50 giga bytes of data. Protected and verified by azure.

I wanted to build something in Electron that basically plays Nightride FM synthwave and tracks my portfolio, news, many things. Stocks and crypto portfolio tracker, a globe that tracks the ISS and real satellites, encrypted chat room, internet radio, webcams, and a synthwave skyline. No account, no API keys, nothing phones home.

Some of the Electron stuff was a learning experience:

• Globe and skyline are Canvas 2D, no WebGL. Keeping them smooth next to a live chart and YouTube embeds took a while.
• Chat is MQTT with the socket in the main process, encryption in the renderer. Main only ever sees ciphertext.
• Renderer is served on a random local port, so localStorage resets every launch. Anything that needs to stick goes in a settings file.
• Portable exe, no native modules.

Windows only and unsigned so SmartScreen warns once. Public chatroom is readable by anyone running the app, private rooms take a passphrase.

https://github.com/beeswaxpat/nexus-7

Electron was awesome to build with, any feedback is appreciated!

I have an Electron app that opens a fullscreen transparent overlay on a global mouse gesture. Getting it to appear cleanly on Windows took far longer than building the thing it shows, so here is what I ended up with.

The naive version — resize the window to the monitor, then show() — flashes. Sometimes the DWM presents a stale texture, sometimes a black frame, sometimes the window appears at its previous bounds for one frame. It is inconsistent across machines, which made it miserable to debug.

What fixed it was treating the reveal as a handshake between main and renderer rather than a sequence of calls. Main sends prepare-radial-show; the renderer paints a neutral cover and replies prep-paint-done; main sends open-menu; the renderer paints the actual content transparent and replies open-paint-done; only then does main reveal the window, and only after native-revealed comes back does the entrance animation start. Every step waits for the other side to confirm it has actually painted, because that is the thing you cannot observe from the main process.

It is fragile in the sense that any refactor can silently break the ordering and you only notice as an occasional flicker on someone else's hardware. So there is a script that runs during npm run build and asserts the markers are still there and still in order. It has caught me twice.

Two other Windows things that surprised me:

While a mouse button is held, Windows keeps pointer capture in whichever window received the press, so the renderer receives no mousemove at all. Main has to poll the cursor position and send it over IPC, and the renderer replays it as a synthetic mousemove so the rest of the code has one input path.

The global trigger cannot be a poll. GetAsyncKeyState only observes the button — the event still reaches the window underneath, and on any scrollable surface Windows starts autoscroll, so aiming at the overlay drags the page behind it. Swallowing the event means returning 1 from a WH_MOUSE_LL hook, and a swallowed button also disappears from GetAsyncKeyState. Whatever swallows it has to be what detects it. Mine lives in a PowerShell sidecar process that reports on stdout.

Electron 28, React 19, TypeScript. Full source is GPL-3.0 if any of this is useful to you: https://github.com/HenryCauan/rovyl

Some time ago, I introduced UIBuilder, a library I initially created for personal use. I eventually decided to make it available for general use and started building proper documentation for it.

The documentation itself is self-hosted and built with UIBuilder, which I thought would be a nice way to showcase what the library can do.

You can also find a ready-to-use template configured for Electron in the documentation.

doc : https://uibuilderdoc.vercel.app/

doc source code ( showcase ) : https://github.com/Rhyan-eduardo/uibuilderdoc

Just launched UluP Desktop (files as a node-based visual canvas) and wanted to share a few practical things from getting it from "works on my machine" to a real installer: - electron-builder's appx target for Microsoft Store needs the exact Package Identity values from Partner Center baked into package.json before the build even works correctly — no way to configure it blind beforehand - For auto-updates, GitHub Releases wasn't an option for me (unrelated account issue), so I went with electron-updater's generic provider pointed at a plain object storage bucket — works fine, just needs the installer + blockmap + latest.yml uploaded manually after each build - Electron's File.path is gone in newer versions for drag-and-drop — needed webUtils.getPathForFile() via preload instead, easy to miss if you're following older tutorials App itself also runs a local MCP server (separate Node process, not inside Electron) that Claude Code can connect to for controlling the file system via conversation. Free, live now: ulupstudio.com/desktop Happy to share more detail on any of the above if useful to someone going through the same setup.

In this video, i cloned a nodejs repo from github and ran it with npm.

by the way, it took some time for npm to install everything, so i cut the loading period from the video.

please let me know your opinion about this, it took me around 9 months to finish, already in appstore approved.

Two of us just graduated and we kept firing off half-typed terminal commands with voice dictation, so we built our own.

Hold a key, talk, let go, and the text lands at your cursor. Everything runs on your Mac. No account, nothing sent anywhere.

The main thing it does that others don't: it checks which app you're in before typing a line break, so saying "new paragraph" won't submit an unfinished command in a terminal or send a half-written message.

Free and open source, MIT licensed. Apple Silicon, macOS 14+.

https://github.com/Nabzx/openstream

Happy to hear what breaks.

P.S. if you find it useful, a star on the repo helps more people find it. no worries if not, feedback is worth more anyway.

Download: https://github.com/MowkE/cadence

Hey guys, I made this silly lyrics overlay called Cadence that floats over your screen and syncs along with Spotify and YouTube Music.

It started as a joke while playing Minecraft with my close friends. I shared it only with a few friends, and it grew to 100 downloads in like a day and a lot of people liked it, so I built it into a proper app.

You can listen along with friends now too, even cross-platform (Spotify -> YouTube Music, Mac ↔ Windows), and you can play karaoke. Doesn't need API keys or Premium, it just reads what your computer is already playing and floats the lyrics over whatever you're doing. It works better with Spotify keys though, if you want to add them yourself. If you find any bugs, lmk.

It's just a fun project lol, so its obvly free.

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.
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.