WebAssembly هرب من المتصفح. والآن يعمل داخل Shopify وCloudflare وعنقود Kubernetes الخاص بك.

انطلق WebAssembly في عام 2017 كحل لمشكلة في المتصفح: كان JavaScript بطيئاً جداً للشفرة الحساسة للأداء، وكانت الإضافات الأصلية خطيرة للغاية. كانت الإجابة تنسيقاً ثنائياً مضغوطاً يمكنه تشغيل شفرة قريبة من الأداء الأصلي داخل بيئة متصفح معزولة — بأمان وقابلية نقل وسرعة. نجح الأمر. انتقلت محررات الفيديو وأدوات CAD والمحاكاة العلمية إلى الويب. وتضاعف أداء Figma ثلاث مرات عند نقل محرك العرض الخاص بها إلى C++ مُجمَّع إلى WASM.

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

نموذج المكونات: القطعة المفقودة التي وصلت

كان لدى مواصفات WebAssembly الأصلية قيد أساسي للاستخدام على مستوى الخوادم: وحدتان من WASM مُجمَّعتان من لغتين مختلفتين لا يمكنهما استدعاء بعضهما البعض بدون شفرة ربط يدوية لإدارة الذاكرة عرضة للخطأ. مكتبة Rust وخدمة Go كانتا تعيشان في مساحات ذاكرة منفصلة ولا تملكان نظام أنواع مشتركاً. هذا جعل معماريات البوليجلوت القابلة للتركيب غير عملية.

نموذج مكونات WebAssembly، الذي استقر في عام 2025، يحل هذه المشكلة بواجهة ثنائية مشتركة للتطبيق ولغة وصف واجهات مستقلة عن لغة البرمجة تُسمى WIT (WebAssembly Interface Types). declares ملف WIT ما تصدره أو تستورده المكون من دوال وأنواع بيانات، دون افتراضات ذاكرة خاصة بلغة معينة. تقوم سلسلة الأدوات — wit-bindgen وwasm-tools وjco — بتوليد شفرة التكامل تلقائياً. والنتيجة العملية: محلل Rust عالي الأداء، وخط أنابيب Python للتعلم الآلي، وواجهة أمامية TypeScript يمكن أن تتكوّن كمكونات WASM بدون FFI مكتوب يدوياً. صودق على WASM 3.0 كمعيار W3C في سبتمبر 2025، مدمجاً جمع القمامة، والذاكرة 64-بت، وrelaxed SIMD، ومعالجة الاستثناءات إلى جانب نموذج المكونات.

WASI: طبقة الواجهة التي تجعل قابلية النقل حقيقة

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

WASI 0.2، الذي أُصدر في يناير 2024، ثبّت خط الأساس المستقر للإنتاج — إدخال وإخراج الملفات، ومقابس الشبكة، والتكامل مع نموذج المكونات. WASI 0.3، الذي يضيف دعماً أصلياً للتزامن غير المتزامن مع أنواع مجردة من التدفقات والمستقبلات، كان يُنهي أعمال المواصفات في أوائل 2026. الإصدار 1.0 — أول إصدار "مستقر إلى الأبد" — مُتوقع في أواخر 2026 أو أوائل 2027. المسار يمنح مؤلفي المكتبات ABI مستهدفاً مستقراً والمشغلين خارطة طريق واضحة لما ستغطيه ضمانات قابلية النقل في النهاية.

أين توجد عمليات النشر الإنتاجية بالفعل

أوضح دليل على النطاق الكبير هو Shopify Functions. منذ عام 2022، أتاحت Shopify لمطوري الطرف الثالث تخصيص منطق الدفع والخصومات والشحن من خلال نشر وحدات WASM تعمل داخل بيئة تشغيل مبنية خصيصاً في بنية Shopify التحتية. كل وحدة تُنفَّذ ضمن ميزانية صارمة قدرها 5 ميلي ثوانٍ؛ ومقاييس الكمون الفعلية تتراوح عادةً بين 0.8 و2.5 ميلي ثانية. يكتب المطورون بلغة Rust أو JavaScript (عبر مترجم Javy من Shopify، الذي يدمج محرك V8 مجرّداً في ثنائي WASM) أو Zig أو TinyGo. حد الأمان مهم: شفرة التاجر غير الموثوقة تعمل في بيئة إنتاج بحجم Shopify دون الوصول إلى موارد النظام المضيف. لم يحدث أي اختراق للعزل. وحتى يونيو 2026، أُحيل نظام Scripts القديم الذي استبدلته Functions إلى التقاعد بالكامل.

على صعيد الحوسبة الطرفية، تُعد Compute@Edge من Fastly بيئة تنفيذ WASM خالصة توفر بدايات باردة بالميكروثانية لمعالجة الطلبات عند حافة الشبكة. تدعم Cloudflare Workers وحدات WASM وأضافت دعماً للحاويات في يونيو 2025 لأحمال العمل الهجينة. جاءت أهم إشارة صناعية في أواخر 2025 عندما استحوذت Akamai على Fermyon — الشركة وراء إطار Spin للخدمات المصغرة الخالية من الخادم على WASM — وأتاحت Fermyon Wasm Functions للاستخدام العام على حافة Akamai الموزعة عالمياً في نوفمبر 2025. عندما تستحوذ أكبر شبكة توصيل محتوى في العالم على شركة WASM للخدمات الخالية من الخادم، فإن الرهان على مستقبل هذه التكنولوجيا يصبح مؤسسياً وليس تجريبياً.

مشهد بيئات التشغيل

أربع بيئات تشغيل تهيمن لحالات استخدام مختلفة. Wasmtime، التطبيق المرجعي من Bytecode Alliance، حصل على حالة Core Project في أبريل 2025 ويحقق حوالي 82% من الأداء الأصلي في معايير الحوسبة. وهو الخيار الافتراضي لـ WASM على الخوادم للأغراض العامة. Wasmer 6.0، الذي أُصدر في أبريل 2025، يدعي أداءً بنسبة 95% من الأداء الأصلي وقدّم Edge.js، الذي يُشغّل تطبيقات Node.js داخل عزل WASM — جسر مثير للاهتمام للفرق التي تملك بنية تحتية قائمة على Node. يستهدف WAMR (WebAssembly Micro Runtime) الأجهزة المدمجة وإنترنت الأشياء، ويعمل على أجهزة بذاكرة تصل إلى 256 كيلوبايت فقط بأداء يتراوح بين 80 و90% من الأداء الأصلي مع تجميع AOT. WasmEdge مُحسَّن لأعباء عمل الذكاء الاصطناعي ويتكامل مع Docker Engine كغلاف حاويات إلى جانب Wasmtime.

صياغة Docker مقصودة: "WASM والحاويات" وليس "WASM مقابل الحاويات". يُصدر Docker Engine أغلفة أصلية لـ Wasmtime وWasmEdge، بحيث يمكن نشر وحدات WASM باستخدام أوامر docker run القياسية من Dockerfile فارغ. سلسلة الأدوات تتقارب بدلاً من التنافس. SpinKube، مشروع CNCF مبني على إطار Spin من Fermyon، يجعل WASM نوع عبء عمل من الدرجة الأولى في Kubernetes — قابلاً للنشر بجانب وحدات الحاويات بنفس بدئات التنسيق.

حجة الأمان

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

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

صورة الأداء الصادقة

WASM على بيئات تشغيل الخوادم يعمل بسرعة تقارب 75 إلى 95% من السرعة الأصلية في أعباء العمل الكثيفة حسابياً — أرقام ذات مصداقية لمعظم حالات الاستخدام، مع تحفظات. العمليات التي تتضمن أعداداً صحيحة 128-بت وبعض البنيات الأولية للتشفير أبطأ بمرتين إلى 7 مرات من الأداء الأصلي. أعباء العمل المقيدة بالإدخال والإخراج لا ترى فائدة ذات معنى؛ فالميزة في الحوسبة. البدايات الباردة تتراوح بين 1 و5 ميلي ثوانٍ، مقارنةً بـ 50 إلى 500 ميلي ثانية للحاويات — وهذا هو الرقم الذي يجعل WASM مقنعاً لعمليات النشر الخالية من الخادم والطرفية حيث يؤثر كمون البداية الباردة مباشرةً على تجربة المستخدم.

وقت التطويل أطول فعلياً. البناء بلغة Rust لـ WASM يتطلب فهماً لإدارة الذاكرة وسير عمل تصحيح مختلف عما يعتاده معظم مطوري الويب. نموذج المكونات وسلسلة أدوات WASI تحسنا بشكل كبير لكن التصحيح عبر حدود اللغة لا يزال أصعب من التصحيح داخل بنية لغة واحدة. النظام البيئي تقريباً حيث كان JavaScript في سنوات Node.js المبكرة: قوي ومنتج ويتطلب استثماراً لاستخدامه بشكل جيد.

سؤال "هل يجب أن أستخدم WASM بدلاً من الحاويات؟" له إجابة أنظف في 2026 مما كانت عليه قبل عامين: استخدم WASM عندما يهم كمون البداية الباردة (الحوسبة الطرفية والخدمات الخالية من الخادم)، وعندما تحتاج إلى تنفيذ معزول لشفرة غير موثوقة، أو عندما تريد تركيب مكونات مستقل عن اللغة. استخدم الحاويات عندما تحتاج إلى بيئة Linux كاملة، وتوافق واسع مع المكتبات، أو وصول إلى GPU. استخدم كليهما عندما يكون لحمل العمل طبقات تستفيد من كل منهما — وهو ما صُممت أدوات البنية التحتية لدعمه بشكل متزايد.