वेब घटक वेब के लिए एकमात्र उज्ज्वल भविष्य है। खुद को नम्र करें

कल [ वेब कंपोनेंट्स के बारे में एक बहुत ही योग्य लेख प्रकाशित हुआ था, और मैंने महसूस किया कि मैं पिछले आठ महीनों में प्राप्त अनुभव को साझा करने में मदद नहीं कर सकता। मैं वेब घटक के साथ काम करने के तरीके के बारे में बात नहीं करूंगा, मैं आपको बताऊंगा कि क्यों। इसलिए, जो लोग इस प्रौद्योगिकी स्टैक के बारे में नहीं जानते हैं, उन्हें उपरोक्त लिंक पर लेख पढ़ना चाहिए।
तथ्य यह है कि जून में मेरी कॉर्नरज लाइब्रेरी का पहला स्थिर संस्करण जारी किया गया था । AngularJS से निर्देशों का एक स्वायत्त कार्यान्वयन के रूप में शुरू करना, यह धीरे-धीरे वेब घटक विनिर्देशन से कस्टम तत्वों के अनुरूप (उपयोग और कार्यान्वयन दोनों में) सरल (गलत, हाँ, मुझे पता है) में बदल गया।

मैं बहुत सारी अड़चनों से गुज़रा, और अब इस पुस्तकालय का उपयोग कई बड़े और वास्तविक स्थितियों में बहुत अधिक परियोजनाओं में नहीं किया जाता है।

यह एक अद्भुत पुस्तकालय है, मेरी राय में, कार्यान्वयन में - मैंने वास्तव में इसे विकास का मुख्य उपकरण माना, और पिछले प्रोजेक्ट (वीडियो पोर्टल) में यह jQuery की तुलना में अधिक महत्वपूर्ण निकला: मैं इसे मना कर सकता था, लेकिन नहीं।

लेकिन मैं, उस व्यक्ति के रूप में जिसने इसे हमारी टीम में पेश किया, और इसे मना कर दिया - हम IE9 + साइटों और IE10 + साइटों के लिए पॉलिमर के लिए मोज़िला एक्स-टैग पर स्विच कर रहे हैं। सौभाग्य से, मेरी स्मृति में हमारे पास केवल एक या दो IE8 + परियोजनाएं थीं।

और इस पोस्ट में मैं बताऊंगा कि वेब कंपोनेंट्स सिर्फ वेब का भविष्य क्यों नहीं हैं। और वेब का एकमात्र भविष्य।

यह सब कैसे शुरू हुआ

इस तरह की वास्तुकला के लिए आवश्यक शर्तें चार साल पहले Google और यैंडेक्स में दिखाई दीं, जबकि राष्ट्रीय स्वाद बनाए रखा।

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

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

अंत में ...

... हमारे पास जो है वह हमारे पास है: बड़ी टीमों को यह अहसास हुआ कि न केवल पुस्तकालयों (हाय, आवश्यकता जेएसएस और मेरे व्यक्तिगत पसंदीदा ब्राउजर) को एनकैप्सुलेटेड और कनेक्ट किया जाना चाहिए, लेकिन सबसे पहले, साइट के प्रत्येक पृष्ठ पर दृश्य घटक।
क्यों? हां, क्योंकि वे कार्यक्रम के मुख्य धागे से संबंधित नहीं हैं। यदि आपके पास एक वेब एप्लिकेशन है, तो मुख्य पृष्ठ पर चार्ट कैसे संबंधित होना चाहिए? कोई तरीका नहीं, आपके लिए आदर्श विकल्प इनपुट डेटा को टेम्पलेट में, सही HTML टैग में घोषित करना है, और फिर उसे स्वयं काम करने देना है। आप वास्तव में यह नहीं सोचना चाहते हैं कि डेटा रेंडर करना कब शुरू करना है, और यदि आप अचानक इस डेटा को डायनामिक रूप से अपडेट करना चाहते हैं, तो आप बस जोड़ना अधिक आसान नहीं चाहते हैं।

<value at=100 is=500> 

आप पहले से ही इस दृष्टिकोण का उपयोग करते हैं, देखें:

 <video width="320" height="240" poster="poster.jpg" controls="controls" preload="none"> <source type="video/mp4" src="myvideo.mp4" /> <source type="video/webm" src="myvideo.webm" /> <source type="video/ogg" src="myvideo.ogv" /> </video> 

और आपके वेब एप्लिकेशन के मूल को वास्तव में महत्वपूर्ण काम करना चाहिए: सामग्री के साथ पृष्ठों का प्रतिपादन, उन्हें गतिशील रूप से अपडेट करना, नेटवर्क, पृष्ठभूमि प्रक्रियाओं, या एआई और भाषण मान्यता (और क्यों नहीं?) के साथ काम करना। हां, यहां तक ​​कि लगभग सभी को आमतौर पर अलग-अलग वेब घटकों के रूप में किया जा सकता है।

मॉड्यूलर वेब

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

परिणाम एक बहुत ही सरल बात है: 90-95% वेबसाइटें केवल स्टैंड-अलोन घटकों से बनाई जा सकती हैं, जो मॉड्यूल हैं जो दृश्य प्रस्तुति, तर्क, साथ ही बाहरी तरीकों और गुणों को जोड़ती हैं। ठीक है, निश्चित रूप से, वे अन्य मॉड्यूल शामिल कर सकते हैं।

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

नमस्कार घटकों

Google, मोज़िला और कई अन्य लोगों के अनुभव के आधार पर, उन्हें संयुक्त रूप से एहसास हुआ कि उन्हें अलग-अलग तार्किक-दृश्य मॉड्यूल को लागू करने की क्षमता बनाने की आवश्यकता है। अनुभव ने उन्हें बताया है कि यह वास्तव में बहुत महत्वपूर्ण है:

एनकैप्सुलेशन सीएसएस

यह सीएसएस शैलियों को पूरी तरह से अलग करने की क्षमता है ताकि दस्तावेज़ शैलियों मॉड्यूल के प्रदर्शन को प्रभावित न करें। यह महत्वपूर्ण क्यों है - और इसलिए यह स्पष्ट है।

कस्टम तरीके और गुण

यह बाहरी इंटरफेस, तरीकों और मूल्यों दोनों को बनाने की क्षमता है। सौभाग्य से, यह js में करना बहुत आसान है, और गेटर्स और सेटर अपेक्षाकृत लंबे समय के लिए आसपास रहे हैं। Object.defineProperty के लिए धन्यवाद। यह महत्वपूर्ण है क्योंकि कस्टम तत्वों में नए इंटरफेस होने चाहिए। आप बिना वीडियो टैग कैसे लागू करेंगे

 HTMLVideoElement.prototype.play() 

?

हर छींक के लिए कॉलबैक का एक गुच्छा

निर्माता, विध्वंसक, और बदलते गुणों के लिए कॉलबैक। एक स्पष्ट क्षण: दो "कंस्ट्रक्टर" कॉलबैक हैं। उनमें से पहला तत्व (document.createElement ('x-tag')) बनाने के लिए जिम्मेदार है, और दूसरा इसे DOM ट्री में जोड़ने के लिए है। मामले में आपने सिर्फ लेआउट में एक तत्व जोड़ा है - दोनों शूट करेंगे। इसकी आवश्यकता क्यों है? फिर, कुछ कार्य (उदाहरण के लिए, ट्रिगरिंग ईवेंट) को DOM ट्री में एक तत्व जोड़कर किया जाना चाहिए। इसके अलावा, उन्हें DOM ट्री में जोड़े गए प्रत्येक तत्व के लिए निष्पादित किया जाना चाहिए, यदि आप तत्व को दूसरे माता-पिता के लिए appendChild से गुजरते हुए स्थानांतरित करते हैं।

सामग्री निष्पादन के बिना टेम्पलेट

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

 <x-video-with-subtitle source="{{video.source}}"> 

स्रोत के रूप में {{video.source}} के साथ लॉन्च किया जाएगा, जो किसी को भी शोभा नहीं देता।

लेआउट एनकैप्सुलेशन

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

 <x-diagram type="histogram"> <value at=100 is=500> <value at=200 is=300> <value at=300 is=200> <value at=300 is=700> </x-diagram> 

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

इस लेख की व्याख्या नहीं की गई, लेकिन मैं टेंपलेटिंग के बारे में स्पष्ट करने का प्रयास करूंगा: वास्तव में, शैडो डोम टेंपलेटिंग इंजन टैग का उपयोग करने तक सीमित नहीं है

 <content> 

माथे पर। इसकी एक चुनिंदा विशेषता है, और इसके साथ यह कुछ इस तरह दिखता है:

 <content select=".first"> 

यह टैग होस्ट डोम घटक से "बाहर निकालता है" सभी तत्व जो टैग की कार्रवाई के अंतर्गत आते हैं। तदनुसार, दूसरी बार इस खोज से कुछ भी नहीं मिलेगा। इस प्रकार लेखन

 <content></content><content></content> 

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

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

कस्टम तत्व घोषणा

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

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

 <div class="directive-agreement directive-scrollbox">    ,     ,        </div> 

लंबे समय तक मुझे समझ नहीं आया कि मेरे पास स्क्रॉलबॉक्स क्यों नहीं है। इसके अलावा, डिबगर ने दिखाया कि यह बनाया गया है ... और फिर गायब हो जाता है।
यह पता चला कि निर्देश-स्क्रॉलबॉक्स निष्पादित करने वाला पहला है। और निर्देश-समझौता दूसरा है, और आंतरिक HTML को भी रूपांतरित करता है।

अंत में

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

वेब के विकास के लिए HTML इम्पोर्ट्स का मैकेनिक्स विशेष रूप से महत्वपूर्ण है, क्योंकि यह बड़ी संख्या में वेब घटक पुस्तकालयों के साथ एक ऑनलाइन रिपॉजिटरी / सीडीएन के निर्माण की ओर ले जाने की गारंटी है, और, जैसा कि हम जानते हैं, केंद्रीकृत रिपॉजिटरी समुदाय द्वारा बनाए गए कोड की गुणवत्ता को सकारात्मक रूप से प्रभावित करते हैं: हर कोई अपने को ऊपर उठाने की कोशिश करता है। प्रतिष्ठा, उच्च-गुणवत्ता कोड जारी करना, समुदाय स्वयं सक्रिय रूप से विकसित हो रहा है, और आवश्यक मॉड्यूल और पुस्तकालय आसानी से ढूंढ और कनेक्ट हो रहे हैं। एक केंद्रीकृत CDN वेब पेजों का तेजी से लोडिंग प्रदान करने में सक्षम है (यह हमारे दिनों का संकट है, पेज का आकार तेजी से बढ़ता है अंत उपयोगकर्ता पर इंटरनेट थ्रूपुट बढ़ता है)।

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

मज़ेदार बात यह है कि तत्व को दृश्य होना नहीं है: ऐसा कुछ क्यों नहीं है?

 var $ = document.createElement('x-library-jQuery') 

वेब घटक आपको कस्टम लाइब्रेरी बनाने के लिए एक सुविधाजनक इंटरफ़ेस देता है, जो कम से कम मानकीकृत है, और यह वास्तव में सुविधाजनक है।

आज ही इनका इस्तेमाल शुरू कर दें।
यह कोशिश करो, आप इसे पसंद करेंगे।

यदि आप IE9 + के लिए विकसित कर रहे हैं - आप मोज़िला एक्स-टैग्स का उपयोग कर सकते हैं (अब उनके पास उफ़ हैं, रिपॉजिटरी का उपयोग करें)

यदि IE10 + के लिए, पॉलिमर में प्लग करें और ईमानदार कस्टम तत्वों का उपयोग करें या बहुलक ।js में वेब घटक सुविधाओं के लाइटर सिंटैक्स और एक्सटेंशन का उपयोग करें। पॉलिमर में भारी निवेश करने और वेब घटकों के सभी घटकों के लिए पॉलीफ़िल (यानी कुछ और IE9 +) बनाने के लिए Google को ईमानदारी से धन्यवाद।

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

अंतभाषण

हाल ही में, इस बात पर चर्चा बढ़ रही है कि वेब अधिक खंडित हो रहा है। यदि आपको एक ब्राउज़र मॉड्यूल और एक एएमडी मॉड्यूल कनेक्ट करने की आवश्यकता है, तो इसका कारण होगा ... कुछ समस्याएं। कुछ लाइब्रेरी टाइपस्क्रिप्ट के लिए अनुकूलित हैं, कुछ कॉफ़ीस्क्रिप्ट के लिए (ठीक है, ठीक है, मुझे पता है कि आप उनके साथ काम कर सकते हैं, लेकिन कई कॉफ़ीस्क्रिप्ट आपको आसानी से डरा सकते हैं यदि आपको किसी छोटे पुस्तकालय में छोटे कीड़े को ठीक करने या अपने स्वयं के तरीकों को जोड़ने की आवश्यकता है)। डार्ट आमतौर पर एक अलग भाषा है जो नियमित जेएस के साथ पूरी तरह से बातचीत करती है। वेब घटक इस विखंडन को हटा सकते हैं: सभी घटक एक दूसरे के साथ संगत होंगे, क्योंकि यह सिर्फ HTML होगा। नए तत्वों के साथ चलो। Google आसानी से अपने डार्ट पर घटक बना सकता है, आप icedCfish का उपयोग कर सकते हैं, फेसबुक पर वे अपने JSX के साथ सभी को डराना जारी रखेंगे, और ओडेसा में वे लाइवस्क्रिप्ट पर मॉड्यूल विकसित करना जारी रखेंगे।
आप अभी भी इन पुस्तकालयों का उपयोग कर सकते हैं, क्योंकि इन सभी में बातचीत करने का तरीका समान होगा।
कृपया आज ही उनका उपयोग करना शुरू कर दें और आप वेब को बेहतर बनायेंगे: कोई भी डेवलपर आपके पुस्तकालय का उपयोग करने में सक्षम होगा, चाहे वह शुद्ध जेएस में लिखता हो, या किसी पूर्वप्रक्रमक में, या बिल्कुल नहीं लिखता है - एक स्लाइडर के बारे में सोचें, उदाहरण के लिए, जेएस से आरंभ करने की कोई आवश्यकता नहीं है, यह उसके लिए पर्याप्त है कि उसे विशेषताओं और आंतरिक सामग्री के माध्यम से कॉन्फ़िगर किया जाएगा। सब के बाद, jQuery पुस्तकालयों के दो-तिहाई संभवतः $ () की तरह ही कुछ हैं।

PS मैं वेब कंपोनेंट्स के सप्ताह को खुला घोषित करने का प्रस्ताव रखता हूं