So far you have seen the same Nómada Tasks screen written in plain JavaScript and in React, and both versions shared one model: a function that runs again in full and an engine that compares the result with the previous one. Vue changes that at the root. Its reactivity is fine-grained: it does not compare trees, it records which expression reads which piece of data and updates only what depends on what changed. It is 10-01's family 2, in its most polished and approachable form. And it also changes the unit of work: instead of splitting a card across a <template>, a CSS file and two JavaScript modules, Vue groups the whole thing into a Single-File Component, with its template, its logic and its scoped styles. In this lesson you will see why it is called a progressive framework and how it is added both to an existing page and to a complete project; the anatomy of a component with <template>, <script setup> and <style scoped>; the whole template syntax —interpolation, v-bind, v-on, v-if versus v-show, v-for with :key (the same old data-id) and v-model explained as sugar rather than magic—; reactivity properly, with ref, reactive, why .value exists, how proxies detect dependencies and where reactivity gets lost —the most disconcerting mistake—; computed compared with your version cache from 09-02 and with useMemo; watch and watchEffect with the criterion for choosing; the lifecycle with onMounted and onUnmounted, which is once again your destroy(); communication with props, emits, slots and provide/inject; composables as the equivalent of custom hooks; Pinia in its minimal form; and the official ecosystem. At the end, the task list with its filter reimplemented in Vue and compared with the two previous versions.

1. What "progressive framework" means
2. Adding Vue to an existing page
3. A complete project with Vite
4. Single-File Components
5. Why group template, logic and styles
6. The declarative template: interpolation
7. v-bind: dynamic attributes
8. v-on: events
9. v-if, v-else and v-show
10. v-for and :key
11. v-model: two-way binding explained as sugar
12. Reactivity: ref and why .value exists
13. reactive and when to use each one
14. How proxies detect dependencies
15. The limits of reactivity: where it gets lost
16. computed: derived values with a cache
17. watch and watchEffect
18. When to use computed, watch or watchEffect
19. The lifecycle: onMounted and onUnmounted
20. Communication: props and emits
21. slots: content composition
22. provide and inject
23. Composables: useBoard and useAssigneeFilter
24. Global state with Pinia
25. The official ecosystem and fragmentation
26. Nómada Tasks in Vue: the complete list
27. Comparison with React and with plain JavaScript
28. Common Mistakes and Tips
29. Exercises
30. Conclusion

Vue describes itself as a progressive framework, and that label has a concrete technical meaning: it can be adopted in layers, starting with the smallest one, without committing to the rest.

That gradation does not exist in Angular, which demands the whole platform from the start, and in React it only half exists (you need a build step for JSX from minute one, unless you give it up). It is the reason Vue shows up so often in projects that started with no framework and grew: they can be converted piece by piece.

For Nómada Tasks that means something very concrete. You could take the current application —your index.html, your Board, your utilities— and convert only the task list into a Vue component, leaving the rest untouched. It is not a theoretical exercise: it is a real migration strategy, and you will pick it up again in 10-06.

Level 1, with no tooling at all:

It is worth pausing here, because this block already contains almost every concept in the lesson and it works by opening the HTML in the browser, with no npm install, no build step and no configuration. Notice three things:

• The template is valid HTML. v-for, :value and {{ }} are attributes and text; the browser ignores them until Vue interprets them. This has an important practical consequence: the markup can be written in any HTML editor, and a designer understands it.
• Vue only controls #board. The rest of the page is still yours. You could have three independent Vue islands on the same page alongside your usual JavaScript.
• BACKLOG is your data module, unadapted. Vue has no opinion about where the objects come from.

For production you would use a compiled build instead of the one that interprets templates in the browser, but the mental model is this one.

For the rest of the lesson we will use level 2 and beyond:

The wizard asks whether you want TypeScript, Vue Router, Pinia, testing with Vitest and Playwright or Cypress. That list is revealing: the whole essential ecosystem is official, maintained by the same team and with integrated documentation. It is the opposite of 10-02's decision table.

The entry point:

The .vue file is Vue's unit of work: template, logic and styles in the same place.

Three blocks, with rules of their own:

• <script setup> is compile-time sugar. Everything you declare at the top level —variables, functions, imports— becomes automatically available in the template, with no return. It is the current and recommended way of writing Vue components; you will see older code with export default { setup() { … return { … } } } or with data()/methods (the Options API), which still work but are no longer the first choice.
• <template> contains HTML with directives. It is compiled into a render function during the build.
• <style scoped> applies the styles only to this component. The compiler adds a unique attribute to the component's elements and another to the selectors, so that the .task here cannot affect a .task somewhere else.

That scoped deserves a paragraph of its own, because it is where Vue solves 10-01's problem 7 more directly than React.

Remember your card in Nómada Tasks: the <template id="task-template"> in index.html, the .task__* classes in css/styles.css, the logic in js/view/card.js and the behavior in js/view/controller.js. Four files, four couplings and not one of them checked. Renaming .task__title in the CSS produces no error: the card just looks wrong.

With a .vue file, all four are visible on the same screen. Renaming a class is a find-and-replace operation inside a 40-line file. And since the styles are scoped, there is no need to invent naming conventions (BEM and the like) to avoid collisions: the isolation is real, not a discipline.

The classic objection —"mixing HTML, CSS and JavaScript is bad practice"— confuses two things. Separation of concerns is not separation of technologies: it is separation of responsibilities. A card's structure, appearance and behavior are one single concern, and splitting them across three files does not decouple them, it only moves them apart. It is exactly the argument from 10-01's section 12 about the component as the correct unit of reuse.

Dynamic text is written with double braces:

Inside goes a JavaScript expression, not a statement — the same rule as JSX's braces. And the content is always escaped: it is textContent, not innerHTML, with the same protection as in 06-02.

A difference from React worth fixing: in JSX you write {} for everything dynamic, attributes included. In Vue, the braces are for text only; attributes use v-bind.

Two special cases that are used constantly:

Classes. :class accepts a string, an object (key = class, value = condition) or an array, and it combines with the static class attribute:

Compare with what you did in paintCard:

Four imperative statements that have to be kept in sync —including the preceding remove, which is easy to forget— versus one declarative description. And compared with React, where the string has to be built by hand with templates or a utility, Vue's object syntax is noticeably cleaner.

Styles. :style accepts an object with camelCase properties:

The visible difference from React is that in the template you can write the call directly (advance(task.id)), without wrapping it in an arrow function. The compiler takes care of it: @click="advance(task.id)" becomes a handler that runs that expression. With @click="advance" (no parentheses) the function itself is passed and receives the event as its argument.

Vue adds modifiers, which declaratively solve things you write by hand in plain JavaScript:

All of them will look familiar from 06-03 and 06-07. They are shortcuts, not new functionality, but they eliminate a whole class of oversights — above all forms' preventDefault.

A note about delegation: as in React, writing @click on each of 600 elements does not create 600 DOM listeners. The compiler generates handlers and Vue manages them efficiently. The closest('[data-action]') pattern from 06-04 is still valid if you need it, but it is no longer mandatory.

And the comparison you need to be clear about:

This table is the formalization of something you already measured in 09-04: hiding 594 tasks with hidden kept 7,812 nodes in the DOM, while removing them left 1,194. v-if is the latter, v-show the former. For the assignee filter, v-if is the right choice.

Vue also lets you group things without adding a node:

It is the equivalent of React's <>…</> fragment.

And here it is, for the third time in the module, the same concept: :key is your data-id from reconcile (06-06) and React's key (10-02). Vue uses it in exactly the same way: it builds a map of key to node, pairs by key and not by position, reuses the ones that are still alive and removes the leftovers.

The same three rules: stable, unique among siblings, never the index if the list moves. And a small but useful Vue advantage: the official plugin's ESLint rule flags a v-for without :key as an error, whereas in React it is only a console warning. It is a decision of a framework "with more opinions", in 10-01's sense.

One detail Vue does better than a pure virtual DOM: since the compiler analyzes the template, it knows which parts are static and skips them entirely on updates. If your <li> has ten elements and only one depends on data, Vue updates one. React runs the whole function and compares all ten. It is 10-01's blend of families 2 and 3 in action.

v-model is Vue's most famous feature and the most misunderstood. It is presented as "two-way binding" and it sounds like bidirectional magic. It is not: it is syntactic sugar for two things you already know how to do.

compiles, essentially, into:

That is: a v-bind that brings the value down and a v-on that sends it up. Exactly 10-02's controlled form, written in one line instead of two. There is no magic channel and no DOM observation: there is an attribute and an event.

Vue adapts the pair to the element, which is what really saves work:

With useful modifiers:

v-model.number deserves a note, because it connects with 01-07: without it, <input type="number"> returns a string, and hours > 40 would compare text. It is one of the most frequent mistakes when validating R3.

In your own components, v-model works over a prop and an event:

Once again: a prop coming down and an event going up. The data flow is still unidirectional; v-model only puts a name to the pattern. Understanding it that way avoids the misconception that the child modifies the parent's state — it does not: it asks the parent to modify it.

Here we reach Vue's heart.

The question everybody asks at the start: why .value?

The answer lies in a limitation of the language you have known since 01-05: JavaScript does not allow assignment to a variable to be intercepted. There is no way for assignee = 'Iván' to run code. You can intercept access to an object's property —that is what 05-03's getter/setter and Proxy do— but not to a standalone variable.

So Vue does the only possible thing: ref(null) returns an object with a single property, value, whose get and set are intercepted.

That .value that looks like a nuisance is, literally, the price of the mechanism existing. And there is an important compensation: in the template it is unwrapped automatically. Inside <template> you write {{ assignee }}, not {{ assignee.value }}, because the compiler knows which variables are refs and adds the .value for you.

A direct comparison with what you already know:

The third row is the fundamental difference. Changing assignee.value does not re-run App: it re-runs the specific expressions that read that ref. That is 10-01's fine grain.

And the fourth has a very useful practical consequence: a ref can be created in a module, exported and modified from anywhere —including your BoardChannel from 07-04 when it receives a WebSocket message— without being inside any component.

reactive is the alternative for objects: it wraps the whole object in a Proxy and needs no .value.

It is more convenient, but it has four real limitations:

The current recommendation, and the one almost all modern Vue code follows: use ref by default. It works with any type, it can be replaced wholesale, and the explicit .value makes it visible where the reactivity is. reactive is left for grouped-state objects whose properties are manipulated one by one, and even then many teams prefer a ref with an object inside:

Time to explain the mechanism properly, because all the behaviors —the good ones and the odd ones— come out of it.

While running a reactive effect (a component's render, a computed, a watchEffect), Vue keeps a reference to the current effect. When during that execution a reactive property is read, the Proxy intercepts the read and records: "this effect depends on this property of this object". When somebody writes that property, the proxy looks up the list of dependent effects and runs them again.

Three consequences that explain everything else:

1 · Detection is automatic and precise. You do not declare dependencies as in useEffect's array: they are discovered by running. That wipes out, in one stroke, the whole class of "a dependency is missing" and "this dependency always changes" errors from 10-02.

2 · Detection is dynamic. If a computed has an if, the dependencies of the branch not taken are not registered in this execution. That is correct and it is what you want: if the result does not depend on a piece of data, changing that data should recompute nothing.

3 · Detection only works during the effect's execution. If you read a reactive value inside a setTimeout, a .then() or an addEventListener, that read happens afterwards, when the effect has already finished and registration is closed. Nothing is recorded. This is the cause of half of Vue's "this does not update" cases.

This section is what separates whoever knows Vue from whoever has tried it. Reactivity is lost in four situations, and they all have the same cause: the link lives in the property, not in the value.

Limit 1 · Destructuring a reactive object.

toRefs walks the object and creates, for each property, a ref whose get/set point at the original property. It is the specific tool for destructuring without breaking anything, and it is used a lot when returning state from a composable.

Limit 2 · Destructuring the props.

With an important nuance: <script setup> has a compiler transform that makes props destructuring written directly in defineProps reactive. Outside that specific case, the rule stands.

Limit 3 · Passing a primitive to a function.

This is the deep reason a ref is an object: objects are passed by reference and primitives by value, exactly as you learned in 01-05 and 04-08. ref turns a primitive into something that can be passed around without losing it.

Limit 4 · Replacing a whole reactive object.

The honest comparison with React, which is the trade-off 10-01 announced:

Neither of the two is "easier". React forces you to declare and that is why it can check it with an ESLint rule; Vue does it by itself and that is why the failure is silent. It is a real trade.

computed declares a value derived from other reactive values:

Four properties:

1. It is cached. The computation only runs if some dependency changed. Reading visible.value a hundred times with no changes runs the filter once.
2. It composes. openHours depends on visible, which depends on tasks and assignee. Vue builds the graph and propagates in the right order, recomputing nothing twice.
3. It is lazy. If nobody reads openHours, it is not computed, even if tasks changes.
4. It is read-only by default (a set can be defined, but it is rare and almost always indicates a design that could be improved).

And here is the parallel that closes 09-02:

You wrote twenty lines —a version counter, invalidation on every mutation, comparison of the cache key— and the permanent risk of forgetting an #invalidate(). computed does the same thing, with the invalidation discovered automatically and no possibility of forgetting.

A comparison with React's useMemo, which is the closest equivalent:

The third row is the cultural difference between the two frameworks. In React, useMemo is the exception and computing directly is the norm. In Vue, computed is the norm: any derived value is declared that way, without thinking about performance, because it is the correct way of expressing it. And that is why in Vue you almost never see 10-02's debate about excessive memoization.

Both perform side effects when something changes. They are the equivalent of useEffect, with the same warning: they are not for deriving values —that is what computed is for.

watch observes a specific source and receives the new value and the previous one:

watchEffect runs the function immediately and discovers its dependencies on its own, like a computed but for effects:

And both accept a cleanup, which is once again your destroy():

That block solves 10-02's race condition with the same AbortController from 07-03, and in Vue there is no [assignee] to declare in any array: the watchEffect signed itself up as a dependent when it read assignee.value.

The table that avoids 90% of Vue's reactivity mistakes:

That last case deserves to be written out, because it is exactly the mistake from 10-02's section 16 translated into Vue:

The same three defects: two sources of truth, a moment when the value is out of date, and more code. The rule transfers between frameworks: if it is a value, declare it as derived; if it is an action, do it in an effect.

The main moments, with their equivalences:

The third row is once again the important one, and 10-01's message still holds: Vue gives you the guaranteed moment, it does not guess what to switch off. A setInterval with no clearInterval in onUnmounted is exactly the same leak as in plain JavaScript.

A practical detail: a template ref (ref="container" in the HTML plus const container = ref(null) in the script) is the equivalent of React's useRef and of your old $('.task-list'). It is null until the component mounts, so it can only be used inside onMounted or later.

The flow is the same as in React —data down, events up— with one difference: in Vue it is declared explicitly in both directions.

Differences from React worth pointing out:

Declaring emits is valuable for a not-so-obvious reason: it documents the component's complete contract. By reading defineProps and defineEmits you know everything that goes in and everything that comes out, without searching the file for which functions are called. In React that information is scattered across the signature and has to be reconstructed.

And the same rule as in React: props are read-only. Modifying props.task.status from the child is a mistake, and Vue warns in development. The child emits; the parent decides.

Slots are the equivalent of React's children, and they are more expressive because they allow several named holes.

And scoped slots, which let the child pass data to the content the parent supplies:

It is a very powerful pattern: the component supplies the logic (the loop, the keys, the filtering) and whoever uses it supplies the presentation. In React the equivalent is done by passing a function as a prop, and it works just as well; the difference is one of syntax, not of capability.

The equivalent of React's Context: making a value available to the whole subtree.

And a technical difference from Context that matters: since Vue has fine-grained reactivity, providing a ref does not repaint everyone who does inject. Only those that actually read its .value are updated. Context's performance problem that 10-03 described —all consumers repaint when the value changes— simply does not exist here.

readonly is good practice: descendants read the value and, to change it, they call the provided function. That keeps control of the state where it belongs.

A composable is a function that uses Vue's reactivity API and returns state and operations. It is the exact equivalent of 10-02's custom hooks, with one important difference: it has no call-order rules, because Vue does not identify state by position but by object.

Compare advance with its React equivalent from 10-02:

This is the most visible practical difference between the two frameworks. In React immutability is mandatory because detection is by reference; in Vue the proxy detects the write to the property, so mutating is correct and natural. Neither is better: React wins on predictability —the state never changes under your feet and comparisons are trivial— and Vue wins on conciseness and on the fact that the 599 tasks that do not change are not even touched.

A note on naming: the Vue ecosystem uses the useSomething convention, exactly like React. That is what we follow here —useBoard and useAssigneeFilter— and it is what you will see in real code. What matters is that it be consistent.

Pinia is Vue's official store, and its minimal form is surprisingly similar to a composable:

storeToRefs is indispensable and it is a direct application of section 15's limit 1: destructuring the store would copy the values and break reactivity. storeToRefs turns the state and the derived values into linked refs; the actions are ordinary functions and can be destructured with no problem.

Compared with Redux (10-03):

10-03's conclusion holds: start with no store. A composable with a ref in a module is already shared state —because a module-level ref is a single object— and it is often enough. Pinia adds DevTools, hot replacement, the guarantee of a single instance and support for server rendering. The difference from Redux is that the step up is much lower: moving from a composable to a Pinia store is ten minutes.

That left-hand column explains why Vue is said to have less fragmentation, and it deserves an honest analysis in both directions.

Real advantages: there is a canonical answer to every question; the official documentation covers the whole set and the examples fit together; updates are coordinated; two Vue projects from different companies look fairly alike, which makes joining one faster; and you do not have to spend a week evaluating four routing libraries.

Real disadvantages: less innovation from outside, because there is less incentive to compete with the official solution; fewer options when your case is unusual; and a smaller third-party ecosystem in absolute numbers —for a very specific need you are more likely to find a React library than a Vue one.

It is 10-01's library-framework axis with Vue placed in the middle: more opinions than React, fewer than Angular. And here too it is worth distrusting automatic conclusions: React's fragmentation is a cost for a small team and an advantage for one that needs something uncommon.

The module's target screen, third version. The domain is the same JavaScript file as in 10-02 and 10-03, untouched:

The filter:

The card is the one from section 4. And the list:

And the application:

The canonical numbers, verified: with no filter, "6 of 6 tasks · 45 h open". With "Iván", "3 of 6 · 25 h". With "Lucía", "1 of 6 · 14 h". With "Marta", "2 of 6 · 6 h". And on pressing "Start" on task 6, advance mutates task.status, the proxy notifies the computeds that read that property, and only the affected card and the summary are updated. The other five cards are not even re-run.

The table of the three versions of the same screen:

And the metrics for the same screen:

And the qualitative balance, without declaring winners:

Vue wins on: conciseness (less ceremony for the same thing), isolated styles with no naming conventions, automatic reactivity that removes the dependency array, computed as the natural form rather than an optimization, a coherent official ecosystem and a gentler learning curve for anyone coming from HTML and CSS.

React wins on: the size of the job market and of the third-party ecosystem, a mental model that is simpler to explain (it is a function that re-runs), "everything is JavaScript" with no template syntax to learn, better third-party tooling support, and React Native for native mobile.

Plain JavaScript wins on: zero dependencies, zero engine weight, no mandatory build step, absolute control and code that will still work ten years from now with nothing updated.

Vue's trade-offs, stated clearly: automatic reactivity fails silently when it is lost (section 15), and the failure is "it does not update", which is harder to diagnose than an error; the template syntax is an extra language you have to learn and that generic tooling does not understand without plugins; and the job market is smaller than React's in most places, which is a legitimate criterion even if it is not a technical one.

Forgetting .value in the script. Mistake number one. In the template it is unwrapped automatically, in the script it is not. if (assignee === 'Iván') compares a ref object with a string and is always false, with no error. The official Vue plugin's ESLint rule catches it: enable it.

Destructuring a reactive object or a Pinia store. const { assignee } = filters copies the value and breaks the link. Use toRefs for reactive objects and storeToRefs for stores.

Reading reactive values outside the tracking context. Inside a setTimeout, a .then() or a handler registered by hand, the read is not recorded. Read the value beforehand, in the effect's body.

Using watch to derive values. It is the same antipattern as useEffect for deriving state in React: two sources of truth and a moment of lag. If it is a value, it is computed.

Confusing v-if with v-show. v-show leaves the nodes in the DOM: with 600 tasks, 600 hidden nodes, findable with Ctrl+F, with the memory and accessibility-tree cost you measured in 09-04. For filtering, v-if.

Using the index as :key. The same mistake as in React and as in your reconcile. If the list is filtered or reordered, nodes change data and focus and internal state are lost.

Forgetting .prevent on forms. @submit without .prevent reloads the page. It is so frequent that Vue made the modifier precisely for that.

Forgetting .number on numeric fields. <input type="number" v-model="hours"> stores a string. R3's validation (hours > 0 && hours <= 40) would compare text. Use v-model.number.

Mutating props from the child. Vue warns in development. The child emits an event; the parent decides what to do. It is the unidirectional flow, which v-model does not break but formalizes.

Believing that v-model is bidirectional magic. It is a v-bind plus a v-on. Understanding it that way avoids expecting behaviors that do not exist.

Tip: use ref by default and reactive only when you can justify it. ref works with any type, can be replaced wholesale, and the .value makes it visible where the reactivity is.

Tip: keep the domain outside the components. domain/rules.js is the same file in all three versions of this screen, and that is the best proof that 10-01's discipline works: changing framework only means rewriting the view.

Tip: install Vue DevTools from day one. It lets you inspect the component tree, see the value of every ref and every computed in real time, and —very usefully— see which dependencies each effect has registered, which is the direct way of diagnosing lost reactivity.

This component has four reactivity flaws. Find them, explain why each one fails and write the corrected version.

Write a useRemoteTasks(assignee) composable that:

1. Receives a ref with the filtered assignee.
2. Loads the tasks from the server with your listTasks from 07-02 every time the assignee changes.
3. Exposes tasks, loading and error as refs.
4. Cancels the previous request when firing a new one and when the component unmounts, avoiding 10-02's race condition.
5. Also exposes a computed with the open hours of the loaded tasks.

Then explain why this version needs no dependency array and which React mistake it avoids.

Without writing new code, fill in this table comparing the same functional change across the three versions of the screen you have seen in the module: adding a badge that shows each task's weighted effort (estimatedHours × WEIGHTS[priority]), with a red background if it exceeds 30.

Then answer: in the plain-JavaScript version, what would happen if you added the badge to paintCard but forgot to add it to the <template> in index.html as well?

Solution 1

Flaw 1 · const { assignee } = filters (line 6). Destructuring a reactive object copies the primitive value null and loses the link. assignee will be null forever, so visible will never filter anything even when the user changes the <select>. It is section 15's limit 1.

Flaw 2 · watch to derive openHours. It is section 18's antipattern: two sources of truth, a moment of lag and more code. On top of that, since tasks is a ref to an array and the watch is not deep, mutating a task's status does not fire the watch: openHours would go stale when marking a task as done, which is precisely the main use case.

Flaw 3 · A read inside a setTimeout in the computed. The read of filters.text happens after the computed has finished, outside the tracking context: it is not registered as a dependency. On top of that, a computed must have no side effects: it must be a pure function of its dependencies, just like your reducers from 10-03.

Flaw 4 · filters = { … } in clear. Reassigning a reactive object breaks the link with the template, which still points at the original proxy. Besides, filters is declared with const, so this would throw a TypeError at runtime (01-05).

Corrected version:

A note about the destructuring on the line const { assignee, text } = filters.value: here it is correct, because it happens inside the computed. Reading filters.value registers the dependency at that moment; what is destructured afterwards are values that have already been read, used immediately. The rule is not "never destructure", it is "do not store destructured values outside a reactive context".

Solution 2

Usage:

Why no dependency array is needed. The watchEffect reads assignee.value during its execution, and the proxy registers that read automatically. When the value changes, the effect runs again — after having called the cleanup, which aborts the in-flight request.

Which React mistake it avoids. Two, in fact:

1. The forgotten dependency. In React, writing }, []) instead of }, [assignee]) produces a component that loads once and never updates. It is so frequent that there is a specific ESLint rule for it. Here it is impossible by construction.
2. The dependency that always changes. If in React you passed an object { assignee } as a dependency, it would be recreated on every render and the request would fire endlessly. In Vue, the dependencies are the reactive values read, not references compared.

And a warning, so as not to oversell: there is a case where Vue's automatic tracking also fails. Reads that happen after an await are not registered, because the tracking context closes when the function suspends. That is why the code reads assignee.value before the await, inside the call. If you needed to read another ref after the await, you would have to read it beforehand and store it. It is the same limit as in section 15, in its subtlest form.

Solution 3

What happens if you forget the <span> in index.html's <template>. It depends on how paintCard is written. If it uses $('.task__effort', li).textContent = …, the selector returns null and the line throws a TypeError: Cannot set properties of null at runtime, while painting the first card: the whole application breaks. If instead it checks first (const badge = $('.task__effort', li); if (badge) …), nothing visible happens: the badge simply does not appear, with no error at all, and the failure is only caught by looking at the screen or with an end-to-end test (08-06).

That is, named and identified, the unchecked coupling that 10-01's section 13 talked about. In the Vue version the mistake is impossible: the markup and the code that fills it in are the same file, and the template compiler warns if a variable does not exist.

You have seen Vue in its modern form —Composition API and <script setup>— and, above all, you have seen 10-01's second reactivity model genuinely at work.

You know what a progressive framework means and you have checked it: the same concepts serve to enhance an existing page with a <script> tag and no build step, or to put together a complete application with Vite, Vue Router and Pinia. You know Single-File Components with their three blocks and why grouping template, logic and styles does not violate separation of concerns but respects it: a card's structure, appearance and behavior are one single concern, and <style scoped> turns isolation into a compiler guarantee instead of a naming convention.

You are fluent in the template syntax: interpolation with its automatic escaping, v-bind with the object forms for classes and styles —four imperative classList statements reduced to one description—, v-on with its modifiers that encode 06-03's preventDefault and stopPropagation, the difference between v-if and v-show —create-and-destroy versus display: none, with the 7,812 nodes versus 1,194 you measured in 09-04—, v-for with :key, which for the third time in the module is your data-id from 06-06, and v-model demystified: a v-bind that brings the value down and a v-on that sends it up, 10-02's controlled form written in one line, with .trim and .number that prevent real mistakes in rules R2 and R3.

You understand reactivity from the inside. You know why .value exists —JavaScript does not allow assignment to a variable to be intercepted, only to a property— and that a ref is an object with intercepted get/set, exactly 05-03's mechanism. You know how proxies register dependencies during an effect's execution, with their three consequences: automatic and precise detection, dynamic detection that ignores branches not taken, and detection only during execution — from which come the four limits where reactivity is lost: destructuring a reactive object, destructuring props, passing a primitive to a function and replacing a whole reactive, with toRefs and storeToRefs as the tools. And you have the honest comparison: React forces you to declare dependencies and that is why it can check them with ESLint; Vue discovers them by itself and that is why the failure is silent.

You know that computed is your version cache from 09-02 with the invalidation discovered automatically —twenty lines and a risk of forgetting turned into one line with no risk— and that, unlike useMemo, it is not an optimization but the natural way of writing derived values. You tell watch and watchEffect apart with the criterion for choosing among the three, and you recognize the antipattern of deriving with watch as the same mistake as deriving with useEffect. You know the lifecycle with onMounted and onUnmounted, which is once again your destroy() with the call guaranteed but the content still your responsibility.

You know how to make components communicate with declared props and emits —a complete, validated contract that reads in two lines—, how to compose content with named and scoped slots, and how to inject values with provide/inject, which unlike Context does not repaint all the consumers because reactivity is fine-grained. You extract logic into composables with no call-order rules, and you know that the most visible practical difference from React is in advance: where React demands an immutable map, Vue mutates the property and the proxy does the rest. You know Pinia in its minimal form —almost identical to a composable, with storeToRefs as a requirement— and the official ecosystem that explains Vue's lower fragmentation, with its advantages and its costs.

And you have seen the third version of the same screen, with the same domain/rules.js untouched across all three, ~120 lines, one file per component with its isolated styles, and updates that touch only what changed. With the trade-offs stated: lost reactivity fails silently, the template syntax is one more language, and the job market is smaller.

Two models remain to be seen. The next one is the most different of all: a framework that is neither a library nor a progressive framework but a complete platform, with TypeScript as a de facto requirement, dependency injection, a CLI that generates everything, observables for asynchronous streams, and —recently— signals very similar to the refs you have just learned. It is the "opinionated" end of 10-01's axis: Angular Basics.