Skip to content
τjs - Composing systems τjs - Composing systems, not just apps

Composing Systems, Not Just Apps

Full control over your whole stack
Get started

τjs orchestrates your application from request to interaction, letting your UI framework focus on building the interactive application.

Leverage the ecosystems you already know

Section titled “Leverage the ecosystems you already know”

τjs composes Fastify and Vite with React, Vue or Solid in a single application architecture while preserving each ecosystem’s native APIs.

  • Fastify - register plugins, hooks, and decorators on the server instance as you would in any Fastify app
  • Vite - use standard Vite plugins directly through τjs’s declared plugin channels; the configuration fields τjs owns are documented and protected
  • React / Vue / Solid - use the component libraries, rendering model and tooling of the frameworks you’re already invested in.

There is no parallel plugin system to learn and no fork to track - when the underlying ecosystems move, τjs moves with them.

Resolve the application response before rendering

Section titled “Resolve the application response before rendering”

τjs defines a clear boundary: everything required for the application response is orchestrated and resolved at the request boundary.

  • Data dependencies are declared before rendering begins
  • Service access is mediated and observable
  • Rendering strategy is resolved before rendering begins, not discovered during rendering
  • Components do not discover data imperatively during SSR

Modern component-driven architectures make it easy to build features. As systems grow, understanding a single application response often means tracing behaviour across the component tree.

τjs deliberately moves orchestration to the request boundary. More is declared up front, so less has to be inferred later. This creates a shared orchestration layer that powers authentication, CSP, tracing and architecture-aware AI from the same request-boundary model.

Learn how τjs exposes this architecture to AI agents through MCP.

Request


│
▼
┌───────────────────────┐
│          τjs          │
├───────────────────────┤
│ Route                 │
│ Policy                │
│ Data & Services       │
│ Metadata              │
│ Render Strategy       │
├───────────────────────┤
│ Trace                 │
└───────────────────────┘


│
▼
Application Response


│
▼
React • Vue • Solid


│
▼
Interactive Application

One architecture. Multiple application styles.

Section titled “One architecture. Multiple application styles.”

Because orchestration happens at the request boundary, τjs can support multiple application styles within the same system.

  • Single-Page Applications (SPA)
  • Multi-Page Applications (MPA)
  • Build-time micro-frontends (MFE)
  • Hybrid per-route composition, where a route can be:
    • a standalone app,
    • part of an MPA,
    • “static” pages via CDN caching of SSR output,
    • or a build-time MFE inside a larger system

Declarative rendering per route

Section titled “Declarative rendering per route”

Any route can explicitly define how it renders, independently of how its data is orchestrated:

  • Client-Side Rendering (CSR)
  • Server-Side Rendering (SSR)
  • Streaming SSR
  • Hydration toggle (enable or disable hydration where needed)

Start simple. Add orchestration only where you need it

Section titled “Start simple. Add orchestration only where you need it”

Start with familiar Fastify, Vite and UI-framework conventions. Routes can remain conventional, adopting declared data, mediated services and explicit render control only where the system benefits from them.

Each route can declare its data, service access and render strategy independently at the request boundary.

  • Data dependencies can be declared at the route boundary
  • Service access can be mediated through a registry rather than direct imports
  • The route declares which data and services participate in the application response
  • Render strategy can be introduced independently for each route
  • Client-side fetching and traditional API patterns remain fully supported alongside request contracts

Incremental by design

Section titled “Incremental by design”

τjs lets you evolve your application along two independent axes: its architecture and its UI framework.

Modular without runtime complexity

Section titled “Modular without runtime complexity”

τjs gives you room to grow without adding runtime complexity:

  • Compose multiple independently built apps at build time
  • Keep strict boundaries between domains without runtime federation
  • Maintain monolithic-level performance with modular structure
  • Deterministic request resolution - same data, services, and routing state resolved regardless of render strategy
  • Minimal, overridable defaults - entry points, directory layout, rendering modes
  • Clear, granular control over routing, data loading, rendering, and hydration

Next steps

Section titled “Next steps”