Krate
Side by side
| Question | Electron | Krate |
|---|---|---|
| What you ship | A packaged app for each operating system, each carrying its own Chromium and Node.js. | One .krate file for all three, opened by a runtime the user installs once and every Krate app shares. |
| App code | HTML, CSS and JavaScript in Chromium, with Node.js in the main process. | A WebAssembly component that calls Krate's interfaces. Rust today. |
| Builds per OS and CPU | One package per target platform. | One file. The runtime is the only per-platform piece, and Krate builds it. |
| Signing | Sign for Windows and macOS, and notarize for macOS, for each release. | No per-OS signing of the app file. Optional Krate signature with your own key. |
| Default access | Renderers are sandboxed by default since Electron 20. The main process is not sandboxed and has Node.js. | The app starts without file or network access. The person running it grants or refuses each request. |
| Platforms | Windows, macOS and Linux. | macOS, Windows and Linux. iOS and Android exist only as reference ports. |
| Maturity | Established, with a large ecosystem and many well-known apps. | Young (0.5.x), with a small ecosystem. |
Electron facts: process model, process sandboxing, code signing and distribution overview.
What one file changes for shipping
With Electron, each release is a set of platform builds that you sign, notarize and host. With Krate, each release is one new file. People who already have Krate open it straight away; everyone else installs the runtime once first. Because Krate apps share the runtime, a second or third app does not bring another copy of a browser.
Count the same things when you compare size: for a first-time recipient, the runtime plus the app; for everyone after that, the app file alone. The measurements page shows one scoped comparison with MarkText, an Electron editor, and says what it does and doesn't cover.
Who decides what the app can touch
In Electron, the developer decides what the main process exposes to the sandboxed renderers, and the main process itself runs with the user's permissions. That is a sound design for code you wrote, but the person running the app has no say in it.
In Krate, the app lists what it wants in its manifest and the person running it approves or refuses. The runtime checks protected calls against what was allowed. Krate is young: the known gaps are on the limits page, and it does not yet claim hardening against deliberately hostile code.
When to stay with Electron
- You have a web or Node.js codebase and want to keep running it as it is.
- You depend on the DOM, npm packages or Chromium's consistent rendering on every system.
- You need mature auto-update tooling or a large plugin ecosystem.
Moving an Electron app to Krate
Start with a scan. It reads your source without building or running it and lists what maps to Krate and what doesn't:
krate port ./my-electron-app
A port is a rewrite in Rust against the Krate SDK, not a repackage. DOM and Node.js APIs do not carry over. Krate Studio can do the rewrite with AI and shows its plan first. Begin with one representative feature and read the porting guide.
Questions
Is Krate a drop-in replacement for Electron?
No. Electron runs your HTML, CSS and JavaScript as they are. A Krate app is written against Krate's interfaces, in Rust today, so moving an Electron app is a port, not a repackage.
Do Krate users need Chromium?
No. Krate apps don't run in a browser engine. Users install the Krate runtime once, and every Krate app shares it.
Can I keep writing JavaScript?
Not for a shipped Krate app today: Rust is the only finished SDK. Krate Studio can write the Rust for you from a description, or port a JavaScript project by rewriting it.