क्या WebAssembly जावा और फ्लैश एप्लेट लौटा रहा है?

WebAssembly पर अंतिम लेख में, मैंने निम्नलिखित वक्तव्य दिया:

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

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

मुझे लगता है कि जब आप WebAssembly के इस विवरण पर आते हैं, तो Flash और Java एप्लेट्स की तुलना काफी स्वाभाविक है :

WebAssembly (कम के लिए Wasm) एक स्टैक्ड वर्चुअल मशीन के लिए एक द्विआधारी अनुदेश प्रारूप है। Wasm को C, C ++ और Rust जैसी उच्च-स्तरीय भाषाओं को संकलित करने के एक पोर्टेबल संस्करण के रूप में विकसित किया गया था, जो आपको इंटरनेट पर क्लाइंट और सर्वर एप्लिकेशन को तैनात करने की अनुमति देता है।

यह पिछले तकनीक की तरह एक सा है। यह तुलना करना तर्कसंगत है कि वे कैसे जुड़े हुए हैं, और उनके बीच छोटे अंतर का सुझाव देने के लिए। लेकिन WebAssembly कई कारणों से काफी अलग है।

वासम हार गया

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

जब मैं WebAssembly की जीत के बारे में बात करता हूं, तो मेरा मतलब है कि यह वेब प्लेटफॉर्म का हिस्सा बन गया है। फ्लैश, जावा एप्लेट्स और पीएनएसीएल ने प्लगइन्स के माध्यम से काम किया। एक मायने में, वे वेब पारिस्थितिकी तंत्र के बाहर थे। वे कभी भी मानक में शामिल नहीं थे, और यह बहुत महत्वपूर्ण है।

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

अन्य प्रौद्योगिकियां मंच में फिट नहीं हुईं

क्या आपको वह याद है?



या है?



इस बारे में कैसे?



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

वेब एक पारिस्थितिकी तंत्र का समर्थन कैसे करता है जो इसके साथ एकीकृत नहीं होता है? ऐसा कभी नहीं होगा। और उपयोगकर्ताओं ने अंततः इसे अस्वीकार कर दिया। गेम्स के अलावा, उपयोगकर्ताओं को फ्लैश से नफरत थी , और जावा एपलेट भारी और धीमी गति से थे। इन तकनीकों को वेब प्लेटफ़ॉर्म में नहीं डाला गया है।

दूसरी ओर, WebAssembly, जावास्क्रिप्ट के बहुत करीब है। वास्तव में, Wasm आपसे स्क्रीन का हिस्सा नहीं छीनता है। वह अपनी छोटी बंद दुनिया का निर्माण नहीं करता है। अब जावास्क्रिप्ट का उपयोग कर रहे हैं, और भविष्य में अपने दम पर , यह पर्यावरण के साथ बातचीत करने में सक्षम है। वह बस ... इसमें फिट बैठता है।

कंपनियों के स्वामित्व वाली अन्य तकनीक

जावा सन माइक्रोसिस्टम्स के स्वामित्व में था, फ्लैश एडोब के स्वामित्व में था। यह महत्वपूर्ण क्यों है?

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

WebAssembly मोज़िला, Google, Apple, Microsoft और अन्य की एक संयुक्त पहल है। यह किसी के विशिष्ट प्लेटफ़ॉर्म को बढ़ावा नहीं देता है, बल्कि कॉरपोरेट और व्यक्ति दोनों के हितधारकों की एक विस्तृत श्रृंखला के सामान्य हितों का प्रतिनिधित्व करता है।

WebAssembly ने वेब प्रक्रिया का पालन किया

कॉर्पोरेट संबद्धता का अर्थ यह भी है कि इन तकनीकों ने वेब को मानकीकृत करने के लिए हमारे द्वारा उपयोग की जाने वाली प्रक्रिया का कभी पालन नहीं किया है। वेब मानकों को अपनाने की प्रक्रिया अच्छी तरह से स्थापित है, लेकिन ये प्रौद्योगिकियां बहुत बड़ी थीं और थोड़ा अलग तरीके से काम करती थीं। इसके विपरीत, WebAssembly ने वेब प्रौद्योगिकियों के लिए अपनाई गई मानक प्रक्रिया का पालन किया।

Asm.js को पहले प्रमाण के रूप में बनाया गया था कि हम वेब के साथ प्रभावशाली चीजें कर सकते हैं। इसका निष्पादन काफी उच्च गुणवत्ता वाला था और प्रौद्योगिकी की क्षमताओं का प्रदर्शन किया, हालांकि वहाँ कुछ भी शानदार नहीं है। asm.js का मुख्य ट्रम्प कार्ड यह था कि यह सिर्फ जावास्क्रिप्ट कोड था: यह मौजूदा पारिस्थितिकी तंत्र के साथ पूरी तरह से संगत है। "इंटरनेट को तोड़ना मत" ब्राउज़र डेवलपर्स के लिए एक बहुत ही महत्वपूर्ण नियम है।

WebAssembly asm.js. का एक बेहतर संस्करण था asm.js आसपास कुछ सर्वसम्मति प्राप्त करने के बाद asm.js हर कोई WebAssembly को एक वास्तविकता बनाने के लिए एक साथ आया। चूंकि यह सिर्फ जावास्क्रिप्ट नहीं है, उसे ब्राउज़रों में कार्यान्वयन के लिए पूरी प्रक्रिया से गुजरना चाहिए था, और उन्होंने इसे पारित कर दिया। यह अब W3C विनिर्देश है, जो वेब मानकों के अनुरूप है , लेकिन उनका खंडन नहीं करता है।

परिणाम: अन्य प्रौद्योगिकियां बहुत बड़ी और अस्थिर थीं

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

ये प्रौद्योगिकियाँ भी स्थिरीकरण की उम्मीद के लिए बहुत बोझिल हैं। क्या आप सोच सकते हैं कि चार ब्राउज़र निर्माता पूरी तरह से जेवीएम विनिर्देशों को परिभाषित करते हैं और फिर इस शब्दार्थ को हमेशा के लिए स्वीकार कर लेते हैं? सभी ActionScript के लिए, जो अपने आप में ECMAScript का एक समान लेकिन अलग संस्करण है? सब कुछ के लिए LLVM-IR?

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

कोरोलरी: अन्य तकनीकों के लिए एक अलग वर्चुअल मशीन की आवश्यकता होती है

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

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

अन्य प्रौद्योगिकियां भी विशिष्ट हैं।

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

क्या हम वास्तव में पूरे इंटरनेट के लिए एक भाषा चुनना चाहते हैं? हमारे पास पहले से ही जावास्क्रिप्ट है। कभी एक तीसरी भाषा की कल्पना करें? चौथे? एक स्वतंत्र दृष्टिकोण लंबे समय में बेहतर है।

वासम की सुरक्षा के लिए एक सख्त दृष्टिकोण है

जावा एप्लेट और फ्लैश एक वास्तविक सुरक्षा दुःस्वप्न थे । भले ही उनकी सुरक्षा के लिए प्रयास किए गए हों, लेकिन वास्तविकता में समस्याएं लगातार पैदा हुईं।

दूसरी ओर, WebAssembly ने जावास्क्रिप्ट वीएम से फिर से बोनस प्राप्त किया: इसके सैंडबॉक्स को अलग करने के सभी प्रयास भी वास पर लागू होते हैं। यहां, सामान्य कोडांतरक के कुछ कार्य गायब हैं, जिससे कमजोरियां हो सकती हैं, जैसे स्टैक विनाश। Wasm मेमोरी के साथ सुरक्षित रूप से काम करता है, जो बहुत महत्वपूर्ण है!

इसके अलावा, WebAssembly को मूल रूप से मान्यता के विचार के साथ डिजाइन किया गया था: यह पूरी तरह से टाइप किया गया है, और प्रोग्राम को रनिंग कोड के साथ जांचा जा सकता है। विनिर्देशों में इस तरह के सत्यापन का संचालन करने के निर्देश शामिल हैं। यह बहुत उपयोगी है!

निष्कर्ष

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

संक्षेप में:

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