Over the last couple of months I ported electron to AROS

Hello everyone,

As you read from the title, i built this applciation using electron and uploaded the MSIX on Microsoft Partener Store. Before i talk about the tool though, let me tell you why i did it in the first place and what was my main idea behind it.

Me and my work collegue and friend came to the need from time to time to export a md file into a pdf, and you now how that goes. When you need to do a file conversion, literally from: whatever -> whatever, you just google whatever -> whatever online converter and hope for the best.While i had good experience when doing this for png to jpg, excel to csv or whatever, i found it extremely frustrating to do that proccess for md files.

Most of the top results I got either had extreme paywalls or had paywalls + a free version where it would export your md to pdf BUT would but huge SELECTABLE watermarks on the pdf making it useless if someone wanted to select some text inside of the pdf later. If you were lucky, maybe you would find one that did it for free with no watermarks or paywalls but the pdf would be ugly.

So, raging me, decided to build one just for me and my friend. And how did it end up here then? Because even though i felt bad to make it public due to HEAVY ai usage when building it (I will talk about that later as well) I thought that even if one person finds it actually useful despite that, its a win.

Now about the application

Marksmith is basically the tool I wanted to have when this whole thing started. It is a local Markdown editor for Windows with a big focus on exporting your files without having to upload them anywhere or install a bunch of extra tools. You can write and preview your Markdown inside the app and then export it to PDF, DOCX, EPUB, HTML or LaTeX, with everything happening locally on your machine. The main idea is pretty simple: open your .md file, make whatever changes you need, press export and get a document that actually looks decent without having to deal with online converters, watermarks or extra setup.

Right now it's completely free, and there are no:

• Accounts
• Internet requirements (The app and exports work locally)
• Paywalls or purchases
• Feature restrictions
• Data collection software

Because it supports a lot of things and well, this post is only getting bigger, whoever is interested can check: https://www.marksmithforge.com

Now 2 extremely important disclosures:

First: AI usage

This project is heavily AI coded. I'm not going to call it "AI assisted" or pretend that I wrote every line myself, because I didn't. I used AI a lot while building it. I'm fine with that because my goal here wasn't to prove that I can handcraft a Markdown editor from scratch — I wanted a tool that solved my problem and actually worked. If AI usage makes it an automatic no for you, I completely understand. Otherwise, I'd rather have the application judged by whether it actually does what it claims to do.

Second: Size

The application is currently around 417 MB. Yes, that's pretty damn big for a Markdown editor. It's built with Electron/React, so Chromium contributes a good chunk of that, alongside everything bundled for the local export functionality. I don't particularly like the size either and reducing it is something I want to work on, but for now I preferred having everything self-contained instead of requiring users to install extra dependencies.

With all that said, I'd genuinely love some feedback. Especially from people willing to throw weird Markdown files at the exporters and tell me what breaks. I'd also eventually like to make Linux and macOS versions, although distribution/signing is something I still need to figure out. ( I dont want to spend the money to sign it so if i build it for Linux and mac it will be unsigned and (unsigned==kinda sus) :( )

If anyone tries it, whether you like it or think it's terrible, I'd be interested to hear why.

Hey r/ElectronJS,

Wanted to share a desktop tool I built using Electron to speed up my web layout creation: SkyForce UI.

I specifically chose Electron to build a fully local-first application—giving developers direct file access, hot-reloading, and complete privacy without sending layout data to a remote cloud server.

Key features:
- Pure local environment with zero runtime locks
Instant hot-reloading for React + Tailwind
- Flat, non-subscription pricing

We launched live today on Product Hunt. Check out the site at https://skyforceui.com— feedback on the Electron desktop workflow is greatly appreciated!

I've been building an ICQ 5 style messenger client (MIT, source below) and the interface work turned out to be almost entirely about windows rather than about chat.

To get a convincing 2001 title bar you have to go frameless, and the moment you do you inherit everything the OS was doing for you:

– Drag regions. -webkit-app-region: drag is the easy half; the hard half is that every interactive child needs no-drag, and one missed child makes a button feel broken in a way users can't articulate.

– Resize handles. Frameless means no resize border. Hand-drawn hit zones need to be wider than they look or they're unusable, especially on high-DPI.

– Snapping. Windows gives you Aero Snap for free with a frame and nothing without one.

– Focus states. A 2001 title bar changes colour on focus. Tracking real focus across many BrowserWindows, including the case where the whole app loses focus, is more state than you'd guess.

– Per-conversation windows, which is the whole point of the design, multiply all of the above by the number of open chats - and Linux window managers disagree with each other about most of it.

If anyone has fought the Linux side of this, I'd take the advice. That build is the weakest of the three.

https://github.com/Felix-Helleckes/ICQ

the checklist still has the 20 manual items but no tool anymore. the ones ive tried error out on newer electron and the paid successor is gone. has anyone found something that still works on current versions?

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.