Vue

Reading is what creates the dependency

Vue wraps your state in a proxy — an object that can observe every read and every write of its properties. That single capability is the whole system, and everything else is a consequence of it.

While an effect is running — a component render, a computed value, a watcher — Vue knows which effect is current. Every property read during that run records the effect against itself. That is tracking. Later, when a property is written, Vue re-runs the effects recorded against that specific property, and nothing else. That is triggering.

The cost shows up as one specific trap. Reactivity lives on the proxy, not on the values inside it, so pulling a value out breaks the connection: const { count } = props copies a number, and the copy will never update. This is why ref exists — it boxes a value in an object with a .value property, so passing the box around keeps reactivity intact. toRefs does the same for an object you want to destructure.

The .value suffix is the part newcomers dislike, and it is worth understanding rather than resenting: it is the visible seam where a plain value becomes a tracked one. In templates Vue unwraps refs automatically, so it only appears in script, and in single-file components a compiler transform removes most of it too.

Single-file components and two APIs

A Vue component is normally one .vue file holding three blocks: the template, the script and the styles. The argument for keeping them together is that they change together — editing a component means editing all three — and the argument against, that it mixes languages in one file, has been steadily losing for a decade.

The styles block accepts a scoped attribute, which is a genuinely useful default: Vue adds a generated attribute to the elements of that component and scopes every selector to it, so a rule cannot escape into another component. That is the locality property CSS methodologies are usually adopted to provide, supplied by the compiler for free.

The difference matters at size rather than at the start. In a component with three concerns, the Options API scatters each one across four sections, so understanding "how does search work here" means reading four places and holding them together; the Composition API lets the three concerns sit as three blocks, and lets any of them move out into a composable that another component can import. Both are supported; new code should use Composition.

Computed or watch

This is the decision Vue developers get wrong most often, and it has a clean rule. A computed derives a value: it is cached, it recalculates only when something it read changes, and it must be free of side effects. A watch reacts to a change by doing something: calling an API, writing to storage, starting an animation.

The test is one question: are you producing a value or performing an action? A watcher that ends by assigning to another piece of state is almost always a computed written the long way — it runs one tick late, it can loop if two watchers write to each other's sources, and it makes the relationship between the two values invisible in the code.

The same rule extends across the framework. v-if removes an element from the DOM and v-show toggles its CSS display, so v-if costs on every toggle and v-show costs once on mount — the choice is about how often it flips. And v-for needs a :key for the same reason React does: without a stable identity, Vue reuses DOM nodes for the wrong items and state ends up attached to the wrong row.

What comes in the box

Vue sits between React and Angular on the amount it decides for you. It is not a library that leaves everything open, and it is not a framework that supplies the whole application architecture. It ships a small number of official packages, and because they are official the ecosystem converges on them rather than splintering.

• Vue Router — the official router, so a Vue project does not begin with a routing comparison.
• Pinia — the official store, and small enough that using it for a single shared value is not overkill.
• Nuxt — the meta-framework for routing conventions, server rendering, data fetching and deployment.
• The reactivity system itself is published separately, and can be used with no components at all.

The last one is worth a moment. @vue/reactivity is a standalone package: refs, computed values and effects with no rendering attached. It is a fair signal about where the framework's centre of gravity is — the component layer is built on the reactivity system, not the other way around.

Vue against React

Neither column is a verdict. The template approach lets the compiler know more — it can see which parts of the view are static and skip them entirely, which is work React has to do at runtime — while JSX is just JavaScript, so anything you can express in the language you can express in the view. Choose on the two things that actually differ in a team: whether you want conventions supplied, and which pool of experienced developers you can hire from.

How this shows up in real delivery

Vue's reputation for being approachable is earned and slightly misleading. The first day is genuinely easier: a template looks like HTML, the reactivity does what you expect, and there is no dependency array to get wrong. The part that requires care arrives later and is specific — knowing exactly where reactivity is preserved and where it is lost, because the failure is silent. Nothing throws when you destructure a reactive object; the value simply stops updating, and the bug looks like a rendering problem.

Where it degrades

• Destructuring a reactive object or props, which silently detaches the value from the system.
• A watcher that assigns to other state, which is a computed running one tick late.
• Mixing Composition and Options APIs inside one component for no stated reason.
• v-if and v-for on the same element, where the precedence is not what most people assume.
• Mutating a prop from a child, which breaks the one-way flow the framework relies on.
• provide / inject used as a global variable, which hides where a value comes from.
• Deeply reactive large lists, where the proxy work is real and shallowRef was the answer.

When to use it

Related pages

• DevelopmentReactReact is a library for describing what the interface should look like for a given state, and letting something else work out how to get the DOM there. The model is one line — UI is a function of state — and almost every difficulty people have with React comes from breaking it: doing work during render that is not pure, or keeping state in a place that cannot be the source of truth.
• DevelopmentAngularAngular is a framework rather than a library, and the difference is the whole point: it supplies dependency injection, routing, forms, HTTP, testing and a build system, and expects you to use them. That removes a hundred small decisions and replaces them with one large one. This page covers dependency injection, change detection and what signals changed, and where the framework earns its weight.
• DevelopmentJavaScriptJavaScript is the language every browser runs, and the one most people learn syntax-first and semantics-never. Almost everything that seems arbitrary about it follows from one fact: your code runs on a single thread with one call stack, and everything asynchronous is a queue waiting for that stack to empty. This page covers the event loop, references, closures, modules, and where async error handling silently fails.