अतीत और भविष्य जावास्क्रिप्ट संकलन

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

Js कोड की व्याख्या करने वाला पहला इंजन स्पाइडरमोंकी था, जिसे 1995 में नेटस्केप 2.0 ब्राउज़र में पेश किया गया था। इसकी त्वरित रचना का मिथक अच्छी तरह से प्रलेखित है । ब्रेंडन इके के पास भाषा को डिज़ाइन करने और संकलक बनाने के लिए केवल 10 दिन थे। जावास्क्रिप्ट शुरू से ही सफल रहा था, और इसी कोड के अगस्त तक, Microsoft ने अपने JScript के संस्करण को पहले ही Internet Explorer 3.0 में एकीकृत कर लिया था। 1996 के अंत तक, भाषा को औपचारिक मानकीकरण के लिए आयोग में स्वीकार कर लिया गया था, और अगले वर्ष के जून में इसने आधिकारिक मानक ECMA-262 का अधिग्रहण कर लिया। तब से, जेएस के लिए समर्थन हर ब्राउज़र के लिए अनिवार्य हो गया है, और हर प्रमुख निर्माता ने जेएस का समर्थन करने के लिए अपना खुद का इंजन बनाना शुरू कर दिया है। वर्षों में, ये इंजन विकसित हुए, एक-दूसरे को प्रतिस्थापित किया, नाम बदला और निम्न इंजनों के लिए आधार बने। सभी बनाए गए संस्करणों का ट्रैक रखना दिल के बेहोश होने के लिए नहीं है।



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

इसके विपरीत प्रक्रियाएं भी हुईं। ऐसे इंजन हैं जिनके नाम अपरिवर्तित रहे हैं, जबकि सभी इंसिडेंस बदल दिए गए हैं। उदाहरण के लिए, मोज़िला के स्पाइडरमोंकी में, 1995 में मौजूद कोड का कोई संकेत नहीं है।

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

जब हम जावास्क्रिप्ट इंजन के बारे में बात करते हैं, तो हम आम तौर पर संकलक का मतलब है, और संकलक द्वारा उत्पन्न कोड तेजी से बना रही है कि असली चुनौती क्या है। शायद सभी जेएस लेखक इस बात से हैरान नहीं हैं कि कंपाइलर कैसे काम करता है।
यह समझा जाता है कि जावास्क्रिप्ट एक उच्च-स्तरीय भाषा है। इसका मतलब है कि यह पठनीय है और इसमें उच्च स्तर का लचीलापन है। कंपाइलर का काम इस मानव-पठनीय कोड से देशी कोड उत्पन्न करना है।

आमतौर पर संकलन 4 चरणों में होता है:

1. लेक्सिकल विश्लेषण (स्कैनिंग) के चरण में, कंपाइलर स्रोत कोड को स्कैन करता है और इसे टोकन नामक अलग-अलग घटकों में तोड़ देता है। यह आमतौर पर नियमित अभिव्यक्तियों के माध्यम से प्राप्त किया जाता है।
2. पार्सर संसाधित कोड को एक सिंटैक्स ट्री में संरचना करता है।
3. फिर इस संरचना को अनुवादक द्वारा बाईटेकोड में परिवर्तित किया जाता है। सरलतम मामले में, अनुवाद को अपनी प्रस्तुति के द्वारा टोकन में मैपिंग के रूप में दर्शाया जा सकता है।
4. अंत में, मूल कोड को प्राप्त करने के लिए बायटेकोड दुभाषिया के माध्यम से बायटेकोड जाता है।

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

तेज, सुरुचिपूर्ण, सही

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

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

जित संकलक

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

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

जावास्क्रिप्ट JIT कम्पाइलर

पहला जावास्क्रिप्ट JIT संकलक मोज़िला का TraceMonkey था। यह तथाकथित ट्रेसरूट जेआईटी था, क्योंकि यह सबसे दोहराया छोरों को ट्रैक करता है। इन "हॉट लूप्स" को मशीन कोड में संकलित किया जाता है। अकेले इस अनुकूलन के लिए धन्यवाद, मोज़िला को अपने पिछले इंजन की तुलना में 20% से 40% का प्रदर्शन सुधार मिला।

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

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

इन सभी परिवर्तनों का महत्वाकांक्षी लक्ष्य मूल कोड गति पर जावास्क्रिप्ट कोड को निष्पादित करना है। कुछ साल पहले यह लक्ष्य अविश्वसनीय लग रहा था, लेकिन निष्पादन की गति में अंतर कम हो रहा है।

अब JS संकलन की कुछ निजी विशेषताओं के बारे में।

छिपी हुई कक्षाएं

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

प्रकार का अनुमान

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

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

इनलाइन कैशिंग

आधुनिक जावास्क्रिप्ट कंपाइलरों में यह सबसे आम अनुकूलन है। यह एक नई तकनीक नहीं है (इसे स्मॉलटाक कंपाइलर के लिए 30 साल पहले लागू किया गया था), लेकिन यह बहुत उपयोगी है।

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

इनलाइन विस्तार, या "इनलाइनिंग"

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

चक्रों के परिवर्तन, "वृद्धि"

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

स्थिरांक का दृढ़ संकल्प

लगातार अभिव्यक्तियों की गणना की जाती है, साथ ही अपरिवर्तनीय चर वाले भाव भी।

आम सबटेक्शन्स को हटाना

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

मृत कोड उन्मूलन

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

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

ES.next

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

ब्राउज़रों द्वारा ES.next की सामग्री अभी भी काफी सीमित है, लेकिन आप इसे कम से कम यहां अनुसरण कर सकते हैं , आप Traceur - ES.next जावास्क्रिप्ट संकलक को जावास्क्रिप्ट में लिखे गए का उपयोग करके भी परीक्षण शुरू कर सकते हैं।

WebGL

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

किसी न किसी रूप में WebGL अधिकांश ब्राउज़रों में समर्थित है , मुख्य रूप से Chrome और Firefox में। सफारी और ओपेरा उपयोगकर्ताओं को पहले उपयुक्त विकल्प को सक्षम करना होगा। Microsoft ने हाल ही में IE11 में WebGL के लिए समर्थन की घोषणा की है।

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

संकलन के परिणामस्वरूप जावास्क्रिप्ट

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

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

विचार का एक दिलचस्प प्रदर्शन एम्सस्क्रिप्टेन प्रोजेक्ट था, जो जावास्क्रिप्ट में एलएलवीएम बायटेकोड को संकलित करने की अनुमति देता है। LLVM (लो लेवल वर्चुअल मशीन) एक बहुत ही लोकप्रिय मध्यवर्ती संकलन प्रारूप है, आप लगभग किसी भी भाषा के लिए LLVM कंपाइलर पा सकते हैं। यह दृष्टिकोण हर किसी को उस भाषा में स्रोत कोड लिखने की अनुमति देगा जो उसके लिए सुविधाजनक है। यह परियोजना अभी भी अपने शुरुआती चरण में है, लेकिन टीम पहले ही कई प्रभावशाली डेमो जारी कर चुकी है। उदाहरण के लिए, महाकाव्य डेवलपर्स ने asm.js कोड में संकलित करने के लिए LLVM C कंपाइलर और Emscripten का उपयोग करके जावास्क्रिप्ट और WebGL में अवास्तविक इंजन 3 को पोर्ट किया।

asm.js

उसी दिशा में काम करने वाला प्रोजेक्ट। इसके रचनाकारों ने जावास्क्रिप्ट के रूप में "जावास्क्रिप्ट कोड को मशीन कोड" के रूप में स्वीकार किया। इस प्रकार, सैद्धांतिक रूप से, आप अपने हाथों से asm.js कोड लिख सकते हैं, लेकिन कोई भी नहीं चाहता है। इस सुविधा का अधिकतम लाभ उठाने के लिए, आपको 2 संकलक चाहिए।
Emscripten संकलक asm.js. परिणामी जावास्क्रिप्ट अपठनीय है, लेकिन यह सही और पिछड़ा संगत है। विशाल त्वरण तब आएगा जब ब्राउज़र इंजन asm.js प्रारूप को पहचानेंगे और एक अलग संकलक के माध्यम से इस कोड को पारित करेंगे। इस उद्देश्य के लिए, मोज़िला ओडिनमॉन्की पर काम कर रहा है, जो आयनमेक में निर्मित asm.js कंपाइलर का अनुकूलन करता है। Google ने Chrome में asm.js के लिए समर्थन की भी घोषणा की। प्रारंभिक परीक्षणों ने लगभग 50% संकलित C ++ का प्रदर्शन दिखाया, यह एक अभूतपूर्व उपलब्धि है, जो जावा और C # के साथ गति में तुलनीय है। टीम को भरोसा है कि परिणाम में सुधार होगा।
मोज़िला रिसर्च वास्तव में अब एक लहर के शिखर पर है। Emscripten और asm.js के अलावा, एक LLJS प्रोजेक्ट (जावास्क्रिप्ट के रूप में C) भी है, और इंटेल के साथ समांतर कंप्यूटिंग के लिए River Trail - ECMAScript एक्सटेंशन भी विकसित कर रहा है। इस दिशा में कितना प्रयास किया गया है, और क्या परिणाम पहले ही प्राप्त हो चुके हैं, यह देखते हुए, हम यह मान सकते हैं कि देशी गति से जावास्क्रिप्ट चलाना पहले की तरह अप्राप्य नहीं है।

ORBX.js

ऐसे भी हैं जो पूर्ण वर्चुअलाइजेशन के माध्यम से जावास्क्रिप्ट प्रदर्शन समस्या को हल करने का प्रस्ताव देते हैं। इसके मशीन पर एप्लिकेशन चलाने के बजाय, यह क्लाउड में चलता है। यह, निश्चित रूप से, जेएस संकलन समस्या का समाधान नहीं है, बल्कि उपयोगकर्ताओं के लिए एक वैकल्पिक समाधान है। ORBX.js एक वीडियो कोडेक का कार्यान्वयन है जो विशेष रूप से जावास्क्रिप्ट का उपयोग करके 1080 पिक्सल के संकल्प के साथ वीडियो स्ट्रीमिंग में सक्षम है। मोज़िला और ओटॉय की एक संयुक्त परियोजना।
प्रौद्योगिकी, निश्चित रूप से प्रभावशाली है , लेकिन शायद यह हल करने की तुलना में अधिक समस्याएं पैदा करता है।

आप जावास्क्रिप्ट के भविष्य के संकलन के बारे में क्या सोचते हैं?