जिम्मेदार जावास्क्रिप्ट विकास भाग 1

संख्याएँ हमें बताती हैं कि जावास्क्रिप्ट कोड के बढ़ने से वेब परियोजनाओं के प्रदर्शन पर बुरा असर पड़ता है। यदि यह आगे भी जारी रहता है, तो बहुत जल्द, मध्य पृष्ठ लोड करते समय, जेएस कोड के कम से कम 400 Kb को स्थानांतरित किया जाएगा। और यह सिर्फ ट्रांसफर किए गए डेटा की मात्रा है। अन्य पाठ संसाधनों की तरह, जावास्क्रिप्ट कोड लगभग हमेशा संपीड़ित रूप में प्रेषित होता है। संपीड़न शायद एकमात्र ऐसी चीज है जो आमतौर पर सर्वर से क्लाइंट में कोड ट्रांसफर करते समय सही ढंग से किया जाता है।



दुर्भाग्य से, कुछ संसाधनों के हस्तांतरण के समय को कम करते हुए, जिसे हम "प्रदर्शन" कहते हैं, उसके लिए एक गंभीर योगदान होता है, संपीड़न को प्रभावित नहीं करता है कि ब्राउज़र को पूरी तरह से लोड होने के बाद स्क्रिप्ट को पार्स करने और संसाधित करने में कितना समय लगता है। ।

यदि सर्वर क्लाइंट के लिए 400 KB संकुचित जेएस कोड भेजता है, तो कोड की वास्तविक मात्रा जिसे ब्राउज़र को प्राप्त डेटा को डिकॉम्प्रेस करने के बाद संसाधित करने की आवश्यकता होती है, मेगाबाइट क्षेत्र में होगा। इस तरह के काम को कितनी अच्छी तरह से संभालना विभिन्न उपकरणों पर निर्भर करता है। इस बारे में बहुत कुछ लिखा गया है, लेकिन हम केवल निश्चितता के साथ कह सकते हैं कि कोड की मात्रा को पार्स करने के लिए आवश्यक समय जो इसके समय के लिए काफी सामान्य है, विभिन्न उपकरणों के बीच बहुत भिन्न होता है।

उदाहरण के लिए, मेरी इस सरल परियोजना पर एक नज़र डालें। पेज लोडिंग के दौरान, 23 के बारे में असम्पीडित जेएस कोड ग्राहक को हस्तांतरित किया जाता है। मैकबुक प्रो पर चल रहा क्रोम, जो 2017 के मध्य में जारी किया गया था, लगभग 25 एमएस में कोड की इस छोटी राशि को संसाधित करता है। नोकिया 2 एंड्रॉइड स्मार्टफोन पर, एक समान आंकड़ा 190 एमएस तक फैलता है। यह कहने के लिए नहीं है कि यह बहुत छोटा है, लेकिन किसी भी मामले में, पेज जल्दी से इंटरैक्टिव हो जाता है।

अब, एक महत्वपूर्ण प्रश्न। आपको क्या लगता है, एक साधारण नोकिया 2 स्मार्टफोन औसत आधुनिक पृष्ठों का प्रबंधन कैसे करता है? वास्तव में - बस भयानक। एक तेज़ इंटरनेट कनेक्शन पर भी वेब पेज ब्राउज़ करना, उपयोगकर्ता को धैर्य रखने के लिए मजबूर करता है, क्योंकि जावास्क्रिप्ट कोड के साथ लोड किए गए पृष्ठों के साथ काम करने के बाद एक भारी प्रतीक्षा अवधि के बाद ही संभव हो जाता है।


जेएस-कोड की एक बड़ी मात्रा वाले पृष्ठ को देखने पर नोकिया 2 का प्रदर्शन अवलोकन, जिसमें से प्रसंस्करण मुख्य धागे को अवरुद्ध करता है

यद्यपि वे उपकरण जिनके साथ वे वेब पेज ब्राउज़ करने के लिए उपयोग करते हैं और जिन नेटवर्क के माध्यम से डेटा संचारित होता है, हाल के वर्षों में काफी सुधार हुआ है, अध्ययनों से पता चलता है कि ये सभी सुधार बड़ी मात्रा में जेएस कोड द्वारा "खाए गए" हैं। हमें जिम्मेदारी से जावास्क्रिप्ट का उपयोग करने की आवश्यकता है। ज़िम्मेदारी की शुरुआत इस बात से होती है कि हम क्या बना रहे हैं और कैसे करते हैं।

"साइटों" और "अनुप्रयोगों" की विचारधारा की तुलना

अजीब चीजें गलत शब्दों के साथ होती हैं जिनका उपयोग हम कुछ नाम करने के लिए करते हैं, हालांकि उनके अर्थ, सहज स्तर पर, सभी के लिए स्पष्ट हैं। कभी-कभी हम "मधुमक्खी" शब्द के अर्थ को ओवरलोड करते हैं, इसे "मधुमक्खी" और ततैया कहते हैं, भले ही मधुमक्खियों और ततैया के बीच अंतर बहुत महत्वपूर्ण है। इस तरह के मतभेदों को ध्यान में रखते हुए तथ्य यह हो सकता है कि "मधुमक्खियों" और "ततैया" अलग तरह से कार्य करेंगे। उदाहरण के लिए, हम एक सींग के घोंसले को नष्ट करने जा रहे हैं, लेकिन अगर हम मधुमक्खियों के बारे में बात कर रहे हैं, तो कीड़े अधिक उपयोगी और कमजोर हैं, गलत जगह पर स्थित उनके घोंसले को शायद नष्ट नहीं करने का निर्णय लिया जाएगा, लेकिन इसे कहीं और स्थानांतरित करने के लिए।

इसी तरह की स्वतंत्रता को हम "वेबसाइट" और "वेब एप्लिकेशन" शब्दों के उपयोग के तरीके से देख सकते हैं। इन अवधारणाओं के बीच का अंतर वास्तविक ततैया और मधु मक्खियों के बीच के अंतर की तुलना में बहुत कम स्पष्ट है, लेकिन अगर इन अवधारणाओं को जोड़ दिया जाए, तो इससे बहुत अप्रिय परिणाम हो सकते हैं। मुसीबतें तब शुरू होती हैं जब हम अपने आप को कुछ करने देते हैं, यह इस बात पर निर्भर करता है कि क्या कोई परियोजना "सिर्फ एक वेबसाइट" या "पूर्ण विकसित वेब अनुप्रयोग" है। यदि आप किसी कंपनी के लिए सूचना साइट बना रहे हैं, तो सबसे अधिक संभावना है कि आप DOM परिवर्तनों के प्रबंधन के लिए या क्लाइंट पर रूटिंग को लागू करने के लिए एक शक्तिशाली ढांचे पर भरोसा नहीं करेंगे। कम से कम, मुझे उम्मीद है। कुछ समस्याओं को हल करने के लिए खराब रूप से अनुकूल उपकरण का उपयोग करना न केवल उन लोगों को नुकसान पहुंचाएगा जो साइट का उपयोग करेंगे, बल्कि यह संभवतः विकास प्रक्रिया को भी बुरी तरह से प्रभावित करेगा।

वेब एप्लिकेशन विकसित करते समय, सब कुछ अलग दिखता है। हम पैकेज स्थापित करते हैं, जो सैकड़ों के अतिरिक्त है, यदि हजारों नहीं, तो परियोजना के लिए निर्भरताएं। इसके अलावा, हम उनमें से कुछ की सुरक्षा के बारे में भी सुनिश्चित नहीं हैं। हम बंडलों के लिए जटिल विन्यास लिखते हैं। इस तरह के सर्वव्यापी पागल विकास के वातावरण में काम करते समय, आपको यह सुनिश्चित करने के लिए ज्ञान और ध्यान की आवश्यकता होती है कि जो एकत्र किया गया था वह त्वरित है, कि यह परियोजना काम करेगी जहां इसे काम करना चाहिए। यदि संदेह है, तो अपने प्रोजेक्ट के रूट डायरेक्टरी में npm ls --prod कमांड चलाएं और देखें कि क्या आप इस कमांड को प्रदर्शित करने वाली हर चीज का उपयोग करने के उद्देश्य को नाम दे सकते हैं। यदि आप यह कर सकते हैं, तो भी यह तृतीय-पक्ष स्क्रिप्ट पर लागू नहीं होता है। मुझे यकीन है कि आपके प्रोजेक्ट में कई ऐसी स्क्रिप्ट्स का भी इस्तेमाल किया गया है।

हम भूल जाते हैं कि दोनों वेबसाइट और वेब एप्लिकेशन एक ही "पारिस्थितिक आला" पर कब्जा कर लेते हैं। दोनों ही पर्यावरण के एक ही प्रभाव के तहत हैं, जिसमें विभिन्न प्रकार के नेटवर्क और डिवाइस शामिल हैं। यदि हम "एप्लिकेशन" के रूप में विकसित कर रहे हैं, तो हम कॉल करने का निर्णय लेते हैं और हमारे उपयोगकर्ताओं के डिवाइस जादुई रूप से बहुत तेज नहीं हो जाएंगे यदि हम "वेबसाइट" को "एप्लिकेशन" कहते हैं तो ऐसे प्रतिबंध गायब नहीं होंगे।

यह हमारी ज़िम्मेदारी है कि हम जो बनाते हैं उसका उपयोग करते हैं, हमें इस तथ्य को ध्यान में रखना चाहिए कि जिन परिस्थितियों में विभिन्न उपयोगकर्ता इंटरनेट से जुड़ते हैं, वे उन लोगों से भिन्न हो सकते हैं जिन पर हम भरोसा करते हैं। कुछ बनाते समय, हमें उस लक्ष्य के बारे में पता होना चाहिए, जिसके लिए हम इसे बना रहे हैं, और उसके बाद हमें इस लक्ष्य को प्राप्त करने में मदद करने के लिए विकास करना चाहिए - भले ही विकास एक ऐसा रोमांचक उपक्रम न हो।

इसका मतलब यह है कि जावास्क्रिप्ट पर हमारी निर्भरता का पुनर्मूल्यांकन करने की आवश्यकता है, और इसका उपयोग, विशेष रूप से HTML और सीएसएस की गिरावट के लिए, हमें तर्कहीन पैटर्न के उपयोग की ओर ले जा सकता है जो वेब परियोजनाओं के प्रदर्शन और पहुंच को नुकसान पहुंचाता है।

फ्रेमवर्क को आप पर तर्कहीन पैटर्न न आने दें

मैंने कोडबेस में अजीब चीजों की खोज देखी जब मैंने अधिक उत्पादक होने में मदद करने के लिए चौखटे के आधार पर टीमों के साथ काम किया। इनमें से कई में एक बात समान है, जो यह है कि जिस तरह से उन्हें लिखा जाता है वह अक्सर साइटों की उपलब्धता और प्रदर्शन के साथ समस्याओं का कारण बनता है। उदाहरण के लिए, निम्नलिखित प्रतिक्रिया घटक पर विचार करें:

import React, { Component } from "react"; import { validateEmail } from "helpers/validation"; class SignupForm extends Component {  constructor (props) {    this.handleSubmit = this.handleSubmit.bind(this);    this.updateEmail = this.updateEmail.bind(this);    this.state.email = "";  }  updateEmail (event) {    this.setState({      email: event.target.value    });  }  handleSubmit () {    //      -      if (validateEmail(this.state.email)) {      // ...    }  }  render () {    return (      <div>        <span class="email-label">Enter your email:</span>        <input type="text" id="email" onChange={this.updateEmail} />        <button onClick={this.handleSubmit}>Sign Up</button>      </div>    );  } } 

यहाँ आप प्रोजेक्ट एक्सेसिबिलिटी के बारे में कई उल्लेखनीय मुद्दे पा सकते हैं:

1. ऐसा फ़ॉर्म जो <form> तत्व का उपयोग नहीं करता है, वह <form> नहीं है। वास्तव में, आप इसे केवल माता-पिता <div> तत्व की भूमिका = "फ़ॉर्म" निर्दिष्ट करके इसे ठीक कर सकते हैं, लेकिन यदि आप एक फ़ॉर्म बनाते हैं, और जो हम देखते हैं वह निश्चित रूप से एक फ़ॉर्म की तरह दिखता है, तो इसके अनुसार सेटिंग करें। action और method गुण। action विशेषता यहां एक महत्वपूर्ण भूमिका निभाती है, क्योंकि यह फ़ॉर्म को कम से कम कुछ करने की अनुमति देता है, भले ही जावास्क्रिप्ट उपलब्ध न हो (स्वाभाविक रूप से, यदि घटक सर्वर पर प्रदान किया गया था)।
2. <span> <label> विकल्प नहीं है, जो उन परियोजनाओं की उपलब्धता के बारे में कुछ सुविधाएँ प्रदान करता है जो <span> पास नहीं हैं।
3. type="submit" बिना <button> तत्व type="submit" विशेषता केवल एक बटन है, जिस पर क्लिक करने से ईवेंट हैंडलर को बाध्य किया जाता है। यदि हम फ़ॉर्म सबमिट करने से पहले डेटा के साथ कुछ करना चाहते हैं, तो हमें बटन पर type="submit" विशेषता असाइन करने की आवश्यकता है और कोड को onSubmit इवेंट हैंडलर से onSubmit फॉर्म इवेंट हैंडलर में onSubmit करना होगा।
4. वैसे, ईमेल पतों को सत्यापित करने के लिए जावास्क्रिप्ट का उपयोग क्यों करते हैं, जबकि एचटीएमएल 5 हमारे निपटान नियंत्रण में है जो लगभग सभी ब्राउज़रों में इनपुट डेटा की जांच का समर्थन करता है - IE10 तक? यहां हम कार्यक्षमता का लाभ उठाने के लिए एक चूक का अवसर देखते हैं जो पहले से ही ब्राउज़र में है और उपयुक्त तत्व प्रकार , साथ ही आवश्यक विशेषता को लागू करता है। हालांकि, इस तरह के निर्माणों का उपयोग करते हुए, ध्यान रखें कि स्क्रीन पाठकों के साथ उनकी सामान्य बातचीत स्थापित करने के लिए कुछ प्रयास करने की आवश्यकता होगी।

उपरोक्त को ध्यान में रखते हुए, हम घटक कोड को रिफलेक्टर करते हैं:

 import React, { Component } from "react"; class SignupForm extends Component { constructor (props) {   this.handleSubmit = this.handleSubmit.bind(this); } handleSubmit (event) {   //    ,         XHR   // (      ,     ,     JS).   event.preventDefault();   //  … } render () {   return (     <form method="POST" action="/signup" onSubmit={this.handleSubmit}>       <label for="email" class="email-label">Enter your email:</label>       <input type="email" id="email" required />       <button type="submit">Sign Up</button>     </form>   ); } } 

अब, यह तथ्य कि यह घटक प्रदान करता है न केवल अधिक सुलभ हो जाता है, लेकिन पहले की तरह ही कार्यक्षमता को लागू करने के लिए कम जेएस कोड का उपयोग किया जाता है। एक ऐसी दुनिया में जो सचमुच जावास्क्रिप्ट में डूब गई, कोड की कुछ पंक्तियों से छुटकारा पाना कुछ सकारात्मक के रूप में देखा जाना चाहिए। ब्राउज़र हमें बहुत सारे अवसर देता है, और हमें इन अवसरों का यथासंभव उपयोग करने का प्रयास करने की आवश्यकता है।

मैं यहां यह नहीं कहना चाहता कि कुछ रूपरेखाओं का उपयोग करते समय पृष्ठों की पहुंच के साथ समस्याएं विशेष रूप से उत्पन्न होती हैं। मेरा मतलब है, जावास्क्रिप्ट पर बहुत अधिक भरोसा करते हुए, डेवलपर, परिणामस्वरूप, कई महत्वपूर्ण HTML और सीएसएस सुविधाओं को याद करेंगे। ज्ञान में ये अंतराल अक्सर त्रुटियों को जन्म देते हैं, इसके अलावा, हम इन त्रुटियों पर संदेह भी नहीं करते हैं। फ्रेमवर्क उपयोगी उपकरण हो सकते हैं जो डेवलपर उत्पादकता को बढ़ाते हैं, लेकिन उनके विकास में उपयोग किए जाने वाले सहायक उपकरणों की परवाह किए बिना, सुविधाजनक, उपयोगी उत्पाद बनाने में बुनियादी वेब प्रौद्योगिकियों की क्षमताओं का निरंतर अध्ययन बेहद महत्वपूर्ण है।

वेब प्लेटफ़ॉर्म की शक्ति पर भरोसा करें और अपनी परियोजनाओं को उज्ज्वल भविष्य दें

चूंकि हम रूपरेखाओं के बारे में बात कर रहे हैं, इसलिए यह ध्यान दिया जाना चाहिए कि वेब प्लेटफॉर्म, अपने आप में एक बहुत बड़ा ढांचा है। जैसा कि पिछले भाग में दिखाया गया है, हम खुद को एक बेहतर स्थिति में पाते हैं अगर हम मार्कअप और ब्राउज़र क्षमताओं के साथ काम करने के लिए स्थापित पैटर्न पर भरोसा कर सकते हैं। इन मानक सुविधाओं का एक विकल्प उन्हें फिर से आविष्कार करना है। कहने की जरूरत नहीं है, इस तरह के "आविष्कार" काफी कठिनाइयों से भरा है। लेकिन क्या होगा अगर इस तरह की समस्याएं, प्रत्येक अपने तरीके से, हमारे द्वारा स्थापित सभी जावास्क्रिप्ट पैकेजों के लेखकों द्वारा हल की जाएंगी?

▍Single पेज एप्लीकेशन

डेवलपर्स की कमजोरियों में से एक जिसे वे आसानी से बर्दाश्त कर सकते हैं, वह सिंगल पेज एप्लिकेशन (एसपीए) मॉडल का उपयोग है, यहां तक ​​कि उन परियोजनाओं में भी जिनके लिए यह मॉडल उपयुक्त नहीं है। बेशक, इस तरह की परियोजनाएं इस तथ्य से लाभान्वित होती हैं कि ग्राहक द्वारा किए गए रूटिंग के कारण उपयोगकर्ताओं द्वारा उन्हें अधिक उत्पादक माना जाता है। लेकिन एसपीए मॉडल का उपयोग करने के नुकसान क्या हैं? ब्राउज़र का अंतर्निहित पेज नेविगेशन क्षमता, हालांकि एक सिंक्रोनस मॉडल पर बनाया गया है, इस परियोजना को लाभ का एक टन देता है। उनमें से एक यह है कि जटिल विनिर्देशों के कार्यान्वयन के माध्यम से यात्राओं के इतिहास का प्रबंधन किया जाता है। जावास्क्रिप्ट के बिना उपयोगकर्ता, चाहे उन्होंने इसे स्वयं अक्षम किया हो या नहीं , परियोजना के साथ काम करने की क्षमता नहीं खोएगा। जावास्क्रिप्ट के साथ ब्राउज़रों में उपलब्ध होने वाले एक-पेज के आवेदन के लिए, यह अचानक पता चला है कि सर्वर रेंडरिंग पर काफी ध्यान देने की आवश्यकता है।


एक धीमी संचार चैनल पर एक प्रयोगात्मक आवेदन लोड करने के लिए विभिन्न विकल्पों की तुलना। बाईं ओर एप्लिकेशन का प्रतिपादन पूरी तरह से जावास्क्रिप्ट पर निर्भर है। दाईं ओर एप्लिकेशन सर्वर पर प्रस्तुत किया गया है, लेकिन फिर क्लाइंट पर, हाइड्रेट () विधि को सर्वर पर पहले से निर्मित मार्कअप से जोड़ने के लिए उपयोग करता है।

यहां आप देख सकते हैं कि एप्लिकेशन, जो क्लाइंट पर प्रदान किया जाता है, कुछ सेकंड के लिए उपयोगकर्ता को एक रिक्त स्क्रीन दिखाता है, और फिर समाप्त इंटरफ़ेस प्रदर्शित करता है।

एक एप्लिकेशन जो सर्वर पर प्रदान किया गया है और क्लाइंट पर परिचालन प्रदान किया गया है, मुख्य इंटरफ़ेस तत्वों को जल्दी से प्रदर्शित करता है, लेकिन आप इसे उसी समय के बाद उपयोग कर सकते हैं, जो एप्लिकेशन क्लाइंट पर पूरी तरह से प्रदान किया गया है।

एप्लिकेशन की उपलब्धता भी पीड़ित होती है यदि क्लाइंट पर स्थित राउटर उपयोगकर्ता को उस पृष्ठ के बारे में सूचित नहीं कर सकता है जो उसने देखा है। यह उपयोगकर्ता को सहायक तकनीकों पर भरोसा करने के लिए बाध्य कर सकता है ताकि यह पता लगाया जा सके कि पेज पर वास्तव में क्या बदल गया है, परिणामस्वरूप, साइट के साथ उपयोगकर्ता का काम बहुत अधिक जटिल है।

इसके अलावा, आप तुरंत हमारे पुराने दुश्मन से मिल सकते हैं - सिस्टम पर अत्यधिक भार। कुछ क्लाइंट राउटर बहुत छोटे होते हैं। लेकिन यदि आप रिएक्ट पर एक प्रोजेक्ट बनाते हैं, तो एक संगत राउटर का उपयोग करें, और, संभवतः, एप्लिकेशन की स्थिति को प्रबंधित करने के लिए एक पुस्तकालय , इसका मतलब है कि आपको यह स्वीकार करना होगा कि इसमें एक निश्चित राशि का कोड होगा, जिसमें से आप कहीं भी नहीं जा सकते। अर्थात्, इस मामले में यह ऐसे कोड का लगभग 135 Kb है। आपके द्वारा बनाई जा रही परियोजनाओं का सावधानीपूर्वक विश्लेषण करें और क्या क्लाइंट रूटिंग सिस्टम पर अतिरिक्त भार के लायक है या नहीं। आमतौर पर ऐसा होता है कि क्लाइंट राउटिंग सिस्टम को मना करना बेहतर होता है।

यदि आप उपयोगकर्ता की भावनाओं के बारे में चिंतित हैं, यदि आप चाहते हैं कि साइट उसे तेजी से दिखे, तो आप rel = prefetch लिंक विशेषता पर भरोसा कर सकते हैं, जो आपको उसी स्रोत से दस्तावेज़ों के पूर्व-लोडिंग को व्यवस्थित करने की अनुमति देता है। इस विशेषता का उपयोग करने से उपयोगकर्ताओं द्वारा मानी जाने वाली परियोजना के प्रदर्शन को बेहतर बनाने पर बहुत प्रभाव पड़ता है, क्योंकि इस विशेषता का उपयोग करने से जुड़े पृष्ठ, जब आप इन लिंक पर क्लिक करते हैं, तो तुरंत कैश से लोड होते हैं। इसके अलावा, चूंकि डेटा को प्री लोड करना कम प्राथमिकता है, इसलिए यह महत्वपूर्ण संसाधनों के साथ बैंडविड्थ के लिए प्रतिस्पर्धा करने की संभावना नहीं है।


जब आप साइट के मुख्य पृष्ठ पर जाते हैं तो HTML कोड लेखन / द्वारा संदर्भित किया जाता है। जब कोई उपयोगकर्ता संबंधित लिंक पर क्लिक करता है, तो HTML कोड तुरंत ब्राउज़र कैश से लोड हो जाता है

मुख्य समस्या जो प्री-लोडिंग पृष्ठों के साथ उत्पन्न हो सकती है, और जिसके बारे में आपको जानकारी होनी चाहिए, वह यह है कि इस तरह की लोडिंग समय और संसाधनों की बर्बादी हो सकती है। इसे हल करने के लिए, आप उदाहरण के लिए, Google की छोटी क्विकलिंक स्क्रिप्ट का उपयोग कर सकते हैं, जो इस समस्या को कम करता है। यह जांचता है कि क्या वर्तमान क्लाइंट एक धीमे कनेक्शन का उपयोग कर रहा है, चाहे उसमें डेटा सेविंग मोड सक्षम हो , और डिफ़ॉल्ट रूप से, आपको पेज सोर्स के अलावा अन्य स्रोतों से प्रीलोडिंग सामग्री से बचने की अनुमति देता है।

साइट को उपयोगकर्ताओं की नज़र में तेज़ दिखाने के लिए जो इसे कई बार देखते हैं, आप सेवा कर्मचारियों का उपयोग कर सकते हैं। उनका उपयोग इस बात पर ध्यान दिए बिना किया जा सकता है कि परियोजना क्लाइंट रूटिंग सिस्टम का उपयोग करती है या नहीं, यह देखते हुए कि आप सेवा कर्मियों की कुछ विशेषताओं से परिचित हैं। सेवा कार्यकर्ताओं के माध्यम से मार्ग कैशिंग प्रदर्शन करना, हमें कई समान लाभ मिलते हैं जो कुछ लिंक की पूर्व-लोडिंग सामग्री के लिए विशिष्ट होते हैं, लेकिन हमारे पास अनुरोधों और उत्तरों के साथ काम करने की अधिक व्यापक क्षमताएं हैं। आप अपनी साइट को "एप्लिकेशन" के रूप में देखते हैं या नहीं, सेवा कार्यकर्ता से लैस करना संभवतः हमारे समय के सबसे महत्वपूर्ण जावास्क्रिप्ट उपयोग मामलों में से एक का एक उदाहरण है।

▍JavaScript लेआउट के लिए डिज़ाइन नहीं किया गया है

यदि हम पृष्ठ लेआउट से संबंधित समस्याओं को हल करने के लिए डिज़ाइन किया गया JS पैकेज स्थापित करते हैं, तो यह समय है कि हम बहुत सावधान रहें और खुद से पूछें कि हम इस पैकेज के साथ क्या हासिल करना चाह रहे हैं। सीएसएस विशेष रूप से पेज लेआउट के निर्माण के लिए बनाया गया था, इसे प्रभावी ढंग से उपयोग करने के लिए, आपको किसी भी सार की आवश्यकता नहीं है। लेआउट बनाने के अधिकांश कार्य जिन्हें वे जावास्क्रिप्ट का उपयोग करके हल करने का प्रयास करते हैं, जैसे कि तत्वों को रखना, उन्हें संरेखित करना, उनके आकारों को समायोजित करना, जैसे पाठ में हेरफेर करना या जावास्क्रिप्ट का उपयोग करके पूरी तरह से लेआउट बनाना , अब CSS का उपयोग करके पूरा किया जा सकता है। फ्लेक्सबॉक्स और ग्रिड जैसे लेआउट बनाने के लिए आधुनिक उपकरण ब्राउज़रों द्वारा अच्छी तरह से समर्थित हैं, इसलिए हमें लेआउट के साथ काम करने के लिए रूपरेखाओं के आधार पर परियोजनाओं को विकसित करने की आवश्यकता नहीं है। वैसे, CSS भी एक फ्रेमवर्क है। जब हमारे निपटान में संपत्ति के अनुरोधों के रूप में ऐसा अवसर होता है, तो उनके गठन के नए साधनों का समर्थन करने के लिए लेआउट के प्रगतिशील सुधार, जैसा कि यह निकला, इतना मुश्किल नहीं है ।

 /*   , ,   ,        CSS Grid. */ /*  @supports  ,     CSS Grid,     . */ @supports (display: grid) { /*      */ @media (min-width: 40em) {   /*       CSS Grid */ } } 

पृष्ठ लेआउट बनाने और उनकी उपस्थिति को अनुकूलित करने की समस्याओं को हल करने के लिए जावास्क्रिप्ट का उपयोग करना समाचार नहीं है। यह हमने 2009 में किया था, जब हम आत्म-धोखे के वातावरण में रहते थे, यह कहते हुए कि हर साइट को उसी तरह IE6 जैसा दिखना चाहिए, जैसे उस समय के अधिक उन्नत ब्राउज़रों में। यदि आज, 2019 में, हम साइटों को विकसित करना जारी रखते हैं ताकि वे सभी ब्राउज़रों में समान दिखें, इसका मतलब है कि हमें अपने लक्ष्यों पर पुनर्विचार करने की आवश्यकता है। हमेशा कुछ ब्राउज़र होंगे जिन्हें समर्थन की आवश्यकता होती है, और जिनमें सबसे आधुनिक ब्राउज़रों की समान क्षमताएं नहीं होती हैं। सभी प्लेटफार्मों पर परियोजनाओं की पूर्ण बाहरी समानता न केवल ऊर्जा की बर्बादी है, बल्कि प्रगतिशील सुधारों के विचार का एक मौलिक दुश्मन भी है।

नीचे पंक्ति: मैं जावास्क्रिप्ट हत्यारा बनने वाला नहीं हूं

मुझे गलत मत समझो, मैं जावास्क्रिप्ट के दुश्मनों से संबंधित नहीं हूं। इस भाषा के लिए धन्यवाद, मैंने एक कैरियर बनाया है, और, ईमानदार होने के लिए, जावास्क्रिप्ट, दस साल से अधिक समय तक, मुझे बहुत खुशी देता है। किसी भी दीर्घकालिक संबंध के रूप में, जितना अधिक समय मैं जावास्क्रिप्ट के साथ काम करने में बिताता हूं, उतना ही मुझे यह जानने में बेहतर होगा। यह कई विशेषताओं के साथ एक परिपक्व भाषा है, जो हर साल बेहतर हो रही है।

हालांकि, कभी-कभी मुझे ऐसा लगता है कि हमारे जावास्क्रिप्ट रिश्ते में कुछ गड़बड़ हो गई है। मैं उसकी आलोचना करता हूं। या, अधिक सटीक रूप से, मैं जावास्क्रिप्ट को साइट निर्माण के लिए मुख्य उपकरण पर विचार करने की वर्तमान प्रवृत्ति की आलोचना करता हूं, जिसे किसी और चीज को देखे बिना, पहली जगह का सहारा लिया जाता है। जब मैंने एक और बंडल का विश्लेषण किया जो एक भ्रमित क्रिसमस माला की तरह लग रहा था, तो मेरे लिए यह स्पष्ट हो गया कि वेब जावास्क्रिप्ट के साथ नशे में था। हम लगभग किसी भी कारण से इस भाषा का सहारा लेते हैं, यहां तक ​​कि ऐसे मामलों में भी जब परिस्थितियों को इसकी आवश्यकता नहीं होती है। कभी-कभी मैं सोचता हूं कि जेएस के प्रति इस रवैये के परिणाम कितने गंभीर हो सकते हैं।

मैं जावास्क्रिप्ट और वेब विकास के बारे में लिखना जारी रखना चाहता हूं, ताकि वेब प्रौद्योगिकियों का तर्कसंगत उपयोग करने के तरीकों की तलाश जारी रख सके। उम्मीद है कि एक साथ हम आधुनिक वेब को बेहतर बनाते हैं।

प्रिय पाठकों! क्या आपको लगता है कि आधुनिक वेब वास्तव में जावास्क्रिप्ट कोड के साथ अतिभारित है?