Most frontend architecture collapses the same way: we copy backend entities into the client and start attaching flags like isDirty, isOptimistic, hasConflict, and isSaving. Before long, one Order object is pretending to be a persisted record, a form draft, a sync job, and an error state all at once.

That works for simple CRUD. It breaks down the moment the app needs to be offline, collaborative, or genuinely realtime. At that point the client is dealing with its own business concepts: drafts, edit sessions, pending submissions, conflicts, and freshness guarantees. Those are not just UI details. They are part of the domain of the client.

This session argues that the frontend needs its own model. Rather than mirroring the backend and sprinkling more flags everywhere, we can model client-side objects explicitly, define the commands and events around them, and separate UI state from local domain state from server-authoritative state. The result is a frontend that is easier to reason about, easier to sync, and far less fragile under optimistic updates and collaboration.