🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🧰 धडा 07 — Frameworks: त्याच कल्पना, automate केलेल्या

📍 तुम्ही इथे आहात: 12 पैकी धडा 07 — भाग 2 सुरू! · मागील: lesson-06-accessibility · पुढील: lesson-08-design-tokens

📦 या ब्रँचमध्ये काय आहे

धडे 01–06, आणि त्यासोबत React, Vue आणि Svelte ची प्रामाणिक सफर: ते काय automate करतात (धडा 05 मधले सगळे), त्यांची किंमत काय, आणि तुमच्याकडे आधीच असलेल्या तीन साध्या files कधी योग्य उत्तर असतात.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

तुम्ही फलक हाताने बांधला. प्रत्येक वेळी state बदलली की तुम्ही render() बोलवलेत, ज्याने यादी पुन्हा बांधली. पाच cards साठी हे सुंदर चालते. पाचशे cards, वीस components आणि ते बदलणारे सहा लोक असले की दोन अडचणी येतात: सगळे पुन्हा बांधणे वाया जाणारे काम आहे, आणि "render() बोलवायला विसरू नका" हा नियम माणसे विसरतात.

framework 🧰 नेमके तेच काम हाती घेतो: दिलेल्या state साठी UI कसा दिसायला हवा ते तुम्ही जाहीर करता, आणि तो DOM मधले सगळ्यात कमी बदल शोधून काढतो — आपोआप, प्रत्येक वेळी state बदलली की. एवढेच. धडा 05 मध्ये शिकलेले मनातले चित्र बदलत नाही; त्याला फक्त एक इंजिन मिळते.

React ⚛️ — components म्हणजे JSX परत करणारी functions; useState state धरते; ती बदलली की function पुन्हा चालते आणि React निकालाचा diff करतो. सगळ्यात मोठी ecosystem, सगळ्यात जास्त नोकऱ्या, सगळ्यात जास्त संकल्पना (hooks, effects, keys).
Vue 🟢 — single-file components (template + script + style); reactive refs; data बदलला की template बदलतो. सुरुवात सोपी.
Svelte 🧡 — एक compiler: तुमचा component compile होऊन नाहीसा होतो आणि थेट DOM updates उरतात, त्यामुळे runtime diffing नाही. छोटे bundles, साधा दिसणारा code.
Vanilla 🍦 — जे तुमच्याकडे आहे ते. शून्य bytes, शून्य build, upgrade करायला काहीच नाही.

अंगठ्याचा नियम: तीन components state शेअर करेपर्यंत vanilla वरच राहा. मग team आणि ecosystem पाहून निवडा, benchmark पाहून नाही.

🗺️ आकृती

flowchart LR
    ideas["🧠 lesson 05: state → components → render()"]
    r["⚛️ React — JSX + hooks + virtual DOM diff"]
    v["🟢 Vue — templates + reactivity"]
    s["🧡 Svelte — compiles to direct DOM updates"]
    van["🍦 vanilla — you call render() yourself"]
    ideas --> r & v & s & van
    cost["all of them add: a build step, a bundle, an upgrade path, a hiring pool"]

❓ काय

प्रत्येक framework तुम्हाला काय देतो: state बदलल्यावर आपोआप re-render, components ची जोडणी, keyed list diffing, event binding, आणि बहुतेक वेळा एक router आणि build toolchain.
JSX ही "हा component काय परत करतो" हे लिहिण्याची syntax आहे; ती HTML नाही — className, onClick, आणि {} मधले expressions.
Keys: lists render करताना, DOM nodes पुन्हा बांधण्याऐवजी हलवण्यासाठी frameworks ना प्रत्येक item साठी स्थिर key लागते (आपला student.id).
किंमत: एक build step (Vite, Next, Nuxt, SvelteKit), प्रत्येक visitor ला पाठवले जाणारे bundle चे वजन, version upgrades, आणि framework-विशिष्ट bugs.
Server-side rendering / meta-frameworks (Next.js, Nuxt, SvelteKit) पहिला paint पुन्हा server वर नेतात — trade-offs पानावरचा SPA trade-off.
तुम्ही मिसळू शकता: बहुतेक static site आणि त्यात एक interactive बेट (एक web component किंवा छोटा mount point) ही पूर्णपणे चांगली architecture आहे — या शाळेची स्वतःची पाने हेच करतात.

🤔 का

कारण "कोणता framework" हा front-end मधला सगळ्यात मोठ्या आवाजातला प्रश्न आहे आणि जवळजवळ कधीच महत्त्वाचा नसतो. महत्त्वाचा प्रश्न असा: तुम्हाला state → view, keys, आणि तुम्ही phone ला काय पाठवत आहात हे समजते का. आता ते तुम्हाला समजते — म्हणून तुम्ही खऱ्या कारणांसाठी framework निवडू शकता, किंवा आत्मविश्वासाने नाकारू शकता.

🔧 कसे (या repo मध्ये — भाषांतराचा सराव)

आपले StudentCard आणि render() framework code वर एकास-एक बसतात. React मध्ये तोच फलक साधारण असा दिसतो:

function StudentCard({ s }) {                 // our StudentCard(s)
  return <li className="card"><strong>{s.name}</strong> <span>class {s.class}</span></li>;
}
function Board() {
  const [students, setStudents] = useState([]);   // our state.students
  const [filter, setFilter] = useState("");       // our state.filter
  useEffect(() => { fetch("/api/students").then(r => r.json()).then(d => setStudents(d.items)); }, []);
  const rows = students.filter(s => !filter || s.class === filter);   // derived, not stored (lesson 05!)
  return <ul className="cards">{rows.map(s => <StudentCard key={s.id} s={s} />)}</ul>;
}

कुठेही render() call नाही: setStudents हाच तो call आहे.

🧪 करून पाहा

# 1) on paper (10 min): translate the enrol form into React — which lines are state, which are the component,
#    where does e.preventDefault() go, and what replaces our manual render()?
# 2) count the cost: our board ships ~9 KB of HTML+CSS+JS, uncompressed and unminified.
wc -c ui/index.html ui/styles.css ui/app.js
#    a "hello world" React app ships ~140 KB of framework before your code. Both numbers are fine — know which you are paying.
# 3) the honest test: does your next feature need shared state across three components? If not, stay vanilla.

✅ तपासा — तुम्हाला काय दिसायला हवे

तुमच्या React आराखड्यात app.js सारखेच चार भाग आहेत (state, component, derived list, fetch करणारा effect) आणि हाताने repaint नाही. Byte count दाखवतो की संपूर्ण फलक काही kilobytes चा आहे.

🏁 तुम्ही आत्ताच काय सिद्ध केले

Frameworks धडा 05 ची जागा घेत नाहीत, तर तो automate करतात — म्हणून तुम्ही त्यांपैकी कोणताही वाचू शकता, आणि एकही न निवडण्याचे समर्थन करू शकता.

⚠️ नेहमीच्या चुका

team आणि ecosystem ऐवजी benchmark पाहून framework निवडणे
state शेअर करणारा तिसरा component येण्याआधीच framework घेणे
derived data state मध्ये साठवणे (तोच bug, आता hooks सह)
lists मध्ये key नसणे किंवा index वर आधारित key — सूक्ष्म, विचित्र क्रम बिघडवणारे bugs
पाच पानांच्या static site साठी meta-framework पाठवणे

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: framework ची निवड team मधल्या बहुतेक लोकांपेक्षा जास्त टिकते. ज्या teams ना खालच्या कल्पना समजतात त्याच उत्पादक राहतात, कारण त्या rewrite न करता upgrade, migrate किंवा बाहेर पडू शकतात.

⏭️ पुढे

तुम्ही कसेही render करा, फलकाला एकच रूप हवे: design systems आणि tokens — एका पत्रकातून रंग, अंतर, अक्षरे आणि dark mode.

git checkout lesson-08-design-tokens

🧰 Lesson 07 — Frameworks: the same ideas, automated

📍 You are here: Lesson 07 of 12 — Part 2 begins! · Previous: lesson-06-accessibility · Next: lesson-08-design-tokens

📦 What's in this branch

Lessons 01–06, plus the honest tour of React, Vue and Svelte: what they automate (everything in lesson 05), what they cost, and when the three plain files you already have are the right answer.

🧒 Explain like I'm 5

You built the board by hand. Every time state changed you called render(), which rebuilt the list. That works beautifully for five cards. For five hundred cards, twenty components and six people editing them, two problems appear: rebuilding everything is wasteful, and "remember to call render()" is a rule humans forget.

A framework 🧰 takes over exactly that: you declare what the UI should look like for a given state, and it works out the smallest set of DOM changes — automatically, every time state changes. That is all. The mental model you learned in lesson 05 does not change; it gets an engine.

React ⚛️ — components are functions returning JSX; useState holds state; changing it re-runs the function and React diffs the result. Biggest ecosystem, most jobs, most concepts (hooks, effects, keys).
Vue 🟢 — single-file components (template + script + style); reactive refs; the template updates when the data does. Gentle on-ramp.
Svelte 🧡 — a compiler: your component compiles away into direct DOM updates, so there is no runtime diffing. Small bundles, plain-looking code.
Vanilla 🍦 — what you have. Zero bytes, zero build, nothing to upgrade.

The rule of thumb: stay vanilla until three components share state. Then pick by team and ecosystem, not by benchmark.

🗺️ Diagram

flowchart LR
    ideas["🧠 lesson 05: state → components → render()"]
    r["⚛️ React — JSX + hooks + virtual DOM diff"]
    v["🟢 Vue — templates + reactivity"]
    s["🧡 Svelte — compiles to direct DOM updates"]
    van["🍦 vanilla — you call render() yourself"]
    ideas --> r & v & s & van
    cost["all of them add: a build step, a bundle, an upgrade path, a hiring pool"]

❓ What

What every framework gives you: automatic re-render on state change, component composition, keyed list diffing, event binding, and usually a router and a build toolchain.
JSX is a syntax for "what this component returns"; it is not HTML — className, onClick, and expressions in {}.
Keys: when rendering lists, frameworks need a stable key per item to move DOM nodes instead of rebuilding them (our student.id).
Costs: a build step (Vite, Next, Nuxt, SvelteKit), bundle weight shipped to every visitor, version upgrades, and framework-specific bugs.
Server-side rendering / meta-frameworks (Next.js, Nuxt, SvelteKit) put the first paint back on the server — the SPA trade-off from the trade-offs page.
You can mix: a mostly-static site with one interactive island (a web component or a small mount point) is a perfectly good architecture — it is what this School's own pages do.

🤔 Why

Because "which framework" is the loudest question in front-end and almost never the important one. The important one is whether you understand state → view, keys, and what you are shipping to a phone. You now do — so you can pick a framework for real reasons, or decline one with confidence.

🔧 How (in this repo — the translation exercise)

Our StudentCard and render() map one-to-one onto framework code. In React the same board is roughly:

function StudentCard({ s }) {                 // our StudentCard(s)
  return <li className="card"><strong>{s.name}</strong> <span>class {s.class}</span></li>;
}
function Board() {
  const [students, setStudents] = useState([]);   // our state.students
  const [filter, setFilter] = useState("");       // our state.filter
  useEffect(() => { fetch("/api/students").then(r => r.json()).then(d => setStudents(d.items)); }, []);
  const rows = students.filter(s => !filter || s.class === filter);   // derived, not stored (lesson 05!)
  return <ul className="cards">{rows.map(s => <StudentCard key={s.id} s={s} />)}</ul>;
}

No render() call anywhere: setStudents is the call.

🧪 Try it

# 1) on paper (10 min): translate the enrol form into React — which lines are state, which are the component,
#    where does e.preventDefault() go, and what replaces our manual render()?
# 2) count the cost: our board ships ~9 KB of HTML+CSS+JS, uncompressed and unminified.
wc -c ui/index.html ui/styles.css ui/app.js
#    a "hello world" React app ships ~140 KB of framework before your code. Both numbers are fine — know which you are paying.
# 3) the honest test: does your next feature need shared state across three components? If not, stay vanilla.

✅ Verify — what you should see

Your React sketch has the same four pieces as app.js (state, component, derived list, effect that fetches) and no manual repaint. The byte count shows the board is a few kilobytes in total.

🏁 What you just proved

Frameworks automate lesson 05 rather than replacing it — so you can read any of them, and justify choosing none.

⚠️ Common mistakes

picking a framework by benchmark instead of by team and ecosystem
reaching for one before the third shared-state component
storing derived data in state (the same bug, now with hooks)
missing or index-based keys in lists — subtle, ugly reordering bugs
shipping a meta-framework to serve a five-page static site

🏭 Why this matters in production: framework choice outlives most of the team. The teams that stay productive are the ones who understand the ideas underneath, so they can upgrade, migrate or opt out without a rewrite.

⏭️ Next

However you render it, the board needs one look: design systems and tokens — colours, spacing, type and dark mode from one sheet.

git checkout lesson-08-design-tokens

← Previousaccessibility Next →design tokens

This page is the lesson's README from the lesson-07-frameworks branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.