← कोर्सच्या मुख्य पानाकडे परत

⏮️ आधी काय होते & फायदे-तोटे

प्रत्येक साधनाने काहीतरी वाईट गोष्ट बदलली — आणि तेच साधन कुठेतरी चुकीचे ठरते. प्रत्येक मोठ्या कल्पनेसाठी: आधी जीवन कसे होते, प्रामाणिक फायदे ✅ / तोटे ❌, आणि कुठे वापरावी 👍 विरुद्ध कुठे नाही 👎.

🍦 साधे JavaScript विरुद्ध framework — धडे 05, 07

⏮️ Frameworks आधी (jQuery चे युग, ~2010)

पाने हाताने बदलली जायची: element शोधा, त्याचा मजकूर बदला, तोच आकडा दाखवणाऱ्या इतर तीन जागा बदलायचे लक्षात ठेवा. State फक्त DOM मध्ये राहायचे — आणि भरकटायचे.

✅ फायदे

  • साधे JS: build नाही, bytes नाहीत, upgrade करायला काही नाही; फलक आणि widgets ना ठीक
  • framework: state → view फुकट, components, भागांची परिसंस्था

❌ तोटे

  • साधे JS: ॲप वाढले की render() आणि diffing तुम्हीच लिहावे लागते
  • framework: build पायऱ्या, bundle चे वजन, आवृत्त्यांची घुसळण, framework नुसार भरती

👍 वापरा जेव्हा

  • छोटे पृष्ठभाग, embeds, हा कोर्स — साधे JS
  • तीन components state वाटून घेतात आणि टीम कोड वाटून घेते तेव्हा framework

👎 दोनदा विचार करा जेव्हा

  • एकाच form साठी framework
  • 200 screens च्या उत्पादनासाठी साधे JS

🎨 Utility classes विरुद्ध tokens + components — धडे 03, 08

⏮️ Design tokens आधी

प्रत्येक पानाचा स्वतःचा निळा, स्वतःचा 13px, स्वतःचा margin. Dark mode म्हणजे दुसरे stylesheet जे कोणीच जुळवून ठेवत नव्हते.

✅ फायदे

  • tokens: --accent एकदा बदला, सगळे मागोमाग येते; dark mode म्हणजे अदलाबदल
  • utility classes (Tailwind): लिहायला वेगवान, भरकटणे कठीण, नावांचे वाद नाहीत

❌ तोटे

  • नुसत्या tokens ना पुनरावृत्ती टाळायला components लागतातच
  • utility HTML लांब होते; प्रणाली config मध्ये राहते, तुम्ही वाचता त्या CSS मध्ये नाही

👍 वापरा जेव्हा

  • कोणत्याही पद्धतीखाली tokens — तोच गणवेश
  • पटकन अनेक screens पाठवणाऱ्या टीम्ससाठी utilities

👎 दोनदा विचार करा जेव्हा

  • कुठेही थेट लिहिलेले रंग
  • dark mode साठी दुसरे stylesheet

🧭 Single-page ॲप विरुद्ध server-rendered पाने — धडे 04, 12

⏮️ SPA आधी (~2012)

प्रत्येक क्लिकला पान server वरून पुन्हा यायचे; forms चे state जायचे; ॲप्स कागदपत्रांसारखी वाटायची. मग SPA नी सगळे ब्राउझरमध्ये हलवले — आणि पहिले रंगणे हळू आणि रिकामे झाले.

✅ फायदे

  • SPA: ॲपसारखा संवाद, एकच कवच, दृश्यांमध्ये state टिकते
  • server-rendered / संमिश्र: पहिले रंगणे वेगवान, JS आधीही चालते, सोपे caching, मजकुरासाठी उत्तम

❌ तोटे

  • SPA: मोठे bundles, हळू पहिले रंगणे, SEO आणि a11y ला काळजी लागते
  • server-rendered: सुधारणा केल्याशिवाय पूर्ण reload; server वर जास्त काम

👍 वापरा जेव्हा

  • लोक ज्यात दिवसभर असतात त्या साधनांसाठी SPA (dashboards, editors)
  • मजकूर, forms, सार्वजनिक काहीही — server-rendered किंवा संमिश्र

👎 दोनदा विचार करा जेव्हा

  • ब्लॉगसाठी SPA
  • प्रत्येक कळेसाठी पूर्ण reload

♿ सुलभता — धडा 06

⏮️ सुलभता चेकलिस्ट होण्याआधी

फलक एकाच प्रकारच्या वाचकासाठी बांधले जायचे: माउस, दृष्टी, वेगवान जोडणी. बाकी सगळे वळसे घालायचे — किंवा वापरूच शकायचे नाहीत.

✅ फायदे

  • semantic HTML keyboard, focus आणि घोषणा फुकट देते
  • तेच semantics चाचण्या आणि शोधालाही चालवतात
  • अनेक ठिकाणी कायदेशीर बंधन; सगळीकडे योग्य गोष्ट

❌ तोटे

  • नंतर बसवणे महाग; चुकीचे ARIA गोष्टी बिघडवते
  • नुसत्या linter नव्हे, खऱ्या सहाय्यक तंत्रज्ञानाने चाचणी लागते

👍 वापरा जेव्हा

  • नेहमी — ते नीट केलेले HTML आहे
  • प्रत्येक form, प्रत्येक स्वतः बनवलेले widget

👎 दोनदा विचार करा जेव्हा

  • <button> वापरण्याऐवजी <div> वर ARIA लावणे
  • a11y शेवटच्या sprint चे काम म्हणून

🧪 End-to-end चाचण्या — धडा 10

⏮️ ब्राउझर automation आधी

प्रत्येक release आधी कोणीतरी ॲपमधून क्लिक करत जायचे आणि नेमका महत्त्वाचा मार्ग चुकायचा.

✅ फायदे

  • खरा ब्राउझर, खरे वापरकर्ता-मार्ग — प्रत्येक चाचणीमागे सर्वाधिक विश्वास
  • unit चाचण्या न पकडणारे integration bugs पकडतात

❌ तोटे

  • हळू, class नावांवर लिहिल्यास अस्थिर, चालू stack लागते
  • मोठ्या संख्येने सांभाळायला महाग

👍 वापरा जेव्हा

  • CI मध्ये मोजके सोनेरी मार्ग (विद्यार्थी नोंदवा)
  • प्रत्येक deploy वर smoke तपासण्या

👎 दोनदा विचार करा जेव्हा

  • फक्त शेकडो e2e चाचण्याच असणे
  • roles आणि labels ऐवजी CSS classes तपासणे

🚚 Front end साठी static hosting विरुद्ध server — धडा 12

⏮️ Static hosting + CDN आधी

Front ends API च्याच application server वरून दिली जायची — प्रत्येक पान-दर्शन त्यावर आदळायचे, प्रत्येक deploy त्याला restart करायचा.

✅ फायदे

  • CDN वरच्या फाइल्स: स्वस्त, सगळीकडे वेगवान, patch करायला काही नाही
  • hash ने cache-busting मुळे deploys अखंड आणि rollbacks क्षुल्लक होतात

❌ तोटे

  • प्रत्येक वापरकर्त्यासाठी बदलणाऱ्या HTML ला server किंवा edge functions लागतात
  • SPA च्या routing ला fallback नियम लागतो

👍 वापरा जेव्हा

  • सगळ्यांसाठी बहुतांश सारखाच असलेला कोणताही फलक — ही अख्खी शाळा
  • API मधून data आणणारी dashboards

👎 दोनदा विचार करा जेव्हा

  • प्रत्येक विनंतीला वैयक्तिक HTML
  • static फाइल्समध्ये भाजलेली गुपिते

🎽 Design system — धडा 08

⏮️ Design systems आधी

प्रत्येक टीम स्वतःची buttons काढायची; उत्पादन पाच उत्पादनांसारखे दिसायचे; प्रत्येक नवी screen अंतर पुन्हा ठरवायची.

✅ फायदे

  • बैठकांशिवाय सुसंगती; tokens + components + नियम
  • वेगवान screens, कमी a11y घसरणी
  • डिझायनर आणि डेव्हलपर एकच शब्दसंग्रह वापरतात

❌ तोटे

  • प्रणालीला मालक आणि release प्रक्रिया लागते
  • एकाच छोट्या ॲपसाठी अतिरेकी रचना

👍 वापरा जेव्हा

  • अनेक टीम्स किंवा अनेक screens
  • ब्रँडची सुसंगती महत्त्वाची

👎 दोनदा विचार करा जेव्हा

  • पाच पानांची साइट — tokens पुरेसे
  • दोन buttons साठी प्रचंड बाहेरची प्रणाली स्वीकारणे