Versatile Npm-Free Web Stack

Simon Ramstedt, 2026-04-24 · last updated 2026-04-26

Heavy full-stack frameworks like Next.js are less useful than ever because AI can assemble the underlying building blocks with more flexibility and specificity.

Meanwhile, the declarativeness of React, the terseness of Tailwind and the composability of Express still hold a lot of value. However, I've always disliked the heaviness and wonky npm dependencies they brought. Combining Hono, Preact and Tailpipe gets you all these things without the dependencies.

Below we'll show how to conveniently set this stack up, sourcing Preact, Hono, etc directly via git without pulling opaque bundles from the npm registry.

Stack	Build	Server	Frontend	Styling^*	Packages^†	Install size
Next.js	built-in	built-in	React	Tailwind	42	342 MB
TanStack Start	Vite	h3	React	Tailwind	167	132 MB
common	Vite	Express	React	Tailwind	105	62 MB
ours	esbuild^‡	Hono	Preact	Tailpipe	0	14 MB

^* Adding Tailwind (or Tailpipe) is not required in any of the stacks.
^† Packages downloaded from npm.
^‡ Or bun / qn, which bundle with built-ins instead of an external tool.

In our stack, Hono serves APIs and static files, Preact renders a SPA and Tailpipe generates Tailwind classes at runtime. There are no transitive dependencies.

Preact is React's API at a fraction of the size (20 kB vs 500 kB). It uses a simpler synchronous virtual DOM diff instead of React's Fiber architecture, drops the synthetic event system for native browser events, and skips concurrent rendering. The compat layer (preact/compat) exposes React's API. In some edge cases, it might not be fully compatible with elaborate pre-existing React components, but that would probably be fixable using AI.

Hono plays the role Express does in the common stack: composable routes and middleware via a familiar app.get(...) / app.use(...) API. The difference is that Hono leverages newer web standards and ships with zero dependencies.

Tailpipe is a cleaned-up fork of Twind. Both generate Tailwind classes at runtime when they are used instead of at build time. For me this hasn't led to performance issues and it completely rids you of all the heavy Tailwind dependencies and build process. That said, you might not even need Tailwind classes anymore because AI has gotten so good at writing and managing plain CSS.

One thing Next.js and TanStack do for you is routing. With this stack you'd implement backend routing in Hono and for the frontend you can ask your AI to write a SPA router to your liking in Preact. It might be a hundred lines of code: convert path patterns to regexes, match against location.pathname, intercept links, render the match inside Suspense. No library needed.

The bundler (esbuild, bun build, qn build) can compile TS/JSX/TSX in watch mode, rebuilding on every file change. No hot module replacement like Vite, but rebuilds feel instant and as long as page refreshes are properly designed to retain basic UI state, it feels close enough to HMR.

Setup. We have a companion repo with minimal full-stack example setups for Node, Bun and our own experimental Qn runtime. We'll continue with Node for now, you can read more about Bun and Qn below.

package.jsonfull file →

...
"scripts": {
  "prepare": "node install.js",
  "start": "node server.js",
  "dev": "node --watch server.js --dev"
},
"sourceDependencies": {
  "preact": {
    "git": "https://github.com/preactjs/...
    "rev": "21dd6d04c1a9a43e5b60976bb5eb...
    "exports": { ".": "./src/index.js", ...
  },
  ...
}

While the standard dependencies field in package.json accepts git URLs, many packages don't work that way (e.g. Hono) or require different build tools. So we declare them in a custom sourceDependencies field instead, each pinned to a git repo and commit hash. The optional exports map covers packages whose source layout doesn't match their published dist/: it points the install step at the right source files.

A small install.js script (run via the prepare hook on every npm install¹) realizes those declarations: each repo is cloned at its pinned commit and built for Node via esbuild. The result is a node_modules dir that is functionally equivalent to one with npm downloads. On Bun the script is simpler, skipping esbuild and only rewriting exports to point at source. On Qn no script is needed at all: qn install handles sourceDependencies natively.

The pinned commit hashes provide full source-based supply chain integrity². In the past, hand-rolling a manifest like this might have been inconvenient. With AI coding, it's practical and explicit.

The server.js runs directly without bundling and shells out to esbuild to build the frontend while rebuilding automatically in --dev mode.

Runtimes. Aside from Node, this stack runs even more elegantly on Bun and Qn. Both come with integrated bundlers and run Hono without @hono/node-server. They also accept unbundled Typescript dependencies in node_modules, which lets you skip the build step during install and get end-to-end type checking across client and server.

Runtime	Bundler	HTTP	Binary size	Example
Node	esbuild	@hono/node-server	118 MB	/node
Bun	Bun.buildbuilt-in	Bun.servebuilt-in	97 MB	/bun
Qn	qn:bundlebuilt-in	qn:httpbuilt-in	3.7 MB	/qn

Or bun install. It can also be invoked manually as node install.js. qn install doesn't need the script at all.
A git commit hash is a content hash over the full source tree. Pinning commit hashes across repos extends git's Merkle DAG into a single tree covering all dependencies.