हमने वह वेब खो दिया।

संक्षेप में : ब्राउज़र युद्धों के बाद, वेब मानक परियोजना जैसे W3C संगठन और विकास टीमों ने एक एकल, अप्रकाशित वेब को पुनर्स्थापित करने के लिए लंबे और कठिन काम किया। लेकिन पिछले कुछ वर्षों में, हमने डेवलपर्स को फिर से सब कुछ ले लिया है और खंडित कर दिया है ... शायद हमें यह समझने की जरूरत है कि इस वेब को हमेशा के लिए खो देने से पहले हम क्या खो रहे हैं।

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

विशेष रूप से अगर वह अवधि, 2000 के दशक के मध्य तक, वेब पर आपकी पूर्ण उपस्थिति से पहले थी, तो आपको धीरे-धीरे उनके लेख को अच्छी तरह से पढ़ने के लिए समय निकालना चाहिए। वेब वास्तव में पिछले एक दशक में बदल गया है, और हमेशा बेहतर के लिए नहीं। अनिल लिखते हैं:

"हमने उन मूल विचारों को खो दिया है, जो बदतर हैं, और इससे भी बदतर, उन मूलभूत मूल्यों को छोड़ दिया है जो वेब के मूल में थे।"

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

संभवतः इनमें से कुछ विचार वास्तव में हवा में हैं, क्योंकि पिछले कुछ हफ्तों में फारुक एटे और जेरेमी कीथ भी इस विषय पर विचार कर रहे हैं।

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

ब्राउज़र युद्ध

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

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

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

लेकिन कार्यों में से कोई भी मूल रूप से मानकीकृत नहीं था, कोई भी विकसित मानक नहीं थे, उनमें से प्रत्येक शुरू में एक ब्राउज़र में दिखाई दिया, और अन्य ने जल्दबाजी में सफल समाधानों को फिर से लागू किया और फिर एक नियम के रूप में, कुछ हद तक असंगत संस्करण के रूप में स्वतंत्र रूप से लागू किया।

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

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

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

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

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

और फिर, कदम दर कदम, उस मेंढक की तरह जो धीरे-धीरे उबलते पानी में अपनी मौत को नोटिस नहीं करता, हमने इस वेब को फेंक दिया।

• हमने DOM लाइब्रेरीज़ और फ्रेमवर्क के विखंडन की अनुमति दी है, प्रोत्साहित किया है और स्वीकार किया है, जिनमें से प्रत्येक के पास एक्सेस करने, तत्वों को संशोधित करने और DOM को प्रबंधित करने का अपना तरीका है।
• हमने इसमें संकलित भाषाओं के साथ जावास्क्रिप्ट को खंडित किया है।
• हमने HTML को टेम्पलेट इंजनों के टन के साथ खंडित किया है।
• हमने Sass और कम जैसे पूर्वप्रक्रमकों के साथ CSS को खंडित किया।

हमने क्या किया है?

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

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

हमें क्या मिला?

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

लेकिन हमने क्या खोया है?

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

शिक्षणीयता

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

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

repairability

प्रौद्योगिकियों का एक सामान्य समूह होने से मौजूदा कोड आधार को बनाए रखना आसान हो जाता है। अंतर्निहित HTML, CSS, JavaScript, और DOM प्रौद्योगिकियां लंबे समय से स्थिर हैं, अधिकांश चौखटे, लाइब्रेरी, भाषा और प्रीप्रोसेसर के विपरीत (उन उपकरणों और भाषाओं का उल्लेख नहीं करने के लिए जो वे आंशिक रूप से निर्भर करती हैं)। क्या आपकी सेवा का आधार 5 वर्षों के लिए समर्थित होगा? और, कम आम प्रौद्योगिकियों के आधार पर, कोड आधार का समर्थन करने में सक्षम डेवलपर्स की संख्या काफी कम हो जाती है।

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

बातचीत

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

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

सहनशीलता

यदि आपने फ्लैश या सिल्वरलाइट / WPF में ज्ञान और अनुभव विकसित करने में वर्षों बिताए हैं, तो यह ज्ञान अधिक से अधिक बेकार हो जाता है। यही बात jQuery के साथ भी होगी, क्योंकि यह अन्य प्रतीत होता है जावास्क्रिप्ट जावास्क्रिप्ट और प्रोटोटाइप जैसे चौखटे के साथ था। यह उन सभी पुस्तकालयों और रूपरेखाओं के साथ होगा जो आज हम इतनी मेहनत से पढ़ते हैं: AngularJS, बूटस्ट्रैप, <... अपने नाम को प्रतिस्थापित करें ...>। बहुत कम प्रौद्योगिकियां हाल के वर्षों में रहीं हैं, दशकों का उल्लेख नहीं करना। एक ऐसे व्यक्ति के रूप में जो तकनीक का अध्ययन करने के लिए उचित समय बिताता है, मुझे चिंता होगी कि प्रयास उचित हैं।

क्या करें?

jQuery, Backbone, AngularJS, CoffeeScript, Bootstrap, Sass, LESS (केवल कुछ लोकप्रिय रूपरेखाओं, पुस्तकालयों, भाषाओं और पूर्वप्रकारों के नाम जो हमने पिछले कुछ वर्षों में समस्याओं को हल करने के लिए विकसित किए हैं, विशेष रूप से कुछ भी उजागर किए बिना तेजी से जटिल चीजें करने के लिए। ) परिष्कृत, शक्तिशाली प्रौद्योगिकियां हैं, जो हजारों, डेवलपर्स के हजारों या अधिक द्वारा उपयोग की जाने वाली कई कार्य प्रक्रियाओं में अच्छी तरह से साबित होती हैं। उनसे रहा नहीं जाता। और उनके बाद दूसरे लोग आएंगे। आपको एचटीएमएल, सीएसएस, डोम, जावास्क्रिप्ट में उच्च प्रौद्योगिकी से विसर्जन धीमा करने की आवश्यकता हो सकती है। सब के बाद, प्रोग्रामर लिखते हैं, अगर बिल्कुल, विधानसभा भाषा, मशीन कोड का उल्लेख नहीं करना है। लेकिन, जैसा कि अनिल दाश ने एक अन्य वेब के बारे में लिखा है, " हमने उन मूलभूत मूल्यों को छोड़ दिया जो वेब की दुनिया के मूल में थे, " और मुझे लगता है कि यह बनाया जा रहा कोड का सच है।

ये मूल मूल्य क्या हो सकते हैं? यह देखना आसान है कि उन्हें W3C संघ द्वारा स्पष्ट रूप से वर्णित किया गया है (एक बार फिर, अनिल ने कहा: " थोड़ा इतिहास सीखें, इसकी उत्पत्ति जानने के लिए ")।

“डब्ल्यू 3 सी तकनीकी उत्कृष्टता के लिए प्रतिबद्ध है, लेकिन अच्छी तरह से पता है कि आज जो ज्ञात है वह कल की समस्याओं को हल करने के लिए पर्याप्त नहीं हो सकता है। इसलिए, हम एक ऐसे वेब का निर्माण करने का प्रयास करते हैं जो आसानी से पहले से ही काम किए बिना एक बेहतर वेब में बदल सकता है। सादगी, प्रतिरूपता, अनुकूलता और व्यापकता के सिद्धांत हमारे सभी डिजाइनों को प्रभावित करते हैं। ”

डब्ल्यू 3 सी लक्ष्य, संचालन के सिद्धांत और उनका ध्यान

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

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

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

... जो होमर के सदृश होने की अधिक संभावना है:

छोटे टुकड़ों का स्वतंत्र लगाव

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

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

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

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

UPD 12.12.2013 16.00 : लेखक ने एक सप्ताह और यहाँ - एक दिन में ब्लॉग पर जो लिखा है, उसकी तुलना करना दिलचस्प है; मैं अंग्रेजी टिप्पणीकारों के अनुवादों की शुरुआत , सभी को एक पंक्ति में दूंगा:

सामान्य तौर पर, थोड़ा और अधिक होता है, लेकिन सप्ताह के लिए, फिर भी, लेकिन हम स्थिति के विश्लेषण की पूर्णता में पीछे नहीं रहते, हमने टिप्पणियों में सभी विशेष बिंदुओं को नोट किया।