أُطلقت WebAssembly، المختصرة عالميًا بـWasm، لأول مرة عام 2017 كجهد مشترك بين مزودي المتصفحات الرئيسيين لحل مشكلة محددة وطويلة الأمد: لم تُصمم JavaScript، رغم انتشارها الواسع، لتكون هدف تصريف عالي الأداء، وكانت تطبيقات الويب ذات المتطلبات الحسابية المكثفة - تحرير الفيديو، التصيير ثلاثي الأبعاد، المحاكاة العلمية، الألعاب - تصطدم بشكل روتيني بسقف أداء لم يستطع أي قدر من تحسين محرك JavaScript التغلب عليه بالكامل. حلّت WebAssembly هذا بتعريف تنسيق تعليمات ثنائي مضغوط يعمل بسرعة شبه أصلية داخل بيئة تنفيذ محصورة، ويمكن التصريف إليه من لغات مثل C وC++ وRust.
ما بدأ كتقنية أداء متصفح ضيقة النطاق توسع منذ ذلك الحين إلى شيء أكثر أهمية بكثير: بدائية حوسبة محمولة وآمنة الذاكرة ومحايدة اللغة تُزيح بشكل متزايد الحاويات والأجهزة الافتراضية لنطاق متوسع من حالات الاستخدام خارج المتصفح تمامًا، من الدوال اللاخادمية إلى أنظمة الإضافات إلى بيئات تشغيل الحوسبة الطرفية. يتطلب فهم سبب خروج WebAssembly من سياقها الأصلي في المتصفح فهم الخصائص المحددة - الأمان والمحمولية وأداء بدء التشغيل - التي تجعلها ملائمة بشكل فريد لمشكلات تحلها الحاويات والأجهزة الافتراضية التقليدية جزئيًا فقط، وهي الخصائص التي يستعرضها هذا المقال بالتفصيل قبل الانتقال إلى حالات الاستخدام العملية والقيود الحالية التي لا تزال تواجه هذه التقنية سريعة التطور.
يُبنى نموذج أمان WebAssembly حول بيئة تنفيذ محصورة بلا وصول افتراضي لأي قدرة خارج ما يُمنح صراحة - لا وصول لنظام الملفات، لا وصول للشبكة، لا قدرة على إجراء استدعاءات نظام تعسفية - على عكس صارخ للكود الأصلي التقليدي، الذي يمتلك افتراضيًا كامل صلاحيات العملية التي تشغّله. نموذج الأمان القائم على القدرات هذا، حيث لا تستطيع وحدة Wasm فعل سوى ما مُنحت الإذن الصريح لفعله، يجعل WebAssembly صندوقًا محصورًا قويًا بشكل غير عادي لتشغيل كود طرف ثالث غير موثوق أو شبه موثوق.
المحمولية هي الخاصية الثانية المُحدِّدة لـWebAssembly. يمكن لملف Wasm ثنائي واحد مُصرَّف العمل بشكل متطابق عبر أي بيئة بها بيئة تشغيل متوافقة - أنظمة تشغيل مختلفة، معماريات معالج مختلفة، بيئات المتصفح وغير المتصفح على حد سواء - دون إعادة تصريف، وهو ضمان محمولية أقوى بكثير مما توفره الحاويات، إذ لا تزال الحاوية تعتمد في النهاية على نواة نظام التشغيل الأساسي ومعمارية المعالج المطابقة لما بُنيت له صورة الحاوية.
أداء بدء التشغيل هو الخاصية الثالثة التي دفعت تبني WebAssembly إلى ما هو أبعد بكثير من المتصفح. يستغرق التطبيق المُحوسَب عادة مئات المللي ثواني إلى عدة ثوانٍ للبدء البارد، إذ يجب على بيئة تشغيل الحاوية تهيئة عملية على مستوى نظام التشغيل بعرض نظام ملفات ومساحة اسم شبكة خاصين بها. أما وحدة WebAssembly، فيمكنها عادة البدء البارد خلال مللي ثوانٍ أحادية الرقم، لأنها لا تحمل عبء طبقة نظام تشغيل ضيف كامل.
وسّعت واجهة نظام WebAssembly، المعروفة بـWASI، مدى WebAssembly بشكل حاسم إلى ما وراء المتصفح بتعريف مجموعة موحدة قائمة على القدرات من واجهات النظام - الوصول لنظام الملفات، الشبكات، الوصول للساعة - يمكن منح وحدة Wasm الوصول إليها عند تشغيلها في بيئة مضيف غير متصفح، مما يتيح لـWebAssembly العمل كبيئة تشغيل تطبيقات عامة الغرض حقيقية بدلاً من أن تكون محصورة بشكل دائم في نموذج عدم الوصول للنظام. مكّن هذا فئة كاملة من بيئات تشغيل WebAssembly من جانب الخادم، بما في ذلك Wasmtime وWasmer وWasmEdge، تُنفذ وحدات Wasm كتطبيقات مستقلة خارج أي سياق متصفح تمامًا، مُشكّلة الأساس التقني لفئة ناشئة من بيئات تشغيل التطبيقات الأصيلة طرفيًا تجمع بين محمولية WebAssembly وسرعة بدء تشغيلها ووصول WASI الموحد لواجهات النظام في بيئات نشر تتراوح من بوابات إنترنت الأشياء إلى أحمال عمل Wasm المُنسَّقة عبر Kubernetes تعمل جنبًا إلى جنب مع الحاويات التقليدية.
كانت منصات الحوسبة اللاخادمية متبنية عدوانية بشكل خاص لـWebAssembly تحديدًا بسبب ميزة أداء بدء التشغيل. تُشغّل كل من Cloudflare Workers وFastly Compute كود العميل كوحدات WebAssembly بدلاً من الحاويات التقليدية، مما يتيح لهذه المنصات بدء تشغيل بيئات تنفيذ معزولة للطلبات الواردة في جزء من الألف من الثانية بدلاً من مئات المللي ثواني التي يتطلبها عادة بدء بارد قائم على الحاويات، وهو فرق يصبح حاسمًا عند النطاق وأنماط الطلبات التي تعمل عندها منصات الحوسبة الطرفية هذه، حيث قد تحتاج دالة لمعالجة طلب واحد فقط ثم الإنهاء بدلاً من البقاء نشطة عبر طلبات عديدة كما تفعل خدمة مُحوسَبة نموذجية.
تمثّل عمارات الإضافات حالة استخدام أخرى سريعة النمو. تستخدم تطبيقات تتراوح من أنظمة قواعد البيانات إلى منصات إدارة المحتوى WebAssembly بشكل متزايد كبيئة تنفيذ للإضافات والامتدادات التي يوفرها المستخدم، تحديدًا لأن الحصر القائم على القدرات في Wasm يتيح لتطبيق مضيف تنفيذ كود طرف ثالث بأمان دون منحه وصولاً لنظام ملفات المضيف أو شبكته أو ذاكرته إلا بما هو مسموح صراحة - نموذج أكثر أمانًا بشكل هائل من النهج التقليدي لتحميل مكتبة مشتركة أصلية، التي تعمل بكامل صلاحيات عملية المضيف ويمكنها الوصول أو إفساد أي شيء يمكن لتلك العملية الوصول إليه. تقاربت شركات قواعد البيانات ومزودو بوابات API وأنظمة إدارة المحتوى جميعها على أنظمة إضافات قائمة على Wasm لهذا السبب تحديدًا.
كان أحد القيود الكبيرة لـWebAssembly المبكرة اقتصارها على أنواع عددية بسيطة عند حدود الوحدة - كان تمرير سلسلة نصية أو بنية بيانات معقدة بين وحدة Wasm ومضيفها يتطلب ترميزًا يدويًا عرضة للخطأ في مخازن ذاكرة خام. يعالج نموذج مكونات WebAssembly، الذي طوّره تحالف Bytecode Alliance على مدى عدة سنوات، هذا بتعريف تنسيق وصف واجهة موحد وعالي المستوى يتيح لوحدات Wasm المكتوبة بلغات مصدر مختلفة تمامًا - Rust وPython وGo وC++ - التواصل مع بعضها ومع تطبيق مضيف باستخدام أنواع غنية مثل السلاسل النصية والسجلات والمتغيرات، دون أن يحتاج أي طرف لمعرفة اللغة التي كُتب بها الطرف الآخر.
لهذا التشغيل البيني تداعيات مهمة على كيفية تفكير المؤسسات في تركيب البرمجيات متعددة اللغات. بدلاً من كتابة تطبيق بالكامل بلغة واحدة، أو تحمّل العبء التشغيلي لتشغيل بيئة تشغيل كل لغة كخدمة مصغرة مُشبَّكة منفصلة، يتيح نموذج المكونات لأجزاء مختلفة من نظام ما - ربما كتبتها فرق مختلفة تمامًا بلغات مختلفة تمامًا - أن تُركَّب معًا كمكونات Wasm تستدعي بعضها مباشرة داخل العملية، مع ضمانات أمان صندوق Wasm المحصور لكن دون كمون الشبكة وعبء التسلسل الخاصين بعمارة الخدمات المصغرة. يضع هذا نموذج المكونات كأرضية وسطى محتملة بين الترابط الوثيق لكتلة أحادية تقليدية والعبء التشغيلي لعمارة خدمات مصغرة مُشبَّكة بالكامل، مُقدِّمًا قابلية تركيب على مستوى اللغة دون التضحية بفوائد عزل النشر التي حفّزت التحول نحو الخدمات المصغرة أصلاً.
WebAssembly ليست بلا قيود ذات معنى يجب على فرق الهندسة وزنها بصدق قبل تبنيها لحالة استخدام معينة. تاريخيًا، كانت اللغات ذات جامع القمامة مثل Python وJava وJavaScript نفسها تُصرَّف إلى WebAssembly بصعوبة فقط، وتتطلب عادة تضمين بيئة تشغيل اللغة بأكملها وجامع القمامة داخل الملف الثنائي Wasm نفسه، مما ينتج أحجام وحدات أكبر بكثير وأداء أقل مقارنة باللغات المُصرَّفة أصليًا مثل Rust وC++. يعمل اقتراح جمع قمامة WebAssembly، المُطبَّق الآن في عدة بيئات تشغيل رئيسية، على سد هذه الفجوة تدريجيًا بالسماح لوحدات Wasm بالتفاعل مع جامع قمامة أصلي للمضيف بدلاً من تضمين جامعها الخاص، رغم أن نظام الأدوات الناضج والمُختبَر إنتاجيًا للغات ذات جامع القمامة المستهدفة لـWasm لا يزال متأخرًا بشكل ذي معنى عن الأدوات المتاحة لـRust وC++.
يظل دعم تعدد الخيوط، رغم وجوده عبر اقتراح خيوط WebAssembly المبني على الذاكرة المشتركة والعمليات الذرية، أقل نضجًا وأكثر تقييدًا من نماذج الخيوط الأصلية، وأدوات تصحيح الأخطاء لـWebAssembly، رغم تحسّنها المطرد، لا تزال متأخرة كثيرًا عن أنظمة تصحيح الأخطاء الناضجة العريقة المتاحة للكود الأصلي، مما يجعل فئات معينة من الأخطاء المعقدة والصعبة التكرار أكثر استهلاكًا للوقت بشكل ذي معنى في التشخيص ضمن وحدة Wasm مقارنة بالكود الأصلي المكافئ.
يقدّم تبني Figma لـWebAssembly مثالاً مبكرًا يوضح مكاسب الأداء المُعرَّضة للخطر. كان محرك تصيير التصميم الأساسي في Figma مكتوبًا أصلاً بلغة C++ وكان يحتاج للعمل داخل متصفح ويب لتشغيل أداة التصميم التعاونية القائمة على المتصفح، وهو مزيج سبق التوفر العام لـWebAssembly وتطلب حلولاً بديلة أكثر تقييدًا بكثير. بمجرد نضج WebAssembly، أعادت Figma تصريف محرك C++ القائم لديها إلى Wasm بدلاً من إعادة كتابته بـJavaScript، وأبلغت عن تحسينات في وقت التحميل بمقدار ثلاث مرات تقريبًا مقارنة بنهجها السابق، إذ يمكن تحليل وحدة Wasm المُصرَّفة وإنشاء نسخة منها بشكل أسرع بكثير من الوظيفة المكافئة المُعبَّر عنها بـJavaScript.
تُذكر الحالة كثيرًا لأنها تُظهر نمطًا تكرر عبر عمليات تبني WebAssembly اللاحقة العديدة: بدلاً من كونها تقنية تتطلب إعادة كتابة تطبيق من الصفر، غالبًا ما تُقدّم WebAssembly قيمتها بالسماح لقاعدة كود أصلية قائمة ومُختبَرة بشدة في المؤسسة بإعادة التصريف لبيئة هدف جديدة، محافظة على سنوات من الهندسة المتراكمة للصحة والأداء بدلاً من التخلي عنها لصالح إعادة تنفيذ من الصفر بلغة أصلية للمتصفح.
يوضح مسار WebAssembly من تقنية أداء متصفح ضيقة إلى بدائية حوسبة عامة الغرض ومحمولة وآمنة كيف يمكن أن ينتهي التأثير الأهم طويل المدى لتقنية ما إلى أن يكون مختلفًا تمامًا عن نيّة تصميمها الأصلية الأضيق. جعل مزيجها من الأمان المحصور القوي والمحمولية الحقيقية عبر المنصات وأداء بدء التشغيل شبه الفوري أساسًا مقنعًا للحوسبة اللاخادمية وعمارات الإضافات والنشر الطرفي - مجالات لا علاقة لها كثيرًا بتصيير صفحات الويب، المشكلة التي بُنيت WebAssembly أصلاً لحلها. مع نضج نموذج المكونات وتحسّن دعم اللغات ذات جامع القمامة، تحتل WebAssembly موقعًا جيدًا لتصبح خيارًا افتراضيًا لنطاق أوسع بكثير من سيناريوهات الحوسبة حيث يهم الأمان والمحمولية وسرعة بدء التشغيل جميعها في آن واحد - مسار يعكس كيف وجدت كثير من التقنيات التأسيسية في تاريخ الحوسبة تطبيقها الأهم في مكان مختلف تمامًا عما تُصوِّر له أصلاً.
