Pre-alpha · Linux x64 only
Write an app in HTML, CSS and TypeScript. Ship a native executable. No browser included.
Blitsen hosts a JavaScript engine directly and pairs it with Blitz's native HTML/CSS renderer. It does not embed Chromium, and it does not use the operating system's WebView.
npm install -D blitsenA dev dependency that acts as a native export toolchain. Your project's shape, bundler and framework are not prescribed.
npx blitsen . # open index.html in a native window
npx blitsen http://localhost:5173 # point at a running dev server
npx blitsen doctor dist # check output against the compatibility profile
npx blitsen build # one executable: runtime + application
With no directory, running and building both read the blitsen config in
package.json, run the configured build command and take its output
directory. --target builds for another platform, fetching and caching
its runtime.
Blitsen is not a browser and does not aspire to be one. Three consequences, none of them accidental.
That is the trade: a renderer you ship and control, at a size that is not absurd, against specification coverage. An application targeting Blitsen is authored against Blitsen, not ported blind from the web.
An application is trusted native software, not an untrusted document. No same-origin policy, no permission prompts.
Rendering arbitrary pages you did not write is a browser engine's job. Use one for that.
The property does not exist, so feature detection works. Never a stub that resolves to nothing, never a silent no-op.
That is enforced rather than reviewed. The API manifest is parsed out of the
runtime source, and a test asserts every API the manifest calls absent is
genuinely undefined against a real bridge context. The
compatibility profile is generated from
the runtime rather than hand-maintained, and blitsen doctor reports
what a bundle uses that the runtime lacks before you hit it at runtime.
Every size figure in this project comes from a measured build. The tracked baseline lives in the repository and CI fails on growth beyond 2%.
| Runtime | Disk | Idle CPU | Idle memory (PSS) |
|---|---|---|---|
| Electron | 339.4 MB | 0.2% | 284.3 MB |
| Tauri | 4.7 MB | <0.1% | 191.9 MB |
| Blitsen | 38.8 MB | 0.1% | 101.0 MB |
Medians of five runs after a five-second warm-up. CPU is the whole process tree over ten seconds, where 100% is one core; disk is the packaged app's apparent size. Tauri's figures include its host and WebKit processes, and its disk figure excludes the system WebKitGTK it uses. Electron ships Chromium; Blitsen ships its renderer and JavaScript engine.
create-vite templates — rendered from their own unmodified
vite build output. All six failed when first measured.
M3b evidence →
examples/hardware is a CPU-Z-shaped report on the machine it is running
on: processor and per-thread load, memory and swap, every mounted volume, kernel
and boot time.
None of it has a web spelling — the closest the platform comes is
navigator.hardwareConcurrency, one deliberately coarsened number. It is
read through blitsen/os,
and it is three files with no build step.
Generated from the markdown in the repository, so it cannot drift from the source.
What Blitsen is meant to be, and how it is built.
Blitsen renders less of the web than a browser does. This is where that line is drawn.
Getting an application in, and an executable out.
Milestones are declared on measurements. These are the measurements.