bionicjs
Reference

The stack

Established tools, no bionicjs abstractions: React and Vite for the client, Nitro for the server, and Python with the mature libraries for AI and jobs.

Established tools, no abstractions

The stack is deliberately unoriginal: React and Vite for the client, Nitro for the server, and Python with its mature libraries for AI and jobs. bionicjs ties them together rather than replacing them.

Client — React + Vite

React renders the UI; Vite bundles it. Routing is filesystem-based and compiled ahead of time into React Router routes. You get HMR in dev and a small, standard production bundle.

Server — Nitro + h3

Nitro is the server engine: the HTTP server, middleware, the /api proxy target, and the .output/ build contract. It is built on h3, which is the handler shape your route files are written in — an event handler exported with defineEventHandler.

A file in server/api/ is an endpoint. Nothing else is required:

import { defineEventHandler } from "h3";

export default defineEventHandler(() => ({ status: "ok" }));

Neither Nitro nor h3 is exposed as a bionicjs API. You write handlers using their standard shape, and both stay implementation details.

Hono — the generated client, not the server

Hono is a separate project that bionicjs uses for type inference, not for serving requests. @bionicjs/dev reads your server/api tree and generates a Hono router plus a typed hc<AppRouter> client into .bionicjs/.

That layer is generated but not mounted yet, so the typed client does not currently work. Every request today goes through Nitro and h3. See Hono for the details and the open design decision.

Python — AI and jobs

Python is first-class, not bolted on. ai/ holds LLM providers, agents, RAG, and MCP; jobs/ holds Celery, RQ, and Dramatiq with a Redis or RabbitMQ broker. Both live at the top level, beside the app.

Why this combination

Each tool is already the best-in-class at one job. The framework's value isn't a new runtime — it's the config that wires all three together and the build that deploys them as one.

How this compares

This is a well-trodden combination rather than a novel one. Nuxt is the closest architectural sibling: Vite for the client, Nitro and h3 for the server, the same server/api convention, and a framework that owns the Nitro configuration so you never write one.

Redwood is the layout sibling: the flat set of top-level capability directories (api, auth, db, jobs) is Redwood's, not bionicjs's. bionicjs keeps ai/ and jobs/ at the root because both are Python and both run out-of-process.

For the full map, including Next.js, SvelteKit, React Router, TanStack Start, and Astro, see How meta-frameworks work.