WebAssembly خارج المتصفح: كيف يصبح Wasm بيئة التشغيل العالمية للسحابة والحافة

من صندوق رمل المتصفح إلى بيئة تشغيل عالمية

وُلد WebAssembly في 2017 كهدف تجميع للمتصفح — طريقة لتشغيل كود C وC++ وRust بسرعة شبه أصلية داخل تطبيقات الويب. غذّى كل شيء من أداة التصميم Figma إلى Photoshop المبني على الويب من Adobe ومحرك الألعاب Unity. لكن بحلول 2024، أصبحت التطورات الأكثر أهمية في WebAssembly لا علاقة لها بالمتصفحات إطلاقاً.

الاقتباس الذي أطلق ألف محاضرة جاء من Solomon Hykes، المؤسس المشارك لـ Docker، في مارس 2019: “If WASM+WASI existed in 2008, we wouldn’t have needed to created Docker.” بعد سبع سنوات، تحققت توقعات Hykes أسرع مما توقع معظمهم. في يناير 2024، أصدر Bytecode Alliance معيار WASI Preview 2 (WASI 0.2) مع واجهات موحدة لـ HTTP والمدخلات/المخرجات والمقابس والساعات — محولاً Wasm من فضول متصفحي إلى منصة تطبيقات حقيقية. في سبتمبر 2025، أصبح WebAssembly 3.0 المعيار الرسمي لـ W3C، مضيفاً جمع القمامة (garbage collection) وفضاء العناوين 64-بت ومعالجة الاستثناءات والذواكر المتعددة. وفي ديسمبر 2025، استحوذت Akamai على Fermyon — الشركة الناشئة وراء إطار عمل Spin — مشيرة إلى أن أكبر شبكة CDN في العالم ترى Wasm مستقبل الحوسبة الطرفية.

النظام البيئي لم يعد تجريبياً. منصة Compute من Fastly وCloudflare Workers وwasmCloud من Cosmonic (أصبح الآن مشروع حاضنة CNCF) ومشاركة Microsoft عبر Bytecode Alliance تمثل جميعها رهانات مؤسسية جادة على Wasm كبيئة تشغيل من جانب الخادم. ما يجعل هذا التحول مهماً ليس وجود بيئة تشغيل أخرى — فالعالم لا يفتقر إليها — بل أن Wasm يحل مشاكل محددة تتعامل معها الحاويات بشكل سيء: زمن التشغيل البارد والعزل متعدد المستأجرين والتنقل عبر المنصات. هذه بالضبط المشاكل الأكثر أهمية على الحافة، حيث تحدث الحوسبة على آلاف العقد الموزعة بدلاً من مراكز البيانات المركزية.

---

الحجة التقنية: لماذا يتفوق Wasm على الحاويات على الحافة

أحدثت الحاويات ثورة في النشر عبر تغليف التطبيقات مع تبعياتها في صور محمولة. لكن الحاويات تحمل عبئاً يصبح محظوراً على الحافة. صورة حاوية بحد أدنى تبلغ عشرات الميغابايت؛ وحدة Wasm لوظائف مكافئة تبلغ عادةً من عشرات الكيلوبايت إلى بضعة ميغابايت. التشغيل البارد للحاويات — بدء مثيل جديد من الصفر — يستغرق مئات الميلي ثانية إلى ثوانٍ حتى مع التحسين. التشغيل البارد لـ Wasm يُقاس بالميكروثانية: منصة Compute من Fastly تُهيئ وحدات Wasm في حوالي 35 ميكروثانية — أسرع بنحو 100 مرة من حلول serverless المنافسة. إطار عمل Spin من Fermyon يحقق تشغيلاً بارداً في حوالي 0.5 ميلي ثانية، ومنصتهم لـ Kubernetes تقدم أكثر من 1,500 تطبيق serverless لكل عقدة مع بدء تشغيل دون الميلي ثانية.

هذا الفارق في الأداء مهم لأن الحوسبة الطرفية تتعلق أساساً بزمن الاستجابة. عندما يعالج Cloudflare Worker طلباً على عقدة طرفية في Johannesburg أو Jakarta، يتوقع المستخدم استجابة في أجزاء من الميلي ثانية. تتعامل منصة Cloudflare الآن مع أكثر من 10 ملايين طلب مدعوم بـ Wasm في الثانية عبر شبكتها العالمية. منصات serverless القائمة على الحاويات مثل AWS Lambda حققت تقدماً في التشغيل البارد — Lambda SnapStart والتزامن المُجهز مسبقاً يساعدان — لكنها تحسّن حول تجريد أثقل بشكل جوهري. Wasm يبدأ بسرعة لأنه صغير ومعزول منذ ولادته ومصمم للتهيئة السريعة. لا يوجد نواة نظام للتشغيل ولا نظام init للتنفيذ ولا فضاء أسماء شبكة لتكوينه.

عزل الأمان هو الميزة الحاسمة الأخرى. كل وحدة Wasm تعمل في بيئة معزولة بدون وصول إلى النظام المضيف ما لم يُمنح صراحةً عبر أذونات قائمة على القدرات. هذا ليس أماناً مُلحقاً مثل namespaces وcgroups الحاويات — إنه مدمج في نموذج التنفيذ. للمنصات الطرفية متعددة المستأجرين — حيث يعمل كود آلاف العملاء المختلفين على نفس الآلة الفيزيائية — نموذج العزل هذا أقوى جوهرياً من البدائل القائمة على الحاويات. Cloudflare تشغل ملايين Workers على بنية تحتية مشتركة بهذا النموذج، وShopify يستخدم Wasm لعزل ملحقات منطق الأعمال للأطراف الثالثة عبر واجهة Functions API الخاصة به، محققاً مستويات كثافة مستحيلة مع الحاويات.

---

WASI ونموذج المكونات: بناء المنصة

WebAssembly الخام هو محرك حوسبة — يمكنه معالجة البيانات وإرجاع النتائج. ما لم يكن قادراً عليه حتى وقت قريب هو التفاعل مع العالم الخارجي بطريقة موحدة. WASI — واجهة نظام WebAssembly — تغير ذلك بتعريف واجهات محمولة لقدرات النظام: المدخلات/المخرجات ومقابس الشبكة وطلبات HTTP والساعات وتوليد الأرقام العشوائية ومتغيرات البيئة. WASI بالنسبة لـ Wasm هو ما POSIX بالنسبة لـ Unix: طبقة واجهة معيارية تسمح للكود بالعمل عبر تنفيذات مختلفة.

WASI 0.2، الصادر في يناير 2024، قدم نموذج المكونات (Component Model) — ربما التطور الأكثر أهمية معمارياً في نظام Wasm البيئي. يسمح نموذج المكونات لوحدات Wasm بتعريف واجهات مُنمَّطة (باستخدام لغة تسمى WIT — WebAssembly Interface Type) والتركيب معاً كوحدات بناء. مكون مكتوب بـ Rust يمكنه كشف واجهة يستهلكها مكون مكتوب بـ Python، مع قيام بيئة التشغيل بتحويل البيانات تلقائياً. هذه قابلية تشغيل متبادل حقيقية بين اللغات — ليس عبر خدع FFI أو طبقات تسلسل، بل عبر نظام أنماط مشترك عند حدود الوحدات.

التداعيات على معمارية البرمجيات عميقة. بدلاً من التطبيقات الأحادية أو الخدمات المصغرة التي تتواصل عبر HTTP، يتيح نموذج المكونات ما يسميه البعض “الخدمات النانوية” — مكونات وظيفية دقيقة تتركب داخل عملية تشغيل واحدة. Spin من Fermyon (الآن جزء من Akamai) وwasmCloud وبيئة التشغيل مفتوحة المصدر Wasmtime تدعم جميعها تركيب المكونات. مشاركة Microsoft عبر Bytecode Alliance — التي تقود مواصفات WASI والتنفيذات المرجعية — تشير إلى أن هذه ليست تجربة هامشية.

خارطة الطريق واضحة: WASI 0.3، المستهدف لأوائل 2026، يضيف دعم async أصلي عبر أنماط صريحة stream وfuture، مما يمكّن أي دالة مكون من الاستدعاء بشكل غير متزامن. معاينات متاحة بالفعل في Wasmtime 37+. بعد ذلك، WASI 1.0 — الإصدار المستقر بدون تغييرات كاسرة — مخطط لنهاية 2026 أو أوائل 2027. عند صدوره، سيمتلك Wasm واجهة نظام ناضجة وموحدة مماثلة في النطاق لما قدمه POSIX لـ Unix.

---

النظام البيئي في 2026: من يراهن على Wasm

نضج النظام البيئي لـ WebAssembly من جانب الخادم بسرعة، وشهد 2025 نقطة تحول مع توحيد كبير. Fermyon، التي أسسها مهندسون سابقون في Microsoft Azure، بنت إطار عمل Spin وFermyon Cloud — منصة serverless مصممة خصيصاً لـ Wasm. رهانهم كان أن Wasm سيحل محل الحاويات لفئة كبيرة من التطبيقات: واجهات API الخلفية ومعالجات الأحداث ومعالجات webhooks حيث تهم سرعة البدء والكثافة أكثر من إنتاجية الحوسبة الخام. جمعت Fermyon 26 مليون دولار إجمالاً (6 ملايين seed بالإضافة إلى 20 مليون Series A) قبل استحواذ Akamai Technologies عليها في ديسمبر 2025. يضع الاستحواذ Akamai — أكبر CDN في العالم — للتنافس مباشرة مع Cloudflare Workers باستخدام حوسبة طرفية قائمة على Wasm، ويصادق على الجدوى التجارية لـ Wasm من جانب الخادم.

أعادت Fastly بناء منصة الحوسبة الطرفية حول Wasm، مغيرة اسمها من Compute@Edge إلى ببساطة Fastly Compute. كل طلب يعالجه CDN Fastly يمكن أن يطلق منطق قائم على Wasm، والمنصة تدعم Rust وJavaScript وGo ولغات أخرى مُجمعة إلى Wasm. Cloudflare Workers، رغم اعتماده أصلاً على معزولات V8، تبنى Wasm بشكل متزايد — خاصة لأحمال العمل المكثفة حسابياً حيث أداء JavaScript غير كافٍ. Shopify يستخدم Wasm لواجهة Functions API الخاصة به، مشغلاً ملحقات منطق أعمال الأطراف الثالثة بأمان عبر بيئة تشغيل معزولة تدعم Rust وAssemblyScript وTinyGo وJavaScript (عبر Javy، سلسلة أدوات JS-إلى-Wasm الخاصة بـ Shopify). Adobe يستخدم Wasm عبر Emscripten لنقل تطبيقات C/C++ الأصلية مثل Photoshop وLightroom إلى متصفحات الويب.

wasmCloud من Cosmonic — منصة تنسيق أصلية لـ Wasm — انتقل إلى حالة حاضنة CNCF في نوفمبر 2024، وأطلقت Cosmonic منصة Cosmonic Control في مارس 2025 لإدارة التطبيقات الموزعة على مستوى المؤسسات. على جانب Kubernetes، أصبح SpinKube مشروع sandbox CNCF، وأوقفت Azure Kubernetes Service من Microsoft حُزم عقد WASI التجريبية في مايو 2025 لصالح SpinKube كمسار موصى به لتشغيل أحمال Wasm على Kubernetes.

نظام الحاويات البيئي يستجيب. Docker Desktop يدعم الآن أحمال Wasm أصلياً، مما يسمح للمطورين بتشغيل وحدات Wasm جنباً إلى جنب مع حاويات Linux التقليدية من نفس ملف docker-compose.yml، باستخدام بيئات تشغيل مثل Spin وWasmEdge وWasmtime عبر شيم containerd. أظهر معيار 2025 أن تطبيقات Wasm تحقق بصمة ذاكرة أقل بنسبة تصل إلى 40% مقارنة بالحاويات التقليدية. يقترح مسار التكامل هذا أن Wasm لن يحل محل الحاويات بالجملة بل سيكملها — يتعامل مع الأحمال الخفيفة والحساسة لزمن الاستجابة حيث الحاويات مبالغ فيها، بينما تستمر الحاويات في خدمة التطبيقات ذات الحالة طويلة الأمد. إطار “Wasm مقابل الحاويات” يتحول إلى “Wasm والحاويات”، مع اختيار بيئة التشغيل بناءً على خصائص الحمل بدلاً من الأيديولوجيا.

---

ما لا يستطيع Wasm فعله (بعد)

رغم كل مزاياه، يملك WebAssembly خارج المتصفح قيوداً حقيقية تخفف الحماس. دعم المسالك (threading) لا يزال غير مكتمل — مقترح مسالك Wasm مُنفذ في بعض بيئات التشغيل لكن ليس عالمياً، مما يحد من أحمال العمل المتوازية المكثفة حسابياً. دعم لغات جمع القمامة تحسن بشكل كبير مع توحيد WasmGC في Wasm 3.0 وشحنه في جميع المتصفحات الرئيسية. Java وKotlin وDart وOCaml وScala يمكنها استهداف WasmGC، وGoogle Sheets نقلت محرك الحساب إلى WasmGC في الإنتاج. مع ذلك، لم تنفذ Go بعد دعم WasmGC، وتشغيل أطر عمل Java المؤسسية الكاملة كـ Wasm يبقى أقل نضجاً من أهداف التجميع الأصلية. النظام البيئي للمكتبات والأطر يتنامى لكنه لا يزال جزءاً مما هو متاح للحاويات — مطور Wasm لا يمكنه ببساطة سحب صورة Docker مع PostgreSQL وRedis وتشغيل حزمة كاملة.

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

إدارة الحالة تحدٍ آخر. وحدات Wasm مصممة لتكون عديمة الحالة وسريعة الزوال — بدء ومعالجة واستجابة وإنهاء. التطبيقات التي تحتاج اتصالات دائمة أو ذاكرة تخزين مؤقت أو عمليات طويلة الأمد لا تتناسب جيداً مع نموذج Wasm. قابلية تركيب نموذج المكونات تساعد بالسماح لمكونات ذات حالة أن تُقدم من بيئة التشغيل المضيفة، لكن هذا النمط يتطلب إعادة تفكير في معمارية التطبيقات بطرق لم تستعد لها معظم فرق التطوير بعد. دعم async الأصلي في WASI 0.3، المتوقع أوائل 2026، يجب أن يخفف بعض هذه القيود بتمكين المكونات من التعامل مع عمليات الإدخال/الإخراج المتزامنة دون حظر — لكن الحالة الحقيقية تبقى تحدي تصميم وليس قيد بيئة تشغيل.

---

---

المصادر والقراءات الإضافية

• Solomon Hykes on WASM+WASI — X (formerly Twitter)
• Wasm 3.0 Completed — WebAssembly.org
• Akamai Acquires Fermyon — Akamai Newsroom
• WASI 0.2 Launched — Bytecode Alliance
• The WebAssembly Component Model — Bytecode Alliance
• Fastly Compute Platform — Fastly
• Cloudflare Workers and WebAssembly — Cloudflare
• Fermyon Spin Framework — Fermyon
• SpinKube: Wasm on Kubernetes — SpinKube
• CNCF Welcomes wasmCloud to Incubator — CNCF
• Docker Wasm Workloads — Docker Docs
• WASI Roadmap — WASI.dev