प्रोग्रेसिव एन्हांसमेंट से मजबूत फ्रंटएंड बनाना

 (gov.uk)
1 पॉइंट द्वारा GN⁺ 2024-09-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GOV.UK सेवाओं को browser, device और connection की स्थिति अलग-अलग होने पर भी उपयोगकर्ताओं को अपना मुख्य काम पूरा करने देने के लिए HTML-first तरीके से काम करना चाहिए, और सभी सरकारी सेवाओं में प्रोग्रेसिव एन्हांसमेंट आवश्यक है
  • HTML में fault tolerance होती है: यह अनजान markup को अनदेखा करके parsing जारी रखता है, इसलिए पुराने browsers या कुछ errors वाले pages में भी बुनियादी navigation और functionality बने रहने की संभावना अधिक होती है
  • CSS और JavaScript अधिक नाजुक layers हैं: CSS में किसी अनजान selector पर पूरा rule set अनदेखा हो सकता है, और JavaScript में unsupported syntax या API error के कारण बाकी code execution रुक सकता है
  • JavaScript का उपयोग core functionality को replace करने के बजाय HTML और CSS को enhance करने के लिए होना चाहिए; autocomplete भी <select> जैसे basic element के ऊपर बनाया जाना चाहिए ताकि failure होने पर भी उपयोगकर्ता काम जारी रख सके
  • Client-side JavaScript frameworks और SPA performance, accessibility और maintenance का बोझ पैदा कर सकते हैं, इसलिए जटिल UI न होने वाली GOV.UK Design System-केंद्रित सेवाओं में इनकी जरूरत नहीं है

प्रोग्रेसिव एन्हांसमेंट के बुनियादी सिद्धांत

  • अच्छी quality वाली service को मजबूत तरीके से बनाया जाना चाहिए, और progressive enhancement वह approach है जिसमें websites और applications को HTML से ही काम करने लायक बनाया जाता है
  • HTML से basic behavior बनाने के बाद ही CSS और JavaScript जैसी layers जोड़ी जाती हैं
  • सभी सरकारी सेवाओं को progressive enhancement का पालन करना चाहिए; भले ही service का कोई हिस्सा या upper-level service JavaScript की मांग करे, यह सिद्धांत बना रहना चाहिए
  • progressive enhancement से मिलने वाले फायदे ये हैं
    • service ज्यादा मजबूत और उच्च quality की बनती है
    • browser या device चाहे जो हो, उसके काम करने की संभावना बढ़ती है
    • सबसे basic functionality काम करती है और उपयोगकर्ता की core needs पूरी होती हैं
    • semantic markup जैसी best practices को बढ़ावा देकर accessibility बेहतर होती है
    • device या connection constraints वाले उपयोगकर्ताओं के लिए भी service इस्तेमाल करना आसान होता है
  • COTS solution इस्तेमाल करते समय या service को किसी external supplier को सौंपते समय purchasing strategy की requirements में progressive enhancement शामिल करने पर विचार करना चाहिए

HTML से शुरू करना

  • सरकारी सेवाओं को सिर्फ HTML से भी काम करना चाहिए
  • ऐसी services के उदाहरण जिन्हें सिर्फ HTML से भी काम करना चाहिए
    • transactional services जैसे forms, जिनमें उपयोगकर्ता सरकार को जानकारी देता है
    • smart answers प्रकार की services, जैसे Registering a birth abroad
    • GOV.UK की foreign travel advice जैसी content-based websites
  • HTML layer design के स्तर पर fault-tolerant होती है
    • browsers वह markup ignore करते हैं जिसे वे समझ नहीं पाते और जहाँ तक संभव हो parsing जारी रखते हैं
    • HTML में bug हो या केवल modern browsers में मौजूद feature इस्तेमाल किया गया हो, तब भी पुराने browsers में service load होने की संभावना अधिक होती है
  • उपयोगकर्ता सिर्फ HTML से भी service में navigation कर सकने चाहिए
  • सही semantic markup का उपयोग करना चाहिए और source order और document outline को logical तरीके से व्यवस्थित करना चाहिए

CSS का उपयोग कैसे करें

  • CSS का उपयोग service को GOV.UK जैसा दिखाने के लिए styling में किया जा सकता है
  • CSS layer अपेक्षाकृत fault-tolerant होती है
    • browsers उन individual declarations को ignore करते हैं जिन्हें वे समझ नहीं पाते
    • modern browsers में ही मौजूद properties इस्तेमाल करने पर केवल वह declaration ignore हो सकती है
  • हालांकि अगर browser को ऐसा selector मिले जिसे वह समझ नहीं पाता, तो वह पूरा rule set ignore कर सकता है
  • CSS कई कारणों से load नहीं हो सकती
  • JavaScript load न होने पर भी site सही दिखे, इसके लिए CSS-in-JS जैसी techniques से बचना चाहिए

JavaScript का उपयोग कैसे करें

  • JavaScript का उपयोग service में interactive elements जोड़ने के लिए किया जा सकता है
  • JavaScript layer fault-tolerant नहीं होती
    • अगर उपयोगकर्ता का browser unsupported syntax इस्तेमाल होते देखे या कोई API call हो जिसे वह support नहीं करता, तो error आता है
    • error आने पर बाकी JavaScript execute नहीं होती
  • इस संभावना को ध्यान में रखे बिना service design करने से उपयोगकर्ता service इस्तेमाल नहीं कर पाएगा
  • कई browsers में JavaScript ठीक से काम करे, इसकी संभावना बढ़ाने के तरीके ये हैं
    • browser APIs पर feature detection इस्तेमाल करना
    • modern browser features के लिए polyfill शामिल करना
    • JavaScript को ऐसे common syntax में transpile करना जिसे target browsers समझ सकें
    • automated tests या linter इस्तेमाल करना
    • पुराने या कम performance वाले devices सहित नियमित manual testing करना
  • transpilation और polyfills JavaScript का size काफी बढ़ा सकते हैं
    • संबंधित trade-offs पर विचार करना चाहिए
    • browser usage बदलता रहता है, इसलिए decisions की नियमित रूप से दोबारा समीक्षा करनी चाहिए
  • जहाँ संभव हो, JavaScript को वही core functionality देने वाले HTML और CSS को enhance करना चाहिए
    • autocomplete को <select> element या समान basic element को enhance करने के तरीके से बनाया जा सकता है
    • JavaScript fail होने पर भी उपयोगकर्ता जरूरी काम जारी रख सकता है

JavaScript के विकल्प और पूरक channels

  • अगर लगे कि service सिर्फ JavaScript से ही बन सकती है, तो पहले यह जांचना चाहिए कि HTML और CSS से बना सरल solution user needs पूरी कर सकता है या नहीं
  • अगर interactive graph JavaScript से देने का विचार हो, तो इन विकल्पों पर विचार किया जा सकता है
    • data को table में दिखाना
    • data export की अनुमति देना ताकि उसे दूसरे applications में analyze किया जा सके
    • graph को image के रूप में पहले से render करना
  • अगर service की core functionality JavaScript के बिना नहीं दी जा सकती, तो users के लिए service का उपयोग करने के दूसरे channels उपलब्ध कराने चाहिए
    • phone
    • office visit

Client-side JavaScript frameworks

  • अगर service ज्यादातर GOV.UK Design System components से बनी है और complex UI नहीं है, तो client-side JavaScript framework की जरूरत नहीं है
  • GOV.UK Design System components में framework के बिना service में JavaScript लाने का तरीका शामिल है
  • Client-side JavaScript frameworks complex UI बनाने में मदद कर सकते हैं, लेकिन साथ ही कई समस्याएँ भी ला सकते हैं
  • framework इस्तेमाल करने से हो सकने वाली समस्याएँ ये हैं
    • पूरे codebase का size बढ़ाना और processing को client पर shift करना, जिससे slow networks या low-performance devices वाले users को performance issues हो सकते हैं
    • ऐसे third-party code पर निर्भरता, जिस पर developers का control नहीं होता; framework में बदलाव के अनुसार service में बड़े changes की जरूरत पड़ सकती है
    • समय के साथ framework की popularity घटने पर maintenance के लिए जरूरी skills वाले लोग मिलना मुश्किल हो सकता है
  • अगर JavaScript framework इस्तेमाल करते हैं, तो ये conditions पूरी होनी चाहिए
    • evidence के आधार पर justify कर सकें कि JavaScript का उपयोग users को क्या benefit देता है
    • negative impacts को समझते हों और उन्हें mitigate कर सकें
    • यह विचार करें कि benefits potential problems से बड़े हैं या नहीं
    • framework का उपयोग केवल UI के उन हिस्सों में करें जिन्हें सिर्फ HTML और CSS से नहीं बनाया जा सकता
    • UI के हर हिस्से को अलग component के रूप में design करें
  • components को अलग करने से JavaScript load failure होने पर केवल वही single component fail होता है और page का बाकी हिस्सा सामान्य रूप से load होता है
  • JavaScript का उपयोग केवल HTML और CSS को enhance करने के लिए होना चाहिए, और fail होने पर भी users service का उपयोग कर सकें

CSS और JavaScript fail क्यों हो सकते हैं

  • CSS और JavaScript कई कारणों से load या execute नहीं हो सकते
    • temporary network error
    • ad blockers जैसे third-party browser extensions
    • content delivery network इस्तेमाल करते समय third-party supplier downtime
    • DNS lookup failure
    • browser update से आया bug
    • उसी page पर जानबूझकर चल रहे third-party JavaScript में bug
    • banks या government departments जैसी बड़ी संस्थाओं में इस्तेमाल होने वाले enterprise firewalls द्वारा content को block, remove या change करना
    • mobile network operators द्वारा load time और bandwidth usage कम करने के लिए content बदलना
    • personal firewall या antivirus software द्वारा content बदलना या block करना
    • insecure connection पर internet provider द्वारा page में अपना code inject करना, और उस code का service code से conflict होना
  • कुछ users जानबूझकर browser features बंद कर सकते हैं
  • service को users की choice का सम्मान करना चाहिए, और ऐसे users भी इसे इस्तेमाल कर सकें

Single Page Applications (SPA) से क्यों बचना चाहिए

  • service को Single Page Application (SPA) के रूप में नहीं बनाना चाहिए
  • SPA में service के अंदर page loading को browser नहीं, बल्कि JavaScript handle करता है
  • SPA बहुत कम benefits लाते हैं और accessibility को नुकसान पहुँचा सकते हैं
    • assistive technologies इस्तेमाल करने वाले users को new page पर जाने पर वही context change हुआ है, यह पता नहीं चल सकता
    • page navigation के समय focus handle नहीं हो सकता
    • users browser के back और forward buttons से navigate नहीं कर सकते
    • network connection interruption जैसे errors से users recover नहीं कर सकते

Testing criteria

  • अगर service के कुछ components JavaScript या JavaScript framework पर काफी निर्भर हैं, तो यह जांचना चाहिए कि वे
  • जहाँ संभव हो, यह accessibility testing से जांचना चाहिए कि वे components service के अंदर ठीक से काम करते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-09-30
Hacker News की राय

  • “अगर आप JavaScript framework इस्तेमाल करते हैं, तो आपको सबूत के आधार पर यह सही ठहराने में सक्षम होना चाहिए कि JavaScript का उपयोग यूज़र को क्या फायदा देता है” — अरे, थोड़ा शांत हो जाइए

    • सच में, क्या आप चाहते हैं कि software complexity ढह जाए और डेवलपर्स के झुंड बेरोज़गार हो जाएँ
    • सिर्फ़ इस्तेमाल करने की बात नहीं है, उसे लगातार चलता रखने के लिए हमेशा देखते रहना पड़ता है

  • एक अच्छा मानदंड यह है कि अगर ऐप desktop app की तरह offline-first तरीके से काम कर सकता है, तो उसे single page application बनाना ठीक है
    Photopea, Google Docs/Sheets, tldraw जैसे उदाहरण हैं, और ऐसे मामलों में यह multi-page browser app से ज़्यादा तेज़ और बेहतर हो सकता है
    ऐसा करने से सबसे बड़ी कमियां—पेजों के बीच navigation और internet connection की ज़रूरत—हट जाती हैं
    लेकिन अगर ऐप को internet connection और कई पेजों की ज़रूरत है, तो बेहतर है कि browser को navigation को failure-resistant तरीके से संभालने दिया जाए

    • अच्छा point है। web platform अब websites और cross-platform GUI दोनों का काम संभाल रहा है
      अगर offline या कई operating systems पर desktop GUI जैसी चीज़ चाहिए, तो single page application फ़ायदेमंद है; और अगर बस website बनानी है, तो single page application शायद सबसे अच्छा विकल्प नहीं है
    • “ज़्यादा तेज़” अब पुरानी धारणा है। अब HTML में ही बहुत सारे tools हैं
      single page application अपने आप में अलग चीज़ है, और उसे बनाने की complexity अलग
    • फिर भी testing बहुत करनी पड़ती है। खासकर gov.uk जैसे context में, अब भी ऐसे काफ़ी users हैं जो iOS 15 Safari जैसे पुराने phones इस्तेमाल करते हैं जिनके browsers अब update नहीं होते

  • 90 के दशक में बच्चा था तब web शुरू किया था। CSS या JS क्या हैं, यह भी नहीं जानता था, और JS को बस कोई magic script समझता था जिसे copy-paste करके कुछ blink कराया जा सकता है
    बाद में local businesses के लिए dynamic sites PHP में बनाए, और तब JS और CSS भी कुछ हद तक सीखा
    फिर IE6 जैसे सबसे खराब browsers में चलाने में बहुत ज़्यादा समय लगने से परेशान होकर web development छोड़ दिया
    करीब 6 साल दूर रहने के बाद 2015 के आसपास वापस आया, क्योंकि समझ आया कि जो काम कर रहा था उसमें web server उपयोगी होगा
    लेकिन यह देखकर झटका लगा कि दुनिया HTML और CSS के बारे में पहले जानी हुई बहुत-सी बातें भूल चुकी थी
    पहले हम site के लिए कई stylesheets बनाते थे, पहले उसे JS के बिना काम करने लायक बनाते थे और फिर JS को enhancement की तरह जोड़ते थे, लेकिन वह तरीका भुला दिया गया
    मैंने देखा कि web developers form validation पूरी तरह JS में ही करते हैं और server पर कुछ भी नहीं करते; हैरानी की बात है कि यह आज भी आम है
    server validation करे और JS सिर्फ़ उसका result दिखाए—यह आम pattern ज़्यादा दिखता नहीं। लगता है सब duplicate implementation करते हैं या server validation बिल्कुल नहीं करते
    यह सब देखने के बाद web पर लोग जो कर रहे थे, वह मुझे अब प्रभावित नहीं करता था। यह वह web नहीं था जिसे मैं जानता था, बस JS से बने “applications” थे, और web-first की वकालत करना हारती हुई लड़ाई थी

    • मेरा अनुभव भी कुछ ऐसा ही है
      बचपन में HTML 3.2/XHTML और CSS से शुरू किया, कुछ साल बाद Django + jQuery का काम किया और फिर infra की तरफ़ आकर्षित हो गया
      करीब एक साल पहले web development team के साथ काम करते हुए मैंने देखा कि वे क्या कर रहे हैं, और मुझे अब कुछ भी समझ नहीं आया
      complexity बहुत ज़्यादा थी, और लगता था कि उनका ज़्यादातर समय build time घटाने, dependency issues सुलझाने, अजीब TypeScript समस्याएं संभालने, कई components में error handling जैसी complexity management में जाता है
      Django+jQuery के दिनों में अभी भी ध्यान उस चीज़ पर था जिसे user देख और इस्तेमाल कर सके
    • username input 16 characters से कम है या नहीं, यह check करने के लिए server को unnecessary request भेजने से रोका जा सकता है, इसलिए मुझे लगता है कि client validation server load घटाता है
      बेशक client पर कभी भरोसा नहीं किया जा सकता, इसलिए बाद में server पर फिर से validation करना ही होगा
      server load कम करना उपयोगी है

  • सलाह अच्छी है, लेकिन “assistive technology user जब नए page पर जाता है तो वही context change पता नहीं चल सकता”, “page transition पर focus handle नहीं कर सकता”, “browser के back/forward buttons से navigate नहीं कर सकता”, “network connection टूट जाए तो error से recover नहीं कर सकता” — ये बातें strictly speaking सच नहीं हैं, है न
    बहुत-सी, शायद अधिकतर single page applications इस पर ध्यान नहीं देतीं, लेकिन single page application में भी ये चीज़ें implement की जा सकती हैं

    • लेकिन pure HTML में ये चीज़ें कुछ हद तक by default मिलती हैं
      जैसे ही आप single page application के दायरे में जाते हैं, उसी स्तर पर लौटने के लिए बहुत सारे पहिए फिर से बनाने पड़ते हैं, या native features को JS replacements से बदलना पड़ता है
      multi-page forms के बारे में सोचिए: कितनी single page applications सब कुछ memory में रखती हैं और अंत में सिर्फ़ एक request भेजती हैं
      अगर JS नहीं होता, तो backend हर step की state store करता ताकि बाद में form पर लौटने या refresh करने पर वह खो न जाए
    • किया जा सकता है, लेकिन यह कहीं ज़्यादा मुश्किल है; और अधिकतर लोग ध्यान नहीं देते, यह बात खुद बताती है कि implementation उतना मामूली नहीं है
      जब basic HTML website default settings से ही ठीक चलती है, तो ऐसा कचरा क्यों थोपना
    • उस हिस्से में “बिना अतिरिक्त मेहनत के” जैसा phrase जोड़ दें तो बात और साफ़ हो जाएगी
    • अगर आप कहते हैं कि user ने जानबूझकर disable की हुई functionality का भी सम्मान किया जाए, तो उसे संभव कैसे बनाया जा सकता है
      अगर user navigation history को बाद में बदलने की अनुमति नहीं देता, तो सिर्फ़ एक ही विकल्प बचता है
      history जिस समय लिखी जा रही हो, उसी समय browser history को ठीक से बनाना

  • काश पूरा internet इस सलाह का पालन करे

    • शायद दर्जनों power plants आसानी से बंद किए जा सकें

  • पुरानी चीज़ फिर से नई बन जाती है
    क्या हमें आज के trend से ज़्यादा सबसे सरल संभव समाधान को प्राथमिकता नहीं देनी चाहिए

    • trends के पीछे भागने की वजह से 99.9% developers बेकार हैं, और उन्हें engineer की उपाधि नहीं मिलनी चाहिए
    • ज़रूरी नहीं। UK government ने web services में JavaScript के इस्तेमाल का कभी समर्थन नहीं किया, और accessibility को core में रखने वाले HTML/CSS आधारित design system में भारी निवेश किया है
      industry के बाकी हिस्से JS के नशे में थे, इसका मतलब यह नहीं कि सभी वैसे थे
    • हाल में Rails World में DHH का keynote देखा; मैं Rails नहीं करता, लेकिन modern web किस दिशा में चला गया है, इस पर उनके नज़रिए से पूरी तरह सहमत हूं

  • इस सूची में Linux क्यों नहीं है?
    https://www.gov.uk/service-manual/technology/designing-for-d...

    • हल्का-फुल्का जवाब यह है कि Linux एक kernel है
      थोड़ा ज्यादा गंभीर, लेकिन उसी संदर्भ वाला जवाब यह है कि distributions दर्जनों हैं, और उनमें Mozilla-परिवार के forks भी जोड़ दें तो browsers भी लगभग दस हो जाते हैं
      कोई एक आधिकारिक distribution/browser चुना जा सकता है, लेकिन ऐसे चुने गए एक विकल्प का user base बेहद छोटा हो जाएगा
      Ubuntu तक के लिए भी, सहायक indicators से निकाली जा सकने वाली संख्या के आधार पर desktop operating system share लगभग 1% दिखता है
    • उसे उस सूची में होना क्यों चाहिए? कब ऐसा होता है कि कोई webpage macOS और Windows पर काम करे लेकिन Linux पर न करे
    • क्योंकि users का अनुपात 2% से कम है?

  • गंभीर सवाल है: comments देखकर लगता है कि लोग इस approach को पसंद करते हैं
    तो फिर overall trend React जैसे frameworks और JavaScript को, कभी-कभी बेवजह, इस्तेमाल करने की दिशा में क्यों जा रहा है

    • end user के रूप में मुझे GOV.UK द्वारा बनाए और recommend किए जाने वाले application style सच में पसंद हैं
      हल्के, साफ layout वाले, accessible, और आम तौर पर JavaScript को minimum रखते हैं या बिना JavaScript के भी काम करते हैं
      इसके उलट मुझे ज़्यादातर single-page applications पसंद नहीं हैं. वे expected browser functionality का बहुत कुछ तोड़ देते हैं, JavaScript के बिना बेकार होते हैं, और कई third-party sites से तरह-तरह की भारी dependencies load करते हैं
      लेकिन users को जो पसंद है और developers को जो पसंद है तथा जिसे वे जल्दी बना सकते हैं, वे अक्सर बहुत अलग चीजें होती हैं
    • शायद इसलिए कि React से app बनाने पर किसी को नौकरी से नहीं निकाला गया
      जब कोई चीज़ industry standard के रूप में स्वीकार हो जाती है, तो flow के साथ जाने वाला decision सुरक्षित होता है
      ऊपर से HTML/CSS/vanilla JS के लिए developer relations गतिविधियां कोई नहीं करता
      कुछ करने का तरीका खोजो तो लगभग सब कुछ framework-related ही मिलता है
    • क्योंकि धीमी, आसानी से टूटने वाली, inefficient websites बनाने की कोई cost नहीं है
      अगर आप अपने computer पर चलने वाला program बनाते हैं, तो वह cost आपको खुद चुकानी पड़ती है, और कम से कम finance team को यह समझाना पड़ता है कि cloud cost 5% क्यों बढ़ी
      लेकिन frontend developer की तरह अगर आप software किसी और के device पर चलाते हैं, तो cost लगभग नहीं होती
      negative signals user reports, support tickets, या शायद Twitter posts जैसे रास्तों से ही आते हैं, और उस process में selection bias बहुत होता है, इसलिए पूरी तस्वीर न दिखने की संभावना बड़ी है
      आखिरकार सब incentives का मामला है
    • क्योंकि web से और ज्यादा काम करवाने का trend भी है
      web पारंपरिक thick clients की जगह ले रहा है, और वे clients भी काफी stable network connection और platform specifications मानकर चलते थे
      government systems को, भले ही rare हो, lowest common denominator पर काम करना चाहिए
      tech startup शुरुआत में सिर्फ 1 customer के साथ भी अस्तित्व में रह सकता है, और scale होने पर यह मान सकता है कि उसकी requirements आम तौर पर common हो जाएंगी
    • क्योंकि इस approach को पसंद करने वाले लोग frontend developers नहीं हैं
      सच कहें तो मुझे लगता है कि frontend developers होने की वजह से ही वे इस approach को नापसंद करते हैं. वरना develop करने के लिए frontend लगभग बचेगा ही नहीं

  • मैं भी इसी तरीके को follow करने की कोशिश करता हूं. server से pre-fetched data के साथ HTML serve करना, client पर जो हो सकता है उसे client पर handle करके server round-trips घटाना, minimum CSS से responsive layout बनाना और vanilla JS इस्तेमाल करना
    जरूरत पड़े तो अलग webpage में बांट देना चाहिए
    लेकिन सिर्फ HTML, CSS और vanilla JS इस्तेमाल करने की वजह से colleagues को शायद यह कुछ अजीब और पुराना लगता है
    खास कमी तो कुछ नहीं है

  • लेख में भी कहा गया है कि बिना सोचे-समझे सिर्फ server-side इस्तेमाल करना अच्छी software engineering नहीं है
    ध्यान देने वाली बात है कि यह “समस्या पैदा कर सकता है” कहता है, “समस्या पैदा करता है” नहीं
    client-side JavaScript frameworks जटिल user interfaces वाली services बनाते समय मदद कर सकते हैं, लेकिन codebase का overall size बढ़ा सकते हैं और processing को client पर धकेलकर धीमे network या low-performance devices वाले users के लिए performance problems पैदा कर सकते हैं
    वे developers को ऐसे third-party code पर निर्भर बना सकते हैं जिसे वे control नहीं करते, और framework changes के साथ चलने के लिए service में बड़े changes की जरूरत भी पड़ सकती है
    अगर framework की popularity घट जाए, तो उसे maintain करने वाले लोग ढूंढना मुश्किल हो सकता है
    अगर JavaScript framework इस्तेमाल करें, तो users को क्या फायदा है इसे evidence के आधार पर justify करना चाहिए, negative impacts को समझकर mitigate करना चाहिए, और देखना चाहिए कि benefits संभावित problems से बड़े हैं या नहीं
    साथ ही इसे सिर्फ user interface के उन हिस्सों में इस्तेमाल करना चाहिए जिन्हें HTML और CSS से नहीं बनाया जा सकता, और हर हिस्से को अलग component के रूप में design करना चाहिए
    components को अलग रखने से JavaScript load fail होने पर सिर्फ वही component fail होता है, और बाकी page हमेशा की तरह load हो जाता है