वेब इतना जटिल क्यों है?

सीमांत में वर्ष के परिणामों की चर्चा अचानक चर्चा का विषय बन गई । मैं अपनी राय जोड़ूंगा, और मुझे दूसरों की राय सुनने में खुशी होगी।

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

जब कोई शिकायत करता है कि आधुनिक वेब बहुत जटिल हो गया है, तो हर बार मैं इस व्यक्ति को यह याद दिलाना चाहता हूं कि यह आधुनिक वेब वह ऑनलाइन बैंकों में अपने पैसे पर भरोसा करता है और प्रपत्र खरीदता है, सामाजिक नेटवर्क में व्यक्तिगत पत्राचार और तत्काल दूतों के वेब संस्करण, और बादलों में व्यक्तिगत फाइलें। और सबसे अधिक संभावना है कि वह वास्तव में इन प्रणालियों की विकास प्रक्रिया को जटिल, कठिन, लेकिन विश्वसनीय और असफल नहीं होना चाहता है।

चित्र स्रोत

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

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

क्यों?

फिलहाल, HTML + CSS + JS बंडल बिल्डिंग इंटरफेस के संदर्भ में सबसे शक्तिशाली में से एक है - न केवल इसकी क्षमताओं के कारण, बल्कि इस पर निर्मित समाधानों की संख्या - सीएसएस फ्रेमवर्क, विज़ुअल घटकों के पुस्तकालय, बड़ी संख्या में सेवाओं और एसएएएस के लिए इंटरफेस। । संभावित दर्शकों और पहुंच के लिए विकास के घंटों में दक्षता के संदर्भ में, वेब प्रौद्योगिकियां मोबाइल और डेस्कटॉप दोनों समाधानों से आगे हैं। और अब यह तीन क्षेत्रों में विभाजित हो गया है:

• आंशिक रूप से गतिशील सामग्री (गैलरी, पॉपअप और इसी तरह) के साथ पूरी तरह से स्थिर और निकट-स्थैतिक साइटों का विकास
• सर्वर फ्रेमवर्क (django, रेल) ​​पर "क्लासिक" वेब अनुप्रयोगों का विकास
• वेब ग्राहक विकास

और उनमें से प्रत्येक की पूरी तरह से अलग विशिष्टता है।

जेएस विकास वास्तव में दर्दनाक था, इसलिए समाधान दिखाई देने लगे जो इस दर्द को हल करते हैं।

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

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

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

यह स्पष्ट प्रमाण है कि वेब बड़ी टीमों में काम करने की दिशा में विकसित हो रहा है, यह "वयस्क" समाधानों का एक मंच बन गया है।

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

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

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

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

नतीजतन, एक तरफ, हमें हर जगह पुन: उपयोग किए जाने वाले कोड के लिए एक बिल्कुल रमणीय मंच मिला, जो कि वाक्यविन्यास आपको कई सपाट कमांड के साथ काम करने की अनुमति देता है। लेकिन ...

सब कुछ जटिल हो गया और हर कोई भ्रमित हो गया

और किसी को समझ नहीं आ रहा था कि क्या किया जाए। वास्तव में, समस्या क्या है? उन तीन अलग-अलग श्रेणियों में।

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

एक प्रविष्टि बिंदु से मेरा क्या मतलब है: यह एक निश्चित इकाई है, जिसका लोडिंग उत्पाद उपयोगकर्ता के लिए न्यूनतम डिलीवरी के बराबर है। यदि उपयोगकर्ता को जानकारी दिखाने की आवश्यकता है, तो हमें HTML + CSS की आवश्यकता है, यदि हम एप्लिकेशन चलाते हैं, तो हमें HTML से चलने वाले JS की आवश्यकता है।

और सभी को पूरी तरह से भ्रमित करने के लिए, एक चौथी श्रेणी दिखाई दी:

आइसोमोर्फिक अनुप्रयोग

वेब विकास में "आइसोमॉर्फिक" के तहत आमतौर पर कुछ ऐसा होता है जो सर्वर और क्लाइंट दोनों पर काम करता है। इस मोड में, प्रतिक्रिया, कोणीय, vue.js पर अनुप्रयोग काम करने में सक्षम हैं, उदाहरण के लिए, तैयार किए गए ढांचे हैं - अगला और Nuxt ।

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

इससे, CSS-in-JS अवधारणा का जन्म हुआ, जो दो अलग-अलग प्रक्रियाओं पर ध्यान केंद्रित कर रही थी: स्थैतिक सामग्री के लिए CSS फ़ाइल बनाना, और घटकों के बगल में शैलियों को सहेजना।

सब कुछ जेएस के लिए छोड़ दिया।

अब JS में आप स्टाइल, लेआउट और वास्तविक कोड पा सकते हैं।

अब सब कुछ js में है और यह अच्छा है

यह एक और विषयांतर करने लायक है - अब किराने की तरफ।

विकास या विकास में किसी भी उत्पाद के लिए दूसरी दिशा में "चाल" करने में सक्षम होना महत्वपूर्ण है। यह किसी भी स्तर पर कार्य करता है:

• कोड की एक पंक्ति जोड़कर न्यूनतम तर्क के साथ एक दृश्य घटक को चालू करने की क्षमता बहुत शांत है। खरोंच से इसे फिर से लिखने की आवश्यकता शांत नहीं है।

  
  

• एसपीए या सर्वर-साइड एप्लिकेशन बनने के लिए इसे सस्ता बनाना वास्तव में अच्छा है, लेकिन यह बहुत कम संभव है। यह समझदार है, अगर यह लागत को लागू नहीं करता है, तो इस तरह के एक मंच के साथ शुरुआत से शुरू करना है।

  
  

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

जब एक एकल मंच होता है जिसके भीतर कुछ संस्थाएँ दूसरों को काफी सस्ते में बदल सकती हैं, तो विकास बहुत तेजी से होता है।

कोणीय / प्रतिक्रिया / प्रतिज्ञा पर एक आवेदन के मामले में, यह वास्तव में ऐसा है। उन्हें समझना मुश्किल है। कोणीय 1 के रूप में जटिल नहीं, ज़ाहिर है, लेकिन वैसे भी - उन्हें समझने का मार्ग लंबा है, और छह महीने के ऑनलाइन पाठ्यक्रम उन्हें समझने के लिए पर्याप्त नहीं हैं। लेकिन वे कुछ ही घंटों में ऐसा करने का अवसर प्रदान करते हैं जो कई सप्ताह पहले किया गया था, और कुछ ही दिनों में - जो कई महीने लगते थे।

हालांकि, विपरीत भी सच है - कई को उनकी ज़रूरत नहीं है, लेकिन उनका उपयोग किया जाता है क्योंकि यह "फैशनेबल" है।

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

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

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