WebAssembly विकास: वास्तविक रेक और उदाहरण

WebAssembly की घोषणा 2015 में हुई - लेकिन अब, वर्षों के बाद, अभी भी कुछ ही हैं जो उत्पादन में इसका दावा कर सकते हैं। इस तरह के अनुभव पर सामग्री सभी अधिक मूल्यवान हैं: व्यवहार में इसके साथ कैसे रहना है, इस बारे में पहली-हाथ की जानकारी अभी भी कम आपूर्ति में है।

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



मेरा नाम एंड्री है, मैं आपको WebAssembly के बारे में बताऊंगा। हम कह सकते हैं कि मैंने पिछली शताब्दी में वेब में संलग्न होना शुरू कर दिया था, लेकिन मैं मामूली हूं, इसलिए मैंने ऐसा नहीं कहा। इस समय के दौरान, मैं बैकएंड और फ्रंटेंड दोनों पर काम करने में कामयाब रहा, और यहां तक ​​कि थोड़ा डिज़ाइन भी आकर्षित किया। आज मुझे WebAssembly, C ++ और अन्य देशी चीजों के रूप में ऐसी चीजों में दिलचस्पी है। मैं भी वास्तव में टाइपोग्राफी से प्यार करता हूं और पुरानी तकनीक इकट्ठा करता हूं।

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

हमने WebAssembly को कैसे लागू किया

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

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



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

हमें एक बहुत बड़ा आवेदन मिला (900 वर्ग), लेकिन यह ठीक काम करता है। विंडोज और लिनक्स के तहत, हम मूल कोड में संकलित करते हैं। Android और iOS के लिए, हम एक लाइब्रेरी बनाते हैं, जिसे हम एप्लिकेशन से कनेक्ट करते हैं। हम एक और बार टिज़ेन के बारे में बात करेंगे, लेकिन वेब पर हम एक ब्राउज़र प्लगइन के रूप में काम करते थे।

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

2017 में, एक नई आशा आई। जैसा कि आप सोच सकते हैं, यह WebAssembly है। परिणामस्वरूप, हम अपने आवेदन को एक ब्राउज़र में पोर्ट करने का कार्य स्वयं निर्धारित करते हैं। चूंकि फ़ायरफ़ॉक्स और क्रोम के लिए समर्थन पहले से ही वसंत में दिखाई दिया, और 2017 के पतन तक, एज और सफारी ने खुद को ऊपर खींच लिया।

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

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

बाइटफॉग आर्किटेक्चर

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



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



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



ऐसी प्रत्येक जगह के लिए हमने एक विनिर्देश निर्धारित किया है, अर्थात्, हमने एक अनुबंध निर्धारित किया है: क्या विधियाँ होंगी, उनके पास कौन से पैरामीटर होंगे, क्या डेटा प्रकार। एक बार जब आप यह कर लेते हैं, तो आप समानांतर में काम कर सकते हैं, प्रत्येक डेवलपर अपनी तरफ से।

परिणाम क्या है? हमने मुख्य वीडियो वितरण चैनल को सामान्य AJAX के साथ प्रदाता से बदल दिया। हम लोकप्रिय HLS.js लाइब्रेरी के माध्यम से खिलाड़ी को डेटा जारी करते हैं, लेकिन यदि आवश्यक हो, तो अन्य खिलाड़ियों के साथ एकीकृत करने की एक मौलिक संभावना है। हमने वेबआरटीसी के साथ पूरे पी 2 पी परत को बदल दिया।



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

बंडल इकट्ठा करना

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

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

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

फ़ाइलों की संख्या के अनुसरण में, मैंने SINGLE_FILE विकल्प का उपयोग करने का निर्णय लिया। यह Base64 फॉर्म में संकलन से उत्पन्न सभी बायनेरिज़ का अनुवाद करता है और इसे एक स्ट्रिंग के रूप में चिपकने वाला कोड में धकेलता है। एक महान विचार की तरह लगता है, लेकिन उसके बाद बंडल आकार में 100 मेगाबाइट बन गया। न तो वेबपैक, न ही बैबेल, न ही ब्राउजर इतनी मात्रा में काम करते हैं। वैसे भी, हम उपयोगकर्ता को 100 मेगाबाइट लोड करने के लिए मजबूर नहीं करेंगे?!

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

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

Thenable

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

return new Promise((resolve, reject) => { Module(config).then((module) => { resolve(module); }); }); 

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

 Module['then'] = function(func) { if (Module['calledRun']) { func(Module); } else { Module['onRuntimeInitialized'] = function() { func(Module); }; }; return Module; }; 

आइए इसे और अधिक विस्तार से देखें। बहुत

 Module['onRuntimeInitialized'] = function() { func(Module); }; 

कॉलबैक लटकाने के लिए जिम्मेदार। यहां सब कुछ स्पष्ट है: एक अतुल्यकालिक फ़ंक्शन जो हमारे कॉलबैक को कॉल करता है। सब कुछ जैसा हम चाहते हैं। इस सुविधा का एक और हिस्सा है।

 if (Module['calledRun']) { func(Module); 

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

यदि आप ध्यान से प्रलेखन को पढ़ते हैं, तो यह पता चला है कि प्रॉमिस के बारे में एक बहुत ही सूक्ष्म बिंदु है। जब हम किसी का उपयोग करने का वादा करने का संकल्प लेते हैं, तो ब्राउज़र उस तबके से मानों को खोल देगा, और ऐसा करने के लिए, यह .then () विधि को कॉल करेगा। नतीजतन, हम वादा को हल करते हैं, इसके लिए मॉड्यूल पास करते हैं। ब्राउज़र पूछता है: तो क्या यह एक वस्तु है? हां, यह एक तबीयत है। फिर .then () फ़ंक्शन को मॉड्यूल पर कहा जाता है, और रिज़ॉल्यूशन फ़ंक्शन को कॉलबैक के रूप में पास किया जाता है।

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



मुझे इस समस्या का एक सुरुचिपूर्ण समाधान नहीं मिला। नतीजतन, मैं बस संकल्प से पहले .then () विधि को हटा देता हूं, और यह काम करता है।

Emscripten

इसलिए, हमने मॉड्यूल को संकलित किया, जेएस को इकट्ठा किया, लेकिन कुछ गायब है। हमें शायद कुछ उपयोगी काम करने की जरूरत है। ऐसा करने के लिए, डेटा ट्रांसफर करें और दो दुनियाओं को कनेक्ट करें - JS और C ++। यह कैसे करना है? Emscripten तीन विकल्प प्रदान करता है:

• पहला ccall और cwrap फ़ंक्शन है। अक्सर आप उन्हें WebAssembly पर कुछ ट्यूटोरियल में मिलेंगे, लेकिन वे वास्तविक काम के लिए उपयुक्त नहीं हैं, क्योंकि वे C ++ की क्षमताओं का समर्थन नहीं करते हैं।
• दूसरा है वेबआईडीएल बाइंडर। यह पहले से ही C ++ फ़ंक्शन का समर्थन करता है, आप पहले से ही इसके साथ काम कर सकते हैं। यह एक गंभीर इंटरफ़ेस विवरण भाषा का उपयोग किया जाता है, उदाहरण के लिए, उनके प्रलेखन के लिए W3C द्वारा। लेकिन हम इसे अपने प्रोजेक्ट में नहीं ले जाना चाहते थे और तीसरे विकल्प का इस्तेमाल किया
• Embind। हम कह सकते हैं कि यह Emscripten के लिए वस्तुओं को जोड़ने का एक मूल तरीका है, यह C ++ टेम्प्लेट पर आधारित है और आपको C ++ से JS और इसके विपरीत विभिन्न संस्थाओं को अग्रेषित करके बहुत सी चीजें करने की अनुमति देता है।

Embind आपको इसकी अनुमति देता है:

• जावास्क्रिप्ट कोड से C ++ फ़ंक्शन को कॉल करें
• C ++ क्लास से JS ऑब्जेक्ट बनाएं
• C ++ कोड से, ब्राउज़र API की ओर मुड़ें (यदि किसी कारण से आप ऐसा चाहते हैं, तो आप उदाहरण के लिए, C ++ में संपूर्ण फ्रंट-एंड फ्रेमवर्क लिख सकते हैं)।
• हमारे लिए मुख्य बात: C ++ में वर्णित जावास्क्रिप्ट इंटरफ़ेस को लागू करना।

डेटा विनिमय

अंतिम बिंदु महत्वपूर्ण है, क्योंकि यह बिल्कुल एक्शन है जिसे आप एप्लिकेशन को पोर्ट करते समय लगातार करेंगे। इसलिए, मैं इस पर अधिक विस्तार से ध्यान देना चाहूंगा। अब C ++ कोड होगा, लेकिन डरा नहीं होगा, यह लगभग टाइपस्क्रिप्ट :-D की तरह है

योजना इस प्रकार है:



C ++ की तरफ, एक कर्नेल है जिससे हम एक्सेस देना चाहते हैं, उदाहरण के लिए, बाहरी नेटवर्क पर - वीडियो अपलोड करने के लिए। यह देशी सॉकेट्स के साथ ऐसा करता था, कुछ प्रकार का HTTP क्लाइंट था जो ऐसा करता था, लेकिन WebSssembly में कोई देशी सॉकेट नहीं हैं। हमें किसी तरह बाहर निकलने की आवश्यकता है, इसलिए हम पुराने HTTP क्लाइंट को काट देते हैं, इस स्थान पर इंटरफ़ेस डालते हैं, और किसी भी तरह से नियमित AJAX का उपयोग करके जावास्क्रिप्ट में इस इंटरफ़ेस को लागू करते हैं। उसके बाद, हम परिणामस्वरूप ऑब्जेक्ट को C ++ में वापस भेज देंगे, जहां कर्नेल इसका उपयोग करेगा।

चलो सबसे सरल HTTP क्लाइंट बनाते हैं जो केवल अनुरोध प्राप्त कर सकते हैं:

 class HTTPClient { public: virtual std::string get(std::string url) = 0; }; 

इनपुट के लिए, इसे डाउनलोड करने के लिए URL के साथ एक स्ट्रिंग प्राप्त होती है, और आउटपुट के लिए
अनुरोध के परिणाम के साथ एक स्ट्रिंग। C ++ में, स्ट्रिंग्स में बाइनरी डेटा हो सकता है, इसलिए यह वीडियो के लिए उपयुक्त है। Emscripten हमें यहाँ लिखते हैं
इस तरह के एक डरावना आवरण:



इसमें, मुख्य चीज दो चीजें हैं - फ़ंक्शन का नाम C ++ पक्ष (मैंने उन्हें हरे रंग में चिह्नित किया है), और जावास्क्रिप्ट पक्ष पर संबंधित नाम (मैंने उन्हें नीले रंग में चिह्नित किया है)। परिणामस्वरूप, हम संचार की घोषणा लिखते हैं:



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



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

आउटपुट पर, विस्तार हमें एक नियमित जावास्क्रिप्ट निर्माता देता है। हम इसे आवश्यक रूप से कई बार कॉल कर सकते हैं और हमें आवश्यक मात्रा में ऑब्जेक्ट उत्पन्न कर सकते हैं। लेकिन एक ऐसी स्थिति होती है जब हमारे पास एक वस्तु होती है, और हम इसे C ++ पक्ष में पारित करना चाहते हैं।



ऐसा करने के लिए, किसी तरह इस ऑब्जेक्ट को एक प्रकार से बांधें जिसे C ++ समझ जाएगा। यह वह कार्य है जो कार्यान्वयन कार्य करता है। आउटपुट पर, यह एक कंस्ट्रक्टर नहीं देता है, लेकिन एक तैयार-से-उपयोग की जाने वाली वस्तु, हमारा क्लाइंट, जिसे हम C ++ को वापस दे सकते हैं। आप ऐसा कर सकते हैं, उदाहरण के लिए, इस तरह:

 var app = Module.makeApp(client, …) 

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

 val client = val::global(″client″); client.call<std::string>(″get″, val(...) ); 

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

बाइंडिंग त्रुटियाँ

सामान्य तौर पर, यह सब है, लेकिन जब आप विकास शुरू करते हैं, तो बाध्यकारी त्रुटियां आपका इंतजार करती हैं। वे कुछ इस तरह दिखते हैं:



Emscripten हमारी मदद करने की कोशिश करता है और समझाता है कि क्या गलत हो रहा है। यदि यह सब संक्षेप में प्रस्तुत किया गया है, तो आपको यह सुनिश्चित करने की आवश्यकता है कि वे मेल खाते हैं (इसे सील करना आसान है और बाध्यकारी त्रुटि प्राप्त करें:

• नाम
• प्रकार
• मापदंडों की संख्या

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

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

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

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

बढ़ाएँ और ES6

एक्सटेंड के साथ एक और समस्या यह है कि यह ईएस 6 कक्षाओं का समर्थन नहीं करता है। जब आप किसी ES6 वर्ग से प्राप्त किसी वस्तु को प्राप्त करते हैं, तो एक्सटेंड सभी संपत्तियों की उम्मीद करता है कि इसमें गुणकारी हो, लेकिन ES6 के साथ ऐसा नहीं है। विधियाँ प्रोटोटाइप में हैं और उनके पास असंख्य हैं: असत्य। मैं इस तरह एक बैसाखी का उपयोग करता हूं, जिसमें मैं प्रोटोटाइप पर जाता हूं और enumerable: true: को चालू करता हूं।

 function enumerateProto(obj) { Object.getOwnPropertyNames(obj.prototype) .forEach(prop => Object.defineProperty(obj.prototype, prop, {enumerable: true}) ) } 

मुझे उम्मीद है कि किसी दिन मैं इससे छुटकारा पा सकता हूं, क्योंकि ES6 के लिए समर्थन में सुधार के बारे में Emscripten समुदाय में बात की गई है।

बिना सोचे समझे याद करना

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

एक और विकल्प है - ALLOW_MEMORY_GROWTH। यह आपको मेमोरी बढ़ाने की अनुमति देता है
धीरे-धीरे आवश्यकतानुसार। यह इस तरह काम करता है: डिफ़ॉल्ट रूप से Emscripten ऑपरेशन के लिए मॉड्यूल 16 मेगाबाइट देता है। जब आप सभी ने उनका उपयोग किया, तो स्मृति का एक नया टुकड़ा आवंटित किया जाता है। सभी पुराने डेटा को वहां कॉपी किया जाता है, और आपके पास नए लोगों के लिए अभी भी उतना ही स्थान है। ऐसा तब तक होता है जब तक आप 4 जीबी तक नहीं पहुंच जाते।

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

निर्भरता इंजेक्शन

ऐसा लगता है कि यह सब था, लेकिन फिर रेक थोड़ा और बढ़ गया। डिपेंडेंसी इंजेक्शन के साथ एक समस्या है। हम सबसे सरल वर्ग लिखते हैं जिसमें एक निर्भरता की आवश्यकता होती है।

 class App { constructor(httpClient) { this.httpClient = httpClient } } 

उदाहरण के लिए, हम अपने HTTP क्लाइंट को अपने एप्लिकेशन में पास करते हैं। हम वर्ग संपत्ति में बचाते हैं। ऐसा लगता है कि सब कुछ अच्छा काम करेगा।

 Module.App.extend( ″App″, new App(client) ) 

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

 class App { _construct(httpClient) { this.httpClient = httpClient this._parent._construct.call(this) } } 

हम लगभग एक ही काम करते हैं: हम वस्तु के क्षेत्र में निर्भरता को संग्रहीत करते हैं, लेकिन यह वह वस्तु है जो विरासत के बाद निकली है। हमें कंस्ट्रक्टर कॉल को मूल ऑब्जेक्ट पर अग्रेषित करना नहीं भूलना चाहिए, जो C ++ साइड पर स्थित है। अंतिम पंक्ति ES6 में सुपर () विधि का एक एनालॉग है। इस मामले में विरासत कैसे होती है:

 const appConstr = Module.App.extend( ″App″, new App() ) const app = new appConstr(client) 

सबसे पहले, हम विरासत में लेते हैं, फिर एक नई वस्तु बनाते हैं जिसमें निर्भरता पहले से ही पारित हो जाती है, और यह काम करता है।

सूचक चाल

एक अन्य समस्या C ++ से जावास्क्रिप्ट तक पॉइंटर द्वारा ऑब्जेक्ट्स को पास करना है। हमने पहले ही एक HTTP क्लाइंट किया था। सादगी के लिए, हमने एक महत्वपूर्ण विवरण याद किया है।

 std::string get(std::string url) 

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

 void get(std::string url, Listener listener) 

जेएस में, यह इस तरह दिखता है:

 function get(url, listener) { fetch(url).then(result) => { listener.onResult(result) }) } 

हमारे पास एक ऐसा फ़ंक्शन है जो इस श्रोता वस्तु को लेता है। हम फ़ाइल डाउनलोड शुरू करते हैं और कॉलबैक लटकाते हैं। जब फ़ाइल डाउनलोड हो जाती है, तो हम श्रोता से वांछित फ़ंक्शन को खींचते हैं और परिणाम को पास करते हैं।

ऐसा लगता है कि योजना अच्छी है, लेकिन जब फ़ंक्शन पूरा हो जाता है, तो सभी स्थानीय चर नष्ट हो जाएंगे, और उनके साथ फ़ंक्शन पैरामीटर, अर्थात, सूचक नष्ट हो जाएगा, और रनटाइम ईस्मैप्टेन C ++ पक्ष पर ऑब्जेक्ट को नष्ट कर देगा।

परिणामस्वरूप, जब लाइन श्रोता को कॉल करने की बात आती है .onResult (परिणाम), श्रोता अब मौजूद नहीं होगा, और इसे एक्सेस करते समय, एक मेमोरी एक्सेस त्रुटि उत्पन्न होगी जो एप्लिकेशन क्रैश का कारण बनेगी।

मैं इससे बचना चाहूंगा, और एक समाधान है, लेकिन इसे खोजने में कई सप्ताह लग गए।

 function get(url, listener) { const listenerCopy = listener.clone() fetch(url).then((result) => { listenerCopy.onResult(result) listenerCopy.delete() }) } 

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

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

स्मृति को तेजी से लिखें

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

 var newData = new Uint8Array(…); var size = newData.byteLength; var ptr = Module._malloc(size); var memory = new Uint8Array( Module.buffer, ptr, size ); memory.set(newData); 

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

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

और हमारे आवेदन में, हम मेमोरी नकल को बचाने के लिए चाल शब्दार्थों पर भी भरोसा करते हैं।

AdBlock

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



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

प्रोडक्शंस

नतीजतन, हम उत्पादन में चले गए। हां, यह आसान नहीं था, इसमें 8 महीने लगे और मैं खुद से पूछना चाहता हूं कि क्या यह इसके लायक था। मेरी राय में - यह मूल्य था:

स्थापित करने की आवश्यकता नहीं है

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

विभिन्न प्लेटफॉर्मों पर एकीकृत कोड आधार और डिबगिंग

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

जल्दी रिलीज

हमें एक त्वरित रिलीज़ मिला, क्योंकि हम एक साधारण वेब-एप्लिकेशन के रूप में रिलीज़ हो सकते हैं और प्रत्येक नई रिलीज़ के साथ C ++ कोड अपडेट कर सकते हैं। इसकी तुलना नए प्लगिन, मोबाइल एप्लिकेशन या स्मार्टटीवी एप्लिकेशन को जारी करने के तरीके से नहीं की जाती है। रिहाई केवल हम पर निर्भर करती है: जब हम चाहते हैं, तब यह जारी किया जाएगा।

त्वरित प्रतिक्रिया

और इसका मतलब है कि त्वरित प्रतिक्रिया: अगर कुछ गलत हो जाता है, तो हम दिन के दौरान पता लगा सकते हैं कि कोई समस्या है और इसका जवाब दें।

मेरा मानना ​​है कि ये सभी समस्याएं इन फायदों के लायक थीं। सभी के पास C ++ एप्लिकेशन नहीं है, लेकिन यदि आपके पास एक है और आप चाहते हैं कि यह ब्राउज़र में हो - WebAssembly आपके लिए 100% उपयोग का मामला है।

आवेदन कहां करें

हर कोई C ++ में नहीं लिखता है। लेकिन WebAssembly के लिए न केवल C ++ उपलब्ध है। हां, यह ऐतिहासिक रूप से बहुत पहला मंच है जो अभी भी मोज़िल्स में उपलब्ध था, जो एक प्रारंभिक मोज़िला तकनीक है। वैसे, यह बहुत अच्छा उपकरण है, के रूप में वे तकनीक से ही पुराने हैं।

रतुआ

नई रस्ट भाषा, जो कि मोज़िला द्वारा भी विकसित की जा रही है, अब टूल के मामले में C ++ से आगे और आगे निकल रही है। सब कुछ इस बिंदु पर जाता है कि वे WebAssembly के लिए सबसे अच्छे विकास की प्रक्रिया करेंगे।

लुआ, पर्ल, पायथन, पीएचपी, आदि।

व्याख्या की जाने वाली लगभग सभी भाषाएँ भी WebAssembly में उपलब्ध हैं, क्योंकि उनके दुभाषिए C ++ में लिखे गए हैं, वे बस WebAssembly में संकलित किए गए थे और अब आप एक ब्राउज़र में PHP को मोड़ सकते हैं।

जाओ

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

कोटलिन / देशी

कोटलिन के साथ एक ही कहानी के बारे में। उनके संकलक को प्रयोगात्मक समर्थन है, लेकिन उन्हें कचरा कलेक्टर के साथ भी कुछ करना होगा। मुझे नहीं पता कि वहां क्या स्थिति है।

3 डी ग्राफिक्स

आप और क्या सोच सकते हैं? पहली चीज जो भाषा में घूमती है वह 3 डी एप्लीकेशन है। और, वास्तव में, ऐतिहासिक रूप से, asm.js और WebAssembly ब्राउज़र में गेम को पोर्ट करने के साथ शुरू हुआ। और यह आश्चर्यजनक नहीं है कि अब सभी लोकप्रिय इंजनों का निर्यात WebAssembly के पास है।

स्थानीय रूप से डाटा प्रोसेसिंग

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

तंत्रिका नेटवर्क

. , , , , . , , ; — .



, Google Chrome, , WebAssembly-. npm- , Wasm, JS. , ++ - — .

HunSpell — Wasm .

— « ». , - , — OpenSSL. WebAssembly. OpenSSL — , , .

use case wotinspector.com. World of Tanks. , , , , , .

— . , , . , , - ++, WebAssembly, ( , ).

. , , . . , , , , . . .

, , ++. , FFmpeg, . , ffmpeg. . , , , , .



— . OpenCV — , WebAssembly, . PDF. SQLite, SQL. SQLite WebAssembly Emscripten, .

Node.js

WebAssembly, Node.js. , Sass — css. Ruby, ++ ( libsass). , Webpack', Node.js. node-sass , JS- .

, , . . :



, node-sass 100 . , ( ) . WebAssembly : , WebAssembly .

Node. , WebAssembly libsass-asm . , . WebAssembly …

Figma — web-. - Sketch, , . ++ ( ), asm.js. , .



WebAssembly, , 3 . , .

Visual Studio Code, , Electron, , , Node-sass. , Node, . , , , WebAssembly.

— AutoCAD. 30 , ++, . , , - JavaScript, , . WebAssembly AutoCAD - , 5 .

, , , , , , , , . FFMpeg — , — QEMU. , , KVM, .



2011 QEMU . , . , Linux , Linux-, , - .

, . bash, , Linux. — GUI . . , , …



, , - . Windows 2000 , , 18 , . , Chrome ( FireFox).

, WebAssembly , , , , .

, WebAssembly. , — , . — , .



, C++ web-. , , — . — , , , .

, . , C++, JavaScript, . , C++. , JS C++, .

— .

CI Pipeline

? JS- , Webpack. , , ( ), JS. webpack watch, , .

, . , , .

Chrome DevTools, Sources wasm-. ( - ), , , .



, , : «, , , , , !». , embedded-, , - .

: -g4 wast- , .



, 100 ( FAR). — , Chrome. E:/_work/bfg/bytefrog/… — . , ++ . , SourceMap!

SourceMap

, .

• Firefox.
• --sourcemap-base=http://localhost , SourceMap -, .
• HTTP.
• .
• Windows «:» . .

. CMake , URL -. : wast- , . , .

, :



++ . ! , , stack trace, . , wasm- stack trace, , , , , .



, — SourceMap . , , . , .



«var0».



, . , SourceMap, , .

. Chrome, Firefox. Firefox — «» , , .



Chrome ( , , Mangled ), , , , .

. , :

• . runtime, . ++ Rust Go.
• JS — Wasm. , JS Wasm. -, , . , .
• . , , , .
• Wasm . Wasm , JS. WebAssembly , .
• JS.

: .

• wasp_cpp_bench
• Chrome 65.0.3325.181 (64-bit)
• Core i5-4690
• 24gb ram
• 5 ; max min;

. JS — , .



++, , - . Grayscale. C++ , . ( ), , JS. , , , ++, .

Sentry, — wasm. , traceKit, Sentry — Raven, — , , wasm . , , , pull request, npm install JS-.



. production, , . debug-, , :

• WebAssembly , .
• — . 8 , C++, , .
• , , WebAssembly — .
• — JS. JS- , «» , , .

, :

• Emscripten Embind. .
• - Emscripten — . , , 3000 Emscripten.
• Sentry.
• Firefox.

आपका ध्यान के लिए धन्यवाद! .

HolyJS, : 24-25 HolyJS . (, Node.js Ryan Dahl!), — 1 .