Design: هل سيكون هناك مترجم JS -> WASM؟

ستظل المتصفحات تحتوي على JavaScript VM أصلي جنبًا إلى جنب. لا يوجد سبب لتجميع JS إلى wasm لأنه سيتعين عليك أيضًا تضمين javascript vm. سيكون الرمز الناتج ضخمًا وأبطأ من JS VM المقدم أصلاً.

هناك وظيفة MVP لمهمة ما لإضافة أشياء مثل إضافة الوصول إلى GC من كود wasm بحيث يمكن تنفيذ لغات البرمجة النصية لـ wasm.

JS → wasm سيكون له معنى فقط بمجرد أن يدعم wasm GC ، وعلى الأرجح تجميع JIT أيضًا ، والذي لا يزال بعيدًا جدًا. هذا من شأنه أن يعادل في الأساس تنفيذ محرك JS في wasm! لقد ذكرت هذا مؤخرًا واتهمتنيBrendanEich بأن

لكي نكون واضحين ، هدف wasm ليس _ استبدال_ JavaScript ، بل تكميله. لذلك ليس هدفًا في الوقت الحالي هو دعم JS → wasm ، لكن الميزات التي نريد تنفيذها ستجعل ذلك ممكنًا. لست متأكدًا من أنه سيكون مفيدًا من منظور المطور. قد تحصل على بعض تصغير الحجم ، ولكن هذا كل شيء. من منظور المتصفح ، قد يكون من المثير للاهتمام أن يتم تنفيذ محرك JS في wasm من منظور أمني خالص.

jfbastien لقد

لكن إجابتك أفضل. أنا متحمس لـ GC و JIT في wasm. أحب إنشاء اللغات الخاصة بي وتشغيلها على الويب.

وماذا عن دعم المتغيرات مثل asm.js أو TypeScript / ES7؟ هؤلاء
نكهات جافا سكريبت تعد بمستوى معين من الضمانات النوعية.

أتخيل أن الحاجة إلى JIT ستكون أقل من ذلك ، لكن GC لا يزال كثيرًا
اللازمة لهذه اللغات. هل سيكون لديك {typedواد JS} -> WASM
هذا أكثر جدوى؟

W: http://bguiz.com

في 24 يونيو 2015 الساعة 09:44 ، كتب Tim Caswell [email protected] :

jfbastien https://github.com/jfbastien لقد هزمتني بفارق ثانيتين: P

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/WebAssembly/design/issues/219#issuecomment -114675456.

نعم ، المترجم asm.js -> هو أولوية عالية ، وقد فعل ذلك لوقا بالفعل
العمل على ضاغط قد يكون بمثابة نقطة انطلاق جيدة.

يوم الأربعاء ، 24 حزيران (يونيو) 2015 ، الساعة 1:59 صباحًا ، Brendan Graetz [email protected]
كتب:

وماذا عن دعم المتغيرات مثل asm.js أو TypeScript / ES7؟ هؤلاء
نكهات جافا سكريبت تعد بمستوى معين من الضمانات النوعية.

أتخيل أن الحاجة إلى JIT ستكون أقل من ذلك ، لكن GC لا يزال كثيرًا
اللازمة لهذه اللغات. هل سيكون لديك {typedواد JS} -> WASM
هذا أكثر جدوى؟

W: http://bguiz.com

في 24 يونيو 2015 الساعة 09:44 ، كتب Tim Caswell [email protected] :

jfbastien https://github.com/jfbastien لقد هزمتني بفارق ثانيتين: P

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
< https://github.com/WebAssembly/design/issues/219#issuecomment -114675456
.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/WebAssembly/design/issues/219#issuecomment -114677789.

لقد تحدثنا مع فريق TypeScript حول هذا الاحتمال وقد أظهروا اهتمامًا ، ولكن يبدو أن هناك تقدمًا حاليًا في إضافة كائنات مكتوبة إلى JS.

bguiz : محرك JS هو محرك wasm ، وسيستمر في دعم لغة JS القياسية المتطورة. لا تقلق هناك (لم أكن متأكدًا مما إذا كنت تعتقد أن هذا قد يختفي. ليس في أي مستقبل يمكنني توقعه). OTOH كما يلاحظ الآخرون ، يحتاج wasm إلى وقت لتطوير GC ودعم JIT وميزات اللغة الديناميكية الأخرى ، ليكون هدفًا من الدرجة الأولى لـ JS. حتى عندما تتطور هذه الأشياء ، لدي شك في أن محركات JS / wasm ستتخلى عن بناء جملة JS والمكونات المدمجة لصالح JS-in-wasm VMs التي تم تنزيلها. سوف نرى!

/يكون

سيكون مترجم asm.js-to-WebAssembly أيضًا شيئًا نخطط لإضافته إلى Emscripten .

بالنسبة إلى JS العادية ، أعتقد أن الآخرين قد أجابوا على السؤال أعلاه.

إن الهدف الكامل من JS سهل البرمجة ويمكنه القيام بأشياء مذهلة: dhteumeuleu أو codepen.io/ge1doot ، ولكن يمكنك رؤية المصدر ومن السهل اختراقه.

"wasm" هو مجرد وسيلة لبيع المزيد من الألعاب وتطبيقات أخرى لجوجل ، أبل وشركاه. "التطور" الوحيد هو أنه سيكون هناك إمكانية للتحكم بك بشكل أفضل من خلال "عدم التثبيت" ، مباشرة من خادم الأخ الأكبر ... أنا فقط مندهش من أنهم لا يخشون أكل بعضهم البعض بعد ...

من الممكن باستخدام تحليل الكود أو التعليقات التوضيحية للتعليمات البرمجية لتجميع ECMAScript إلى WebAssembly. لا يبدو هذا كأولوية لفريق WebAssembly ولكنه يبدو فكرة رائعة لجهد مستقل.

لقد بدأت للتو في تجربة لغة برمجة ألعاب قد تكون ذات صلة: https://github.com/evanw/thinscript. يستخدم بناء جملة بنمط TypeScript ويقوم بالتجميع إلى WebAssembly. اعتقدت أنني يجب أن أذكرها لأنها قد تكون دراسة حالة مثيرة للاهتمام. كما أنني فوجئت بسرور بمدى سهولة إنشاء WebAssembly. عمل جيد للجميع!

أود أن أحذر الناس من استخدام أغلفة رفيعة جدًا فوق الوبر ، بشكل عام. على سبيل المثال ، بالاطلاع على كود thinscript ، أرى أن هناك عبارة while تم تخفيضها إلى loop { if (!condition) break; } ، والتي ستكون أقل كفاءة من if (condition) loop { ...; br_if condition } في العديد من محركات wasm.

بالنسبة لي ، الشيء الذي يجعل wasm أكثر من مجرد JS مُعاد تسخينه هو إمكانية وجود فلسفة مختلفة: نظرًا لأن wasm هو هدف مترجم ، يمكن للمترجمين إجراء تحسينات قبل شحن الكود إلى العملاء ، لذلك يمكننا الحفاظ على الأجهزة الافتراضية من جانب العميل أبسط و أسرع. ومع ذلك ، إذا أصبحت الأغلفة الرقيقة حول wasm شائعة ، فهناك خطر يتمثل في أن عمليات التنفيذ من جانب العميل ستضطر في النهاية إلى زيادة حجمها وتعقيدها من أجل القيام بالتحسينات التي لم يتم إجراؤها.

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

يبدو رائعًا جدًا! سأكون مهتمًا بمعرفة إلى أين يقودنا ذلك.

أتخيل أن JS-> WASM أكثر جاذبية للخوادم من العملاء. كنظرة عامة عالية المستوى عن الهندسة المعمارية التي أفكر فيها ...

JavaScript -> WebAssembly -> Tracing Interpreter -> LLVM IR -> Machine Code

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

فقط بعض الأفكار ، لا تتردد في حذفها إذا كانت زائفة!

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

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

إذا كان الجميع ينقلون كودهم إلى ES5 ، فما فائدة الحصول على دعم ES 2016 في بيئة في المقام الأول؟

يحاول مشروع جديد يسمى "babel-preset-env" محاربة هذه المشكلة من خلال استهداف البيئات بإصداراتها. الفكرة من وراء ذلك هي أنك (1) تطلب منه استهداف إصدارات معينة أو "أحدث إصدارات X" من المتصفحات ، (2) يحدد القاسم المشترك الأدنى للميزات و (3) يتيح عمليات النقل الضرورية فقط. هذا يساعد ، ولكن للأسف لا يمكن حل المشكلة.

ما زلنا نواجه خطر عدم تصرف بائع رئيسي والتسبب في نفس المشكلات التي كانت Microsoft تتسبب فيها مع Internet Explorer لسنوات. النظام البيئي بأكمله في أيدي عدد قليل من البائعين ، الذين يقررون ما يجب تنفيذه ومتى يتم تنفيذه. هذا ليس مجانيًا ولا مفتوحًا.

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

JS -> سيكون WASM أمرًا مثيرًا للاهتمام لحماية الملكية الفكرية عن طريق تشويش الشفرة عندما يتعلق الأمر بالتثبيتات المحلية لتطبيقات Electron على خوادم العملاء. من الصعب تصديق ذلك ، لكن هناك العديد من المؤسسات الصغيرة في ألمانيا ذات اتصال ضئيل جدًا أو معدوم بالإنترنت ، الأمر الذي يتطلب تثبيتات داخل الشركة ، ولكن إعطاء التعليمات البرمجية بالكامل في نص عادي قد يكون أمرًا مخيفًا لشركات البرمجيات.

@ Simran-B Wasm لديه مبدأ تصميم لدعم تنسيق نص مألوف. ومن الجدير بالذكر أنه يحتوي على تصميم منظم للتحكم في التدفق من أجل التحليل السريع ، وهو مُحسَّن لتعريفات الاستخدام الفردي المستخدمة في ترتيب المكدس بحيث تكون مُحسَّنة للتعبيرات القابلة للقراءة. وبالتالي ، فهو ليس هدفًا لـ "تشويش الكود" ، ولكن يمكن للمطورين إصدار "تشويش الكود" الخاص بهم فوق هذا ، لكن يجب أن يفهموا أنه من المتوقع أن يكون لذلك تكلفة من حيث انخفاض كفاءة التشفير وانخفاض الأداء.

مرحبًا بالجميع ، لقد اكتشفت مؤخرًا WebAssembly ، لكن بالتفكير في مترجم JS -> wasm ، تخيلت شيئًا مثل تجميع Angular2's Ahead-of-Time ، طريقة jsut أكثر تحسينًا (أفكر في الكود الآلي بدلاً من جافا سكريبت) ... هل هذا ممكن ابدا؟ هل تستحق ذلك؟

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

ريتشارد

@ Richard87 يمكنك التفكير في webassembly باعتباره مجموعة تعليمات مستقلة للنظام الأساسي مع اصطلاحات تشفير واستدعاء متخصصة خاصة به. لا يوجد ما يقول أنه لا يمكنك وصف مجموعة فرعية من جافا سكريبت سيكون من السهل جدًا تحويلها للعمل في عالم webassembly لهذه الأشياء ، ولكن فرض ذلك ربما يكون صعبًا. تنمو مجموعة الميزات ومنطقة سطح التنفيذ إلى الأبد في جافا سكريبت ، ومن المحتمل أن يكون تكييف المكتبات وأطر العمل الحالية للعمل في هذه المجموعة الفرعية أمرًا صعبًا ، لا سيما بالنظر إلى النقص الحالي في تجميع البيانات المهملة في Webassembly ، وستفقد بشكل أساسي فوائد جافا سكريبت الحالية الشفرة.

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

أعتقد أنه من المهم للغاية بالنسبة لبعضنا ممن ينظرون إلى Browser و Webgl أن يكونا أسرع في ممارسة الألعاب. أعتزم إحضار لعبة ذات جودة تجارية في webgl لكن التكنولوجيا الحالية تنتج الكثير من القمامة التي تتخطى الإطارات.
فشلت ألعاب المتصفح التي تستخدم محركات ألعاب JS تقريبًا وانطلقت Unity. أعتقد أن C ++ => Wasm هي ميزة غير مستحقة لهؤلاء الصانعين مثل صانعي الإطار الذين يمكنهم تجميع الكود الخاص بهم إلى WASM.
ولكن ماذا عن الأشخاص الذين يكتبون JS يدويًا باستخدام Three JS أو Babylon .. عدم وجود JS / Asm.js => Wasm toolchain سيعني أن التطبيق الكبير في Js سيكون ميتًا وسيستخدم الأشخاص C ++ وخلفيات إنشاء الشفرات لإنتاج Wasm. بشكل أكثر تحديدًا في الألعاب وما شابه.
عدم وجود JS => Wasm backend بشكل غير عادل لمطوري JS. كما تخصص EMCC كومة كبيرة عند تشغيلها وتكون السرعات واضحة بسبب ذلك ، لكن Js Developers الذين يكتبون كود js جيد لا يزالون غير قادرين على تحقيق الكثير من الأداء بسبب تعقيد كتابة مثل هذا الكود. يجب أن تكون هناك آلية ما لإعادة استخدام معظم الأشياء والقدرة على الاتصال بـ gc في وقت مبكر أو حسب الرغبة. يعد تخطي الإطار عند تشغيل GC يتسبب في تخطي Webgl للإطارات مشكلة كبيرة ويجب حلها. يجب أن تكون هناك آلية لضبط كود JS بشكل أفضل من مولدات الكود. مثل التجميع المكتوب بخط اليد ، لا يزال ينتج رمزًا أصغر بكثير ومتوافقًا للغاية. يجب أن يكون ذلك ممكنًا في تجميع الويب.

يمكن ترجمة metacritical C ++ إلى WASM لأن العديد من الأشخاص يبذلون الكثير من العمل في هذه العملية. يمكن أن يحدث نفس الشيء مع JavaScript ، ولكن على حد علمي ، لا أحد يحاول ذلك حاليًا. ليس هناك سبب وجيه للقيام بذلك: لن يتغير الأداء.

مشكلة محركك هي جمع القمامة. لا تختفي هذه المشكلة إذا قمت بإنشاء خوارزمية لجمع البيانات المهملة تستخدم الذاكرة الخطية ورمز WASM ... في النهاية عليك إيقاف البرنامج لمعرفة الكائنات التي لا تزال على قيد الحياة وحذف الكائنات غير الموجودة. الحل هو عدم إنشاء كائنات غير نظيفة ، مما يمنع الحاجة إلى تشغيل GC. لا تحتاج إلى WASM لتحقيق ذلك ، فأنت بحاجة إلى إعادة صياغة محركك.

يصعب للغاية كتابة جافا سكريبت فائقة النقاء التي تعيد استخدام المصفوفات وتنتج مخلفات منخفضة. أعتقد أيضًا أنه لا يمكن تجميع Plain Js إلى WASM. سيكون Asm.js أو Typescript أسهل في التحويل البرمجي إلى WASM نظرًا لتوفر التعليقات التوضيحية أو الأنواع الموجودة فيها على التوالي.

metacritical صعب ، لكن ليس مستحيلًا. حتى في محركات C ++ ، يدور الكثير من التعليمات البرمجية حول إدارة عمر الكائن. على الرغم من أنه غير تقليدي ، فلا يوجد سبب يمنعك من فعل الشيء نفسه في JavaScript.

يمكن تجميع لغة JS العادية إلى WASM ولكن يجب على المترجم إضافة الكثير من التعليمات البرمجية المساعدة لتمكين ميزات المستوى الأعلى لجافا سكريبت مثل جمع البيانات المهملة والانعكاس والخصائص وما إلى ذلك. بشكل أساسي ، كل الأشياء التي تحصل عليها مجانًا باستخدام محرك JS المدمج في المتصفح. لا يساعد TypeScript كثيرًا.

بالمقارنة ، سيكون من السهل تحويل ASM.JS إلى WASM. المجموعة الفرعية الصارمة من ميزات JS التي يسمح بها ASM.JS مغطاة أيضًا بنسبة 100٪ بواسطة WASM. إذا كان هناك عدد كبير من التعليمات البرمجية المكتوبة بلغة ASM.JS ، فسيكون هذا جهدًا يستحق العناء ، ولكن بقدر ما أعرف ، يتم إنتاج جميع ملفات ASM.JS الرئيسية من شفرة مصدر C ++ ، والتي يمكنها بالفعل استهداف WASM مباشرةً.

بالمقارنة ، سيكون من السهل تحويل ASM.JS إلى WASM.

صحيح ، والطريقة الرئيسية في الواقع التي نجمع بها C ++ إلى wasm اليوم هي تجميعها إلى asm.js أولاً ، ثم تجميع ذلك asm.js إلى wasm باستخدام asm2wasm في Binaryen .

kripken بالنظر إلى مواصفات asm.js ، يبدو من السهل كتابة asm.js بخط اليد ، مما يعني عدم فقد كل شيء لمبرمجي js ، فلا يزال بإمكاننا الحصول على ثنائيات WASM باستخدام ما سبق.

ألن يؤدي تطور JS ، أي لغة مطبوعة بدقة ، إلى جعلها مرشحًا جيدًا لـ JS -> WASM؟
أعتقد أن TC39 لديه اقتراح لكائن مكتوب. قد يكون المزيد من الميزات الأخرى تجعل ذلك ممكنًا.

@ aruns07 كلما قل عدد ميزات JavaScript التي تسمح للأشخاص باستخدامها ، كان من الأسهل تجميعها إلى WASM ، وزادت احتمالية عدم رغبة الأشخاص في التعايش مع قيودك بسبب عدم التوافق مع مكتباتهم المفضلة.

Kardax @ aruns07 يحب الناس راحة اللغة الديناميكية. نحن بحاجة إلى أنواع قوية في بعض الأحيان وليس طوال الوقت.

jfbastien علق في 24 يونيو 2015
JS → wasm سيكون له معنى فقط بمجرد أن يدعم wasm GC ، وعلى الأرجح تجميع JIT أيضًا ، والذي لا يزال بعيدًا جدًا. هذا من شأنه أن يعادل في الأساس تنفيذ محرك JS في wasm!

حسب الرابط التالي:
https://lists.w3.org/Archives/Public/public-webassembly/2017Feb/0002.html
إجماع WebAssembly ونهاية معاينة المستعرض

الآن ، بعد عامين من ردك الأول ، أصبح WebAssembly الآن مدعومًا من قبل متصفحات الويب الرئيسية.
لذلك لا يكافئ تنفيذ محرك JS في wasm.
مزايا js -> wasm ليست فقط دعم GC ، ولكن أيضًا حجم رمز أصغر ، وتنفيذ أسرع ، خاصة في مجال تطوير التطبيقات الهجينة مثل Ionic2 الذي ينتج عادةً ملف JS حوالي 10 ميجابايت مما يتسبب في تجاوز وقت تحميل التطبيق 5 ثواني (كل 2 ميجابايت من تحليل JS = ثانية واحدة)

jfbastien لذا يرجى نشر إجابتك المحدثة حول JS -> wasm transpiler؟

كجزء من رسالتي الرئيسية ، أحاول كتابة Transpiler من مجموعة فرعية من JavaScript إلى WebAssembly. في البداية ، سيقتصر على TypeScript ، ولكن قد يتم دعم المتغيرات المكتوبة الأخرى مثل Flow في المستقبل.

ومع ذلك ، فإن الهدف ليس تنفيذ لغة JavaScript كاملة ، حيث في هذه الحالة ، سأواجه نفس المشكلات التي تواجهها تطبيقات JIT اليوم ، وبالتالي ، لا يمكن توقع تسريع (بالتأكيد ، سيكون تطبيقي أبطأ 100 مرة! ). ستكون مجموعة فرعية كما هو محدد بواسطة SoundScript

هدفي هو السماح بترجمة أجزاء معينة من التطبيق إلى WebAssembly دون الحاجة إلى أن يترك المطور بيئة التطوير المألوفة لديه أو يستخدم لغة برمجة أخرى. لذلك ، سيكون الغرض منه هو تسريع أداء الأجزاء المهمة من التطبيق وليس كمحول للأغراض العامة يقبل أي تطبيق JavaScript موجود.

أشعر بالفضول الشديد لمعرفة النتائج التي توصلت إليها لأنني أرى إيجابيات وسلبيات مثل هذا النهج. اسمحوا لي أن أعرف إذا كان لديك أي مدخلات.

@ Mohsen7s تظل إجابتي دقيقة: إصدار MVP من WebAssembly لا يدعم إمكانات GC و JIT التي تجعل من الممكن تنفيذ آلة افتراضية JavaScript سريعة. المترجم ممكن تمامًا ، باستخدام الحيل الذكية يمكن أن يكون جيدًا جدًا ، ولكن ليس بقدر ما تفعله التطبيقات المحلية.

هذا متأصل في نهجنا "الحد الأدنى من المنتج القابل للتطبيق": قم بشحن شيء يصلح لبعض حالات الاستخدام أولاً ، ثم أضف ميزة لتلبية حالات الاستخدام الأخرى. يرجى الاطلاع على الموضوع التالي لمناقشة مماثلة حول MVP و "الميزات المستقبلية" المفقودة: https://github.com/WebAssembly/design/issues/992#issuecomment -281735235

إذا تركنا جانباً المناقشات التقنية حول ما يمكن وما لا يمكن تنفيذه حاليًا ، فأنا مندهش من أن JS -> WASM ليس الهدف رقم 1 من الناحية الفلسفية ومن منظور التسويق - أخفق في معرفة كيف ستحصل على موافقة المطور حتى هذا هو الحال. إذا أراد جميع مطوري البرامج الأمامية / الخلفية / الكاملة المكدسة الذين يتمتعون بمهارات JS القادرة على العمل في أي قطاع سوقي أن يقضوا وقتهم في تعلم C ++ الذي يتم استخدامه في مجموعة فرعية أصغر بكثير من الصناعات ، فعندئذٍ كانوا قد فعلوا ذلك بالفعل لذلك - أعلم ، أنا أتحدث كواحد. لا يسعني إلا أن أشعر أن هذه المناقشة بأكملها عبارة عن غرفة صدى إلى حد ما وأن أولئك الذين يدافعون عن عدم وجود مترجم سيجدون أنه من الأفضل قضاء وقتهم في التحدث إلى الأشخاص الموجودين على الفحم يسألونهم عما يريدون حقًا.

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

إذا تركنا جانباً المناقشات التقنية حول ما يمكن وما لا يمكن تنفيذه حاليًا ، فأنا مندهش من أن JS -> WASM ليس الهدف رقم 1 من الناحية الفلسفية ومن منظور التسويق - أخفق في معرفة كيف ستحصل على موافقة المطور حتى هذا هو الحال. إذا أراد جميع مطوري البرامج الأمامية / الخلفية / الكاملة المكدسة الذين يتمتعون بمهارات JS القادرة على العمل في أي قطاع سوقي أن يقضوا وقتهم في تعلم C ++ الذي يتم استخدامه في مجموعة فرعية أصغر بكثير من الصناعات ، فعندئذٍ كانوا قد فعلوا ذلك بالفعل لذلك - أعلم ، أنا أتحدث كواحد.

يمكن للمتصفحات بالفعل تشغيل JavaScript بكفاءة. لا تستطيع المستعرضات تشغيل حالات الاستخدام المقصودة بكفاءة. وفوق ذلك ، يحتوي WebAssembly على تطلعات غير متعلقة بالويب.

توضح هذه المناقشة ، وكذلك https://github.com/WebAssembly/design/issues/992#issuecomment -281735235 ، مجموعة متنوعة من الأهداف التي يمتلكها مختلف الأشخاص. لا يوجد خطأ! يحتاج MVP ببساطة إلى تحديد أولويات من يحصل على الخدمة أولاً.

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

كان هذا هو الهدف الأساسي من تكوين مجموعة مجتمع W3C. نعتقد أنه نجح ، كما سمعنا من العديد من المطورين المهتمين. البعض ليس مهتمًا بـ MVP ، لكنهم مهتمون بالميزات المستقبلية .

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

يمكن للمتصفحات بالفعل تشغيل JavaScript بكفاءة.

ها ، لقد كنت أحاول كتابة لعبة HTML5 متعددة اللاعبين على نطاق واسع قادرة على العمل بسرعة FPS مناسبة على هاتف محمول متوسط ​​منذ عام 2008 وما زلت غير موجود! وبالنظر إلى أنه عندما أذهب للتعاقد لدفع الفواتير ، فإنني أكافأ جيدًا ، وأنا متأكد تمامًا من أن عدم تقدمي لا يرجع إلى جودة الكود الخاص بي.

كان هذا هو الهدف الأساسي من تكوين مجموعة مجتمع W3C

ها مرة أخرى - كم عدد مطوري العالم الحقيقي الذين تعرفهم والذين ينضمون إلى مجموعة المجتمع؟ المطورين الذين يقومون بذلك هم عادةً مبشرون وما إلى ذلك يتمتعون بالمعرفة نعم ، لكنهم لم يشعروا بألم مطور الحياة الواقعية.

وأنا آسف ، لا أريد حقًا التقليل من شأن أي شخص في هذه الصفحة / مشارك / في W3C. كما قلت ، هذا نقاش ، وهذه وجهة نظري من الخطوط الأمامية.

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

من أجل الارتقاء بالأداء المستند إلى المتصفح إلى المستوى التالي ، ستحتاج إلى تعلم لغة أخرى ؛ هل هذا يكون مقبولا؟

لأن هذا هو السؤال الذي تمت الإجابة عليه بالفعل (في رأيي ، بشكل ضار) من قبل البعض في هذه الصفحة.

وأخيرًا (أعدك ؛-)) jfbastien ، إذا:

وفوق ذلك ، يحتوي WebAssembly على تطلعات غير متعلقة بالويب.

لماذا تسمى "WebAssembly"؟

BossLevel أعتقد أنني أرى من أين أتيت. لا يمكنني التحدث عن الأشخاص الذين يقومون بالتبشير ، لكن ما أفهمه هو أن المبشرين المختلفين كانوا على اتصال بالمطورين "المحليين" التقليديين المهتمين بـ WebAssembly. من وجهة نظرك ، قد لا يكون ذلك واضحًا ، ولكن على الأقل يمكنني أن أشير إلى اهتمام Unity كدليل على وجود مطورين "جادين". ينشر هؤلاء الأشخاص أيضًا في github ، بأسمائهم الخاصة ، لكن الانتماءات ليست ظاهرة دائمًا. ليس مكاني للتحدث نيابة عنهم.

ها ، لقد كنت أحاول كتابة لعبة HTML5 متعددة اللاعبين على نطاق واسع قادرة على العمل بسرعة FPS مناسبة على هاتف محمول متوسط ​​منذ عام 2008 وما زلت غير موجود! وبالنظر إلى أنه عندما أذهب للتعاقد لدفع الفواتير ، فإنني أكافأ جيدًا ، وأنا متأكد تمامًا من أن عدم تقدمي لا يرجع إلى جودة الكود الخاص بي.

لم أقصد الإيحاء بأن كتابة JavaScript بسرعة أمر سهل. ما أردت قوله هو: WebAssembly لا يجعل تحسين JavaScript أسهل. بدلاً من ذلك ، فهو يسمح للمتصفحات باستهلاك تنسيق أكثر ملاءمة لتوليد أداء موثوق. كما أنه يسمح لـ TC39 بالتركيز على تحسين JavaScript نفسه ، وليس فقط JavaScript كهدف تجميع.

ها مرة أخرى - كم عدد مطوري العالم الحقيقي الذين تعرفهم والذين ينضمون إلى مجموعة المجتمع؟ المطورين الذين يقومون بذلك هم عادةً مبشرون وما إلى ذلك يتمتعون بالمعرفة نعم ، لكنهم لم يشعروا بألم مطور الحياة الواقعية.

وأنا آسف ، لا أريد حقًا التقليل من شأن أي شخص في هذه الصفحة / مشارك / في W3C. كما قلت ، هذا نقاش ، وهذه وجهة نظري من الخطوط الأمامية.

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

من أجل الارتقاء بالأداء المستند إلى المتصفح إلى المستوى التالي ، ستحتاج إلى تعلم لغة أخرى ؛ هل هذا يكون مقبولا؟

لأن هذا هو السؤال الذي تمت الإجابة عليه بالفعل (في رأيي ، بشكل ضار) من قبل البعض في هذه الصفحة.

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

أنا واثق إلى حد ما من أن هذا سيظهر بسبب التعليقات التي رأيناها على Twitter و Hacker News و Reddit والمؤتمرات المختلفة. مرة أخرى ، ربما أكون مخطئًا وأنا أستمع إلى غرف الصدى. على الأقل ، لقد أجريت مناقشات واعدة جدًا في المؤتمرات مع أشخاص لديهم خلفيات C ++ بالإضافة إلى خلفيات JavaScript.

في الوقت نفسه ، يحاول TC39 حقًا تحسين JavaScript. أعتقد أنه حدث في السنوات الأخيرة ، خاصة مع ES6.

لكن تظل وجهة نظرك: ربما يرغب المطورون في أن يكونوا على دراية جيدة بجافا سكريبت بالإضافة إلى المزيد من لغات "WebAssembly" الملائمة مثل C ++ أو Rust. لا أعرف إلى أي طريق ستسير الأمور.

لماذا تسمى "WebAssembly"؟

ها! هذا سؤال رائع. لدي حديث بعنوان "WebAssembly: لا ويب ولا تجميع". سأضطر إلى إعطائها علنًا حتى أتمكن من التعبير عن شعوري تجاه الاسم: ابتسامة:

لذلك سأبقيك معلقة على ذلك.

أنا أقرأ رغبتين هنا:

1. تمثيل ثنائي لجافا سكريبت القياسي لأوقات تحميل سريعة.
2. شيء ما لسد فجوة الأداء بين C ++ المترجمة محليًا وجافا سكريبت القياسي.

البند 2 هو موضوع البحث المستمر والاستثمارات الضخمة من قبل العديد من الشركات. إذا نظرت إلى قياسات أداء محركات JavaScript على مدار الخمسة عشر عامًا الماضية ، فستجد أنها تعمل أيضًا ... الفجوة تتضاءل.

لا يتم العمل على العنصر 1 من قبل أي شخص ، على حد علمي. إنه أمر معقد للغاية ، ويزداد صعوبة مع استمرار تطور JavaScript بوتيرة سريعة. يعتبر WebAssembly صارمًا للغاية وغير معقد نسبيًا ، ولا يزال تطويره يستغرق سنوات.

jfbastien - شكرًا جزيلاً على

إذن ، هناك بضع نقاط توضيحية ، بدون ترتيب معين:

1) مثال جيد أراه لهذه المناقشة بأكملها ووجهة نظري حول الاتجاه الذي يجب أن تتجه إليه ، يكمن في NodeJS - واجهة برمجة تطبيقات JS / واجهة أمامية إلى نهاية خلفية C ++ - تحصل على سهولة الاستخدام / الإلمام وما إلى ذلك. من ناحية والسرعة من ناحية أخرى.
2) التمسك بـ Node ، مرة أخرى في عام 2008 عندما شرعت في ملحمتي الشخصية ؛-) في الأصل نظرت إلى كل من PHP و Java للحصول على النهاية الخلفية (كنت أعود إلى التطوير بعد عقد من الجانب المظلم من إدارة تكنولوجيا المعلومات والمبيعات ؛-)!) ولكن سرعان ما قاموا بتخفيضها لسبب بسيط هو أنني أردت فقط أن أتعلم لغة واحدة ، وأن أتعلم تلك اللغة جيدًا! قصة شخصية أعرفها ، لكنني أشك في أنني المطور الوحيد الذي يشعر بهذه الطريقة ، لا سيما أولئك الذين يعملون من أجل أنفسهم ، وليس على عشرة سنتات للشركة بينما يتعلمون اللغة.
3) لم أقم بالبحث عن الأرقام في Google عن عمد قبل توضيح نقطتي التالية (في الواقع أنا لست متأكدًا مما إذا كان بإمكاني حتى ذلك) ولكنني سأكون على استعداد للمراهنة على أن معدل الاستحواذ على ASM كان منخفضًا. أعلم أنني شعرت بالحماس الشديد عندما رأيت العرض الأولي ولكن عندما علمت أنه لا يوجد مترجم ، رفضته على الفور. أن أسأل مطور ويب هو جزء من أكبر مجتمع مطور على هذا الكوكب (JS) مع مجموعة واسعة من واجهات برمجة التطبيقات والمكتبات والموارد والبرامج التعليمية وأطر العمل المتاحة عبر الإنترنت للابتعاد عن ذلك ، في رأيي يطلب الكثير ، و من خلال عدم تزويدهم بوسيلة للقيام بالخطوة الأولى (أي مترجم) يفتقد إلى خدعة واضحة من جانبك. حتى أنني سأذهب إلى حد الرهان على أن التطوير في Shading langage (GLSL) قد شهد نموًا أكبر من ASM الآن حيث يمكنك أ) كتابته مباشرةً في أطر عمل ممتازة مثل Pixi.js و Three.js و b) اللعب بها مباشرة على مواقع مثل ShaderToy .
4) صناعة الألعاب / الألعاب بشكل عام. يمكنني التحدث من خلال التجربة هنا على النحو التالي: أ) كنت أكتب (لم يتم إصدارها بعد!) ألعاب على مدار السنوات التسع الماضية و ب) عملت في مجلس إدارة TIGA (الاتحاد التجاري لمطوري الألعاب في المملكة المتحدة) لمدة عامين. صدقني ، أعتقد أنه من المحتمل أن يتم احتساب عدد مطوري الألعاب الذين يرغبون في الانتقال إلى الويب من جهة - مطورو الألعاب موجودون بالفعل في الصناعة التي يحبونها وحتى أنهم يأخذون رواتبهم / يعملون لساعات طويلة على الرغم من ذلك ، لذلك هؤلاء لا ينبغي أن يكون الجمهور المستهدف في WA. نعم ، يبحث أصحاب العمل دائمًا عن وسائط جديدة لنقل ألعابهم إليها ، ولكن دعونا لا نخدع أنفسنا ، باستثناء الهاتف المحمول (حيث يفوز الكود الأصلي للأسف وهو ما أريد إصلاحه من قبل WASM) ، لا يزال الويب يمثل علاقة ضعيفة بجهاز الكمبيوتر / وحدة التحكم من حيث الأداء وتحقيق الدخل.
5) على العكس من ذلك ، في حين أن مشهد المبرمج / المستقل في غرفة النوم ليس في ذروته منذ بضع سنوات ، هناك عدد كبير من مطوري الويب الذين يتوهمون صنع لعبة على الويب في أوقات فراغهم. وبينما لا أريد الانجراف علانية إلى السياسة وأنا لا أطرق بأي حال من الأحوال رجال الوحدة (لقد تعاملت مع عدد منهم وهو منتج رائع) ، فأنا شخصياً أعتقد أنه يجب عليك الاهتمام بالاهتمامات من الرجال الصغار المتعددين ، وليس الرجل الكبير (هذا له معنى فلسفي وتجاري).

سوف أتطلع بشدة لرؤية حديثكjfbastien :)

RyanLamansky - أعتقد أنك تقوم بتمييز معقول. بالنسبة إلى:

لا يتم العمل على العنصر 1 من قبل أي شخص ، على حد علمي. إنه أمر معقد للغاية ، ويزداد صعوبة مع استمرار تطور JavaScript بوتيرة سريعة.

على المستوى الشخصي تمامًا ، باعتباري شخصًا يكتب JS 8 ساعات يوميًا منذ عام 2008 ، أود بشدة أن أرى تطور JS يتوقف لفترة من الوقت ويسمح للجميع باللحاق بالركب! لقد عملت دائمًا على مبدأ التطوير لأدنى قاسم مشترك ، أي إذا لم يكن لديه دعم بنسبة 100٪ فلن يحدث (IE6 / 7/8/9 جانبًا ؛-)). وهكذا نجد أنفسنا في موقف مثير للسخرية يتمثل في التركيز على أنماط ES6 العصرية وحالات الاستخدام المفترضة عندما لا نحصل حتى على دعم المتصفح بنسبة 100٪ لـ ES5 عبر سطح المكتب والجوال. من الواضح أن اللغة تعمل كما هي (على الرغم من نقاط الضعف المعترف بها) كما يتضح من حصتها في السوق ، فكيف نقضي ، كمجتمع من المطورين ، السنوات القليلة المقبلة في تعلم كتابة كود فعال ومثالي بما لدينا بدلاً من بعد إعادة اختراع العجلة مرة أخرى برمز محب جديد (آسف لأنني دخلت منطقة صاخبة ؛-))؟

أعتقد أن الوقت قد حان لأحصل على معطفي ؛-)

RyanLamansky لقد

ولكن كما لاحظت ، هناك بعض الثغرات في دورة حياة التطوير المستندة إلى JS لتطبيقات الويب الموجهة نحو الأعمال الأكثر نموذجية:
1) تحتوي حزم JS الكبيرة على تحليل علوي كبير وتوفر عادةً تشويشًا غير كافٍ.
2) يفتقر رمز JS القياسي إلى التعليقات التوضيحية للنوع (وربما تلميحات أخرى) المطلوبة لإجراء تحسينات JIT / التعليمات البرمجية الأصلية.

يشير هذا إلى أن الحل المحتمل هو إصدار مكتوب بشكل صحيح ومشروح من JS يمنح المطور مسارات تحسين أكثر حتمية وشفافية ، وإصدارًا ثنائيًا تم تحليله مسبقًا من هذا الإصدار من اللغة.

تشير التعليقات والمستندات إلى أن WASM يعمل إلى جانب JS ويستخدم نفس محرك JS للمتصفحات (المحسن). https://developer.mozilla.org/en-US/docs/WebAssembly

أنا لا أفهم هذا السؤال حقا.

آسف لطرح سؤال غبي وإبداء تعليق غبي: هل السؤال وتعليق فريق Webassembly يعني أن Webassembly is FASTER than Javascript? I do not see performance comparison for WebAssembly Code and similar Javascript Code? أرى أفكارًا ذاتية فقط. هل يمكن لاحد ان يشرح هذا؟ إذا كان Webasembly أسرع من Javascript فلماذا لا توفر مترجمًا؟ إذا لم يكن Javascript ممكنًا ، فلماذا لا يكون رمز ES7 / TS؟ لماذا هناك الكثير من السرية حول هذا؟

ganeshkbhat الإصدار الأولي لـ WASM هو أكثر بقليل من ترميز ثنائي مضغوط لـ asm.js ، وهي مجموعة فرعية صارمة جدًا من JavaScript. لا يعمل بشكل أسرع من asm.js ما لم يتم استخدام أعداد صحيحة 64 بت ، حيث يجب محاكاتها في asm.js.

هناك مقترحات لإضافة ميزات إلى WASM تجعله أقرب إلى JavaScript من حيث القدرة (جمع البيانات المهملة ، وتكامل DOM ، والخيوط) ، ولكن لا توجد خطط لإضافة مجموعة ميزات JavaScript الكاملة. لذلك ، من المحتمل ألا يكون ناقل JS-> WASM موجودًا أبدًا. بدلاً من ذلك ، سيتم إنشاء تطبيقات ومكتبات جديدة مصممة للعمل ضمن قيود WASM. اليوم ، هذه هي C و C ++ ، حيث تتوافق قيود اللغة بشكل جيد مع WASM و asm.js.

ليس هناك سر ولا سحر. Wasm "أسرع من JavaScript" لأنها لغة أبسط بكثير وهي أقرب إلى الأجهزة. JavaScript هي لغة معقدة يتعين عليها القيام بالعديد من الأشياء المكلفة أثناء التنفيذ. لن تصبح أسرع بطريقة سحرية من خلال تجميعها في كود أصلي من خلال Wasm بدلاً من ترجمتها مباشرة.

ganeshkbhat حاليًا ، لا يمكن تخصيص كائنات داخل asm.js / webassembly. في asm.js و webassembly ، ستستخدم جميع عمليات JavaScript مصفوفة واحدة كبيرة لتخزين وتحميل القيم هناك. لا يمكن إنشاء كائنات JavaScript (مثل var obj = {a: 1, b: 'test'} ) ومصفوفات (مثل var a = []; ) داخل webassembly نظرًا لعدم وجود دعم كائن حتى الآن. هذا قرار تصميم لمنتج قابل للتطبيق الأدنى تم إجراؤه للحصول على دعم Webassembly في جميع المتصفحات الرئيسية في أسرع وقت ممكن.

في إصدار مستقبلي ، تم التخطيط لدعم GC للتجميع عبر الويب. نحن (مطورو LeaningTech.com ) نعمل على اقتراح لدعم الكائن في Webassembly ، لكن هذا سيستغرق بعض الوقت للوصول إلى المواصفات والتنفيذ في جميع المتصفحات الرئيسية. حتى ذلك الحين ، لا يمكن تحويل JavaScript (و CoffeeScript و TypeScript وما إلى ذلك) إلى Webassembly. عند قبول الاقتراح ، يجب أن يكون من الممكن تحويل مجموعة فرعية أكبر من JavaScript ، لكنها لن تدعم جميع الميزات المتوفرة حاليًا.

بالتأكيد. لا تتطلع إلى دعم أفضل لـ JS هنا. أنا بالتأكيد أشعر أنه يمكن دعمه. كتابة الناقل هو ما قد يكون مطلوبًا للغات الداعمة للكتابة.

من خلال ما قرأته عن webassembly ، فإنه يستهدف بشكل أساسي متصفحات الويب وفي هذا المجال لا يبدو جذابًا أن يكون لديك js -> webassembly compiler. لكن يمكنني أن أتخيل تشغيل webassembly في بيئات غير مستعرض. هذا ليس صحيحًا تمامًا حيث يمكن تشغيله أيضًا في nodejs ، لكنني أرى أنه إمكانات حقيقية في بيئات nodejs في شيء مثل vertx - متعدد اللغات يسمح بتشغيل الوحدات النمطية المكتوبة بأي لغة ، والتي يمكن تجميعها على webassembly. أستطيع أن أتخيل أنه سيكون من الصعب للغاية إنجاز شيء كهذا. سيتطلب العديد من الميزات مثل GC ، وربما حتى نوع من VM ليتم تنفيذه ، لكن لا شيء مستحيل. تذكر أن العديد من الأشخاص كانوا متشككين بشأن asm.js أيضًا وانظروا إليها اليوم.

بالنسبة لكل هؤلاء ، المتحمسين (مثلي) حول تجميع js -> webassembly ، قد تكون هناك طريقة غير مباشرة ووعرة جدًا عبر js -> c -> webassembly باستخدام مشروع ts2c transpiler في المستقبل.

@ mauron85 تعد بيئات وقت التشغيل بدون مستعرض وغير جافا سكريبت بالتأكيد اعتبارًا للتصميم ، ولكن فقط واجهة برمجة تطبيقات JS موجودة اليوم.

من ناحيتي ، كنت أقوم بتجربة نظام .NET JIT ولا أرى أي عوائق حقيقية بخلاف الوقت ، وأنا متأكد من أن هناك آخرين يتطلعون إلى دمج WASM في منصاتهم المفضلة أيضًا. أنا متأكد من أنه بعد بضع سنوات من الآن ستكون هناك أوقات تشغيل عالية الجودة بخلاف JavaScript لـ WebAssembly ، والسؤال الوحيد المفتوح هو الدرجة التي سيتم اعتمادها رسميًا من قبل فريق WebAssembly.

تتمثل إحدى فوائد IMO لقدرة الترجمة JavaScript -> WebAssembly أن مطوري / المشرفين على مكتبات وأدوات جافا سكريبت قد يكونون قادرين على إصدار واجهات برمجة التطبيقات الخاصة بهم في شكلين:

1. في JS (كما هو الحال الآن) والتي يمكن للمستخدمين استخدامها للمتصفحات والعقدة
2. WASM كمكتبة مترجمة والتي قد تكون أكثر كفاءة.

وهذا دون الحاجة إلى إعادة كتابة كود JS الحالي في C / C ++ ، إذا كانوا يريدون إطلاق العنان لمزايا أداء WASM في مكتبات JS الخاصة بهم.
لذلك سيظل مطورو المكتبة قادرين على التطوير والصيانة في Javascript وإنتاج ناتجين لهدفين مختلفين في كل من JS و WASM.

ومن المؤكد أن استخدام مكتبة إصدارات WASM المترجمة سيكون أكثر كفاءة للمستخدمين لأن كل ما يحتاجون إليه هو استخدام واجهة برمجة التطبيقات المكشوفة من المكتبة ومن الواضح أنهم لن يهتموا بما إذا كانت مكتوبة بلغة WASM أم لا. لكن الأداء سيتحسن بالتأكيد.

WASM كمكتبة مترجمة والتي قد تكون أكثر كفاءة

لماذا ا؟ لماذا قد تكون كتلة من تجميع ويب javascript transpiled (أسوأ سيناريو ، بما في ذلك الكثير من وقت تشغيل محرك جافا سكريبت في هذا الثنائي ؛ أفضل سيناريو للحالة ، بما في ذلك طبقة مبنية فوق المستقبل الذي تم إنشاؤه في wasm GC ، والذي يتحمل النفقات العامة الخاصة به على أي حال ) تشغيل أسرع من جافا سكريبت الذي تم إلقاؤه في جيت مخصص لتشغيل جافا سكريبت؟

حسنًا ، تقصد أن ذلك سيكون أبطأ مع زيادة الحمل؟

ربما هناك شيء لم أفهمه جيدًا. كيف تكون الأشياء المجمعة C/C++/Rust -> WebAssembly فعالة حقًا وحتى إذا كان هناك دعم JS -> WASM في المستقبل من شأنه أن يتسبب في زيادة النفقات؟ هل هذا فقط لأن JS هي لغة ديناميكية وأن C و C ++ و Rust ليست كذلك؟ أم لأن JS بطبيعتها ليست لغة مجمعة بالكامل ولكن هذه اللغات الأخرى كذلك؟

أعتقد أنه من غير المحتمل أن يؤدي تجميع JS إلى WASM إلى تعزيز الأداء المستدام ؛ ومع ذلك ، قد يحسن حجم الشفرة ووقت التحليل بسبب الترميز الثنائي ، والذي لا يزال مفيدًا.

أعتقد أنه يمكننا فقط تحديد تشفير ثنائي لـ JS ، وتجاهل الذاكرة الخطية وما إلى ذلك في الوقت الحالي. هذا بسيط وقابل للتعبئة.

kabirbaidhya المشكلة الرئيسية في JS -> WASM في الوقت الحالي هي أنه لا يمكنك بناء جامع قمامة فعال بداخله حيث لا توجد طريقة لتحليل المكدس لمعرفة الكائنات الحية. هذا يعني أنه سيتعين عليك وضع نسخة من جميع مراجع الكائنات في الذاكرة الخطية (الكومة) والحفاظ عليها متزامنة ، مما يؤدي إلى تدهور الأداء بشكل خطير. كما أنه يفتقر إلى خيوط الذاكرة المشتركة المتعددة ، لذا فإن جمع البيانات المهملة في الخلفية أمر مستحيل. ستتمكن الإصدارات المستقبلية من WASM من الاستفادة من محرك جمع البيانات المهملة للمتصفح المضيف ، مما يلغي هذه المشكلة.

الحاجز الرئيسي الآخر لـ JS -> WASM هو حقيقة أن جميع الكائنات تقريبًا ديناميكية بالكامل. تتوقع WASM جوهريًا أن يكون كل شيء ثابتًا تمامًا ، لذا ستكون هناك حاجة إلى طبقات رسم الخرائط المعقدة والمحاكاة وإنشاء الكود الديناميكي للتعامل مع أداء JS القياسي. لحسن الحظ ، تساعد TypeScript في ذلك ، لذلك قد تتمكن مجموعة فرعية صارمة من TypeScript من استهداف WASM إلى حد ما. أعلم أن هناك شخصًا واحدًا على الأقل يحاول بناء هذا.

تعمل C / C ++ بشكل جيد مع الإصدار الأول من WASM نظرًا لحقيقة أن قيود WASM تتماشى بشكل وثيق مع قيود الأجهزة الأصلية ، والتي تم تصميم C / C ++ لاستهدافها.

FWIW هناك شريحة رائعة حول كيفية معالجة V8 لحساب JavaScript: https://docs.google.com/presentation/d/1wZVIqJMODGFYggueQySdiA3tUYuHNMcyp_PndgXsO1Y/edit

tl ؛ dr هذا هو مجرد مثال واحد حيث يكون الواقع أصعب بكثير مما قد يبدو وفي الممارسة العملية ليس له معنى كبير لأن الجهاز الافتراضي الأصلي يمكنه (ومن المحتمل أن) يقوم بعمل أفضل وأسرع لأنه أصلي حقًا ولديه إمكانية الوصول إلى الموارد وواجهات برمجة التطبيقات لم تكن أبدًا - والأهم من ذلك (ربما) سنوات من التكرار.

هذا لا يعني أن _subset_ من JS / TypeScript لا يمكن أن تتكاثر بنجاح ، مثل ThinScript و TurboScript وما إلى ذلك. ستبدو مألوفة جدًا لمبرمجي JS للوهلة الأولى.

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

في 6 أبريل 2017 الساعة 00:36 ، كتب Ryan Lamansky [email protected] :

الحاجز الرئيسي الآخر لـ JS -> WASM هو حقيقة أن جميع الكائنات تقريبًا
ديناميكية بالكامل. تتوقع WASM جوهريًا أن يكون كل شيء بحتًا
طبقات رسم الخرائط الثابتة والمعقدة للغاية والمحاكاة وتوليد الكود الديناميكي
ستكون هناك حاجة لمقاربة أداء JS القياسي. لحسن الحظ،
يساعد TypeScript في ذلك ، لذلك قد تتمكن مجموعة فرعية صارمة من TypeScript من القيام بذلك
تستهدف WASM إلى حد ما. أعلم أن هناك شخصًا واحدًا على الأقل يحاول ذلك
بناء هذا.

لسوء الحظ ، أشك في أن TypeScript يساعد في هذا الصدد. لتشمل
JS تراث ، نظام النوع الخاص به بشكل عميق وغير سليم بشكل أساسي
لا توجد مجموعة فرعية "صارمة" مثيرة للاهتمام. على سبيل المثال ، فإن مثل هذه المجموعة الفرعية
بحاجة إلى استبعاد أي من أفكار TS الخاصة بالتصنيف الفرعي ، مما يجعلها جميلة
عديمة الجدوى في مجالها.

كانت هناك أوراق بحثية جيدة ، مثل SafeTypeScript ، لكن ليس كذلك
فقط إذا كانت مقيدة بشكل أكبر ، فهي تتطلب أيضًا كميات كبيرة من
تشغيل إضافي مكلف ومسك الدفاتر والشيكات ، وهزيمة الغرض من
المناقشة (وكونها لغة مختلفة فعليًا عن JS / TS).

ربما لا أحصل على شيء ما ، ولكن إحدى أفكار WebAssembly هي تحميل AST مباشرةً لتجنب وقت تحليل js ، أليس كذلك؟

لذا ، إذا كانت لدينا أداة تقوم بتجميع js لهذا التنسيق ast وتمريرها إلى المتصفح ، ألا تستفيد من تجنب وقت التحليل؟

agnivade ، إنها AST للغة مختلفة تمامًا وذات مستوى منخفض.

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

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

@ rossberg-chromium - شكرا جزيلا. هذا يوضح الكثير! شك واحد رغم ذلك -

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

لماذا تحتاج إلى نظام تشغيل VM؟ أليس المتصفح نفسه هو وقت تشغيل الجهاز الافتراضي؟ أريد فقط أن يكون الرمز بتنسيق AST حتى يتمكن المتصفح من بدء تنفيذه بسهولة. أدرك أن الحجم الصافي سيزداد لأن اللغة نفسها معقدة ، ولا يمكننا تنفيذ التحسينات الديناميكية. ولكن لماذا نحتاج إلى تجميع وقت تشغيل الجهاز الظاهري نفسه ، عندما يكون لدينا متصفح لذلك؟

agnivade ، بدون التحسينات الديناميكية ، ستكون JavaScript بطيئة ، وأعني

لا أقصد بـ "وقت التشغيل" عناصر المتصفح مثل DOM ، ولكن دعم لغة JS المجردة ، على سبيل المثال ، أشياء مثل جامع القمامة ، تمثيلات الكائنات ، العناصر الأولية والمكتبات الأساسية ، إلخ. بحاجة إلى إعادة تنفيذ كل ذلك داخل واسم.

وبالطبع ، ستحتاج أيضًا إلى طبقة واجهة لـ DOM.

حسنًا ، أعتقد أنني أفهم الأمور بشكل أفضل قليلاً الآن. اعتقدت أن

جامع القمامة ، تمثيلات الكائنات ، العناصر الأولية والمكتبات الأساسية ، إلخ.

يمكن استخدامها من المتصفح نفسه. ويمكنني فقط السماح للمتصفح بتحميل AST والقيام بعمله المعتاد. لكنني أدرك الآن أن كل شيء يحتاج إلى حزم داخل WASM نفسها.

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

distransient ، هل تريد الجنون الاندماجي لجميع لغات البرمجة النصية؟ أنا متفائل بأنه سيكون من الممكن للبشرية جمع الموارد الهندسية لتحديد وتنفيذ ذلك بكفاءة بحلول عام 2050. :)

أولئك الذين يرغبون في ترجمة TypeScript إلى WebAssembly باستخدام LLVM. تحقق من هذا المشروع. https://github.com/MichaReiser/speedy.js
يبدو أن هذه المناقشة لا تنتهي أبدًا ...

@ rossberg-chromium قلت أنه سيكون "مثيرًا للاهتمام" ، وليس سهلاً أو جميلًا 😉

سيكون رمز بايت لغة البرمجة العالمية ish مثيرًا للاهتمام ...

بينما يتطور WASM بشكل تدريجي لدعم أشياء مثل Python في النهاية ، يمكننا الحصول على دعم من الدرجة الأولى لتطوير لغات البرمجة النصية للويب في وقت أقرب بكثير مما يمكن لـ WASM توفيره ، إذا تعاملنا مع المشكلة من الطرف المقابل في نفس الوقت.

يجب أن يكون الأمر بسيطًا نسبيًا لمحركات JavaScript للكشف عن قدرتها على تنفيذ JavaScript ASTs ، ويمكن توحيد ASTs التي قبلوها (حتى لو تم تحويلها على الفور إلى تنسيق متوسط ​​غير قياسي داخليًا).

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

بمجرد إنشاء الدعم الأساسي ، يمكن أن يتطور المعيار بشكل تدريجي ليلبي WASM في الوسط ، عن طريق إضافة أنواع عقدة جديدة بشكل أساسي. هناك أشياء بسيطة لتبدأ بها ، مثل العقد الصريحة add و concat ، أو ربما إضافة أنواع بيانات جديدة ، مثل DEC64.

نظرًا لأن WASM يعمل على دعم لغات البرمجة النصية ، عن طريق إضافة أشياء مثل GC ، فإن تنفيذ AST سينتقل إلى أسفل ، مما يوسع دلالات JavaScript لتشمل ميزات من لغات أخرى عالية المستوى ، لذلك يمكن لمجموعة أوسع من لغات البرمجة النصية التحويل إلى نوع من JavaScript مجردة .

في 25 مايو 2017 الساعة 02:57 ، كتب Carl Smith [email protected] :
>

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

فقط من أجل تعريف أوسع بكثير لمصطلح "بسيط نسبيًا" أكثر مما أنت على الأرجح
خليه في عقللك... ؛)

بالنسبة إلى WASM ، الأمر بسيط.

bguiz على سبيل المثال:

• لا يمكنك ترجمة JS أصلاً إلى ASM ، لأن لها بنية مختلفة.
• لا يمكنك معالجة DOM من ASM ، لأنه لا يمكنك الوصول إلى موارده على مستوى سطح الأرض لوحدة المعالجة المركزية.

يقوم محرك Google V8 بالفعل بتجميع JavaScript مباشرة إلى كود الجهاز الأصلي ، عن طريق تجميع مهمة وقت التشغيل بالكامل ، قبل تنفيذها.

لذلك سيكون من غير الضروري على الإطلاق أن يكون لديك خط أنابيب بديل من WASM من جانب العميل.

من ناحية أخرى ، تم تقديم WASM مع عرض Mandelbrot التجريبي ، ثم يتميز بعرض Unity "Tanks" في المقام الأول ، لكنني أشك كثيرًا في أن رسم وحدات البكسل باستخدام ASM-> CPU (حتى مع الدقة المزدوجة SSE) يمكن أن يكون أسرع من أي وقت مضى من WebGL-> GPU ، لأنه كما يقول هذا المجتمع ، فإن وحدة معالجة الرسومات ليست في النطاق. وماذا في ذلك؟

تضمين التغريدة أين يقول هذا المجتمع أن وحدة معالجة الرسومات ليست في المواصفات؟

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

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

-ملف

https://github.com/WebAssembly/design/issues/273#issuecomment -123094583

تم نقل وقت تشغيل C # إلى wasm وكان نموذجًا أوليًا يعمل بكامل طاقته ليحل محل JS تمامًا. هذا يعني أنه في المستقبل يمكنك توقع ظهور أوقات التشغيل لاستبدال JS على المتصفحات وكتابة تطبيقات الويب من جانب العميل في Java أو C # أو حتى C ++ مع عبارة تقول "سيتم تشغيل الشفرة بشكل أسرع بالقرب من اللغة الأصلية" ، و "الشفرة المجمعة أسرع من VM" أو أي شيء بدون مساعدة JavaScript.

يرجى مشاهدة هذا الفيديو لما أحاول قوله.

تم تقديم WebASM لتكملة JS لعدم توليها بالكامل ، لتحل محل لغة الدرجة الأولى.

في المستقبل القريب ، يمكنك توقع تسليم صفحات الويب من خادم تم تجميعه محليًا

https://github.com/ballercat/walt

Steakeye لطيف جدا :)

يمكنك ترجمة JS إلى WebAssembly باستخدام NectarJS. العرض التوضيحي: http://nectar-lang.com/ اختر من القائمة المنسدلة WebAssembly

من المثير للاهتمام أن العرض التوضيحي لـ NectarJS يستخدم emscripten ، ويمكنك أن ترى ذلك في إخراج asm.js. يبدو أنه يجمع JS بشكل ثابت إلى شيء - من المحتمل C أو LLVM IR - ثم يدير ذلك من خلال emscripten.

يستخدم إخراج wasm أيضًا emscripten (يمكن رؤيته من فحص الملف الثنائي) ، ولكن يبدو أنه يستخدم إصدارًا قديمًا لأنه يصدر ثنائيات 0xd wasm ، والتي لا تعمل في أجهزة VM الحديثة. كما أنه يرسل لك الوسم وليس JS ، لذلك لا يمكن تشغيله على أي حال. على أي حال ، من المحتمل جدًا أنه يفعل الشيء نفسه بالنسبة لـ asm.js ، فقط تشغيل emscripten مع انعكاس إشارة إخراج wasm.

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

إن عروضهم التوضيحية المجمعة لنظام التشغيل Windows تتعطل ببساطة بالنسبة لي 🤕

أتفق مع شكوك kripken هنا. أعتقد أنه لا يمكن تحويل JS التعسفي بشكل معقول إلى WebAssembly. من المحتمل أن تعمل أي أداة تدعي تحقيق ذلك على مجموعة فرعية قابلة للتتبع من لغة JS ، أو تتخلى عن أداء التنفيذ.

JS هي لغة ديناميكية للغاية. يمكن لعمليات وقت التشغيل غير المتوقعة أن تغير دلالات الكود بشكل كبير وعالمي. هذا يعني أن المترجم Ahead-Of-Time (أو غير متصل) يمكنه فقط افتراض الأسوأ وإنشاء رمز عام غير فعال للغاية يمكنه التعامل مع جميع الحالات المحتملة. على سبيل المثال ، خذ كود JS التالي:

var a = {prop1: 1};
func(a);

يمكن تحويلها (في الزائفة الزائفة) إلى هذا

i32.const 42
call $CreateJSValFromStrTable ;; Returns prop1
i32.const 1
call $CreateJSValFromInt
call $CreateJSObj1 ;; Consume a JS string and a JS value to make an object
call $_func

الآن ، هذه دعوة بعيدة عما يمكن أن نعتبره بشكل معقول "ترجمة" وهو أشبه بإلغاء تعيين مترجم. من الممكن أيضًا بالطبع تشغيل مترجم JS مترجم إلى Wasm ، لكن هذا لن يكون فوزًا في الأداء.

يمكن لمحركات JS مثل V8 و Spidermonkey تشغيل كود JS بأسرع ما يمكن عن طريق تجميعه في الوقت المناسب. من خلال القيام بتجميع JIT ، يمكنهم ملاحظة ما هو المقصود من الدلالات الحقيقية لجزء معين من JS وإنشاء رمز سريع لتلك الحالة المحددة ، مع الحرص بالطبع على اكتشاف أي تغيير في البيئة يمكن أن يبطل الافتراضات الحالية.

متفق. ومع ذلك ، لا أمانع في استخدام مجموعة فرعية من JavaScript. أو ربما متغير مكتوب ، والذي من المحتمل أن يقلل من الديناميكية ويسمح بإنشاء كود أكثر كفاءة.

هل هناك أي أخبار عن "الوضع القوي" الأمامي راجع للشغل؟

@ Simran-B ، لقد تخلينا منذ فترة طويلة عن الوضع القوي ، للأسباب الموجزة هنا . والخلاصة أنه من المستحيل إلى حد كبير تشديد دلالات جافا سكريبت دون فقدان التوافق مع الكود الموجود.

للسبب نفسه ، ليس لدي أمل كبير في فكرة تصميم لهجة "قابلة للترجمة بشكل ثابت" لجافا سكريبت أو تيب سكريبت - ستكون لغة مختلفة لا يمكنها تشغيل التعليمات البرمجية الموجودة ، لذا لا فائدة من ذلك.

@ Simran-B: "لا أمانع في استخدام مجموعة فرعية من JavaScript. أو ربما متغير مكتوب"

هناك بعض الأعمال المثيرة للاهتمام في هذه المساحة ، مثل AssemblyScript وهي مجموعة فرعية صارمة من TypeScript يتم تجميعها إلى WebAssembly ، https://github.com/AssemblyScript/assemblyscript

rossberg : "ليس لدي أمل كبير في فكرة تصميم لهجة" قابلة للتجميع بشكل ثابت "لجافا سكريبت أو تيب سكريبت - ستكون لغة مختلفة لا يمكنها تشغيل التعليمات البرمجية الحالية ، لذا لا فائدة من ذلك."

أعتقد أن الإمكانات الكبيرة لأشياء مثل AssemblyScript لا تتعلق بتشغيل الكود الحالي (أتفق معك هناك ، لن يكون ذلك ممكنًا بشكل عام) ، لكن امتلاك لغة ودية ومألوفة هو صفقة ضخمة.

الآن ، إذا كنت مطورًا لـ TypeScript وتريد كتابة WebAssembly ، فأنت بحاجة إلى استخدام C ++ أو Rust. كلاهما لغتان جيدتان ولكن لهما أيضًا جوانب سلبية. بالنسبة لشخص لديه هذه الخلفية ، يمكن أن يكون شيء مثل AssemblyScript هو أسرع طريق للإنتاجية.

إذا كان بإمكان AssemblyScript الترجمة إلى كل من JavaScript و Assembly ، فسيكون ذلك مثاليًا جدًا. نتطلع إلى هذه التحديثات.

أيضًا ، في المستقبل ، ما لم يقم شخص ما بذلك أولاً ، ربما سأحاول كتابة TypeScript -> محول البرنامج النصي التجميعي الذي يمر عبر الملفات ، ويطرح الأسئلة التي يجب طرحها ، ثم يقوم بإجراء التحويل. نأمل أن يعمل!

SephReed نعم ، يمكنه التحويل البرمجي إلى JavaScript ، نظرًا لوجود WebAssembly -> asm.js مترجم ، والذي يجب أن يعمل مع جميع تعليمات WebAssembly.

راجع أيضًا "هل يمكن تعبئة WebAssembly؟"

إذا كنت تقصد بدلاً من ذلك "هل من الممكن أن تقوم AssemblyScript بالتجميع إلى كود JavaScript اصطلاحي ؟" ، إذًا يجب أن أسأل ، لماذا تريد القيام بذلك عندما يكون WebAssembly / asm.js أسرع بكثير من كود JavaScript الاصطلاحي؟

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

راجع أيضًا هذا القسم من وثائق AssemblyScript.

أيها السادة ، يرجى مراعاة WALT ، وهي لغة WebAssembly التي تشبه جافا سكريبت.

محدث. آسف على الجثث

أرى الكثير من الناس يعتبرون المترجم "JS -> WASM" فكرة جيدة.

بالنسبة لأولئك الذين لا يجدونها مفيدة ، مثل:

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

من فضلك ، هذا هو المثال الملموس عن سبب أهميته ، ولماذا هو مفيد ، وليس فقط "الحصول على بعض تقليل الحجم ، ولكن هذا يتعلق به". إحدى الميزات التي تأتي مع WebAssembly هي:

<= XXX « SaNdBoXeD EnViRoNmEnT » XXX =>

لا يقتصر WebAssembly على الأداء فقط. قد ترى مقالًا جيدًا عن المكونات الإضافية من فريق Figma .

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

يمنحك WebAssembly ذلك - بيئة خالصة خالية من الفوضى مثل بعض المتغيرات العالمية. يجعله AssemblyScript مناسبًا بطريقة ما ، - لديك نفس بيئة TypeScript تقريبًا ، مثل بيئة تطبيقك الرئيسي ، وهو أمر رائع جدًا.

ولكن هذه هي المشكلة ، "تقريبًا نفسها":

هل يمكنني استخدام حزم JS من NPM في بيئتي الآمنة؟

لا.

حسنًا ، مشروع WALT هذا هو نوع من بديل AssemblyScript. إنها بالكاد تشبه JS ، - تمت كتابتها js. إنه أشبه بـ TS. لا يمكنك ترجمة / تحويل مكتبات js الموجودة بهذا.

هل يمكنني استخدام حزم TS من NPM في بيئتي الآمنة؟

لا.

AssemblyScript هي لغة تشبه TS أيضًا. قد يجمع شيئًا مكتوبًا في TS إذا كان مغطى بالكامل بالأنواع. لا استثناءات. لا يوجد أي any . ولكن غالبًا ما يكون لدى الأشخاص تكويناتهم غير صارمة بدرجة كافية أو لديهم عدد قليل من @ts-ignore ، أو حتى في كثير من الأحيان - يكتبون حزمة في js ويقدمون أنواعًا منفصلة في ملفات .d.ts - في كل هذه الحالات أنت لن يكون قادرًا على تجميع مثل هذه الحزمة إلى WASM.

نقاط JerryGreen جيدة ، ولكن من ناحية الأداء ، أعتقد في الواقع أنه من المفاهيم الخاطئة الكبيرة أنه لا توجد فوائد أداء مهمة تتجاوز توفير بضع بايت. الناس ، بما في ذلك المعايير ، مهووسون جدًا بأداء وقت التشغيل. ترى مدى سرعة تشغيل الألعاب ثلاثية الأبعاد؟

ومع ذلك ، فإن الفرصة الواقعية تكمن في الواقع في أداء الشركات الناشئة ، مما يعود بالفائدة على جميع مواقع الويب كبير في وقت بدء التشغيل (لكل بايت) ، وهو ما يتجاوز بكثير أي مزايا وقت تشغيل. هذا هو السبب في أن gzip على سبيل المثال في المحتوى النصي ، مثل JavaScript ، له تأثير ضئيل في العالم الحقيقي على PLT - إنه حجم الشفرة المجمعة هو المهم.

ومن المفارقات ، أن الصناعة مهووسة بـ PLT (أوقات تحميل الصفحة) ، والعديد من العلامات المرئية الكاملة ، ولكن لا أحد يرى العلاقة بين WebAssembly وهذه المتجهات؟ يعد JavaScript مسؤولاً عن أكثر من 30٪ من الوقت الذي يقضيه قبل هذه الأحداث الهامة ، على معظم مواقع الويب. في الواقع ، حجم الصفحات والنطاق الترددي لهما تأثير أقل بكثير على أنظمة PLT مقارنة بعوامل الأداء الخطية ، أي أوقات بدء تشغيل JavaScript ووقت الاستجابة.

مع ذلك ، ليس من الواضح بالنسبة لي جدوى JS -> WebAssembly.

نهج JerryGreen Figma هو حالة محددة للغاية وأعتقد أنه بالنسبة لمعظم المشاريع ، JavaScriptCore إلى WebAssembly.

يمكنك أيضًا استخدام Web Workers ، وتشغيل التعليمات البرمجية قبل التعليمات البرمجية غير الموثوق بها التي تحذف أي واجهات برمجة تطبيقات لا تريد أن يكون للشفرة غير الموثوق بها حق الوصول إليها. لا حاجة لـ WASM في هذه الحالةJerryGreen!

Framerate Drops في Three js في شيء حقيقي ، لست متأكدًا مما إذا كان يمكن أن يساعد wasm ولكن من المؤكد أنه يبدو كذلك على الأقل على السطح.

لا يوجد سبب لتجميع JS إلى wasm لأنه سيتعين عليك أيضًا تضمين javascript vm. سيكون الرمز الناتج ضخمًا وأبطأ من JS VM المقدم أصلاً.

ألا يمكننا القيام بجميع أشكال monomorphisation وما إلى ذلك التي يتم إجراؤها بواسطة JS VMs من خلال التحسين الموجه للملف

يتكون بناء PGO من تمريرين: المرور الأول لبناء ثنائيات مُجهزة ، ثم المرور الثاني لإعادة بناء الثنائيات المُحسَّنة باستخدام معلومات الملف الشخصي المستقاة من تشغيل الثنائيات المُجهزة.

سيوفر لنا التشغيل الأول جميع معلومات النوع (التي يتم استدعاؤها مع أي وسيطات مكتوبة وما إلى ذلك) ، ثم نقوم ببناء ثنائي محسّن مع جميع المتغيرات التي تسمى الدالة بها (+ واحد عام يحتوي على أرجل ديناميكية للتعليمات البرمجية غير المحددة) . لن نحتاج إلى JS VM بأكمله .

تطلب PGO تغطية اختبار رائعة لبرنامجك. هذا ليس ممكنًا دائمًا. ولكن يمكنك تتبع بعض أنواع المعلومات أثناء التنفيذ في الإصدار 8. راجع هذا المستند: https://docs.google.com/document/d/1JY7pUCAk8gegyi6UkIdln6j_AeJqQucZg92advaMJY4/edit#heading = h.xgjl2srtytjt

لقد تحدثنا مع فريق TypeScript حول هذا الاحتمال وقد أظهروا اهتمامًا ، ولكن يبدو أن هناك تقدمًا حاليًا في إضافة كائنات مكتوبة إلى JS.

لا تحتاج أنواع

هل يمكن بالفعل تجميع QuickJS إلى WASM؟

نعم ، تستخدم Figma QuickJS لنظام البرنامج المساعد الخاص بهم على سبيل المثال

ويتم استخدامه أيضًا في http://numcalc.com/ .