Framework Benchmarks

Manic is purpose-built for maximum performance. These benchmarks compare Manic against leading React frameworks using identical test cases.

Test Environment

Frameworks Tested

Dev Server Startup Time

Time from running dev command to server ready.

Why Manic is Faster

Documented development responsibilities for Vite 7.x and Next.js 16.x below follow the wording on the cited pages. Diagrams show a conceptual order where docs imply sequencing (for example Vite’s first-run pre-bundle before loading the site locally); they are not meant as byte-accurate timelines—internals can overlap or repeat work.

Sources (fact-check):

• Vite (pin to 7.x for this page) — The frameworks table benchmarks Vite 7.x. Dependency pre-bundling for Vite 7 is documented as esbuild and development-only: Dependency pre-bundling (Vite 7). The same page notes that after the server has started, newly discovered dependency imports can trigger another pre-bundle pass. Current docs for the latest Vite line describe dependency optimization with Rolldown instead (Dependency pre-bundling); do not mix those claims when verifying versions. Split dev model (pre-bundle deps vs native ESM for sources): Why Vite.
• Next.js + Turbopack — Default bundler, unified graph, bundling in dev, lazy compilation driven by dev-server requests, incremental parallelism: Turbopack API reference — Why Turbopack?. SWC for JS/TS: same page language-features table (JavaScript & TypeScript — Uses SWC under the hood). Webpack loaders via turbopack.rules and loader-runner: next.config — turbopack.
• Webpack fallback — next dev --webpack / next build --webpack when you need webpack (Turbopack API reference — Supported platforms).

Manic starts faster because:

1. Bun's native serve — The dev server is Bun.serve, not a Node script bootstrapping a bundler daemon.
2. OXC end-to-end — JSX/TS stripping, lint, format, and minify share one Rust parser and AST (oxc-transform, oxlint, oxc-minify). There is no chain of separate tools round-tripping text between processes.
3. Minimal runtime — No webpack, Vite, or Turbopack process to initialize before your app runs.

Why Turbopack can still carry webpack-era cost. Next’s Turbopack documents a turbopack.rules surface for webpack loaders executed through a subset of the webpack loader API (next.config turbopack). Real apps often depend on loaders, aliases, or fallback to next dev --webpack, all of which keep the overall dev path heavier than a Bun-and-OXC SPA that never emulates webpack.

Why Bun + OXC stays fast. Manic keeps the critical path narrow: Bun owns HTTP and Bun.build owns graphs and hashing; oxc-transform plugs in as the JSX/TS compiler. Production minification runs through oxc-minify in parallel over outputs. Fewer processes, fewer serialized handoffs, and no emulation layer for webpack loaders—so cold dev startup and builds skew lighter than stacks juggling Node entrypoints plus a compatibility-oriented bundler.

Production Build Time

Time for complete production build.

Build Breakdown (Manic)

Production parallelism (Manic). Bundling runs mostly in order: oxlint → route manifest → Bun.build client → each API route (Bun.build per entry, sequentially in the CLI) → Bun.build server. Then Promise.all runs oxc-minify over dist/client, dist/api (if present), and server.js at the same time — and inside each folder, .js files are minified concurrently (packages/manic/src/cli/commands/build.ts).

The actual bundling is ~300ms. The rest is process startup overhead that scales poorly with more code in other frameworks.

Build Output Size

Size of production build directory.

Output Composition (Manic)

Approximate layout after manic build (exact chunk names are hashed):

Typical sizes from this benchmark run: client bundle ~1.99MB (before CDN gzip), API + server.js add the remainder of the .manic/ total (~2.5MB unminified in the table above).

Dependencies

Why Fewer Dependencies

Manic uses Bun's native APIs instead of external packages:

Summary Comparison

When to Choose Manic

Choose Manic when:

• Maximum DX speed is critical
• Bun runtime is acceptable
• Client-side SPA (no SSR needed)
• Full-stack with Hono API routes

Choose Next.js when:

• SSR is required
• Largest ecosystem needed
• Enterprise support needed

Choose Astro when:

• Content-focused static site
• Minimal JavaScript output

Choose Vite when:

• Quick prototyping
• Simple React SPA

Running Benchmarks

# Navigate to testbench
cd testbench

# Dev server startup
bun run dev    # Watch for "Ready in Xms"

# Build benchmarks  
time bun run build

# Check output sizes
du -sh .manic

Notes

• Timings are averages across multiple runs
• Results may vary ±10-20%
• Cold starts vs warm starts differ
• Network doesn't affect local benchmarks