Why Effuse

Why Effuse

Status: Framework thesis. The implementation is experimental.

Effuse is for applications where UI, shared services, and server endpoints belong to the same product capabilities. An authentication capability should not require one client context, a separate server route tree, unrelated action handlers, and manually synchronized type declarations.

The Contract

const ProfileButton = define({
  layers: { auth: AuthLayer } as const,
  script({ layers: { auth } }) {
    return { user: auth.service('auth').currentUser() };
  },
  template: ({ user }) => <button>{user.name}</button>,
});

The component names its local dependency auth. The runtime layer can retain a globally unique name such as platformAuth. That layer may also own lifecycle, state, validation, API routes, and actions.

Why This Is Different

Concern	Effuse ownership
Reactive UI	Signals update dependent work directly.
Component logic	script returns the values consumed by template.
Shared capabilities	Layers define services, dependencies, and lifecycle.
Local naming	Components and hooks bind layers through local aliases.
Server endpoints	API routes and actions can stay with the owning layer.
Type transport	Manifests describe server routes/actions for typed clients.
Failure behavior	Tagged errors and validation bodies are explicit contracts.

The value is coherence, not a larger list of component primitives.

Intended Users

• TypeScript teams building applications with durable domain boundaries.
• Teams that want fine-grained reactivity without a virtual-DOM mental model.
• Full-stack applications that want server endpoints close to service ownership.
• Framework contributors exploring a layer-first alternative to file-only or component-only architectures.

Non-Goals

• Effuse does not claim stable production compatibility today.
• It is not a React-compatible runtime.
• It does not auto-register capabilities when a lazy component renders.
• It does not hide application composition or dependency ordering.
• It does not yet provide one completed file manifest for client routes, layouts, metadata, and server handlers.

Design Test

A new feature should answer four questions:

1. Which capability owns the state and services?
2. Which components and hooks bind to that capability?
3. Which server routes or actions belong to it?
4. Which manifest, diagnostics, and tests prove the contract?

When those answers require unrelated systems, the framework still has a DX gap.