Design: Webasm يمكن أن يحل محل جافا سكريبت في المتصفح؟

لست على دراية كافية بـ c # ، لكن في الواقع ، أعتقد أن wasm لا يمكنه تولي جافا سكريبت تمامًا.

أولاً ، إذا جربت ، فستجد أن جافا سكريبت أسرع بكثير من تلك الموجودة في بعض العمليات ذات المستوى الأدنى ، مثل "+ ، - ، * ، /" وبعض العمليات الأخرى المتعلقة بالرياضيات بسبب الحمل الطفيف عند الاتصال من JavaScript في WebAssembly والعودة. # 1120

ثانيًا ، بالنسبة لمطوري الويب ، فقد كان لديهم بالفعل دراية بجافا سكريبت وقواعدها ، ومن غير الضروري ومن الصعب عليهم إنشاء تطبيقات ويب بلغة أخرى غير متعلقة بتطوير الويب.

أخيرًا ، بمساعدة " Binary AST " ، سيتم رفع أداء تطبيقات الويب الحالية إلى مستوى جديد دون أي مراجعات على تلك التطبيقات.

ملاحظة:
بغض النظر عن C # أو Java ، إذا كنت ترغب في جعل لغة البرمجة هذه أكثر ملاءمة للمطورين ، فستكون كفاءة هذه اللغة محدودة بسبب بعض الميزات "سهلة الاستخدام" مثل "الكتابة الضعيفة" وأي ميزات أخرى ، بالعكس.

Becavalier قد يكون نعم إذا كنت تحاول استدعاء دالة wasm من سياق JS ، لكن وقت التشغيل لا يتصل بجافا سكريبت حتى وما لم يكن مطلوبًا حصريًا .. مثل استعلام DOM / معالجة ، CSS مضمّن ، لوحات قماشية _etc .._ كل عمليات الإعدام التي تحدث داخل سياق الوسم أسرع بكثير. يظهر التأخير في الصورة عند تقديم جسر JS ، كما في حالة # 1120 ، تحاول طباعة الطابع الزمني للأداء في سياق Javascript لوظيفة يتم تنفيذها في سياق wasm وهو تأخير إضافي.

أطر العمل الشائعة مثل Angular2 / 4 وهي عبارة عن تجديد كامل يعتمد على Typescript ، أو Android في Kotlin أو iOS في Swift ، عندما يكون هناك اسم كبير وراء بعض الأطر أو اللغة يحاول العالم بأسره تبني التغيير.

لذا فإن النقطة هي ، هناك احتمال أن يتم تهميش JS أو حتى إزالتها من الصورة عن طريق تلخيص جسور API ونقل أوقات التشغيل على المتصفح. لقد فتح Webassembly الباب لمترجمي اللغات الأخرى للتنافس مع Javascript على المتصفح.

لقد اعتدنا في البداية على تبني التقنيات التي جعلت كود JS الخاص بنا أكثر كفاءة للتشغيل على أجهزة VM مثل V8 وغيرها ، ولكن الآن يمكنك الكتابة والترجمة إلى كود تجميع يمكنه تخطي كود JS.

الآن يمكنك توقع استبدال المترجمات للويب مثل TypeScript و CoffeeScript وما إلى ذلك.

مطورو جافا سكريبت ، ابقوا أصابعكم متقاطعة . يمكن أن نتوقع بعض التحرك الكبير في السنوات القادمة المقبلة.

ملاحظة: أحب جافا سكريبت وسي-لانج

لقد فتح Webassembly الباب لمترجمي اللغات الأخرى للتنافس مع Javascript على المتصفح.

نعم بالفعل ، هذا هو أحد أغراض WebAssembly.

فيما يلي اقتباس من الأسئلة الشائعة حول WebAssembly :

بينما سيسمح WebAssembly ، بمرور الوقت ، بترجمة العديد من اللغات إلى الويب ، فإن JavaScript لديها قدر لا يُصدق من الزخم وستظل اللغة الديناميكية الوحيدة (كما هو موضح أعلاه) للويب. علاوة على ذلك ، من المتوقع أن يتم استخدام JavaScript و WebAssembly معًا في عدد من التكوينات:

• تطبيقات C ++ المجمعة بالكامل والتي تستفيد من JavaScript لربط الأشياء معًا.

ضع في اعتبارك أن اللغات الأخرى قد تم تجميعها في JavaScript لسنوات ، وستستمر في القيام بذلك مع WebAssembly أو بدونه.

يمكنك بالفعل ترجمة C # و F # و C ++ و OCaml و Elm و PureScript و Haskell و Java و Python و Ruby و Perl وما إلى ذلك إلى JavaScript.

يمكنك ترجمة .NET bytecode إلى JavaScript ، ويمكنك ترجمة OCaml bytecode إلى JavaScript ، وكان GWT موجودًا منذ 11 عامًا وقد تم استخدامه في المشاريع الكبيرة.

هذه المشاريع كانت موجودة منذ سنوات عديدة. إنه ليس شيئًا جديدًا حقًا.

جافا سكريبت تتنافس بالفعل مع لغات أخرى. WebAssembly يجعل اللغات الأخرى أكثر فاعلية ، هذا كل ما في الأمر.

لقد اعتدنا في البداية على تبني التقنيات التي جعلت كود JS الخاص بنا أكثر كفاءة للتشغيل على أجهزة VM مثل V8 وغيرها ، ولكن الآن يمكنك الكتابة والترجمة إلى كود تجميع يمكنه تخطي كود JS.

نعم ، لأن JavaScript VMs لا يمكنها

لذا فإن النقطة هي ، هناك احتمال أن يتم تهميش JS أو حتى إزالتها من الصورة عن طريق تلخيص جسور API ونقل أوقات التشغيل على المتصفح.

لا ، سيستمر الأشخاص في استخدام JavaScript.

لسنوات عديدة على سطح المكتب ، كانت هناك العديد من اللغات للاختيار من بينها: Python و Perl و Ruby و PHP و Haskell و JavaScript (Node.js) و OCaml و C ++ و Java وما إلى ذلك.

يستخدم الناس العديد من اللغات ، بما في ذلك JavaScript. جافا سكريبت لا تذهب إلى أي مكان.

حتى في عالم افتراضي (بعيد الاحتمال جدًا ) حيث JavaScript ليست لغة من الدرجة الأولى ، لا يزال بإمكان الأشخاص ترجمة JavaScript إلى WebAssembly.

الآن يمكنك توقع استبدال المترجمات للويب مثل TypeScript و CoffeeScript وما إلى ذلك.

هذا غير مرجح ، فلا تزال هناك أسباب وجيهة للأشخاص لاستخدام TypeScript و JavaScript.

بالطبع ستكون هناك بدائل لـ TypeScript ، وسيستخدم بعض الأشخاص هذه البدائل ، لكن من غير المحتمل أن تختفي TypeScript.

أقول ذلك نظرًا لوجود بدائل جيدة بالفعل لـ TypeScript لسنوات (مثل Haxe ) لكنها لم تحل محل TypeScript أبدًا.

في 4 سبتمبر 2017 الساعة 03:42 ، كتب Pauan [email protected] :
>

جافا سكريبت تتنافس بالفعل مع لغات أخرى. WebAssembly فقط يجعل
لغات أخرى أكثر كفاءة ، هذا كل شيء.

هذا الأخير ليس صحيحًا تمامًا. الهدف الآخر من Wasm هو تمكين الميزات
التي لا تدعمها JavaScript ، ومن المحتمل ألا تكون كذلك. ل
على سبيل المثال ، التزامن أو مكالمات الذيل أو الاستثناءات القابلة للاستئناف كلها في
خريطة الطريق.

@ rossberg-chromium في الواقع أنت محق ، لقد نسيت تلك التفاصيل. شكرا للتوضيح.

@ باوان شكرا على التفاصيل. على الرغم من أن بعض وجهة نظرك صحيحة ومنطقية ، إلا أنني لا أتفق مع الجميع.

يبدو C # من جانب العميل واعدًا ومثالًا قاتلًا لتجنب جافا سكريبت تمامًا في مرحلة التطوير. على سبيل المثال .. يمكنني استخدام C # لكتابة تطبيق ويب كامل الوظائف دون أن أكتب أي كود جافا سكريبت. تتمتع هذه الأطر القائمة على المواقف بفرصة محتملة لكتم تراث جافا سكريبت على الأقل إلى حد ما.

يمكنك بالفعل ترجمة C # و F # و C ++ و OCaml و Elm و PureScript و Haskell و Java و Python و Ruby و Perl وما إلى ذلك إلى JavaScript.

نعم ، كان جافا سكريبت في الصورة. ولكن الآن مع WASM / Webasm تغير دافعي للتجميع إلى Javascript. يمكن للمرء أن يترجم مباشرة إلى wasm ويكتب طبقة أو جسور قناع API في Javascript كلما لزم الأمر ، لذلك لا تحتاج قاعدة المطورين إلى معرفة Javascript لتطوير تطبيق ويب باستخدام Webapp ، أعني أن Webapp خالص وليس ASP.net وأطر JSP kinda.

ضع في اعتبارك أن اللغات الأخرى قد تم تجميعها في JavaScript لسنوات ، وستستمر في القيام بذلك مع WebAssembly أو بدونه.

يمكنك بالفعل ترجمة C # و F # و C ++ و OCaml و Elm و PureScript و Haskell و Java و Python و Ruby و Perl وما إلى ذلك إلى JavaScript.

بينما يمكن ترجمة العديد من اللغات إلى JavaScript بالفعل ، فهل يؤدي التحويل البرمجي إلى Webasm إلى تجنب التحميل الكبير وعقوبات أداء وقت التشغيل للقيام بذلك؟ ومشكلات الأداء إذا قمت بتجميع لغات كاملة C VM إلى Webasm للقيام بذلك بهذه الطريقة؟

إذا كان استخدام لغات أخرى يؤدي إلى مشاكل أداء حتمية ، أو الكثير من الأماكن التي تنتهك مواصفات اللغات هذه (لأسباب تتعلق بالأداء) ، فهذا بديل جزئي لجافا سكريبت في أحسن الأحوال ، وعمومًا رأيت أنها تستخدم أكثر في نقل الشفرة القديمة أكثر من التعليمات البرمجية الجديدة لاستبدالها JavaScript "(باستثناء CoffeeScript و TypeScript وما إلى ذلك المصممة للترجمة إلى JS بشكل جيد).

هل هذه المشاكل يمكن حلها؟ على سبيل المثال مع برنامج Ruby الجديد -> Webasm compiler ، واحصل على أداء مشابه لمتصفح JavaScript الحالي؟

لاستخدام JavaScript و Ruby (مع Opal) كمثال (كشيء جربته وتركته سابقًا):

في 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))) {

ربما من الناحية النظرية ، يمكن لـ JIT تحسين ذلك تمامًا ، لكن لا تعتقد أنه قريب (لم يكن مقياسًا دقيقًا ، ولكن بالنسبة لتطبيق / صفحة نموذج أولي كامل ، كان إصدار Ruby أبطأ بشكل ملحوظ) ويبدو أن التحويلات من هذا القبيل تؤدي فقط إلى تحسين الحياة أصعب؟

وحتى مع ذلك ، فإن بعض الأشياء خاطئة أو غير مدعومة (على الرغم من أن Webasm يحتوي على أعداد صحيحة أصلية ، لذلك نأمل أن تكون هذه بداية إذا تم التحويل إلى Webasm بدلاً من JS):

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"

nirus

يمكنني استخدام C # لكتابة تطبيق ويب كامل الوظائف دون أن أكتب أي كود جافا سكريبت.

نعم ، وأنا أوافق على أن هذا رائع جدًا (أنا أعمل على لغة أخطط لترجمتها إلى WebAssembly) ، لكن وجهة نظري هي أنه يمكنك فعل ذلك بالفعل ، حتى بدون WebAssembly.

يمكن للمرء أن يترجم مباشرة إلى wasm ويكتب طبقة أو جسور قناع API في Javascript كلما لزم الأمر ، لذلك لا تحتاج قاعدة المطورين إلى معرفة Javascript لتطوير تطبيق ويب باستخدام Webapp ، أعني أن Webapp خالص وليس ASP.net وأطر JSP kinda.

في الواقع ، كان هذا ممكنًا بالفعل منذ سنوات عديدة. لا تحتاج إلى انتظار WebAssembly ، يمكنك البدء الآن : asm.js موجود منذ عدة سنوات.

تضمين التغريدة

بينما يمكن ترجمة العديد من اللغات إلى JavaScript بالفعل ، فهل يؤدي التحويل البرمجي إلى Webasm إلى تجنب التحميل الكبير وعقوبات أداء وقت التشغيل للقيام بذلك؟ ومشكلات الأداء إذا قمت بتجميع لغات كاملة C VM إلى Webasm للقيام بذلك بهذه الطريقة؟

قد يساعد ذلك في أوقات التحليل ، ولكن من غير المحتمل أن يساعد في أداء وقت التشغيل.

اسمحوا لي أن أوضح شيئًا: asm.js موجود منذ عدة سنوات. يسمح لك بترجمة برنامج إلى JavaScript ، وسيعمل هذا البرنامج بسرعات تكاد تكون أصلية. بمعنى آخر ، يمكنك تشغيل برنامج بنفس السرعة التي يعمل بها على سطح المكتب.

لذلك كان من الممكن بالفعل أخذ لغة ، وتجميع VM ، ووقت التشغيل ، ومجمع البيانات المهملة إلى asm.js ، ويمكنك بعد ذلك تشغيل أي لغة تريدها في المتصفح ، بنفس السرعة تقريبًا على سطح المكتب. لقد كان هذا ممكناً منذ فترة طويلة الآن.

ومع ذلك ، فإن تجميع VM ووقت التشغيل ومجمع البيانات المهملة يعني أن حجم الملف سيكون كبيرًا جدًا (العديد من الميجابايت).

ومن الصعب التواصل مع JS APIs (مثل DOM).

لكن بعض الأشخاص فعلوا ذلك على أي حال ، وأنشأوا أشياء مثل PyPy.js التي تجمع مترجم PyPy إلى asm.js.

يعمل بشكل أسرع من CPython (نعم ، حقًا! مترجم PyPy الذي تم تجميعه إلى JavaScript ويعمل في متصفح يعمل بشكل أسرع من CPython الأصلي على سطح المكتب!)

لكن حجم الملف سيء للغاية (5 ميغا بايت مضغوطة و 15 ميغا خام).

لذلك يمكن أن تجمع VM + جمع القمامة + وقت التشغيل روبي لasm.js، وسيكون سريع جدا، ولكن سيكون لديك تلك المشاكل. لذا بدلاً من ذلك ، يصنع الناس أشياء مثل أوبال.

WebAssembly هو التطور التالي لـ asm.js. في الوقت الحالي ، أي شيء يمكنك القيام به باستخدام WebAssembly ، يمكنك القيام به باستخدام asm.js أيضًا.

لذا ، نعم ، من الممكن ترجمة لغتك + VM + وقت التشغيل + جامع البيانات المهملة إلى WebAssembly ، وسيتم تشغيله بسرعة أصلية تقريبًا.

لكن بالطبع له نفس الجوانب السلبية مثل asm.js: حجم ملف كبير جدًا ، ومن الصعب التواصل مع واجهات برمجة تطبيقات JS.

هناك سبعة اختلافات بين WebAssembly و asm.js:

1. يعد WebAssembly أسرع قليلاً (5٪) من asm.js بشكل عام.

2. يعد WebAssembly أسرع بشكل ملحوظ (400٪ تقريبًا) من asm.js إذا كنت تستخدم أعدادًا صحيحة 64 بت.

3. WebAssembly يمكن تحليل أسرع بكثير. لا يؤدي ذلك إلى تحسين سرعة وقت تشغيل البرنامج ، ولكنه يعني أن وقت التحميل الأولي يكون أسرع مع WebAssembly.

4. حجم ملف WebAssembly أصغر من حجم ملف asm.js (حوالي 10-20٪ أصغر).

5. قد يكتسب WebAssembly في المستقبل ميزات رائعة لا يمتلكها asm.js (الخيوط ، والتزامن ، واستثناءات التكلفة الصفرية ، وما إلى ذلك).

6. قد يتمكن WebAssembly في المستقبل من الوصول إلى أداة تجميع البيانات المهملة في JavaScript (مما يعني أنك لن تحتاج إلى تجميع أداة تجميع البيانات المهملة للغة الخاصة بك إلى WebAssembly بعد الآن ، مما يعني أحجام ملفات أصغر).

7. سيكتسب WebAssembly في المستقبل القدرة على استخدام واجهات برمجة تطبيقات JS بسهولة (مثل DOM).

ولكن حتى في المستقبل ، سيظل من الضروري تجميع وقت تشغيل VM + الخاص بلغتك في WebAssembly ، لذا سيظل حجم الملف يمثل مشكلة.

إذا كان تجميع VM + runtime + مجمّع البيانات المهملة الخاص بلغتك في asm.js أمرًا غير مقبول بالنسبة لك ، فربما لا يزال غير مقبول حتى مع WebAssembly.

وإذا جمع VM + وقت + جامع القمامة لغتك غير مقبول لديك، يمكنك القيام بالفعل الآن مع asm.js (وبعد ذلك بسهولة الانتقال إلى WebAssembly في وقت لاحق).

هل هذه المشاكل يمكن حلها؟ على سبيل المثال مع برنامج Ruby الجديد -> Webasm compiler ، واحصل على أداء مشابه لمتصفح JavaScript الحالي؟

الغرض من WebAssembly هو تشغيل البرامج بسرعات أصلية. بمعنى آخر ، تشغيلها بنفس السرعة التي تعمل بها على سطح المكتب.

لذلك إذا جمعت Ruby إلى WebAssembly ، فسيتم تشغيله بنفس السرعة التي يعمل بها Ruby على سطح المكتب.

روبي لغة بطيئة جدًا. ستظل اللغات البطيئة والبرامج البطيئة بطيئة ، حتى عند تجميعها باستخدام 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.

يمكن إصلاح ذلك من خلال وجود سلاسل ترجمة Opal في مصفوفات JavaScript (والتي يمكن تغييرها).

تضمين التغريدة

قد تحصل WebAssembly في المستقبل على ميزات رائعة لا يمتلكها asm.js (الخيوط ، والتزامن ، واستثناءات التكلفة الصفرية ، وما إلى ذلك).

يعد Thread ميزة مهمة للغاية للعديد من اللغات والمكتبات والأطر ، فبدون الخيط ، لا يمكن للعديد من التطبيقات التي تم إنشاؤها بواسطة c ++ و c # و java والتي تعتمد على multithread أن تتحول إلى webapp لأنها قد تسبب سلوكًا غريبًا (ناهيك عن شيء جيد آخر مثل SIMD دعم _ في المستقبل (؟) _). باختصار ، أعتقد أن asm.js ليس جيدًا بما فيه الكفاية ، سواء الأداء أو قدرة المنفذ ، إذا كان هذا جيدًا ، فيجب أن يكون هناك المزيد من المكتبات "المنقولة" إلى asm.js منذ وقت طويل.

كما قال الجميع إن جافا سكريبت لن تختفي لأنها شائعة جدًا وللدعم القديم ، فإن معظم المستعرضات ستظل تدعم تشغيل جافا سكريبت أصليًا ، لكنني أعتقد في المستقبل أن أي شخص يقوم بإنشاء مواقع ويب جديدة باستخدام جافا سكريبت سوف يقوم بتجميعها وفقًا لجميع مكاسب الأداء هذه

unmellow ، لفضح هذه الأسطورة مرة أخرى: لن يكون هناك مكاسب سحرية في الأداء من تجميع JS إلى Wasm ، بل على العكس تمامًا. إذا كنت تريد أداءً أفضل مما تستطيع محركات JS تقديمه ، فعليك اختيار لغة أفضل.

نعم آسف لقد نسيت أنني قصدت أنها ستحلل بشكل أسرع
تحرير: شيء قد يحدث على الرغم من أن المتصفح لا يقوم بتحديث محركات جافا سكريبت لدعمه
إصدارات أحدث من حاسة جافا سكريبت يمكن للناس تجميعها دون أي خسائر في الأداء

لست مرتاحًا حقًا في الحصول على تذكرة عمرها عام ، ولكن من أجل المناقشة والقليل من الصراخ.

أستطيع أن أرى الكثير من الناس متشككين في فكرة استبدال Javascript بـ WASM ، ولكن هناك شيء واحد هو أن WASM لا يتعلق بالأداء فقط. ما ينسى الناس غالبًا هو أن جافا سكريبت ليست اللغة التي يريدونها (أو يريدونها). أعني ، على الأقل ، أن جافا سكريبت المجردة ليست ما يريده الناس. يتزايد عدد الأشخاص الذين يستخدمون أجهزة التحويل ، والتي تعد في الأساس مجمعين للغات الطرف الثالث. هذا مجرد أن الناس تخلوا عن الاعتماد على المعايير وتحولوا إلى حلول userland (؟).

لكن الترشيح ، بطبيعته ، أصعب بكثير من التجميع. لا تقتصر المشكلة الرياضية المتمثلة في تعيين لغة إلى أخرى دائمًا على النطاق المحلي. يجب نقل بعض المعلومات السياقية إلى الجانب الآخر ، والقيام بذلك بشكل صحيح يمثل مشكلة صعبة. هذا هو السبب في عدم اعتماد محولات الصوت التي لا تشبه جافا سكريبت على نطاق واسع (أو لماذا لا ينبغي الاعتماد عليها).

أيضًا ، هناك مشكلة في تكرار الجهود. Transpilers عبارة عن مجمّعين ، والمجمّعات عبارة عن روابط. لدينا جميعًا هذه الأدوات على مر العصور. الوحدات النمطية ، اهتزاز الشجرة ، تقسيم الكود ، التحميل الديناميكي / البطيء ، إدارة الأصول ، إلخ. ليس هناك ما هو جديد حقًا ، ولكن يحتاج الأشخاص إلى أدوات جديدة للحصول على هذه الميزات للويب فقط ، وهي ليست صديقة للحلول بخلاف الويب.

ليس الأمر كما لو أن WASM سيغير كل شيء في يوم واحد. جافا سكريبت لديها نظام بيئي جيد البناء في الوقت الحالي ، بينما اللغات الأخرى لا تفعل ذلك. سآخذ بعض الوقت قبل أن تذهب Javascript حقًا إلى مكان ما ، ولكن من الواضح أنها ستحدث على المدى الطويل.

جافا سكريبت تتجه ، ما أعتبره ، اتجاه فظيع لذلك أرحب باستبدال WASM. أعتقد أنه بينما كانت هناك تحسينات كبيرة ، كان الكثير من المجتمع والتوجيه مضللًا على مدار السنوات العديدة الماضية. سأرحب أكثر من أي لغة مناسبة .. ليس بالضرورة أن تحل محلها ، ولكن لأكون منافسًا مباشرًا لذلك لم يكن علي أن أكتب هذه النكهة البغيضة الجديدة لـ JS و "أطرها" التي ظهرت.

spencerudnick لم يكتب أبدًا التجميع لتحقيق مكاسب في الأداء لا يمكنك الحصول عليها من C؟