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 rendering.

Leverage every ecosystem

Section titled “Leverage every ecosystem”

τjs composes Fastify, Vite and React, Vue or Solid into a single application architecture while preserving the native APIs of each ecosystem.

  • 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 - bring the component libraries, tooling, and patterns of whichever framework each app uses

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

Orchestrate before rendering

Section titled “Orchestrate 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

τjs deliberately moves orchestration to the request boundary. More is declared up front, so less has to be inferred later.

In return, applications become easier to reason about, rendering strategies become predictable, and the architecture remains observable as systems grow.

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”

Each route defines, at the request boundary, whether τjs performs orchestration.

  • Initial render data is declared at the route boundary
  • Service access can be mediated through a registry rather than direct imports
  • The request defines which data and services participate in the initial render
  • Rendering remains downstream of orchestration (CSR / SSR / Streaming)
  • Client-side fetching and traditional API patterns remain fully supported alongside request contracts

Modular without the runtime complexity

Section titled “Modular without the 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 behavior - consistent across environments and render modes
  • 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”