Functional vs Object-Oriented Frontend Architecture: Two Cost Curves
Vue teams with large codebases are paying the functional-style tax as a tangle of composables, stores, and provide/inject conventions; Zova's container model is one coherent alternative with a hard SSR correctness argument. React teams get a structural warning: an object-graph state model like Zova's cannot follow React's move toward serializable, concurrently rendered data.
React's function components are not pure functions: Hooks require a stable Fiber node per component to hold the hooks list, and Vue's setup() runs inside a component instance backed by Proxy objects and ref boxes. Both are object systems wearing function syntax. Zova, an IoC-oriented framework built on Vue, makes the underlying model explicit by turning state into container-managed beans with declared roles, scopes, and lifecycles.
The cost curves differ. A single Vue component costs almost nothing to write, but Vue ships four orthogonal sharing mechanisms: props/emits, composables, provide/inject, and stores. Once dozens of modules and multiple teams share a codebase, all four coexist, conventions multiply linearly, and deviations grow exponentially. Zova front-loads ceremony: every bean declares its container and scope, and in return the four mechanisms collapse into one IoC semantics with ctx, host, app, and sys injection scopes.
Three requirements only containerization handles cleanly: SSR request isolation, interceptable bean method calls, and cross-module contracts via bean identifiers. The honest costs are runtime magic from decorators and metadata, coarser granularity, and a structural conflict with React's RSC and concurrent rendering direction. The closing criterion: anything that must be found, replaced, shared across scopes, or destroyed with a lifecycle is an object; everything else should be a function.
The functional-versus-object-oriented label conflates syntax, state host, and architectural ownership; once Fiber nodes and component instances are visible, React and Vue are both object systems, so the debate should move to who manages the objects.
Vue's four sharing mechanisms are the hidden tax of its functional style: the framework never enforces a single path, every team writes its own convention, and entropy arrives exactly when the codebase is too large to refactor cheaply.
The SSR request-scope argument is the strongest case for containerized beans because it is a correctness constraint rather than a preference; one user's data leaking into another request is a bug, not a style tradeoff.
The claim that Zova cannot run on React because beans are non-serializable while RSC wants serializable state is the most consequential structural limit; it ties Zova's future to Vue's component model rather than to any universal architecture principle.
Zova adopting functional APIs while the React ecosystem adopts identity-bearing stores cuts against any claim that either paradigm is inherently superior; both sides are converging on the same split between expression and identity.
State attribution matters more than syntactic form.