Comparison with Vite

Vantris shares Vite's mental model on purpose — the index.html entry, the transform-don't-bundle dev server, import.meta.hot, import.meta.env, optimizeDeps, and a Rollup-shaped plugin API. This page is an honest, side-by-side comparison so you can decide what fits.

If you're actively porting a project, see the step-by-step Migrating from Vite guide.

At a glance

	Vantris	Vite
Dev command	vantris dev	vite
Build / preview	vantris build / preview	vite build / preview
Entry	index.html	index.html
Dev transform	esbuild, per module	esbuild, per module
Prod bundler	Rolldown (internal)	Rollup / Rolldown
HMR API	import.meta.hot	import.meta.hot
Env	import.meta.env, VANTRIS_	import.meta.env, VITE_
Client types	vantris/client	vite/client
Plugins	by string, definePlugin	imported factories
Engine escape hatch	none (Vantris-owned options)	rollupOptions, esbuild, …
Runtimes	Node.js and Bun (one bootstrap)	Node.js (Bun community)
Framework scope	React + vanilla JS/TS	broad (Vue, Svelte, Solid, …)

Where they're the same

If you know Vite, these carry over unchanged:

• index.html-first dev and build, with multiple <script type="module"> entries.
• Transform, don't bundle in dev — instant startup regardless of app size.
• import.meta.hot — same accept/dispose/prune/invalidate/decline/ data and on/off/send shape. See HMR API.
• import.meta.env — MODE/DEV/PROD/BASE_URL built-ins; a prefix guard keeps unprefixed secrets out of the bundle.
• optimizeDeps.include / exclude — same semantics, same on-demand default.
• resolve.alias — plus a tsconfig paths fallback.
• CSS — CSS Modules (*.module.css), Sass/Less as optional deps, PostCSS via a config file, code splitting.
• public/ served verbatim; imported assets hashed.
• DevTools ignore-listing of pre-bundled deps.

Where Vantris differs

The engines are never exposed

Vite lets you reach the underlying tools — build.rollupOptions, esbuild, css.postcss object config. Vantris does not. There's no rolldownOptions escape hatch; every option is Vantris-owned and Vantris-typed. The trade-off:

• You lose the ability to configure Rolldown directly.
• You gain a config that's a stable contract — an internal engine could be swapped without touching your config — and a smaller, fully-typed surface. The common needs (output naming, minify, sourcemaps) are first-class options; anything more bespoke is a plugin.

Plugins are referenced by string

Vite imports and calls plugin factories in an array. Vantris lists strings:

// Vite
import react from "@vitejs/plugin-react";
export default defineConfig({ plugins: [react()] });

// Vantris
export default defineConfig({ plugins: ["@vantris/react"] });

To pass options, you wrap the plugin in a local module and reference that file — see @vantris/react → With options. The hook set and this context are Rollup/Vite-shaped but Vantris-typed.

Host/port live in dev, networking in server

Vite puts port, proxy, https, cors all under server. Vantris splits them: host/port in dev, the networking layer in server. See Networking.

Node and Bun through one bootstrap

Vantris's dev and preview servers are native — node:http or Bun.serve, selected at runtime through the same createDevServer(). There's no ws/h3 dependency; the WebSocket is a hand-rolled RFC 6455 implementation. Behaviour is verified identical on both runtimes.

Where Vite is ahead

Being honest about scope:

• Framework breadth. Vite has a mature plugin ecosystem — Vue SFCs, Svelte, SolidJS, and many more. Vantris targets React and vanilla JS/TS; @vantris/react is the first official plugin, and the plugin API is in place for others.
• Ecosystem maturity. Vite is battle-tested across huge projects with years of community plugins and integrations. Vantris is younger.
• Escape hatches. If your build genuinely needs raw rollupOptions, Vite gives you that today; Vantris asks you to model it as a plugin (or file a request for a first-class option).

When to pick Vantris

• You build React or vanilla JS/TS apps or libraries and want a small, fully-typed config with no engine leakage.
• You run on Bun, or want the option to, with identical behaviour to Node.
• You value a stable config contract over maximal configurability.

When to pick Vite

• You need a non-React framework plugin (Vue, Svelte, Solid, …) today.
• You depend on raw rollupOptions/esbuild configuration.
• You want the broadest, most mature plugin ecosystem.

Either way, the concepts transfer both directions — the migration guide works as a phrasebook.