في
المقالة الأخيرة حول WebAssembly ، أدليت بالبيان التالي:
يقارن البعض WebAssembly مع تطبيقات Java الصغيرة. بمعنى ما ، هم على حق ، ولكن من ناحية أخرى هم مخطئون بشكل كبير. بطريقة ما سأكتب مقالًا عن الاختلافات ، لكن الآن لنتحدث عن أوجه التشابه. بطريقة ما ، تعد WebAssembly طريقة مختلفة لتحقيق ما تم تصميمه من أجل JVM: فهي آلة افتراضية عادية للبرامج عبر الأنظمة الأساسية.
لقد عبّر الكثير من الأشخاص عن اهتمامهم بهذا الموضوع ، لذلك دعونا نلقي نظرة فاحصة عليه! في هذه المقالة ، نقارن WebAssembly مع ثلاث تقنيات: Flash ، وتطبيقات Java الصغيرة ،
وقليلاً مع PNaCL. تركز المقالة أيضًا على استخدامه على
الويب ، على الرغم من أننا نظرنا سابقًا في استخدام خيارات لاستخدام WebAssembly دون اتصال. لكننا سنتحدث عن
مثل هذه المقارنة لاحقًا. أخيرًا ، تشبه هذه المقالة تناول التاباس [وجبة خفيفة إسبانية من العديد من المكونات المختلفة - تقريبًا. في.] ، هنا مجموعة من الأقسام الصغيرة. يبدو لي أنها قصيرة بعض الشيء ، ولكن في نفس الوقت أحاول التدوين ، وإذا واصلت توسيعه ، فسيستغرق الأمر إلى الأبد ، لذلك أنا آسف.
أعتقد أن المقارنة مع تطبيقات Flash و Java أمر
طبيعي تمامًا عندما تصادف هذا الوصف لـ WebAssembly:
WebAssembly (Wasm اختصار) هو تنسيق تعليمات ثنائي لجهاز ظاهري مكدس. تم تطوير Wasm كنسخة محمولة من تجميع اللغات عالية المستوى مثل C و C ++ و Rust ، مما يسمح لك بنشر تطبيقات العميل والخادم على الإنترنت.
هذا يشبه إلى حد ما التكنولوجيا السابقة. من المنطقي مقارنة كيفية ارتباطها واقتراح اختلافات صغيرة بينهما. لكن WebAssembly يختلف اختلافًا كبيرًا لعدة أسباب.
هزم Wasm
السبب الأول في اختلاف WebAssembly هو أنه انتهى بها النجاح ، بينما لم تنجح التقنيات السابقة. أعني النصر بمعنى محدد. إذا قارنت عدد تطبيقات Flash وعدد تطبيقات WebAssembly ، فمن المحتمل أن تفقد Wasm. سيتعين على أتباع WebAssembly العمل بجد لتوزيع هذا النظام الأساسي.
عندما أتحدث عن فوز WebAssembly ، أعني أنه أصبح جزءًا من النظام الأساسي للويب. عملت تطبيقات Flash و Java و PNaCL من خلال المكونات الإضافية. إلى حد ما ، كانوا
خارج النظام البيئي للويب. لم يتم تضمينها مطلقًا في المعيار ، وهذا مهم جدًا.
بمعنى ما ، هذا التفسير كافٍ. لكن مجرد الإشارة إلى حقيقة لا يعني شرح
أسبابها . ستحاول بقية هذه المقالة معرفة
سبب حدوث ذلك: لماذا نجحت WebAssembly في ما لم تتمكن التقنيات الأخرى من القيام به. هنا ،
هناك أسباب
عديدة مرتبطة ببعضها البعض ، لكنني أحاول تقسيمها بشكل معقول إلى نقاط منفصلة.
لم تتناسب التقنيات الأخرى مع النظام الأساسي
هل تتذكر ذلك؟
أم هو كذلك؟
ماذا عن هذا؟
تطبيق صغير مبني على هذه التقنيات ليس
تطبيق ويب حقًا. لديك صفحة ويب مع قطعة مقطوعة ، وعمل التطبيق الصغير الخاص بك في هذا الإطار. ستفقد كل مزايا تقنيات الويب الأخرى: لا HTML ولا CSS ولا القدرة على الاندماج في الويب. لا تتفاعل هذه الأنظمة الأساسية مع بقية النظام الأساسي في المتصفح. حسنًا ،
يمكنهم تقنيًا ، ولكن من الناحية العملية ، تم استخدام هذه التقنيات بشكل مختلف.
كيف يدعم الويب نظامًا بيئيًا لا يتكامل معه؟ هذا لن يحدث أبداً. وقد رفضها المستخدمون بشكل قاطع. بالإضافة إلى الألعاب ، كان المستخدمون
يكرهون Flash ، وكانت تطبيقات Java الصغيرة ثقيلة وبطيئة. هذه التقنيات ليست راسخة في منصة الويب.
من ناحية أخرى ، فإن WebAssembly أقرب إلى JavaScript. في الواقع ، لا يأخذ Wasm جزءًا من الشاشة منك. لا يخلق عالمه الصغير الخاص به المغلق. الآن باستخدام JavaScript ، وفي
المستقبل بمفردها ، فهي قادرة على التفاعل مع البيئة. انه فقط ... يناسبها.
التكنولوجيا الأخرى المملوكة للشركات
كانت جافا مملوكة لشركة Sun Microsystems ، وكانت Flash مملوكة لشركة Adobe. لماذا هذا مهم؟
تأثير الشركات على الإنترنت هو موضوع معقد.
بشكل عام ، يعمل الويب على نموذج إجماع زائف. من ناحية أخرى ، تم التحكم في Java و Flash من قبل شركاتهم. لديهم دافع قوي لتحقيق الربح ، وليس لتحسين الإنترنت. وأدى ذلك جزئيًا إلى الوضع المذكور أعلاه: لم تهتم هذه الشركات بالاندماج بشكل صحيح مع بقية النظام الأساسي. لماذا يحتاجونها؟ من الأفضل للأعمال التجارية أن تحجب منصتها وتتخلى تمامًا عن بقية الإنترنت. الدافع منحرف بالكامل.
WebAssembly هي مبادرة مشتركة بين Mozilla و Google و Apple و Microsoft وغيرها. إنه لا يروج لمنصة معينة لشخص ما ، ولكنه بدلاً من ذلك يمثل المصالح المشتركة لمجموعة واسعة من أصحاب المصلحة ، سواء الشركات والأفراد.
يتبع WebAssembly عملية الويب
يعني الانتماء المؤسسي
أيضًا أن هذه التقنيات لم تتبع أبدًا العملية التي نستخدمها لتوحيد الويب. عملية اعتماد معايير الويب راسخة جيدًا ، ولكن هذه التقنيات كانت كبيرة جدًا وعملت بشكل مختلف قليلاً. في المقابل ، اتبعت WebAssembly الإجراء القياسي المعتمد لتقنيات الويب.
تم إنشاء Asm.js لأول مرة كدليل على أنه يمكننا القيام بأشياء مثيرة للإعجاب مع الويب. اتضح أن تنفيذها عالي الجودة وأظهر قدرات التكنولوجيا ، على الرغم من أنه لا يوجد شيء رائع هناك. كانت الورقة الرابحة الرئيسية لـ
asm.js أنها كانت رمز JavaScript فقط: فهي متوافقة تمامًا مع النظام البيئي الحالي. "لا تكسر الإنترنت" هي قاعدة مهمة جدًا جدًا لمطوري المتصفح.
كان WebAssembly نسخة محسنة من
asm.js بعد العثور على بعض التوافق حول
asm.js الجميع لجعل WebAssembly حقيقة. نظرًا لأن هذه ليست جافا سكريبت فقط ، كان عليه أن يمر بالعملية الكاملة للتنفيذ في المتصفحات ، وقد اجتازها. هذه هي الآن مواصفات W3C ، والتي
تتوافق مع معايير الويب ، ولكنها لا تتعارض معها.
العواقب: التقنيات الأخرى كانت كبيرة للغاية وغير مستقرة
سبب آخر وراء نجاح واسم: إنه صغير. تتبع Wasm نهج تقنيات الويب الأخرى: ابدأ بشكل صغير واكبر حجمًا على هذا الأساس. الحفاظ على التوافق مع الإصدارات السابقة. كما أن التقنيات السابقة لم تتبع هذا التقاليد الاجتماعية الخاصة. تم تحميل وقت تشغيل محدد لتطبيقات Flash و Java ، لذا لم يكن التوافق مطلوبًا. تم بناء PNaCl فوق رمز LLVM IR غير المستقر تمامًا. كانوا سيجعلونها مجموعة فرعية مستقرة ، ولكن إذا تغير LLVM ، فسيكون هناك تناقض ، وهو ليس جيدًا جدًا.
كما أن هذه التقنيات معقدة للغاية بحيث لا تأمل في تحقيق الاستقرار على الإطلاق. هل يمكنك أن تتخيل أن أربعة من صانعي المتصفح يحددون مواصفات JVM بشكل كامل ثم يقبلون هذه الدلالات إلى الأبد؟ لجميع أكشن سكريبت ، وهو في حد ذاته نسخة مماثلة ولكن مختلفة من ECMAScript؟ لكل شيء LLVM-IR؟
تشكل التقنيات الكبيرة خطرًا غير مقبول على الوضع. هذه صفقة الكل أو لا شيء ، وهنا رهان آمن "لا شيء". من ناحية أخرى ، لا يقوم WebAssembly بأي شيء تقريبًا. هذا هو أساسا الرياضيات ومكالمة جافا سكريبت. أي أنه
من الأسهل
بكثير الاتفاق هنا.
نتيجة طبيعية: تتطلب التقنيات الأخرى آلة افتراضية منفصلة كاملة
في هذه المقالة لم أذكر دارت ، ولكنها تناسبها أيضًا هنا. الجملة ، "دعنا فقط نضع JVM في كل متصفح" ، المشكلة الرئيسية هي أن المتصفح لديه
بالفعل وقت تشغيل JavaScript. حتى وقت تشغيل واحد يصعب الحفاظ عليه ، ناهيك عن اثنين. وكيف تدمجهم؟
من ناحية أخرى ، تم تصميم WebAssembly بمثابة امتداد صغير لأجهزة JavaScript الظاهرية الموجودة. على الرغم من أنه يمكنك تنفيذ جهازك الظاهري WebAssembly - غالبًا ما يتم ذلك باستخدام WebAssembly دون اتصال ، ولكن بالنسبة للمتصفحات ، تكون تكاليف الصيانة أقل بكثير.
التقنيات الأخرى محددة للغاية.
WebAssembly هي لغة مستقلة بشكل أساسي. تم تصميم تطبيقات Flash و Java بشكل أساسي لتشغيل ActionScript و Java. هم مرتبطون بعمق بدلالاتهم النسبية. حتى PNaCl يعاني إلى حد ما من هذا: LLVM مناسب حقًا للغات المشابهة لـ C ، على الرغم من أنه ليس بنفس الدرجة.
هل نريد حقًا اختيار لغة واحدة للإنترنت بالكامل؟ لدينا بالفعل جافا سكريبت. هل تخيلت لغة ثالثة؟ رابعاً؟ النهج المستقل أفضل بكثير على المدى الطويل.
Wasm لديه نهج صارم للأمن
كانت تطبيقات جافا وفلاش
كابوسًا أمنيًا حقيقيًا. حتى لو جرت محاولات لحمايتهم ، فقد نشأت مشاكل في الواقع باستمرار.
من ناحية أخرى ، تلقت WebAssembly مرة أخرى مكافآت من JavaScript VM: كل الجهود المبذولة لعزل وضع الحماية الخاص بها تنطبق أيضًا على Wasm. هنا ، بعض وظائف المجمع المعتادة مفقودة ، مما قد يؤدي إلى نقاط ضعف ، مثل تدمير المكدس. Wasm يعمل بأمان مع الذاكرة ، وهو أمر مهم للغاية!
بالإضافة إلى ذلك ، تم تصميم WebAssembly في الأصل مع
الأخذ في الاعتبار فكرة
التحقق من
الصحة : فهي مكتوبة بالكامل ، ويمكن التحقق من البرامج دون تشغيل التعليمات البرمجية. تشمل المواصفات تعليمات حول كيفية إجراء مثل هذا التحقق. هذا مفيد جدا!
الخلاصة
أريد أن أقول ما يلي حول هذا المقال: إنه مكتوب من وجهة نظر
المطور . لكن المطورين مهمون لأنهم يتحكمون في الويب. يجب أن تكون التكنولوجيا متسقة مع أهدافها - وهذا لا يقل أهمية عن الراحة للمستخدمين النهائيين. في مقال لاحق ، سأحاول تحليل المشكلات من وجهة نظر المستخدمين. يجب أن تكتب الكثير!
لتلخيص:
- لم يتم دمج التقنيات الأخرى في منصة الويب ، وقد أعاقت ذلك المصالح التجارية.
- تتطلب التقنيات الأخرى الكثير: كان على الكثير أن يضحي في التنفيذ.
- يتمتع Wasm بعزل رمل جيد والتحقق من صحته ، وهو ما لم يكن لدى الآخرين.