لماذا تعتبر أطر عمل WebAssembly مستقبل الويب

جدول المحتويات:

لماذا تعتبر أطر عمل WebAssembly مستقبل الويب
لماذا تعتبر أطر عمل WebAssembly مستقبل الويب
Anonim

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

ما هو WebAssembly؟

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

يمكن استخدام Wasm كهدف تجميع محمول للغات أخرى
يمكن استخدام Wasm كهدف تجميع محمول للغات أخرى

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

ومع ذلك ، يمكنك أيضًا التحويل إلى تنسيق مختلف ؛ عادة ما ينتهي الأمر بهذه اللغة "ذات المستوى الأدنى" والتي تكون أقرب إلى رمز الآلة النهائي. على سبيل المثال ، تقوم Java بالتجميع إلى Java bytecode الذي يتم إرساله إلى وقت تشغيل JVM ، ويقوم Cبالتجميع إلى Microsoft Intermediary Language (MSIL) الذي يتم إرساله إلى وقت تشغيل. NET. يمكنك حتى "تحويل" اللغات ، من لغة عالية المستوى إلى لغة أخرى ، والأكثر شيوعًا امتدادات مثل TypeScript إلى JavaScript ، ولكن أيضًا أغرب تلك التي لا تتوقعها ، مثل Python إلى JavaScript ، على الرغم من أن هذا عادة ما يكون فوضويًا ومليئًا بالأخطاء.

WASM هي مجرد لغة وسيطة يسهل تجميعها. في الواقع ، إنه تقريبًا نفس مفهوم Java bytecode و CMSIL - كلا التنسيقين يجعل من السهل تشغيل نفس الكود عبر النظام الأساسي ، باستخدام نفس التنسيق الذي يعمل على أوقات تشغيل محددة تم تصميمها لكل نظام أساسي.

صورة
صورة

ما يعنيه هذا عمليًا هو أن JavaScript لم تعد اللغة الوحيدة التي يمكنك تشغيلها على الويب. يمكن لمتصفحات الويب تشغيل أي لغة الآن ، إذا كانت هذه اللغة بها مترجم WebAssembly

حتى لغات سطح المكتب التقليدية مثل C ++ و Rust يمكن تجميعها وصولاً إلى WASM بسهولة نسبية ؛ تمكن AutoDesk من نقل قاعدة بيانات C / C ++ البالغة من العمر 35 عامًا إلى WASM في غضون بضعة أشهر ، كما قامت Google بنقل Google Earth ، وكلاهما يعرض مشاهد ثلاثية الأبعاد معقدة ويعملان بأداء شبه أصلي. يمكن تشغيل محرك لعبة Unity أيضًا في WASM.

يعمل WASM حاليًا في 94٪ من متصفحات المستخدم ، مع متصفح IE و UC ودعم Opera Mini كونها الأشياء الرئيسية التي تعيقه ، كالمعتاد.ومع ذلك ، فهي مدعومة من قبل مطورين من Mozilla و Microsoft و Google و Apple ، كما أن دعمها في المتصفحات الحديثة سريع الحركة. مثل معظم معايير الويب ، تتم إدارته حاليًا بواسطة منظمة معايير W3C.

JavaScript ليس الخيار الوحيد بعد الآن

عظيم ، فماذا يعني هذا للجميع؟ حسنًا ، في حين أن تشغيل DOOM 3 في متصفح الويب هو بالتأكيد عرض توضيحي رائع ، إلا أنه لا يغير اللعبة تمامًا.

حتى الآن ، كان JavaScript هو خيارك الوحيد لجعل صفحات الويب الخاصة بك تفاعلية. سواء كنت تحبها أو تكرهها ، لم يتم تصميمها أبدًا لاستخدامها كما هي اليوم. لقد كانت لغة برمجة نصية مصممة للقيام بمهام تافهة مثل جعل القوائم المنسدلة متحركة ، وقد تم اختراق أكثر من 25 عامًا معًا لتشغيل أعباء العمل في العصر الحديث. فقط من خلال استخدام أحدث محركات JS وتحسينات تجميع JIT يمكن مقارنتها بالسرعات الأصلية.

وهكذا ، مع نمو صفحات الويب لتصبح تطبيقات ويب كاملة ، تم دعم أطر عمل عميل JavaScript مثل React و Vue و Angular لتلبية الطلب.بالطبع ، لا تزال هناك أطر عمل من جانب الخادم - أنت تقرأ هذا من WordPress ، إطار عمل PHP - لكن أطر عمل العميل تقدم زيادات هائلة في الأداء. باستخدام إطار عمل العميل ، يتم تحديث DOM تلقائيًا بعد الضغط على زر أو التفاعل مع التطبيق. حتى أطر العمل التي يقدمها الخادم في الوقت الفعلي يجب أن تقدم طلبًا للشبكة لتغيير أي شيء ، وفي أسوأ الأحوال ، يجب أن تقوم بتحديث الصفحة بأكملها.

الابتكار الذي تحتاجه الويب حقًا هو المنافسون المناسبون لأطر مثل React ، مكتوبة بلغات ليست JavaScript.

بينما تتم كتابة جميع كود الواجهة الأمامية للويب بلغة جافا سكريبت ، فإن كود الواجهة الخلفية غالبًا لا يكون كذلك. في أحمال عمل مركز البيانات عالية الأداء ، غالبًا ما يكون من المفيد استخدام لغات سطح مكتب مناسبة مثل Cو C ++ و Rust و Go. بعد كل شيء ، يمكن أن توفر لك هذه الأموال حرفيًا من خلال طلب عدد أقل من الخوادم لتلبية نفس الطلب.

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

امتلاك القدرة على كتابة كود Cو C ++ و Rust و Go الذي يتم تشغيله على الخادم والعميل سيفتح الباب أمام العديد من الخيارات الأخرى ، ويزيل الحاجة إلى JavaScript كلغة برمجة بالكامل تقريبًا. في إطار عمل عميل WASM Blazor ، يتم حجز استخدام JavaScript للتشغيل البيني مع حزم العميل الحالية والبرمجة الأساسية.

كيف تعمل أطر عمل WASM للعميل؟

نظرًا لأن WebAssembly هو مجرد طريقة لتشغيل التعليمات البرمجية في نوع من "بيئة WebAssembly" ، يمكنك التفكير في الأمر مثل تشغيل حاوية Docker. على سبيل المثال ، إطار عمل Blazor من Microsoft (إلى حد بعيد إطار عمل عميل WASM الأكثر شيوعًا حتى الآن) له وضعان للتشغيل:

  • خادم Blazor ، الذي يدير جميع عمليات المعالجة والتقديم على الخادم ، ويرسل التحديثات إلى HTML DOM عبر WebSocket ، و
  • Blazor WebAssembly ، الذي يقوم بنفس الشيء تمامًا ، باستثناء الآن تتم المعالجة والعرض على العميل ، من خلال وقت تشغيل. NET تم تجميعه لـ WASM.

في الحالة الأخيرة ، يتم استبدال اتصال WebSocket برابط مباشر إلى DOM ، من خلال JavaScript لأن WebAssembly حاليًا لا يملك طريقة لتعديل DOM مباشرةً دون استدعاء JS APIs. تحتاج أيضًا إلى JavaScript في أي حال من أجل "تمهيد" تطبيق WASM ، لذلك لن يتم إيقاف JS في أي وقت قريبًا.

صورة
صورة

علاوة على ذلك ، تعمل أطر عمل WASM بشكل عام مثل أي إطار عمل آخر ، وستعتمد التفاصيل الدقيقة على التنفيذ.

على سبيل المثال ، يحتفظ Blazor بحالة داخلية ويؤدي إلى إعادة عرض التطبيق عند النقر على زر أو إدخال إدخال.يقوم بإنشاء HTML جديد باستخدام كود Cالذي يعمل على WASM ، ثم يرسل HTML هذا إلى واجهات برمجة تطبيقات JavaScript لتطبيقه على DOM. يؤدي القيام بذلك على WebAssembly إلى إزالة حمل المعالجة من الخادم ويجعل العميل سريع الاستجابة. حتى الوصول إلى DOM من خلال JavaScript أبطأ قليلاً ، إلا أنه لا يزال أسرع من الوصول إلى DOM البديل عبر الإنترنت.

إلى أي مدى نتحدث بشكل أسرع؟

السؤال "ما مدى سرعة WASM؟" يصعب تحديده. من الواضح أنه أسرع بشكل عام ، ولا شك في ذلك ، ولكن في بعض الحالات يكون الأمر أكثر تعقيدًا من ذلك.

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

بالنسبة للتطبيقات عالية الأداء التي تحتاج إلى قدر كبير من قوة المعالجة ، مثل الألعاب والتطبيقات ، يكون WASM عادةً في أي مكان من 1.5x - 2x أسرع. لكنها قد تكون بنفس السرعة. قد يكون أيضًا أبطأ بنسبة 20٪ من JavaScript. قد يكون أيضًا أسرع بعشر مرات لبعض الوظائف. هناك معايير تُظهر كل هذه النتائج ، لذا فإن الشيء الوحيد الذي يمكن قوله بالتأكيد هو أن المسافة المقطوعة الخاصة بك ستختلف.

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

مع كل ما قيل ، لا يحتاج WASM إلى أداء مجنون ليكون ثوريًا. كل ما تحتاجه هو العمل ، وليس بطيئًا ، ودعم العديد من اللغات.

ما هي الأطر التي تعمل الآن؟

أهمها حتى الآن هو Blazor ، الذي طورته شركة Microsoft. إنه أول إطار عمل لعميل WASM يتم دعمه من قبل شركة كبرى ، ومن المحتمل أن يكون حافزًا لـ WASM للحصول أخيرًا على التبني السائد الذي يستحقه.

يبلغ عمر Blazor WASM عامًا واحدًا فقط ، حيث تم إصدار Blazor Server منذ 3 سنوات ، ولكن الشيء العظيم في Blazor هو أنه مجرد امتداد لـ ASP. NET ، وهو إطار ويب عمره 20 عامًا كانت Microsoft تعمل به باستمرار يتحسن. يمكنك استخدام العديد من مكتبات الواجهة الأمامية المكتوبة بالفعل لـ ASP. NET ، ومن المحتمل أن تكون الإطار الوحيد المدعوم من قبل مدير حزم الويب الذي ينافس NPM.

هذا ليس مشروعًا جانبيًا أيضًا ، فقد كانت Microsoft تدفع Blazor على أنه أكثر من مجرد إطار عمل ويب ؛ إنه نموذج برمجة تطبيقاتهم التالي. إنهم يعملون على Blazor Desktop ، الذي سيصدر في أواخر عام 2021 ، والذي يعمل كثيرًا كما تفعل Electron لتشغيل تطبيقات الويب Blazor نفسها على سطح المكتب. من الواضح أنهم يهتمون كثيرًا بهذا الأمر ، وهو خبر سار لـ WASM بشكل عام.

إذا كنت ترغب في معرفة المزيد ، فيمكنك قراءة أدلةنا حول ماهية Blazor وكيفية البدء في استخدامه.

إطار العمل الآخر الجاهز للإنتاج هو Yew ، المبني على Rust ، وهي لغة حديثة مشابهة لـ C ++ ، باستثناء أمان الذاكرة نظرًا للطريقة الغريبة التي يتعامل بها مع المراجع. الطقسوس سريع ، ويدعم نموذجًا قائمًا على المكونات مثل React ، ولديه إمكانية التشغيل البيني مع واجهات برمجة تطبيقات JS.

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

Vugu هو إطار عمل مكتوب بلغة Go ، ويدعم المكونات وتم تصميمه على غرار بناء جملة Vue ، لكنه لا يزال تجريبيًا. هناك أيضًا Vecty ، وهو أيضًا إطار عمل Go شائع.

مستقبل WebAssembly

ركز هذا كله على أطر عمل الويب للعميل باستخدام WASM لمعالجة DOM وبناء التطبيقات.ولكن ، يمكنك أيضًا نقل تطبيقات سطح المكتب بالكامل إلى الويب. هذا ما يفعله Uno - يستخدم WASM لتشغيل تطبيقات Universal Windows Platform (UWP) مباشرة في حاوية ويب ، والتي تأتي أيضًا مع ميزة إضافية تتمثل في كونها تعمل عبر الأنظمة الأساسية بالكامل. إنه أمر غريب بعض الشيء في الواقع مدى جودة عمل هذا ، ويشعر حقًا أنك تستخدم تطبيق Windows أصلي. يمكنك التحقق من ذلك بنفسك في معرض الصور الخاص بهم.

صورة
صورة

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

أبرز ما لم نذكره هنا هو WASI - وهي طريقة لتشغيل WebAssembly بشكل قابل للنقل على أي نظام باستخدام واجهة نظام قياسية. نظرًا لأن WASM أصبح أكثر وأكثر أداءً ، فقد يثبت WASI أنه طريقة قابلة للتطبيق لتشغيل أي نوع من التعليمات البرمجية على أي نوع من الأنظمة ، على غرار طريقة عمل Docker ولكن بدون قيود على نظام التشغيل.في الواقع ، لقد أيدها Solomon Hykes ، مبتكر Docker ، بكل إخلاص:

WebAssembly لا يتجاوز عمره بضع سنوات. لا يزال لديها متسع كبير للنمو ، ولا يزال يكتسب سرعته. ليس من غير المعقول أن تكون أطر عمل مثل Blazor و Yew بعد خمس سنوات من الآن شائعة مثل React و Angular و Vue.

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

على أي حال ، تتمتع أطر عمل الويب التي تعمل على WebAssembly بإمكانيات هائلة ، وبدعم Microsoft شخصيًا ، نحن واثقون من أنها تمثل مستقبل الويب.

موضوع شعبي