Overview of 983: Why I Chose Electron Over Native (And I’d Do It Again)
Wes Bos and Scott Tolinski discuss a desktop screen/video recording app Scott built (vFramer) and the engineering choices behind it. The episode focuses on why Scott chose Electron over native frameworks like Tauri (and newer tools like ElectroBun), the recording pipeline and formats, reliability and distribution considerations (licensing, notarization, CI/CD), and UX/feature decisions he made to solve real-world pain points in recording workflows.
Key topics covered
- The core problem: existing screen/recording apps are either too limited or force you into proprietary editors/formats and slow post-processing.
- Requirements Scott had: multi-source recording (screens/apps/camera/audio), per-source independent files, minimal/no post-processing, fault tolerance (no data loss if the app crashes), good preview UI, and cross-platform potential.
- Technical decisions: using browser getUserMedia for capturing, recording to WebM segments, stitching into MKV, and using Electron as the runtime.
- Why Tauri/ElectroBun weren’t chosen: Safari/OS WebView limitations (missing MediaRecorder screen-selection dialog, lack of retina resolution for screen captures), predictability of a single browser runtime, maturity concerns.
- Packaging, licensing and distribution: handling notarization, Stripe checkout, license generation (self-hosted KeyGen), Cloudflare Workers for webhooks, and app updating via GitHub Actions + Electron Updater.
- UX features: vertical framing preview, multi-source previews, shortcuts, trial mode, FPS locking, light/dark themes and planned UI tweaks.
Main takeaways
- Electron was chosen because of predictability (Chromium-based environment), ecosystem maturity, and abundant docs/plugins (updater, packaging, notarization helpers).
- Using the browser’s getUserMedia simplifies dealing with varied device quirks and offers easy selection of app/window sources — it avoids many native-edge-case bugs.
- Recording pipeline design prioritized fault tolerance: capture to WebM segments written to disk so partial recordings aren’t lost; final output is assembled into MKV with minimal processing (the main processing cost Scott saw was audio handling).
- Native APIs can be powerful, but cross-platform complexity and device-specific edge cases made the web-first approach preferable for Scott’s goals.
- Building and shipping the product required as much effort outside the app logic (licensing, notarization, updates, release CI) as inside it.
Technical details and pipeline
- Capture: getUserMedia in the embedded browser captures video/audio. This lets users pick apps, windows, or screens as sources.
- Format & storage: media is recorded initially as WebM segments (small chunks) and saved continuously to disk; segments are then combined into MKV containers. Audio may be converted to WAV; Scott experimented with MKA but compatibility was poor.
- Fault tolerance: because segments are stored raw, a crash does not lose the recorded data — reprocessing can reconstruct the final files.
- Backend/transcoding: FFmpeg (and related tooling) used server-side/local to assemble and process the final outputs.
- Electron vs Tauri vs ElectroBun:
- Tauri used the system WebView (Safari/WebKit) which initially lacked a MediaRecorder screen-selection dialog; Safari also produced non-retina (blurry) captures.
- ElectroBun is new and offers a hybrid approach, but Scott preferred a mature, predictable stack (Electron/Chromium).
- Electron provided the consistent browser behavior and rich ecosystem Scott needed.
Distribution, licensing and ops
- Licensing flow:
- Stripe checkout used for purchases.
- Stripe webhooks → Cloudflare Worker → self-hosted Keygen (key generation) → email license to buyer.
- The app accepts/pastes the license key to unlock features (trial mode is limited: one video, one audio).
- Hosting:
- Scott self-hosted Keygen (self-hosted version has no UI, required CLI/API interactions).
- He used Coolify/Docker to host servers; experienced latency issues when deployed in a distant region, so spun up local-region instances.
- Notarization and macOS distribution:
- Apple developer account, certificates, and notarization required for smooth macOS launch — Electron has tooling to make many steps straightforward but Apple’s developer UX is time-consuming.
- Updates and CI:
- GitHub Actions build pipeline produces releases, signs/notarizes them, and uploads to an R2 bucket.
- Electron Updater checks the R2 bucket and prompts users about updates; updates can be applied on next relaunch.
UX & features implemented
- Multi-source recording: arbitrary number of video and audio sources (apps, windows, screens, camera).
- Per-source independent files for easy editing in the user's editor of choice — no proprietary wrapper/editor lock-in.
- Live previews (including a vertical crop preview for social/vertical video framing).
- Controls: pause/stop, customizable keyboard shortcuts, FPS lock (e.g., 30 FPS).
- Trial mode and license key entry.
- UI choices: light/dark mode, aesthetic inspired by Teenage Engineering — Scott planned small interface polish items (bitrate controls, icons, contrast improvements).
Known limitations and planned improvements
- Bitrate control: current builds use a set high bitrate; Scott plans to add UI knobs to set bitrate/resolution to control file sizes.
- Audio container compatibility: MKA worked for internal workflows but lacked editor support (e.g., DaVinci).
- Cross-platform native APIs: Scott intentionally avoided deep native platform APIs to reduce cross-platform complexity; this may limit using some hardware-specific features (e.g., direct Bluetooth mic support) unless implemented later.
- Licensing UI for self-hosted Keygen: the self-hosted Keygen lacks a friendly admin UI; paying KeyGen service could simplify that part.
- ElectroBun/Tauri tradeoffs: newer runtimes may become viable later as they mature.
Notable quotes / insights
- “Electron gets a lot of heat… VS Code has shown that an app can be Electron and still be performant.”
- “Safari doesn’t give you the retina resolution of screen recordings” — a key reason for abandoning Tauri on macOS for this app.
- “The browser smooths out a lot of those APIs” — a reason Scott prefers getUserMedia-based capture over many native cam/screen APIs.
Practical recommendations / next steps (for listeners)
- If you want to try the app or join the waitlist: vframer.video (Scott planned to link it in show notes).
- If you build similar tools:
- Consider using browser getUserMedia for multi-source capture to reduce device/API edge-case work.
- Record to a chunked container (WebM segments) to make recordings fault-tolerant.
- Plan for the non-development work early: notarization, licensing, CI/CD, update server.
- For app authors shipping desktop apps: Electron remains a practical, well-documented choice when predictability and documentation are priorities.
Short status / callouts
- The app (vFramer) is close to release; Scott is testing with a few folks before public release.
- Scott is open to feedback on UI/feature tweaks (bitrate knobs, icons, shortcuts, contrast).