How is Expressive MVC different from MobX?

MobX is the closest relative - both use tracked reactivity with direct mutation. Expressive is more opinionated about what MobX leaves as an exercise: context between instances, lifecycle with cleanup, async values that integrate with Suspense, and component binding are built in rather than userland conventions.

When should I use Zustand or Jotai instead of Expressive MVC?

Use Zustand when state is a modest shared store and the team wants minimal API surface with no classes. Use Jotai when state decomposes into small independent values with sparse dependencies. Expressive earns its structure when behavior, derived values, and lifecycle cluster into cohesive domain models.

When should I not use Expressive MVC?

When your team has a strict functional-only style, your app is mostly server-rendered with minimal client state, your existing state solution causes no pain, or you rely daily on Redux devtools time-travel debugging. The library’s own audit guide recommends against adoption in those cases.

Is Expressive MVC actively maintained?

Yes. The commit history predates the release: development ran unannounced from 2021, and the public launch - documentation site, stable API surface, published adapters - is 2026. Coverage is a CI-enforced, measured 100% of statements, branches, functions, and lines across every package.

Comparisons - Expressive MVC

How Expressive relates to the store libraries you already know. For the case against raw hooks, see Why Classes? - this page is about the libraries you'd otherwise pick instead.

Every library makes a single counter short, so a lone widget proves little. The fair test is a feature that splits: one owner, several views, each re-rendering only for what it reads. Below, the views' markup is held identical - only the cost of the owner and the wiring differs.

One feature, two views

A player owns a track and a play state. Title shows the track; Toggle plays and pauses. Pausing should not re-render Title. Flip through:

ExpressiveExpressive

import { Component } from '@expressive/mvc';

class Player extends Component {
  track = 'Intro';
  playing = false;

  toggle() {
    this.playing = !this.playing;
  }

  render() {
    return (
      <>
        <Title />
        <Toggle />
      </>
    );
  }
}

function Title() {
  const { track } = Player.get();

  return <h2>{track}</h2>;
}

function Toggle() {
  const { playing, toggle } = Player.get();

  return <button onClick={toggle}>{playing ? 'Pause' : 'Play'}</button>;
}

import { createContext, useContext, useState } from 'react';

const PlayerContext = createContext<{
  track: string;
  playing: boolean;
  toggle: () => void;
} | null>(null);

function usePlayer() {
  const player = useContext(PlayerContext);

  if (!player)
    throw new Error('Player missing');

  return player;
}

function Player() {
  const [playing, setPlaying] = useState(false);
  const toggle = () => setPlaying(p => !p);

  return (
    <PlayerContext.Provider value={{ track: 'Intro', playing, toggle }}>
      <Title />
      <Toggle />
    </PlayerContext.Provider>
  );
}

function Title() {
  const { track } = usePlayer();

  return <h2>{track}</h2>;
}

function Toggle() {
  const { playing, toggle } = usePlayer();

  return <button onClick={toggle}>{playing ? 'Pause' : 'Play'}</button>;
}

// every consumer re-renders on any change

import { Component } from '@expressive/mvc';

class Player extends Component {
  track = 'Intro';
  playing = false;

  toggle() {
    this.playing = !this.playing;
  }

  render() {
    return (
      <>
        <Title />
        <Toggle />
      </>
    );
  }
}

function Title() {
  const { track } = Player.get();

  return <h2>{track}</h2>;
}

function Toggle() {
  const { playing, toggle } = Player.get();

  return <button onClick={toggle}>{playing ? 'Pause' : 'Play'}</button>;
}

Every other tab builds the same three things by hand: a per-instance store, a context to carry it, and a typed hook to read it back - then each view declares what it reads, through a selector or a wrapper. In Expressive the Component is all three. It owns the instance, provides itself to whatever it renders, and Player.get() is the typed hook. Destructuring is the selector: Title re-renders when track changes, not when playing does.

Growing the feature changes nothing about the owner - another view is another function calling Player.get(). And the fields are typed props: <Player track="Verse" />.

Shared state

Context is where store libraries quietly hand the problem back to you. In Expressive, your classes themselves are context keys - anything needing Theme just asks for it: another instance via get(Theme), a component via Theme.get().

ExpressiveExpressive

import { Model, get } from '@expressive/mvc';

class Theme extends Model {
  mode = 'light';

  toggle() {
    this.mode = this.mode === 'light' ? 'dark' : 'light';
  }
}

class Panel extends Model {
  theme = get(Theme);

  get dark() {
    return this.theme.mode === 'dark';
  }
}

function ModeBadge() {
  const { mode, toggle } = Theme.get();

  return <button onClick={toggle}>{mode}</button>;
}

import { createContext, useContext, useState } from 'react';

const ThemeContext = createContext<{
  mode: string;
  toggle: () => void;
} | null>(null);

function ThemeProvider({ children }) {
  const [mode, setMode] = useState('light');

  const toggle = () =>
    setMode(m => (m === 'light' ? 'dark' : 'light'));

  return (
    <ThemeContext.Provider value={{ mode, toggle }}>
      {children}
    </ThemeContext.Provider>
  );
}

function ModeBadge() {
  const theme = useContext(ThemeContext);

  if (!theme)
    throw new Error('ThemeProvider missing');

  return <button onClick={theme.toggle}>{theme.mode}</button>;
}

import { Model, get } from '@expressive/mvc';

class Theme extends Model {
  mode = 'light';

  toggle() {
    this.mode = this.mode === 'light' ? 'dark' : 'light';
  }
}

class Panel extends Model {
  theme = get(Theme);

  get dark() {
    return this.theme.mode === 'dark';
  }
}

function ModeBadge() {
  const { mode, toggle } = Theme.get();

  return <button onClick={toggle}>{mode}</button>;
}

No createContext<T>, no null default, no missing-provider guard, no Provider/Consumer pair to keep in sync. Every library lands back here eventually - Zustand has you wrap a store in React context yourself, Jotai's Provider scopes a whole atom store, MobX leaves it to you entirely.

vs Zustand

Zustand is a great lightweight store. The differences that matter in practice:

Destructuring is the selector - no per-access selector functions or shallow-compare helpers.
Classes are the organizational unit - no factory functions, no spread-based updates.
One API for every scope - the same class can back a global store, a per-component instance, or a provider tree.
Lifecycle is built in - new()/mount() and automatic destruction replace manual subscribe/teardown.

vs Redux (and RTK)

Redux introduces actions, reducers, selectors, and a dispatch indirection. Expressive collapses all four into methods:

class Counter extends Model {
  count = 0;

  increment() {
    this.count++;
  }
}

Updates: direct assignment instead of dispatch(action).
Subscription: destructure instead of useSelector.
Async: regular async methods instead of thunks or sagas.
Composition: class inheritance instead of store merging.

Redux's time-travel devtools are real value. If you rely on them daily, factor that in - Expressive gives you plain objects and standard browser debugging instead.

vs MobX

MobX is the closest relative - both use observable objects with automatic dependency tracking. Expressive is what you get when that idea is allowed to own the whole problem:

No observer() wrapper. Miss one in MobX and you get stale renders. Expressive tracks through render() and get() themselves.
No makeAutoObservable. Extending Model is enough - and methods arrive pre-bound.
Lifecycle, context, and Suspense are built in - new()/mount(), class-keyed context, async set(). In MobX these are pieces you wire together yourself.

If you like MobX, you'll feel at home here. Expressive is simply more opinionated about the parts MobX leaves as an exercise.

When not to use Expressive

Your team has a strict "functional only" code style.
Your app is mostly server-rendered with minimal client state.
You already have a state solution that works and causes no pain.
You rely heavily on Redux devtools' time-travel debugging.

Expressive is a tool for a specific kind of complexity. If you don't have it, you don't need it.

Comparisons