# Appendix A
LLMS index: [llms.txt](/frontend-book/llms.txt)
---
# Appendix A - Front-End Architectural Rosetta Stone
## Vanilla JavaScript, React, and Vue Compared by Architectural Concept
This appendix is a translation guide.
Its purpose is not to teach three separate technologies.
Instead, it takes the architectural ideas used throughout this book and shows how the **same responsibility** is commonly expressed in:
- browser-platform / Vanilla JavaScript;
- React;
- Vue.
The key word is **responsibility**.
The implementations are not identical.
For example:
- React primarily expresses UI as repeated render calculations followed by reconciliation and commit;
- Vue tracks reactive dependencies and updates affected rendering/effects;
- browser-platform JavaScript gives you lower-level DOM, events, classes, modules, Custom Elements, and Web APIs from which you build your own update model.
Therefore, this appendix should not be read as:
```text
React API X
=
Vue API Y
=
Vanilla API Z
```
It should be read as:
> **If I understand the architectural responsibility, what is the closest normal way to express it in each environment?**
That makes the appendix useful when:
- moving between React and Vue;
- reading an unfamiliar codebase;
- deciding whether a framework abstraction is actually necessary;
- translating a design pattern without copying framework-specific syntax;
- teaching frontend architecture independently of one library.
---
# 1. Quick Rosetta Stone
| Architectural responsibility | Browser / Vanilla JavaScript | React | Vue |
|---|---|---|---|
| UI unit | function/class/Custom Element/module | component | component |
| External input | function args, properties, attributes | props | props |
| Output to parent | callback, DOM `CustomEvent` | callback prop | emitted component event |
| Nested UI composition | DOM nodes, callbacks, templates | `children` / render props | slots / scoped slots |
| Local state | variables/objects + explicit update/render logic | `useState`, `useReducer` | `ref`, `reactive` |
| Derived value | function/getter | calculate during render, optionally `useMemo` | `computed` |
| Reaction to external system | event/subscription/lifecycle code | `useEffect` | `watch`, `watchEffect`, lifecycle hooks |
| Direct DOM reference | DOM query/reference | `useRef` | template ref |
| Deep dependency sharing | module/service/object reference | Context | `provide` / `inject` |
| Reusable stateful behavior | function/class/module | custom Hook | composable |
| Conditional rendering | DOM creation/removal | JavaScript condition in JSX | `v-if`, `v-show` |
| List rendering | loops + DOM creation | `map()` + `key` | `v-for` + `:key` |
| Controlled input | assign `value` + handle input event | `value` + `onChange` | `v-model` or `:value` + `@input` |
| Uncontrolled input | browser owns current value | `defaultValue` + ref/FormData | native DOM/form behavior or template ref |
| Lifecycle setup | explicit initialization | Effect/lifecycle abstraction | lifecycle hooks |
| Lifecycle cleanup | remove listener/cancel/close | Effect cleanup | `onUnmounted`, watcher cleanup |
| DOM event | `addEventListener` | JSX event prop | `v-on` / `@event` |
| Shared state | shared object/module/custom store | lift state / Context / store | lift state / provide-inject / store |
| URL state | `URL`, `URLSearchParams`, History API | router/framework APIs over URL/history | Vue Router APIs over URL/history |
| Async module loading | `import()` | `import()`, framework lazy APIs | `import()`, async component/router APIs |
| Network request | `fetch()` | `fetch()` / framework/data library | `fetch()` / framework/data library |
| Escape hatch to platform | already at platform level | refs, Effects, DOM APIs | template refs, lifecycle/watchers, DOM APIs |
The table is intentionally compact.
The rest of this appendix explains the important differences behind it.
---
# 2. Component: What Is the Unit of UI?
## Architectural responsibility
A component should own a coherent piece of interface responsibility.
It may define:
- structure;
- inputs;
- output events;
- local state;
- behavior;
- lifecycle.
The architectural question is:
> What belongs together, and what deserves its own boundary?
The answer should come before framework syntax.
---
## Browser / Vanilla JavaScript
There is no single mandatory component model.
A component can be represented by:
- a function returning DOM;
- a class;
- a factory;
- a Custom Element;
- a module that mounts/unmounts a region.
A simple function-based component:
```js
export function createStatusBadge(
{
label,
status
}
) {
const element =
document.createElement(
"span"
);
element.className =
`status-badge status-${status}`;
element.textContent =
label;
return element;
}
```
Use:
```js
const badge =
createStatusBadge({
label:
"Approved",
status:
"success"
});
container.append(
badge
);
```
The function creates one coherent UI unit.
---
## React
A component is normally a function returning JSX.
```jsx
function StatusBadge({
label,
status
}) {
return (
{label}
);
}
```
React calls the component during rendering.
The returned JSX describes desired UI.
---
## Vue
A Vue Single-File Component often separates script and template while remaining one component boundary.
```vue
{{ label }}
```
Vue connects the template to reactive component state and props.
---
## Translation principle
```text
Component
≠
framework syntax
```
A component is an architectural boundary.
React and Vue provide standardized component runtimes.
Vanilla JavaScript makes you define more of that runtime behavior yourself.
---
# 3. Inputs: Properties Passed Into a Component
## Architectural responsibility
Components need external information.
Examples:
```text
label
product
selected
disabled
```
A healthy component input API should be:
- understandable;
- narrow;
- stable;
- explicit.
---
## Vanilla JavaScript
Function arguments:
```js
createButton({
label:
"Save",
disabled:
false
});
```
Custom Element properties:
```js
button.label =
"Save";
```
Custom Element attributes for serializable markup-facing configuration:
```html
Delete
);
}
```
Callback props are a normal React communication pattern.
---
## Vue
Vue can receive callback props too, but framework-native component communication commonly uses emitted events.
```vue
Delete
```
Parent:
```vue
```
These represent browser interaction.
Component-level communication is conceptually higher-level:
```text
product-selected
dialog-closed
save-requested
```
A good component API often communicates domain intent rather than exposing every internal DOM event.
---
# 7. Custom Events in Vanilla Components
A Custom Element can emit a DOM `CustomEvent`.
```js
this.dispatchEvent(
new CustomEvent(
"product-selected",
{
detail: {
productId:
this.productId
},
bubbles:
true
}
)
);
```
Consumer:
```js
element.addEventListener(
"product-selected",
event => {
console.log(
event.detail.productId
);
}
);
```
Architecturally, this is close to Vue component emits.
React usually expresses the same parent-child contract through callback props rather than DOM custom events.
---
# 8. Composition: Passing Interface Structure
Components should not need a prop for every possible layout variation.
Composition lets the parent provide child content or behavior.
---
# 9. Vanilla Composition
A function can accept DOM content:
```js
function createPanel({
header,
body
}) {
const panel =
document.createElement(
"section"
);
panel.append(
header,
body
);
return panel;
}
```
Custom Elements can use native slots:
```html
Profile
Account information
```
Shadow DOM template:
```html
```
Native Web Component slots and Vue slots are related composition ideas, though their runtimes differ.
---
# 10. React Composition
React uses `children`.
```jsx
function Panel({
children
}) {
return (
);
}
```
Use:
```jsx
Profile
Account information
```
Multiple composition regions are commonly modeled as props:
```jsx
```
Use:
```vue
Profile
Account information
```
Named slots:
```vue
```
---
# 12. Children and Slots Solve the Same Architectural Problem
The problem is:
> The container should own layout/behavior without knowing every concrete nested UI element.
React normally calls this:
```text
children / composition
```
Vue normally calls this:
```text
slots
```
Web Components use:
```text
slots
```
as a browser primitive.
Do not translate syntax mechanically.
Translate the responsibility.
---
# 13. Scoped Composition
Sometimes the container needs to expose data to parent-provided content.
Architectural idea:
```text
container owns behavior/data
consumer owns rendering
```
React may use a render prop:
```jsx
{data => (
```
Vue may use a scoped slot:
```vue
```
Vanilla code may use a callback:
```js
createDataSource({
render(data) {
return createProductList(
data
);
}
});
```
This is one of the clearest Rosetta Stone mappings.
---
# 14. Local State
## Architectural responsibility
Local state belongs to one UI boundary.
Examples:
```text
dialog open
selected tab
temporary input
hovered row
```
---
# 15. Vanilla Local State
You choose the update mechanism.
```js
function createCounter() {
let count =
0;
const button =
document.createElement(
"button"
);
function render() {
button.textContent =
`Count: ${count}`;
}
button.addEventListener(
"click",
() => {
count +=
1;
render();
}
);
render();
return button;
}
```
Here:
```text
state
→ explicit render function
```
---
# 16. React Local State
```jsx
import {
useState
} from "react";
function Counter() {
const [
count,
setCount
] =
useState(0);
return (
setCount(
count + 1
)
}
>
Count: {count}
);
}
```
React state update:
```text
requests another render
```
React recalculates component output.
---
# 17. Vue Local State
```vue
Count:
{{ count }}
```
Vue tracks the reactive `count` value used by the template.
Changing it causes dependent UI work.
---
# 18. Local State Translation
```text
Vanilla:
state + explicit update logic
React:
state update → render/reconcile/commit
Vue:
reactive dependency change → affected update
```
The user-visible responsibility is the same.
The runtime mechanism is not.
---
# 19. `ref` Means Different Things in React and Vue
This is an important terminology trap.
React:
```js
const elementRef =
useRef(null);
```
commonly represents a mutable reference that does not itself trigger rendering when `.current` changes.
Vue:
```js
const count =
ref(0);
```
normally creates a reactive value.
These concepts are not equivalent despite sharing the word `ref`.
Vue also has **template refs**, which are much closer to React DOM refs.
---
# 20. Object State
## Vanilla
```js
const state = {
query:
"",
selectedId:
null
};
```
You decide whether mutations require rendering.
---
## React
```jsx
const [
filters,
setFilters
] =
useState({
query:
"",
status:
"all"
});
```
Updates usually create a new value:
```js
setFilters(
current => ({
...current,
query:
"monitor"
})
);
```
Identity matters to React state/update patterns.
---
## Vue
```js
const filters =
reactive({
query:
"",
status:
"all"
});
```
Then:
```js
filters.query =
"monitor";
```
Vue observes reactive property access/mutation.
Again, the programming models differ.
---
# 21. Derived State
Suppose:
```text
subtotal
=
price × quantity
```
Usually do not store all three.
Store:
```text
price
quantity
```
derive:
```text
subtotal
```
This architectural rule is framework-independent.
---
# 22. Vanilla Derived Value
```js
function subtotal(
price,
quantity
) {
return (
price *
quantity
);
}
```
or:
```js
const viewModel = {
get subtotal() {
return (
this.price *
this.quantity
);
}
};
```
---
# 23. React Derived Value
Usually calculate during render.
```jsx
function LineItem({
price,
quantity
}) {
const subtotal =
price *
quantity;
return (
{subtotal}
);
}
```
If the calculation is genuinely expensive and repeated unnecessarily, memoization may be appropriate:
```jsx
const result =
useMemo(
() =>
expensiveTransform(
data
),
[data]
);
```
Do not use an Effect merely to copy derived data into state.
---
# 24. Vue Derived Value
For simple expressions, the template can calculate directly.
For reusable/cached reactive derivation:
```js
const subtotal =
computed(
() =>
price.value *
quantity.value
);
```
Vue tracks dependencies automatically.
---
# 25. Derived-State Rosetta Stone
| Need | Vanilla | React | Vue |
|---|---|---|---|
| Cheap derived value | function/getter | calculate during render | expression/function |
| Cached reactive derivation | custom memoization | `useMemo` when justified | `computed` |
| Store duplicate derived value? | usually no | usually no | usually no |
The principle is more important than the API.
---
# 26. Effects: Synchronizing with Something Outside Normal Rendering
An effect exists when UI state must synchronize with something external.
Examples:
- browser event listener;
- network subscription;
- third-party widget;
- media element;
- timer;
- WebSocket.
Effects should not become a general-purpose “run code when something changes” mechanism for ordinary derivation.
---
# 27. Vanilla Effect
```js
function mountOnlineStatus(
output
) {
function update() {
output.textContent =
navigator.onLine
? "Online"
: "Offline";
}
window.addEventListener(
"online",
update
);
window.addEventListener(
"offline",
update
);
update();
return () => {
window.removeEventListener(
"online",
update
);
window.removeEventListener(
"offline",
update
);
};
}
```
The returned function is cleanup.
---
# 28. React Effect
```jsx
useEffect(
() => {
function handleStatus() {
setOnline(
navigator.onLine
);
}
window.addEventListener(
"online",
handleStatus
);
window.addEventListener(
"offline",
handleStatus
);
return () => {
window.removeEventListener(
"online",
handleStatus
);
window.removeEventListener(
"offline",
handleStatus
);
};
},
[]
);
```
Architectural meaning:
```text
component is synchronized with an external system
```
React Effects should generally not be used merely to calculate render data.
---
# 29. Vue Watcher / Lifecycle Effect
One possibility:
```js
onMounted(
() => {
window.addEventListener(
"online",
update
);
window.addEventListener(
"offline",
update
);
}
);
onUnmounted(
() => {
window.removeEventListener(
"online",
update
);
window.removeEventListener(
"offline",
update
);
}
);
```
For state-change-triggered side effects:
```js
watch(
query,
async value => {
// side effect
}
);
```
or:
```js
watchEffect(
() => {
// reactive dependencies
// used in this effect
}
);
```
---
# 30. Effect Translation Warning
Do not mechanically translate:
```text
React useEffect
→ Vue watchEffect
```
They overlap conceptually but belong to different reactivity/rendering models.
Ask instead:
> What external system or side effect am I synchronizing?
Then choose the most natural mechanism.
---
# 31. Event Handler vs Effect
This distinction is architectural.
User presses:
```text
Buy
```
The purchase request is caused by that event.
Put it in the event path.
Do not create:
```text
state: shouldBuy = true
↓
Effect watches shouldBuy
↓
POST /buy
```
unless architecture truly requires indirection.
This principle holds across Vanilla, React, and Vue.
---
# 32. Lifecycle Setup and Cleanup
A component may acquire resources:
```text
listener
timer
subscription
socket
observer
```
It must release them.
---
## Vanilla
Explicit mount/unmount:
```js
const cleanup =
mountFeature();
cleanup();
```
Custom Elements:
```js
connectedCallback() {
// setup
}
disconnectedCallback() {
// cleanup
}
```
---
## React
Effect setup + returned cleanup:
```jsx
useEffect(
() => {
const connection =
connect();
return () => {
connection.close();
};
},
[]
);
```
---
## Vue
Lifecycle hooks:
```js
onMounted(
() => {
// setup
}
);
onUnmounted(
() => {
// cleanup
}
);
```
Watchers/effects also support cleanup mechanisms for invalidated async work.
---
# 33. Direct DOM Access
Declarative frameworks reduce direct DOM manipulation.
They do not eliminate it.
Legitimate examples:
- focus;
- measurement;
- third-party library integration;
- media control.
---
# 34. Vanilla DOM Reference
You already have direct platform access.
```js
const input =
document.querySelector(
"#search"
);
input.focus();
```
Prefer keeping references when you already created the element rather than repeatedly querying.
---
# 35. React Ref
```jsx
const inputRef =
useRef(null);
function focusSearch() {
inputRef.current
?.focus();
}
return (
```
The exact helper syntax can vary with Vue version/style, but the architectural idea is:
```text
obtain a direct reference to rendered DOM
```
---
# 37. Do Not Use DOM References for Ordinary Data Flow
Weak architecture:
```text
parent queries child's DOM
to discover selected value
```
Stronger architecture:
```text
child reports value
through component API
```
Refs should remain escape hatches.
---
# 38. Conditional Rendering
## Vanilla
```js
if (
user
) {
container.append(
createProfile(
user
)
);
}
```
Or show/hide an existing node:
```js
panel.hidden =
!open;
```
---
## React
```jsx
{
user
? (
onChange(
!checked
)
}
>
Toggle
);
}
```
State lives in the parent.
---
# 45. Controlled Toggle - Vue
```vue
Toggle
```
Parent can use:
```vue
```
A descendant can read the nearest provided value through the React Context API.
Context is useful for tree-wide dependencies.
It is not automatically a replacement for all state management.
---
# 54. Vue Provide / Inject
Provider:
```js
provide(
"locale",
locale
);
```
Descendant:
```js
const locale =
inject(
"locale"
);
```
For larger applications/libraries, Symbol keys help avoid collisions.
Vue's model explicitly resembles dependency injection.
---
# 55. Context and Provide/Inject Are Closest Analogues
Both solve:
```text
make dependency available to descendants
without prop drilling through every intermediate layer
```
But do not overuse them.
Explicit props remain valuable when dependencies are part of the immediate component API.
---
# 56. Dependency Injection Is Not Global State
Good injected dependency:
```text
form controller
theme
locale
API service
```
Potentially poor injected dependency:
```text
every mutable value in the application
```
The pattern should reduce plumbing without hiding ownership.
---
# 57. Reusable Stateful Behavior
Sometimes several components need the same behavior without sharing the same rendered UI.
Examples:
- online status;
- debounced value;
- resize observer;
- API query logic.
---
# 58. Vanilla Reusable Behavior
A normal function or class often suffices.
```js
export function subscribeOnline(
callback
) {
function handle() {
callback(
navigator.onLine
);
}
window.addEventListener(
"online",
handle
);
window.addEventListener(
"offline",
handle
);
handle();
return () => {
window.removeEventListener(
"online",
handle
);
window.removeEventListener(
"offline",
handle
);
};
}
```
---
# 59. React Custom Hook
```jsx
function useOnlineStatus() {
const [
online,
setOnline
] =
useState(
navigator.onLine
);
useEffect(
() => {
function update() {
setOnline(
navigator.onLine
);
}
window.addEventListener(
"online",
update
);
window.addEventListener(
"offline",
update
);
return () => {
window.removeEventListener(
"online",
update
);
window.removeEventListener(
"offline",
update
);
};
},
[]
);
return online;
}
```
A custom Hook packages reusable React stateful behavior.
---
# 60. Vue Composable
```js
export function useOnlineStatus() {
const online =
ref(
navigator.onLine
);
function update() {
online.value =
navigator.onLine;
}
onMounted(
() => {
window.addEventListener(
"online",
update
);
window.addEventListener(
"offline",
update
);
}
);
onUnmounted(
() => {
window.removeEventListener(
"online",
update
);
window.removeEventListener(
"offline",
update
);
}
);
return {
online
};
}
```
A composable packages reusable Vue reactive/lifecycle behavior.
---
# 61. Custom Hook vs Composable
Closest conceptual mapping:
```text
React custom Hook
↔
Vue composable
```
Both can:
- package framework-aware state;
- package lifecycle;
- package derived values;
- package subscriptions.
They are not interchangeable source code.
They share an architectural purpose.
---
# 62. Pure Utility vs Hook/Composable
If code needs no framework reactivity/lifecycle:
```js
export function normalizeSearch(
value
) {
return value
.trim()
.toLowerCase();
}
```
keep it a normal function.
Do not turn every helper into:
```text
useSomething
```
or:
```text
composable
```
Pure domain logic remains easier to test and reuse.
---
# 63. Refs vs State
Use state/reactivity for values that should affect rendered UI.
Use mutable references for values that must persist but do not themselves require a render.
---
## React
State:
```jsx
const [
count,
setCount
] =
useState(0);
```
Mutable reference:
```jsx
const requestId =
useRef(0);
```
Changing:
```js
requestId.current
```
does not by itself request a render.
---
## Vue
Reactive state:
```js
const count =
ref(0);
```
For non-reactive mutable data, use ordinary JavaScript variables/objects where appropriate.
A template ref is specifically for a DOM/component reference.
The terminology differs, so translate by behavior rather than name.
---
# 64. State Machine Thinking
A workflow may have explicit states:
```text
idle
editing
submitting
success
error
```
This can be expressed in every environment.
Vanilla:
```js
let status =
"idle";
```
React:
```jsx
const [
status,
setStatus
] =
useState(
"idle"
);
```
Vue:
```js
const status =
ref(
"idle"
);
```
The architecture is the state transition model.
Framework APIs are storage mechanisms.
---
# 65. Reducer Pattern
A reducer expresses:
```text
current state
+
event/action
→
next state
```
Pure function:
```js
function reducer(
state,
action
) {
switch (
action.type
) {
case "increment":
return {
...state,
count:
state.count + 1
};
default:
return state;
}
}
```
This function is framework-neutral.
React has:
```text
useReducer
```
as a built-in component-state mechanism around reducer logic.
Vue can use the same reducer function inside reactive state management, but does not require one canonical reducer API for local components.
---
# 66. Routing
Routing is not fundamentally a framework feature.
It maps:
```text
URL
↔
application state/view
```
---
# 67. Browser Routing Primitives
Platform tools include:
```text
URL
URLSearchParams
location
history.pushState()
history.replaceState()
popstate
```
Example:
```js
const url =
new URL(
location.href
);
const query =
url.searchParams
.get(
"q"
);
```
Navigation:
```js
history.pushState(
null,
"",
"/products?q=monitor"
);
```
Then application code must render the new route and handle Back/Forward.
---
# 68. React Routing
React itself does not define one complete application router.
React applications commonly use:
- a routing library;
- a React framework with integrated routing.
The architectural concepts remain:
```text
path
parameters
query/search params
nested layouts
navigation
```
Do not confuse a particular router's API with routing itself.
---
# 69. Vue Routing
Vue's official ecosystem commonly uses Vue Router.
It maps:
```text
routes
route params
query
nested views
navigation
```
into Vue components/reactivity.
Again, the platform URL remains the underlying browser contract.
---
# 70. URL State
Same architectural rule in all three:
Use URL state when it should be:
- reload-safe;
- shareable;
- navigable through Back/Forward;
- bookmarkable.
Examples:
```text
search
filters
sort
page
selected tab when navigational
```
---
# 71. URL State Example
Desired URL:
```text
/products?q=monitor&page=2
```
Vanilla:
```js
const params =
new URLSearchParams(
location.search
);
const query =
params.get("q")
?? "";
const page =
Number(
params.get(
"page"
)
?? 1
);
```
React/Vue routers expose convenience APIs around the same URL state.
The architecture should remain understandable without the convenience layer.
---
# 72. Navigation Is Not Just Rendered Component State
Weak:
```text
currentPage = "products"
```
with no URL change.
Now:
- Back may fail;
- refresh may lose state;
- sharing may fail.
If the state represents navigation, use the browser navigation model.
---
# 73. Async Data Fetching
All three ultimately depend on browser/network primitives.
```js
const response =
await fetch(
"/api/products"
);
```
The architectural questions are:
- who starts the request?
- who owns loading/error state?
- is data cached?
- how is stale data handled?
- how is cancellation handled?
- does the framework/server prefetch it?
---
# 74. Vanilla Fetch
```js
async function loadProducts() {
const response =
await fetch(
"/api/products"
);
if (
!response.ok
) {
throw new Error(
"Request failed"
);
}
return (
await response.json()
);
}
```
Then your own controller/view code manages state.
---
# 75. React Fetching
A simple component can fetch through an Effect.
But modern React applications often use:
- router loaders;
- framework server/data APIs;
- server-state libraries;
- server components/framework data mechanisms.
The architectural rule is:
> Avoid creating ad hoc request synchronization in every component when the application has a better data boundary.
---
# 76. Vue Fetching
A component can fetch in lifecycle code or a watcher.
Larger applications often use:
- route-level loading conventions;
- framework data APIs;
- server-state libraries;
- composables.
Again, architecture should centralize repeated request policy.
---
# 77. Do Not Translate Fetching as `useEffect` ↔ `watch`
Those are low-level mechanisms.
The stronger translation is:
```text
Where does the application own server state?
```
Possible answer:
```text
route
server cache
framework loader
feature query module
```
The same question applies in React and Vue.
---
# 78. Loading State
Vanilla:
```js
state.status =
"loading";
render();
```
React:
```jsx
if (
status ===
"loading"
) {
return (
```
All eventually represent browser interaction.
Frameworks normalize integration into their component models.
---
# 86. Event Delegation
Vanilla:
```js
list.addEventListener(
"click",
event => {
const button =
event.target.closest(
"[data-product-id]"
);
if (
!button
) {
return;
}
// ...
}
);
```
React and Vue framework runtimes manage event integration, but event delegation as an application technique may still be useful in direct DOM/custom integration.
Do not assume framework event syntax means browser event propagation disappeared.
---
# 87. Preventing Default Behavior
Vanilla:
```js
event.preventDefault();
```
React:
```jsx
function handleSubmit(
event
) {
event.preventDefault();
}
```
Vue can call it directly or use a template event modifier:
```vue
);
}
```
Architecture is unchanged.
---
# 140. Vue Search Panel
```vue
```
Same architecture:
```text
component owns draft
parent receives search intent
```
---
# 141. What the Search Example Teaches
Do not memorize:
```text
onChange
vs
v-model
```
Notice the deeper invariants:
```text
query draft has one owner
form submission reports intent
input has semantic label
browser form behavior is respected
```
Those concepts survive framework migration.
---
# 142. Comparative Example - Derived Filtered List
Requirements:
```text
products
query
visibleProducts derived from both
```
Do not store `visibleProducts` separately unless there is a strong reason.
---
## Vanilla
```js
function filterProducts(
products,
query
) {
const normalized =
query
.trim()
.toLowerCase();
return products.filter(
product =>
product.name
.toLowerCase()
.includes(
normalized
)
);
}
```
Call when rendering/updating.
---
## React
```jsx
const visibleProducts =
products.filter(
product =>
product.name
.toLowerCase()
.includes(
query
.trim()
.toLowerCase()
)
);
```
If proven expensive:
```jsx
const visibleProducts =
useMemo(
() =>
filterProducts(
products,
query
),
[
products,
query
]
);
```
---
## Vue
```js
const visibleProducts =
computed(
() =>
filterProducts(
products.value,
query.value
)
);
```
The architectural principle is:
```text
derive
rather than
synchronize duplicated state
```
---
# 143. Comparative Example - External Subscription
Requirement:
```text
show online/offline status
```
Source:
```text
browser online/offline events
```
The external system is the browser.
---
## Vanilla
```js
function subscribe(
callback
) {
function update() {
callback(
navigator.onLine
);
}
addEventListener(
"online",
update
);
addEventListener(
"offline",
update
);
update();
return () => {
removeEventListener(
"online",
update
);
removeEventListener(
"offline",
update
);
};
}
```
---
## React
Package the subscription in a Hook or use the appropriate external-store abstraction.
The important structure:
```text
subscribe
read snapshot
cleanup
```
not the exact API.
---
## Vue
Package it in a composable:
```text
reactive status
+
mounted subscription
+
unmounted cleanup
```
Again, the architecture translates.
---
# 144. Comparative Example - Deep Locale Dependency
Requirement:
```text
many descendants need current locale
```
Bad architecture:
```text
pass locale through 11 components
that do not use it
```
Potential approaches:
Vanilla:
```text
explicit service/dependency object
```
React:
```text
Context
```
Vue:
```text
provide/inject
```
But if only one direct child needs locale:
```text
pass it explicitly
```
is still clearer.
---
# 145. Comparative Example - Dialog
Architectural responsibilities:
- open state;
- accessible label;
- focus;
- Escape handling;
- backdrop;
- close intent;
- portal/teleport/body placement if needed.
The framework syntax is secondary.
A design-system Dialog should provide the same behavioral contract whichever implementation technology is used.
---
# 146. Comparative Example - Shared Product Query
Requirement:
```text
ProductDetails
ProductPrice
StockBadge
```
all need Product `P-42`.
Possible architecture:
```text
one server-state query/cache
```
not:
```text
three independent fetch calls
```
React and Vue may use different query libraries or framework loaders.
Vanilla may use a shared request cache.
The architecture is:
```text
deduplicate ownership of remote state
```
---
# 147. When to Stay in Vanilla
Vanilla/platform code is especially strong when:
- behavior is small;
- DOM is mostly static;
- long framework lifecycle is unnecessary;
- interoperability matters;
- the platform already solves the problem.
Examples:
```text
small enhancement
Custom Element widget
simple form behavior
URL helper
domain logic
```
---
# 148. When a Component Framework Helps
A framework becomes useful when the UI has substantial:
- state-driven rendering;
- composition;
- repeated component patterns;
- lifecycle;
- team conventions;
- ecosystem needs.
The decision is not:
```text
Vanilla = simple
framework = professional
```
Both can be engineered well.
The question is whether the runtime/conventions reduce total complexity.
---
# 149. React Mental Translation
When reading React, think:
```text
component function
→ describes UI for current props/state
setState
→ request new rendering work
props
→ external inputs
callback prop
→ child reports intent
children
→ composition
Context
→ deep tree dependency
Effect
→ synchronize with external system
ref
→ mutable/direct reference escape hatch
```
This is more useful than memorizing Hooks independently.
---
# 150. Vue Mental Translation
When reading Vue, think:
```text
component
→ template + reactive logic
props
→ external inputs
emit
→ child reports intent
slot
→ composition
ref/reactive
→ reactive local state
computed
→ reactive derived state
watch/watchEffect
→ reactive side-effect mechanism
provide/inject
→ deep dependency sharing
template ref
→ direct rendered-node reference
```
---
# 151. Vanilla Mental Translation
When reading framework code from a platform perspective, ask:
```text
Where is the state?
What DOM should exist?
Which browser events change state?
What needs cleanup?
What network/storage API is underneath?
```
This prevents framework abstractions from becoming magic.
---
# 152. Migration Thinking - React to Vue
Preserve:
```text
component boundaries
state ownership
domain logic
URL model
server-state model
```
Translate:
```text
props
→ props
callback outputs
→ emits/callbacks as appropriate
children/render props
→ slots/scoped slots
local state
→ ref/reactive
derived render values
→ computed or plain derivation
Context
→ provide/inject where appropriate
custom Hooks
→ composables where appropriate
```
Do not try to reproduce React's render/effect semantics exactly.
---
# 153. Migration Thinking - Vue to React
Preserve:
```text
domain boundaries
state ownership
component APIs
route structure
server-state policy
```
Translate:
```text
props
→ props
emits
→ callback props
slots
→ children/named render props
ref/reactive state
→ useState/useReducer/store
computed
→ render-time derivation/useMemo where justified
provide/inject
→ Context where appropriate
composables
→ custom Hooks where React state/lifecycle is needed
```
Do not expect automatic dependency tracking in ordinary React code.
---
# 154. Migration Thinking - Framework to Vanilla
Do not simply delete framework APIs one by one.
First identify:
```text
component boundaries
state owners
effects
events
composition
```
Then choose platform structures:
```text
modules
DOM functions
Custom Elements
EventTarget
URL APIs
fetch
```
A framework replacement requires recreating the necessary runtime conventions.
---
# 155. Migration Thinking - Vanilla to Framework
Do not wrap every existing function as a component.
Keep:
```text
domain logic
validation
parsers
formatters
API schemas
```
as normal modules.
Move UI lifecycle/state responsibilities into framework components gradually.
This keeps architecture cleaner.
---
# 156. Framework-Neutral Layers
These often remain reusable across React and Vue:
```text
TypeScript domain types
runtime schemas
API clients
business rules
formatters
Intl helpers
design tokens
CSS foundations
test data builders
```
This is one reason separating domain logic from UI runtime is valuable.
---
# 157. Framework-Specific Layers
These often need dedicated implementations:
```text
rendering components
component lifecycle
Context/provide-inject integration
router bindings
framework-specific state integration
```
Do not spend excessive effort pretending these are framework-neutral.
Some coupling is legitimate.
---
# 158. Browser-Platform Layer
Always underneath:
```text
DOM
events
URL
History
HTTP/fetch
storage
workers
Intl
CSS
HTML
accessibility tree
```
React and Vue organize how you use the platform.
They do not replace it.
---
# 159. A Layered Architecture That Survives Framework Change
```mermaid
flowchart TD
A[Product UI Components] --> B[Framework Integration]
B --> C[Domain / Feature Logic]
C --> D[API / Runtime Validation]
C --> E[Design Tokens / CSS Foundations]
D --> F[Web Platform]
E --> F
B --> F
```
The more stable lower layers remain ordinary platform/TypeScript code, the easier framework evolution becomes.
But do not add artificial abstraction merely to claim portability.
---
# 160. Final Comparative Checklist
When you encounter unfamiliar code, ask these questions.
## Components
```text
What is the UI boundary?
```
## Inputs
```text
How does external information enter?
```
## Outputs
```text
How does the component report intent?
```
## State
```text
Who owns mutable information?
```
## Derived values
```text
What can be calculated instead of stored?
```
## Effects
```text
Which external system requires synchronization?
```
## Composition
```text
How does the consumer provide nested UI?
```
## Dependencies
```text
How is deep shared infrastructure provided?
```
## URL
```text
Which state belongs to navigation?
```
## Server data
```text
Who owns remote truth and caching?
```
## Lifecycle
```text
What resources must be cleaned up?
```
## DOM escape hatches
```text
Where is direct platform access required?
```
These questions translate much better than API names.
---
# 161. Compact Translation Dictionary
## `props`
React:
```text
props
```
Vue:
```text
props
```
Vanilla:
```text
arguments/properties/attributes
```
---
## Parent callback
React:
```text
callback prop
```
Vue:
```text
emit or callback prop
```
Vanilla:
```text
callback or CustomEvent
```
---
## `children`
React:
```text
children
```
Vue:
```text
default/named slots
```
Vanilla:
```text
DOM children/native slots/callback content
```
---
## Local reactive value
React:
```text
useState
```
Vue:
```text
ref/reactive
```
Vanilla:
```text
variable/object + explicit update mechanism
```
---
## Derived reactive value
React:
```text
render-time calculation
useMemo if needed
```
Vue:
```text
computed
```
Vanilla:
```text
function/getter/memoized calculation
```
---
## External synchronization
React:
```text
Effect
```
Vue:
```text
watch/watchEffect/lifecycle/composable
```
Vanilla:
```text
subscription/listener/setup code
```
---
## DOM reference
React:
```text
useRef
```
Vue:
```text
template ref
```
Vanilla:
```text
element reference/query
```
---
## Deep tree dependency
React:
```text
Context
```
Vue:
```text
provide/inject
```
Vanilla:
```text
explicit service/module/DI
```
---
## Reusable framework-aware behavior
React:
```text
custom Hook
```
Vue:
```text
composable
```
Vanilla:
```text
module/function/class/controller
```
---
## Form two-way synchronization
React:
```text
value + onChange
```
Vue:
```text
v-model
```
Vanilla:
```text
value/property + input/change listener
```
---
## List identity
React:
```text
key
```
Vue:
```text
:key
```
Vanilla:
```text
your DOM identity/reconciliation strategy
```
---
## Render elsewhere in DOM
React:
```text
Portal
```
Vue:
```text
Teleport
```
Vanilla:
```text
append/move node to target container
```
---
# 162. What Should Not Be Translated One-to-One
Some concepts look similar but should not be equated directly.
## React `useRef` and Vue `ref`
Not the same conceptual default.
## React `useEffect` and Vue `watchEffect`
Overlap, but different runtime models.
## React `useMemo` and Vue `computed`
Both can cache derived work, but Vue computed participates directly in dependency-tracked reactivity.
## React Context and a global store
Context distributes a value through a tree. It is not automatically a full store architecture.
## Vue provide/inject and a global store
Same warning.
## JSX and Vue templates
Both express UI structure, but compiler/runtime behavior differs.
## Virtual DOM
React and Vue may both use virtual DOM concepts, but their reactivity and update strategies are not identical.
---
# 163. What Does Translate Almost Perfectly
These concepts are stable across frameworks:
```text
single source of truth
derive rather than duplicate
keep state close to owner
semantic HTML
accessible names
URL as navigation state
runtime validation at trust boundaries
cancel stale async work
clean up subscriptions
stable component APIs
composition over deep inheritance
avoid premature abstraction
```
These are the architectural ideas worth remembering.
---
# 164. Final Rosetta Stone Diagram
```mermaid
flowchart TD
A[Architectural Responsibility]
A --> B[Inputs]
A --> C[Outputs]
A --> D[State]
A --> E[Derived Values]
A --> F[Effects]
A --> G[Composition]
A --> H[Dependencies]
A --> I[Routing / URL]
A --> J[Server Data]
A --> K[Lifecycle]
B --> L[Vanilla / Platform]
B --> M[React]
B --> N[Vue]
C --> L
C --> M
C --> N
D --> L
D --> M
D --> N
E --> L
E --> M
E --> N
F --> L
F --> M
F --> N
G --> L
G --> M
G --> N
H --> L
H --> M
H --> N
I --> L
I --> M
I --> N
J --> L
J --> M
J --> N
K --> L
K --> M
K --> N
```
The architecture comes first.
The implementation vocabulary comes second.
---
# 165. Closing Perspective
A developer who knows only one framework can easily confuse:
```text
framework habit
```
with:
```text
frontend architecture
```
This appendix is designed to prevent that.
React, Vue, and Vanilla JavaScript differ significantly in their rendering and reactivity models.
But mature applications in all three still need answers to the same questions:
```text
Where does state live?
What is derived?
What is an effect?
Who owns this behavior?
How does a child communicate?
What is the component API?
What belongs in the URL?
Which data comes from the server?
What needs cleanup?
Which dependency should remain explicit?
What should remain private?
```
Those questions are the transferable knowledge.
If you move from React to Vue, do not search only for renamed Hooks.
If you move from Vue to React, do not try to recreate automatic dependency tracking.
If you move to Vanilla JavaScript, do not abandon component boundaries merely because the browser does not impose one component model.
Instead:
1. identify the architectural responsibility;
2. understand the target runtime;
3. express the responsibility naturally in that runtime.
That is the purpose of a Rosetta Stone.
It translates meaning, not merely words.