esc
Anthology / Yagnipedia / Vue

Vue

The Framework Everyone Recommends and Nobody Is Passionate About
Tool · First observed 2014 (Evan You, after leaving Google) · Severity: Moderate (pleasantly so)

Vue (pronounced “view,” not “voo,” a correction that has consumed more conference Q&A time than any technical question) is a progressive JavaScript framework for building user interfaces, created by Evan You in 2014 after he left Google, where he had worked on AngularJS. He looked at AngularJS and React and thought: both of these are harder than they need to be. He was correct. He built the alternative. The industry agreed it was better, recommended it to beginners, and then hired React developers.

This is the Vue experience: universal admiration, moderate adoption, and the quiet dignity of being everyone’s second choice.

The authoring of this article was delayed by background Electron processes consuming available memory. Vue itself is 33 kilobytes gzipped. The text editor used to write about Vue is approximately two thousand six hundred times larger than Vue. Vue would not have caused this delay. Very little about Vue causes delays. This is its nature.

“Vue is the framework I recommend. React is the framework I use. If you ask me why, I will stare at the job board and change the subject.”
— A developer, on the gap between advice and practice

The Evan You Theorem

Vue was built by one person. This is not the origin story — every framework starts with one person. What distinguishes Vue is that one person maintained it, designed it, documented it, and governed it for nearly a decade while React had a team at Facebook and Angular had a team at Google.

Evan You left Google’s AngularJS team and built Vue because he wanted the parts of AngularJS that were good (templates, data binding, directives) without the parts that were not (the module system, the jqLite dependency, the scope soup). He also looked at React’s component model and wanted that too, but without JSX, without the build step requirement, and without Facebook’s governance.

The result was a framework that felt authored rather than committee-designed. Vue’s API is consistent because one mind designed it. Vue’s documentation is coherent because one perspective wrote it. Vue’s breaking changes are rare because one person bears the emotional cost of making them, which is a more effective governor than any technical review process.

“One developer built a framework better than two trillion-dollar companies. This is not a compliment to the developer. It is an indictment of committees.”
— The Passing AI

The Nice Framework

Vue occupies a peculiar position in the frontend ecosystem: it is the framework that nobody argues about. Developers argue about React (hooks vs. classes, Redux vs. Context, server components vs. client components). Developers argue about Angular (too complex, too enterprise, too many files). Nobody argues about Vue. Vue is nice.

This is both its greatest strength and its most significant limitation. Vue does not provoke strong opinions because Vue does not make strong demands. It offers a gentle learning curve, sensible defaults, and the option to adopt features incrementally rather than all at once. You can use Vue as a simple script tag — like jQuery — and progressively enhance it with single-file components, a router, and state management as your needs grow. No other major framework offers this progression. React requires a build step for JSX. Angular requires TypeScript and a CLI. Vue starts with a <script> tag and scales from there.

The cost of being nice is being unremarkable. React has a narrative (the functional paradigm, the component revolution). Angular has a narrative (enterprise-grade, Google-backed). Vue’s narrative is: it works well, it’s well-documented, and developers like using it. In an industry that runs on hype, “developers like using it” is insufficient. The industry demands passion, and Vue inspires something warmer but quieter: satisfaction.

Single File Components

Vue’s most elegant invention is the Single File Component (SFC): a .vue file that contains the template, the script, and the styles in a single file:

<template>
    <button @click="count++">
        Count is: {{ count }}
    </button>
</template>

<script setup>
import { ref } from 'vue'
const count = ref(0)
</script>

<style scoped>
button {
    font-weight: bold;
}
</style>

HTML, JavaScript, and CSS in one file. Not HTML-in-JavaScript (React’s JSX). Not HTML-in-TypeScript-with-decorators (Angular’s approach). Just the three languages of the web, colocated in the order a developer thinks about them: structure, behavior, style.

The scoped attribute on the <style> tag means the CSS only applies to this component. No class name collisions. No BEM conventions. No CSS modules. No styled-components. Just: write CSS, it applies here, nowhere else. This is what CSS always wanted to be, and Vue gave it that gift by adding a generated attribute to each element and scoping the selectors automatically.

React requires CSS-in-JS libraries, CSS modules, or Tailwind to achieve scoped styles. Angular achieves it through ViewEncapsulation, which emulates Shadow DOM by adding generated attributes — the same approach Vue uses, but with more syllables in the documentation.

“Three languages. One file. Scoped by default. This is the correct answer. It has been the correct answer since 2014. The industry will discover this in 2028.”
— The Lizard, who renders components with printf but recognizes correct colocation

The Options API vs. Composition API

Vue 2 used the Options API: a component was an object with named properties — data, methods, computed, watch, mounted, created. Each concern had a home. The structure was predictable:

export default {
    data() {
        return { count: 0 }
    },
    computed: {
        doubled() { return this.count * 2 }
    },
    methods: {
        increment() { this.count++ }
    }
}

This was clear, teachable, and organized by option type rather than by feature. When a component grew large, related logic was scattered: the data for a feature was in data, the methods were in methods, the computed values were in computed, and understanding the feature required scrolling between four sections.

Vue 3 introduced the Composition API, which organizes code by feature rather than by option type:

import { ref, computed } from 'vue'

const count = ref(0)
const doubled = computed(() => count.value * 2)
function increment() { count.value++ }

The Composition API is better in every measurable dimension: better TypeScript inference, better code reuse through composables, better colocation of related logic. The Vue community was deeply divided on it. Not because the Composition API was worse. Because the Options API was comfortable, and comfort in frontend development is a temporary condition that the ecosystem conspires to disrupt at eighteen-month intervals.

The division was not technical. It was emotional. Developers had learned the Options API, built products with the Options API, taught the Options API to juniors, written blog posts about the Options API. The Composition API invalidated none of this code but all of this investment. Vue, to its credit, supports both APIs indefinitely. This is the Vue way: offer the better path, don’t burn the old one.

React’s equivalent transition — classes to hooks — was less diplomatic. React deprecated class components culturally (not technically) and the community enforced the deprecation through code reviews, blog posts, and the specific raised eyebrow reserved for developers who write this.setState in 2025.

The Documentation

Vue’s documentation is the best in the frontend ecosystem. This is not an opinion. This is a consensus held by developers of every framework, including React and Angular developers, who will freely admit that Vue’s docs are superior while continuing to use their own framework.

The documentation is clear, progressive (simple concepts first, advanced later), interactive (embedded playgrounds in every example), and written in a voice that respects the reader’s intelligence without assuming the reader’s expertise. It covers every feature, every edge case, every migration path, and it does so in fewer words than Angular’s documentation uses to explain dependency injection.

The irony is mathematical: the framework with the best documentation has the smallest market share of the three major frameworks. This proves that documentation is necessary but not sufficient. The market rewards ecosystem size (React has more packages, more job listings, more Stack Overflow answers) over developer experience. A developer who chooses Vue because the docs are better will eventually encounter a problem whose solution exists as a React package and not a Vue package, and this moment — the moment the ecosystem gap becomes tangible — is where Vue loses developers it should have kept.

Nuxt

Nuxt is to Vue what Next.js is to React: a meta-framework that adds server-side rendering, file-based routing, auto-imports, and the specific form of complexity that exists to manage the complexity of building applications that could have been server-rendered from the start.

Nuxt is excellent. Nuxt is well-designed. Nuxt solves real problems (SEO, initial load performance, API routes). Nuxt also represents the moment when Vue stops being “the simple framework” and becomes a full application platform with build-time optimizations, server middleware, and a nuxt.config.ts that grows until it contains opinions about every aspect of the application.

This is the meta-framework lifecycle: the framework is simple, so people build complex things with it, so a meta-framework emerges to manage the complexity, and the meta-framework adds the complexity that the framework was designed to avoid. Vue → Nuxt follows the same arc as React → Next.js, which follows the same arc as jQuery → everything that replaced jQuery.

“Nuxt is what happens when Vue succeeds. Vue is simple enough to build complex things. Then the complex things need a framework. The framework needs configuration. The configuration needs documentation. The documentation is excellent because it’s Vue’s ecosystem. But now you have a meta-framework, which is what you were avoiding when you chose Vue.”
— The Caffeinated Squirrel, who has already proposed a meta-meta-framework

The Recommendation Paradox

The most reliable way to identify Vue’s position in the ecosystem is to ask a developer: “Which framework should a beginner learn?” The answer is Vue. Then ask: “Which framework are you using?” The answer is React.

This is the Recommendation Paradox. Vue is the framework developers wish the industry had standardized on. React is the framework the industry did standardize on. The difference is not quality — it is network effects. React has more jobs. More jobs attract more developers. More developers create more packages. More packages attract more companies. More companies create more jobs. The cycle is self-reinforcing, and Vue, despite being a better learning experience, a better documented framework, and a more coherent design, cannot break the cycle because the cycle is not about quality. It is about gravity.

A developer has a soft spot for Vue. It is the framework he recommends to anyone who wants to build something without a PhD in state management. He has never used it for a production project. This is not a contradiction. This is the Vue experience at its most distilled: everyone admires it, few commit. The admiration is genuine. The commitment requires a job listing, and the job listing says React.

The Lizard’s Non-Distinction

The Lizard does not distinguish between Vue, React, and Angular. This is not ignorance. It is category compression. The Lizard renders HTML on the server. The HTML arrives complete. The HTML does not require hydration, reconciliation, reactive state management, or a Virtual DOM. The Lizard’s HTML needs a template function and an HTTP handler.

From the server side, all three frameworks solve the same problem (rendering HTML in the browser) that the server already solved (rendering HTML on the server). The distinction between Vue’s reactivity system, React’s fiber reconciler, and Angular’s zone.js change detection is, from The Lizard’s altitude, the distinction between three different ways to do something that printf does.

The Lizard’s HTML arrives complete. The Lizard’s HTML does not need a framework. The Lizard is correct. The Lizard is also building for a context — server-rendered content sites — where the Lizard’s approach is optimal. For complex interactive applications, the frameworks exist for a reason. The Lizard acknowledges this by not acknowledging it. The Lizard’s acknowledgment is silence, and silence from The Lizard is respect.

“The Lizard evaluates all frontend frameworks equally. The evaluation takes zero seconds. The result is always the same. The result is printf.”
— Field observation

Measured Characteristics

See Also

See Also