A decorator-native frontend, bolted onto the Velocity backend.

Make this page yours

Minimal, persistent (localStorage) reading preferences — theme, accent, font, and size.

Backend-first, frontend by installation

Velocity’s identity is a fast, batteries-included backend. The view layer ships as a separate package the developer chooses to install — the NestJS @nestjs/* model. Absent the package, there is nothing to gate: no frontend code on disk, in node_modules, or in RSS.

Teaching the core about a layer it doesn’t contain

velo.scan() classifies against fixed symbols today. @Page is a new kind. Three bridges — starting with your inert-symbols idea.

A Page is a class. A class is a component.

One @Page per file, extending Component. Signals and methods are fields; a few well-known methods are overridable — chiefly view(). Resolved by the same DI container that serves controllers.

• Fields — usually signal()s, plain values, or injected deps.
• view() (required) — the markup (§04). Now may return multiple roots (fragments).
• Hooks — onStart/onPause/onClose + reactions (§07), all optional.
• Data members — Callers/Actions/Chains or injected controllers/contexts (§06, §09, §10).

How view() returns markup

Four routes, from “free on Bun” to “build a compiler.” All target the same output: vnodes with signal-bound holes.

The rendering model matters more than the syntax

Fragments — no forced single root your request

Yes, and cheap. A view() may return a fragment (<>…</>) or an array of siblings. Internally a fragment is just a vnode with no host element — its children mount into the parent directly; when a component is used elsewhere, it expands to exactly those siblings (as you pictured). Fine-grained binding makes this free: there’s no wrapper node and no diff cost.

Signals, not state

A signal is a reactive box: read .value → subscribe; write → subscribers update. computed derives, effect reacts, batch groups.

Linking components to endpoints — any method

The heart of the framework. Everything is typed off velogen, so URLs are never hand-written. Two primitives — Caller (you want the reactive result) and Action (you fire a command) — each now method-generic.

Callers — an endpoint bound to a Feeder

A Caller binds any endpoint to a Feeder (a signal holding the response). It doesn’t fetch eagerly: it fires when the Feeder is first read, or when a trigger changes. Method is generic — a POST that returns data you want to keep reacting to is a PostCaller. Caller('METHOD', …) is the base; the verb forms are shortcuts.

Actions — an imperative command

An Action is a command you invoke on an event; it returns a promise and can invalidate Feeders or run optimistic. Same method family: Action('METHOD', …) base + Get/Post/Patch/DeleteAction shortcuts.

The three linking styles (choose per component)

Function-scoped Feeders your request

Besides the field/decorator form, a Feeder can be created inside a method via a functional API — it exists only within that reactive scope and is disposed when the scope ends. Useful for on-demand data (a modal, a one-off report) you don’t want alive for the page’s lifetime.

Calling @Fn endpoints as local methods your idea

Velocity already ships @Fn — RPC-style endpoints reachable at GET /.name(args). When a @Page shares a path/namespace with a controller, that controller’s @Fn methods can be surfaced as if they were methods of the component: write this.greet('Alice') and the add-on turns it into the RPC. The only obstacle is your exact observation — TypeScript won’t let you call a method that isn’t declared. Three ways around it:

Overridable hooks and signal reactions

Reactions — “do X when signal Y changes” (beyond auto-DOM-update)

Pages, endpoints, collisions & hiding

Default in fullstack mode: API under /api (Pages own the root) — no collisions, clean URLs. Callers target /api/* transparently.

Endpoint hiding via @Internal() your idea, formalized

Mark an endpoint internal: never exposed over HTTP, only reachable from a component’s Caller (server-side during SSR, or via a signed page-scoped channel). Same path as a Page → the public GET returns the Page; the data stays private.

Backend ↔ fullstack sync

Piping endpoints — each response feeds the next

Your idea: call endpoints in order, each result flowing into the next, the last being the result — with destructors so only the needed slice passes forward (no giant input lists). Delivered as a first-class primitive with reactive and imperative variants.

Design

A Chain is an ordered list of steps. Each step has a method + path and a mapper that transforms the previous response into this step’s input — the mapper is the destructor: it picks only what’s needed. The final step’s response lands in a Feeder (reactive) or is returned (imperative). Triggers re-run the whole pipe; results are de-duped/cached by input tuple; an error short-circuits into .error.

Destructors — keeping inputs small

The worry you raised — “the input list gets very long” — is solved by making each step responsible only for its own input, derived from the immediately-previous result (not all prior results). If a step needs an earlier value, a tiny ctx accumulator carries just the fields explicitly kept via keep(). So the pipe never threads a growing tuple; each hop declares its slice.

Django-style SSR — the component reads a context, not endpoints

A distinct delivery mode you flagged for the future: the component never calls an API. A service exposes providers; when the Page’s path is opened, all its providers run server-side, merge into one context object, and the page is rendered from it and returned. Like Django templates / Remix loaders / getServerSideProps.

How it runs: on GET /dashboard, the add-on resolves the declared service(s), runs every @Provider() in parallel (they’re server-only — full DB/DI access, no HTTP hop), merges the results into ctx, renders view(ctx) to HTML, and ships it. No client fetching for this data; it can be embedded in the hydration payload so the client never re-requests it.

Route params, dependencies & errors

Providers receive the request, so route params flow straight in. A provider can depend on another’s result (the add-on resolves the dependency graph and orders them), and a provider that throws surfaces a typed error you branch on in the view — so you never ship a half-rendered page. This is the whole ergonomic win over hand-wiring loaders: the page declares what it needs and the framework figures out how and in what order to get it.

Providers run in parallel by default; add after only when one genuinely depends on another. Each result can be cached — per-request always, and optionally across requests with a TTL — so an expensive query isn’t repeated for every visitor. Because it all runs server-side, a context page reads the session, hits the DB directly, and ships a fully-formed HTML document with zero client round-trips: the ideal shape for SEO-critical, content-heavy, or first-paint-sensitive routes. And it composes with Callers — take the context for the static shell, then let a @GetCaller drive the one live widget on the page. Context is the fast skeleton; Callers are the beating heart.

.tmpl files — extract the markup out of the class

For big components, move the view’s markup into a separate .tmpl file with the same syntax. Signals and child components are used identically inside — no re-declaration, no type ceremony. A preprocessor inlines it as the view body.

How it works: a Bun build plugin (or a velogen step) reads .tmpl, compiles the markup to a render function bound to the component instance (so this’s fields — query, users, loading — are in scope), and replaces view with it. Inside the file, identifiers resolve against the component instance, so no imports/types are repeated.

Everything a real frontend also needs

Borrowed from Vue & Angular — plus mine

A fast scan of both for ideas worth stealing. Each is a suggestion, not a commitment.

From Vue

From Angular

Mine

Ideas that need backend work first separate — core change required

These frontend features can’t exist until the core gains a capability. Each lists the backend change and its estimated effect on the backend’s benchmarks — because touching the core is the one thing that can move the numbers we’ve protected everywhere else.

A CRUD fullstack app, whole-project

Two samples: Easy — a focused Users CRUD (switch data style with the tabs); Pro — a full app showing auth, encrypted sessions, entity relations, guards, validation, WebSocket + liveSignal, shared memory, clustering, context providers, chains, and @Fn. Flip the Sample switch. (Illustrative; not meant to compile.)

Both Velocity modes vs the field

No fullstack code exists yet → these are reasoned estimates from Velocity’s real backend numbers + published characteristics. Backend baseline (Bun, c=32): GET 42,927 · POST 29,750 · 66 MB.

Velocity backend-only vs Velocity fullstack

Fullstack capability matrix

Estimated performance profile

Jot & keep (saved in your browser)

Title + note → saved to localStorage. No server, no export — just for you, on this machine.

Calls I made — flag any to change