Most state libraries are really framework libraries with a state API attached. SDuX Vault™ flips that model. Its core is Plain TypeScript, Zero Magic™, and the framework layers are thin adapters. That means your state architecture is not trapped inside Angular, React, Vue, or Svelte. It stays portable as teams, products, and runtimes change.

Most State Libraries Are Secretly Framework Libraries

State management is supposed to protect business rules from churn, but most libraries tie those rules to a rendering story. NgRx is an Angular story. Pinia is a Vue story. Redux is more portable in theory, but many teams still end up adopting it through framework-specific providers, hooks, selector conventions, effect patterns, and store bootstrapping. The result is the same: change the framework, and your state layer becomes migration work.

That coupling is expensive because state logic usually outlives UI trends. Product teams replatform screens, split applications, introduce server-side orchestration, or move shared logic into tools and background jobs. If the state engine only makes sense inside one framework, the rewrite cost shows up every time the platform moves.

Key takeaway: Framework lock-in rarely starts in your components. It starts when your state model depends on a framework lifecycle, a framework container, or a framework-only runtime assumption.

What Plain TypeScript, Zero Magic Actually Buys You

Plain TypeScript, Zero Magic is not branding language. It is an architectural constraint. SDuX Vault does not depend on reflection, runtime patching, framework lifecycles, or hidden side effects. Its core concepts, including FeatureCells, pipelines, reducers, filters, interceptors, lifecycle signals, and immutable state snapshots, are language-level primitives composed in TypeScript.

Because the runtime is explicit, the guarantees stay stable everywhere the code runs. A cell is still registered explicitly. Initialization is still explicit. The pipeline still executes in a deterministic order. State is still committed as immutable snapshots. Framework adapters improve ergonomics, but they do not rewrite the underlying rules.

  • Identical state semantics across platforms
  • Explicit lifecycle control everywhere
  • No framework lock-in
  • Predictable behavior in any runtime
  • Frameworks add ergonomics, not rules

One State Engine Across Angular, React, Vue, and Svelte

The reason portability is real instead of aspirational is simple: the core contract stays the same. Angular uses dependency injection and Signals-friendly helpers. React, Vue, and Svelte consume the same committed snapshots through their own reactive surfaces. The state owner does not change, the pipeline does not change, and the lifecycle rules do not change.

The original post compares the same FeatureCell with framework-specific wiring only:

Angular Registration

// app.config.ts

export const appConfig: ApplicationConfig = {
  providers: [
    provideVault({ logLevel: 'off' }),

    provideFeatureCell(EmployeeService, {
      key: 'employees',
      initialState: []
    })
  ]
};

// employee.service.ts
import { Injectable } from '@angular/core';
import { FeatureCell, injectVault } from '@sdux-vault/angular';

@FeatureCell<Employee[]>('employees')
@Injectable({ providedIn: 'root' })
export class EmployeeService {
  readonly vault = injectVault<Employee[]>(EmployeeService);

  constructor() {
    this.vault.initialize();
  }
}

Enter fullscreen mode Exit fullscreen mode

Core Runtime Registration

// main.ts
import { FeatureCell, Vault } from '@sdux-vault/core';

Vault({ logLevel: 'off' });

// employee.cell.ts
export const employeeCell = FeatureCell({
  key: 'employees',
  initialState: []
});

employeeCell.initialize();

Enter fullscreen mode Exit fullscreen mode

The Angular version adds DI-friendly registration. The plain core version is what powers React, Vue, Svelte, Node.js, Bun, and Vanilla JavaScript integrations. Different wiring, same state semantics.

Redux Knowledge Still Transfers

This is not an argument that everything you learned in Redux was wrong. Pure reducers, immutable state evolution, selectors, and deterministic thinking all transfer directly. The change is where the architecture lives. Redux usually centers the application on a global store and dispatch flow. SDuX Vault centers it on the owning FeatureCell and a deterministic pipeline.

The migration mapping is straightforward: Redux centralizes state through a global store and reducer tree, while SDuX Vault scopes state to independent FeatureCells and executes updates through a deterministic pipeline. Existing reducer logic often transfers cleanly as long as it remains pure and deterministic. Redux and SDuX Vault can also run side by side, so migration does not have to be a rewrite.

Concern Redux SDuX Vault
Primary architecture Global store and dispatch-centric integration Scoped FeatureCell ownership and direct state intent
Framework relationship Usually adopted through framework-specific bindings Thin adapters that do not change runtime rules
Migration path Concepts transfer, but store wiring often stays central Can run beside Redux while features migrate cell by cell

Why Runtime-Agnostic State Matters for Teams

Teams rarely live in a single runtime forever. An Angular product team adds a React microsite. A frontend flow needs shared logic in a Node.js worker. A proof of concept becomes a long-lived internal tool. Runtime-agnostic state means the architectural investment can move with those decisions instead of being thrown away by them.

That matters operationally too. Shared state rules become easier to document, review, and test when they are not hidden behind four different framework-specific abstractions. You can teach one mental model, keep one set of guarantees, and let each framework focus on rendering rather than owning correctness.

Key takeaway: The win is not just portability. It is organizational consistency. One runtime-level state model is easier to migrate, easier to review, and easier to share across teams than four separate framework-native patterns.

Framework Ergonomics Without Framework Lock-In

Thin adapters are the right compromise. Angular can use DI and Signals-friendly consumption. React can use hooks. Vue can use the Composition API. Svelte can bind reactive values naturally. None of those conveniences require the core runtime to become framework property.

Platform Adapter Ergonomics What Stays Fixed
Angular DI registration, decorators, injectVault, Signals support Explicit init, deterministic pipeline, immutable snapshots
React Hook-based consumption of committed state FeatureCell ownership, lifecycle rules, pipeline semantics
Vue Composition-friendly consumption and reactive bindings Identical state semantics and explicit control
Svelte Natural fit with fine-grained reactivity Same runtime guarantees and state correctness model
Node.js and Deno No UI adapter required The same core runtime used in browser applications

That is the practical meaning of Plain TypeScript, Zero Magic. The library stays small enough to travel, explicit enough to trust, and stable enough to survive framework churn.

Deeper Dive

Explore the full Supported Languages page, compare the same feature side by side in the framework comparison demos on sdux-vault.com, and review the migration guide to see how Redux concepts transfer directly. If you want runnable examples, the official StackBlitz demos cover Angular, React, Vue, Svelte, Node.js, Bun, and Vanilla JavaScript through the same core runtime.