Foundations/The honest baseline

The honest baseline

The status quo of gluing two runtimes, and the bridge that replaces it.

The status quo

In the real world today, most full-stack AI teams write React in TypeScript, and models/agents in Python. They wire them together using REST endpoints, tRPC, or manually typed fetch calls. It works, but it's fragile. The "glue" is the most common source of errors.

Some teams try to write everything in Python (Streamlit, Reflex) but hit a wall with UI complexity. Others try to write everything in TypeScript (LangChain.js) but hit a wall with the AI ecosystem.

The typical setup
1nextjs-app/          fastapi-service/
2|-- app/            |-- app/
3|-- package.json    |-- requirements.txt
4`-- server.ts      `-- main.py
5      |                   |
6      -- untyped JSON ---/     <- the fragile part

The two worlds are connected by hand-written HTTP: service URLs, manual fetch calls, duplicated types, and a schema that drifts the moment someone touches the Python side.

The BionicJS bridge

BionicJS's long-term ambition is a true shared runtime, but we are starting with an honest baseline: a beautifully orchestrated monorepo where TypeScript and Python live side-by-side, sharing a dev server, a build pipeline, and a generated RPC boundary.

The same app as one project
1one-app/
2|-- app/        # React client (TypeScript)
3|-- server/     # Nitro API (TypeScript)
4|-- ai/         # models & agents (Python)
5|-- jobs/       # workers (Python)
6-- bionicjs.config.ts

The boundary stops being glue and becomes a contract: Python functions are callable from TypeScript by name, with types on both sides. One dev command starts everything, one build produces the deployable, and the schema cannot drift because it is generated, not copied.

We are building the framework that makes the dual-language reality feel like a single, cohesive product.

ⓘ
This is the reason BionicJS exists. If single-language frameworks (Next.js, Rails, Django) solved your problem, you should use them. BionicJS is for the product that needs both worlds - the web surface and the intelligence - and does not want the seam to be the liability.