Design: वेबसम ब्राउज़र में जावास्क्रिप्ट को बदल सकता है?

मैं सी # से पर्याप्त परिचित नहीं हूं, लेकिन असल में, मुझे लगता है कि वास पूरी तरह से जावास्क्रिप्ट को नहीं ले सकता है।

सबसे पहले, यदि आपने कोशिश की है, तो आप पाएंगे कि जावास्क्रिप्ट से कॉल करते समय कुछ निचले स्तर के संचालन, जैसे "+, -, *, /" और कुछ अन्य गणित से संबंधित संचालन में जावास्क्रिप्ट वासम की तुलना में बहुत तेज है। WebAssembly में और वापस। #1120

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

अंत में, " बाइनरी एएसटी " की मदद से, वर्तमान वेब अनुप्रयोगों के प्रदर्शन को उन अनुप्रयोगों पर बिना किसी संशोधन के एक नए स्तर पर ले जाया जाएगा।

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

@Becavalier हाँ हो सकता है यदि आप जेएस संदर्भ ओवरहेड से एक wasm फ़ंक्शन को कॉल करने का प्रयास कर रहे हैं, लेकिन रनटाइम जावास्क्रिप्ट से तब तक संवाद नहीं करता है जब तक कि इसकी विशेष रूप से आवश्यकता न हो .. जैसे डोम क्वेरी/मैनिपुलेशन, सीएसएस इनलाइन, कैनवास पेंट्स _etc.._ wasm सन्दर्भ के अंदर होने वाले सभी निष्पादन बहुत तेज़ हैं। देरी तब सामने आती है जब JS ब्रिज पेश किया जाता है, जैसे कि #1120 के मामले में आप एक फ़ंक्शन के लिए जावास्क्रिप्ट संदर्भ में प्रदर्शन टाइमस्टैम्प को प्रिंट करने का प्रयास कर रहे हैं जो कि wasm संदर्भ में निष्पादित है जो एक अतिरिक्त देरी है।

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

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

हम शुरू में ऐसी तकनीकों को अपनाते थे जो हमारे JS कोड को VM की तरह V8 और अन्य पर चलाने के लिए अधिक कुशल बनाती थीं, लेकिन अब आप एक असेंबली कोड लिख और संकलित कर सकते हैं जो JS कोड को आगे बढ़ा सकता है।

अब आप टाइपस्क्रिप्ट, कॉफीस्क्रिप्ट इत्यादि जैसे ट्रांसपिलर को बदलने वाले वेब के लिए कंपाइलर्स की अपेक्षा कर सकते हैं।

जावास्क्रिप्ट डेवलपर्स, अपनी उंगलियों को पार रखें । आने वाले वर्षों में कुछ बड़े कदम की उम्मीद कर सकते हैं।

पुनश्च: मुझे जावास्क्रिप्ट और सी-लैंग पसंद है

वेब असेंबली ने ब्राउज़र पर जावास्क्रिप्ट के साथ प्रतिस्पर्धा करने के लिए अन्य भाषाओं के संकलक के लिए द्वार खोल दिया है।

हाँ वास्तव में, यह WebAssembly के उद्देश्यों में से एक है।

यहाँ WebAssembly FAQ का एक उद्धरण है:

जबकि WebAssembly, समय के साथ, कई भाषाओं को वेब पर संकलित करने की अनुमति देगा, जावास्क्रिप्ट में अविश्वसनीय मात्रा में गति है और यह वेब की एकल, विशेषाधिकार प्राप्त (जैसा कि ऊपर वर्णित है) गतिशील भाषा बनी रहेगी। इसके अलावा, यह उम्मीद की जाती है कि JavaScript और WebAssembly का एक साथ कई कॉन्फ़िगरेशन में उपयोग किया जाएगा:

• संपूर्ण, संकलित C++ ऐप्स जो चीजों को एक साथ चिपकाने के लिए JavaScript का लाभ उठाते हैं।

ध्यान रखें कि अन्य भाषाओं ने वर्षों से जावास्क्रिप्ट को संकलित किया है , और वे WebAssembly के साथ या उसके बिना ऐसा करना जारी रखेंगे।

आप पहले से ही C#, F#, C++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl, आदि को JavaScript में संकलित कर सकते हैं।

आप जावास्क्रिप्ट के लिए .NET बाइटकोड संकलित कर सकते हैं, आप ओकैमल बाइटकोड को जावास्क्रिप्ट में संकलित कर सकते हैं, और जीडब्ल्यूटी लगभग 11 वर्षों से है और बड़ी परियोजनाओं में इसका उपयोग किया गया है।

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

जावास्क्रिप्ट पहले से ही अन्य भाषाओं के साथ प्रतिस्पर्धा करता है। WebAssembly अन्य भाषाओं को और अधिक कुशल बनाता है, बस।

हम शुरू में ऐसी तकनीकों को अपनाते थे जो हमारे JS कोड को VM की तरह V8 और अन्य पर चलाने के लिए अधिक कुशल बनाती थीं, लेकिन अब आप एक असेंबली कोड लिख और संकलित कर सकते हैं जो JS कोड को आगे बढ़ा सकता है।

हां, क्योंकि जेआईटी इंजन (और जावास्क्रिप्ट की स्वाभाविक रूप से गतिशील प्रकृति) के ऊपरी हिस्से के कारण जावास्क्रिप्ट वीएम मूल प्रदर्शन प्राप्त नहीं कर सकते हैं, इसलिए यदि आप अधिक प्रदर्शन चाहते हैं तो आपको कोड निष्पादन के कड़े निम्न-स्तरीय नियंत्रण की आवश्यकता है। WebAssembly आपको वह नियंत्रण देता है।

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

नहीं, लोग जावास्क्रिप्ट का उपयोग करना जारी रखेंगे।

डेस्कटॉप पर कई वर्षों से चुनने के लिए कई भाषाएँ हैं: पायथन, पर्ल, रूबी, पीएचपी, हास्केल, जावास्क्रिप्ट (नोड.जेएस), ओकैमल, सी ++, जावा, आदि।

लोग जावास्क्रिप्ट सहित कई भाषाओं का उपयोग करते हैं। जावास्क्रिप्ट कहीं नहीं जा रहा है।

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

अब आप टाइपस्क्रिप्ट, कॉफीस्क्रिप्ट इत्यादि जैसे ट्रांसपिलर को बदलने वाले वेब के लिए कंपाइलर्स की अपेक्षा कर सकते हैं।

इसकी संभावना नहीं है, लोगों के लिए टाइपस्क्रिप्ट और जावास्क्रिप्ट का उपयोग करने के लिए अभी भी अच्छे कारण हैं।

बेशक टाइपस्क्रिप्ट के विकल्प होंगे, और कुछ लोग उन विकल्पों का उपयोग करेंगे, लेकिन टाइपस्क्रिप्ट के जाने की संभावना नहीं है।

मैं ऐसा इसलिए कहता हूं क्योंकि सालों से टाइपस्क्रिप्ट के अच्छे विकल्प मौजूद हैं (जैसे कि Haxe ) लेकिन उन्होंने टाइपस्क्रिप्ट को कभी नहीं बदला।

पर 4 03:42 सितंबर 2017, Pauan [email protected] लिखा है:
>

जावास्क्रिप्ट पहले से ही अन्य भाषाओं के साथ प्रतिस्पर्धा करता है। WebAssembly बस बनाता है
अन्य भाषाएं अधिक कुशल, बस इतना ही।

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

@ रॉसबर्ग-क्रोमियम वास्तव में आप सही हैं, मैं उस विवरण को भूल गया था। स्पष्टीकरण देने के लिए धन्यवाद।

@Pauan विवरण के लिए धन्यवाद। हालाँकि आपकी कुछ बातें मान्य हैं और समझ में आती हैं, मैं सभी से सहमत नहीं हूँ।

क्लाइंट साइड पर सी # पूरी तरह से विकास के स्तर पर जावास्क्रिप्ट से बचने के लिए आशाजनक और एक हत्यारा उदाहरण दिखता है। यानी .. मैं किसी भी जावास्क्रिप्ट कोड को लिखे बिना पूरी तरह कार्यात्मक वेबपैप लिखने के लिए सी # का उपयोग कर सकता हूं। इस तरह के दृष्टिकोण आधारित ढांचे में कम से कम एक हद तक जावास्क्रिप्ट विरासत को म्यूट करने का एक संभावित मौका है।

आप पहले से ही C#, F#, C++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl, आदि को JavaScript में संकलित कर सकते हैं।

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

ध्यान रखें कि अन्य भाषाएँ वर्षों से जावास्क्रिप्ट में संकलित हैं, और वे WebAssembly के साथ या उसके बिना ऐसा करना जारी रखेंगी।

आप पहले से ही C#, F#, C++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl, आदि को JavaScript में संकलित कर सकते हैं।

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

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

क्या ये समस्याएं हल हो सकती हैं? उदाहरण के लिए एक नई रूबी -> वेबसम कंपाइलर के साथ, और वर्तमान ब्राउज़र जावास्क्रिप्ट के तुलनीय प्रदर्शन प्राप्त करें?

एक उदाहरण के रूप में जावास्क्रिप्ट और रूबी (ओपल के साथ) का उपयोग करने के लिए (जैसा कि मैंने कोशिश की और मूल रूप से पहले छोड़ दिया):

जावास्क्रिप्ट में + ऑपरेटर के साथ, यह संख्याओं को एक स्ट्रिंग में परिवर्तित करने की अनुमति देता है, उदाहरण के लिए

5 + " example" === "5 example"

रूबी के पास अधिक मजबूत टाइपिंग है, और इसकी अनुमति नहीं है:

5 + " example"
#TypeError: String can't be coerced into Integer

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

function $rb_plus(lhs, rhs) {
  return (typeof(lhs) === 'number' && typeof(rhs) === 'number') ? lhs + rhs : lhs['$+'](rhs);
}
String.prototype['$+'] = function (r){var t=this,n=arguments.length;return 1!==n&&e.ac(n,1,this,"+"),r=ke.get("Opal").$coerce_to(r,ke.get("String"),"to_str"),t+r.$to_s()}

इसी तरह कई बुनियादी कार्यों के लिए।

# Ruby: if a || b
if ((($a = ((($b = a) !== false && $b !== nil && $b != null) ? $b : b)) !== nil && $a != null && (!$a.$$is_boolean || $a == true))) {

हो सकता है कि सिद्धांत रूप में एक जेआईटी पूरी तरह से अनुकूलित कर सके, लेकिन ऐसा नहीं लगता कि वे करीब हैं (माइक्रो बेंचमार्क नहीं था, लेकिन पूरे प्रोटोटाइप ऐप/पेज के लिए मैंने रूबी संस्करण काफी धीमा था) और इस तरह के रूपांतरण सिर्फ बना रहे हैं आशावादी जीवन कठिन?

और फिर भी, कुछ चीजें गलत हैं या समर्थित नहीं हैं (हालांकि वेबसम में मूल पूर्णांक हैं, इसलिए जेएस के बजाय वेबसम को संकलित करने की उम्मीद है):

1 / 2 == 0.5 # Should be 0, Ruby has integer division

str = "Hello"
str << " World" # Opal: String#<< not supported. Mutable String methods are not supported in Opal.
puts str # "Hello World"

@निरस

मैं किसी भी जावास्क्रिप्ट कोड को लिखे बिना पूरी तरह कार्यात्मक वेबपैप लिखने के लिए सी # का उपयोग कर सकता हूं।

हां, और मैं मानता हूं कि यह बहुत अच्छा है (मैं एक ऐसी भाषा पर काम कर रहा हूं जिसे मैं WebAssembly में संकलित करने की योजना बना रहा हूं), लेकिन मेरा कहना है कि आप पहले से ही WebAssembly के बिना भी ऐसा कर सकते हैं।

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

वास्तव में, और यह पहले से ही कई वर्षों से संभव है। आपको WebAssembly के लिए प्रतीक्षा करने की आवश्यकता नहीं है, आप अभी शुरू कर सकते asm.js कई वर्षों से अस्तित्व में है।

@wnewbery

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

यह पार्स समय में मदद कर सकता है, लेकिन रनटाइम प्रदर्शन में मदद करने की संभावना नहीं है।

मुझे कुछ स्पष्ट करने दो: asm.js कई वर्षों से अस्तित्व में है। यह आपको एक प्रोग्राम को जावास्क्रिप्ट में संकलित करने की अनुमति देता है, और वह प्रोग्राम लगभग मूल गति से चलेगा। दूसरे शब्दों में, आप किसी प्रोग्राम को उसी गति से चला सकते हैं जिस गति से वह डेस्कटॉप पर चलता है।

इसलिए किसी भाषा को लेना, उसके VM, रनटाइम और कचरा संग्रहकर्ता को asm.js में संकलित करना पहले से ही संभव हो गया है, और फिर आप ब्राउज़र में जो भी भाषा चाहते हैं, उसे डेस्कटॉप पर लगभग उसी गति से चला सकते हैं। यह काफी समय से पहले ही संभव हो चुका है।

हालाँकि, VM, रनटाइम और कचरा संग्रहकर्ता को संकलित करने का अर्थ है कि फ़ाइल का आकार काफी बड़ा होगा (कई मेगाबाइट)।

और जेएस एपीआई (डीओएम की तरह) के साथ संवाद करना मुश्किल है।

लेकिन कुछ लोगों ने इसे वैसे भी किया है, और PyPy.js जैसी चीजें बनाई हैं जो PyPy दुभाषिया को asm.js में संकलित करती हैं।

यह CPython की तुलना में तेज़ चलता है (हाँ, वास्तव में! PyPy दुभाषिया जो जावास्क्रिप्ट में और एक ब्राउज़र में चल रहा है , डेस्कटॉप पर देशी CPython की तुलना में तेज़ी से चलता है!)

लेकिन फ़ाइल का आकार काफी खराब है (5 मेगाबाइट gzipped, 15 मेगाबाइट कच्चा)।

तो आप रूबी के वीएम + कचरा कलेक्टर + रनटाइम को asm.js पर संकलित कर सकते हैं , और यह बहुत तेज़ होगा, लेकिन इसमें वे समस्याएं होंगी। इसलिए इसके बजाय लोग ओपल जैसी चीजें बनाते हैं।

WebAssembly asm.js का अगला विकास है। फिलहाल, आप WebAssembly के साथ जो कुछ भी कर सकते हैं, आप asm.js के साथ भी कर सकते हैं।

तो हाँ आपकी भाषा + VM + रनटाइम + कचरा संग्रहकर्ता को WebAssembly में संकलित करना संभव है, और यह लगभग मूल गति से चलेगा।

लेकिन निश्चित रूप से इसमें asm.js के समान ही डाउनसाइड्स हैं: बहुत बड़ा फ़ाइल आकार, और JS API के साथ संवाद करना कठिन है।

WebAssembly और asm.js के बीच सात अंतर हैं:

1. WebAssembly सामान्य रूप से asm.js की तुलना में एक छोटा सा (5%) तेज़ है।

2. यदि आप 64-बिट पूर्णांकों का उपयोग कर रहे हैं, तो WebAssembly asm.js की तुलना में महत्वपूर्ण रूप से (~ 400%) तेज़ है।

3. WebAssembly को बहुत तेजी से पार्स किया जा सकता है। यह आपके प्रोग्राम की रनटाइम गति में सुधार नहीं करता है, लेकिन इसका मतलब यह है कि प्रारंभिक लोड समय WebAssembly के साथ तेज है।

4. WebAssembly फ़ाइल का आकार asm.js फ़ाइल आकार (लगभग 10-20% छोटा) से छोटा है।

5. WebAssembly भविष्य में बहुत बढ़िया सुविधाएँ प्राप्त कर सकता है जो asm.js के पास नहीं है (थ्रेड्स, समवर्ती, शून्य-लागत अपवाद, आदि)।

6. WebAssembly भविष्य में जावास्क्रिप्ट के कचरा संग्रहकर्ता तक पहुँच प्राप्त कर सकता है (जिसका अर्थ है कि अब आपको अपनी भाषा के कचरा संग्रहकर्ता को WebAssembly में संकलित करने की आवश्यकता नहीं होगी, जिसका अर्थ है छोटे फ़ाइल आकार)।

7. WebAssembly भविष्य में JS API (जैसे DOM) का आसानी से उपयोग करने की क्षमता हासिल कर लेगा।

लेकिन भविष्य में भी आपकी भाषा के VM + रनटाइम को WebAssembly में संकलित करना आवश्यक होगा, इसलिए फ़ाइल का आकार अभी भी एक मुद्दा होगा।

यदि आपकी भाषा के VM + रनटाइम + कचरा संग्रहकर्ता को asm.js में संकलित करना आपको स्वीकार्य नहीं है, तो शायद यह अभी भी WebAssembly के साथ भी स्वीकार्य नहीं होगा।

और अगर आपकी भाषा के VM + रनटाइम + कचरा संग्रहकर्ता को संकलित करना आपको स्वीकार्य है, तो आप पहले से ही asm.js के साथ ऐसा कर सकते हैं (और फिर बाद में आसानी से WebAssembly में संक्रमण कर सकते हैं)।

क्या ये समस्याएं हल हो सकती हैं? उदाहरण के लिए एक नई रूबी -> वेबसम कंपाइलर के साथ, और वर्तमान ब्राउज़र जावास्क्रिप्ट के तुलनीय प्रदर्शन प्राप्त करें?

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

इसलिए यदि आप रूबी को WebAssembly में संकलित करते हैं, तो यह उसी गति से चलेगा जिस गति से रूबी डेस्कटॉप पर चलती है।

रूबी काफी धीमी भाषा है। WebAssembly के साथ संकलित होने पर भी धीमी भाषाएँ और धीमे प्रोग्राम अभी भी धीमे होंगे।

1 / 2 == 0.5 # Should be 0, Ruby has integer division

यह ओपल में एक बग है जिसे केवल $rb_divide फ़ंक्शन की परिभाषा को बदलकर ठीक किया जा सकता है।

str << " World" # Opal: String#<< not supported. Mutable String methods are not supported in Opal.

इसे जावास्क्रिप्ट सरणियों (जो कि परिवर्तनशील हैं) में ओपल संकलन तार होने से तय किया जा सकता है।

@पौआन

WebAssembly भविष्य में बहुत बढ़िया सुविधाएँ प्राप्त कर सकता है जो asm.js के पास नहीं है (थ्रेड्स, समवर्ती, शून्य-लागत अपवाद, आदि)।

थ्रेड कई भाषाओं, पुस्तकालयों, ढांचे के लिए एक बहुत ही महत्वपूर्ण विशेषता है। थ्रेड के बिना, सी ++, सी #, जावा द्वारा बनाए गए कई ऐप्स जो मल्टीथ्रेड पर भरोसा करते हैं, वे वेबएप में परिवर्तित नहीं हो सकते हैं क्योंकि इससे अजीब व्यवहार हो सकता है (सिमड जैसी एक और अच्छी चीज का उल्लेख नहीं करना समर्थन _भविष्य में (?)_)। संक्षेप में, मुझे लगता है कि asm.js पर्याप्त अच्छा नहीं है, या तो प्रदर्शन और न ही पोर्ट क्षमता, यदि यह अच्छा है, तो बहुत समय पहले asm.js पर अधिक पुस्तकालय "पोर्टेड" होने चाहिए।

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

@unmello , उस मिथक को फिर से

हाँ क्षमा करें मैं भूल गया था मेरा मतलब था कि यह तेजी से पार्स करेगा
संपादित करें: कुछ ऐसा हो सकता है जो ब्राउज़र समर्थन के लिए अपने जावास्क्रिप्ट इंजन को अपडेट नहीं कर रहा है
जावास्क्रिप्ट अर्थ के नए संस्करण लोग प्रदर्शन में बिना किसी नुकसान के wasm को संकलित कर सकते हैं

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

मैं देख सकता हूं कि बहुत से लोग जावास्क्रिप्ट को WASM से बदलने के विचार से संशय में हैं, लेकिन एक बात यह है कि WASM वास्तव में केवल प्रदर्शन के बारे में नहीं है। लोग ज्यादातर इस बारे में भूल जाते हैं कि जावास्क्रिप्ट वह भाषा नहीं है जो वे चाहते हैं (या चाहते थे)। मेरा मतलब है, कम से कम, बेयरबोन जावास्क्रिप्ट वह नहीं है जो लोग चाहते हैं। अधिक से अधिक लोग ट्रांसपिलर के साथ जा रहे हैं, जो मूल रूप से तृतीय पक्ष भाषाओं के लिए कंपाइलर हैं। यह सिर्फ इतना है कि लोगों ने मानकों पर भरोसा करना

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

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

ऐसा नहीं है कि WASM एक दिन में सब कुछ बदल देगा। जावास्क्रिप्ट में अभी एक अच्छी तरह से निर्मित पारिस्थितिकी तंत्र है, जबकि अन्य भाषाओं में नहीं है। जावास्क्रिप्ट वास्तव में कहीं जाने से पहले मैं समय लूंगा, लेकिन यह स्पष्ट रूप से लंबे समय में होगा।

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

@spencerudnick ने कभी भी प्रदर्शन लाभ के लिए असेंबली नहीं लिखी जो आपको सी से नहीं मिल सकती है?