Skip to content

← Writing

engineering

Vue 3's Function-API RFC Drama: Governance in the Open

· Jerwin Arnado

Archive note: this is a backdated post, written years later while rebuilding this site. It’s dated to the moment it covers, but the hindsight is real.

My corner of the internet caught fire this week. The Vue team published an RFC for a function-based component API planned for Vue 3 — composition logic via functions like setup(), value(), computed() instead of (or alongside) the familiar options object — and the reaction went from feedback to fury in about a day. Reddit threads with thousands of angry comments, “Vue is becoming React” hot takes, claims the Options API we all write daily was being deprecated, dramatic farewells from people who’d apparently adopted Vue specifically to avoid this kind of churn.

I write Vue at work more or less daily, so I did the radical thing: read the actual RFC.

What it actually proposes

The honest summary, minus the smoke:

  1. The problem is real. In big components, the Options API smears one feature across data, methods, computed, and lifecycle hooks. Reuse across components is served by mixins, which are genuinely bad — invisible property sources, naming collisions, a dependency graph you reconstruct by guesswork. Anyone maintaining a large Vue app has felt this; I have specific components in mind as I type.
  2. The proposal is composition by function. Group logic by feature, extract it into reusable functions, get full TypeScript inference along the way. It looks unfamiliar in a Vue file, yes — and it solves exactly the problems above.
  3. The Options API is not being removed. The RFC’s own text says additive. The panic’s central claim was checkable and false — which didn’t slow it down even slightly.

The drama is the interesting part

The technical question will resolve itself; the governance spectacle is the durable lesson. Evan You is running language design in public, via RFC, before shipping — the responsible process — and discovering its tax: a draft document read by thousands as a signed decree, secondhand summaries outrunning the source, and the loudest feedback coming from people who hadn’t hit the problem the RFC solves.

What I’m taking from the spectacle:

  • A community this passionate is an asset wearing a costume. People rage because they care about their daily tool. Indifference would be the actual death sentence. The Vue team’s challenge is to keep the caring while routing it through reading comprehension.
  • Stability is a feature with constituents. A chunk of Vue’s user base chose it as a refuge from JavaScript fatigue. For them, any large addition feels like betrayal regardless of substance. That’s not stupidity — it’s a real constituency whose core need (“don’t make me relearn my tool”) deserves explicit acknowledgment, which later drafts are now giving it.
  • Read the primary source. Evergreen advice, freshly vindicated. The gap between the RFC and its Reddit summary was the entire crisis.

Where I land

Cautiously, genuinely interested. The mixin problem is real in my own codebases, the function approach plausibly fixes it, and “additive” means my existing components aren’t hostage to the experiment. If the final design ships with the Options API intact and the new style opt-in, this week will look — in hindsight — like a community stress-testing its own steering wheel and finding it holds.

Vue 3 itself is still over the horizon. When it lands, I suspect this API (whatever it’s renamed to by then) will be the headline, and this week’s fury will be a footnote. Bookmarking this post to check.