WebAssembly غادر المتصفح — ويصبح بيئة التشغيل العالمية للحافة

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

يعالج Cloudflare Workers أكثر من 50 مليون طلب في الثانية عبر 300 موقع حافة، مع Wasm كهدف تنفيذ من الدرجة الأولى إلى جانب JavaScript. منصة Compute@Edge من Fastly — المبنية بالكامل حول Wasm — تعالج حركة مرور إنتاجية لعملاء يحتاجون إلى بدء تشغيل بارد أقل من ملي ثانية لا يمكن للخوادم بدون حاويات (Serverless) القائمة على الحاويات توفيره. قواعد البيانات مثل SQLite (عبر libsqlite-wasm)، أدوات المراقبة، وأنظمة الإضافات في المحررات ومحركات الألعاب تنشر Wasm كبيئة تشغيل إضافات آمنة وقابلة للنقل. وجدت التقنية ملاءمة المنتج للسوق خارج السياق الذي صممت من أجله.

ما الذي يجعل Wasm مثيراً للاهتمام كبيئة تشغيل

ثلاث خصائص تميز WebAssembly عن البدائل مثل الحاويات، الملفات الثنائية الأصلية، أو البايت كود JVM.

قابلية النقل الثنائي. ملف .wasm هو تنسيق ثنائي مضغوط مع مجموعة تعليمات محددة جيداً. قم بالتجميع مرة واحدة من Rust أو C أو Go أو Swift أو Python أو أي لغة تدعم Wasm، وسيعمل نفس الملف الثنائي على أي مضيف لديه بيئة تشغيل متوافقة — x86، ARM، RISC-V، بغض النظر عن نظام التشغيل. هذا هو الوعد الذي قطعته JVM في التسعينيات، ولكن بدون حمل GC أو الحاجة إلى تثبيت بيئة تشغيل خاصة بالمنصة.

سرعة تنفيذ قريبة من السرعة الأصلية. تم تصميم مجموعة تعليمات Wasm للترجمة مباشرة إلى كود آلة بأقل حمل. تستخدم بيئات التشغيل الحديثة التجميع المتدرج: مترجم أساسي سريع يعالج زمن البدء البارد، ومترجم محسّن قائم على Cranelift أو LLVM يتدخل للوظائف الساخنة. تظهر نتائج القياس المعياري من Bytecode Alliance أن Wasm ينفذ ضمن 1.5–2x من الكود الأصلي المكافئ للأحمال المرتبطة بوحدة المعالجة المركزية — أفضل بكثير من اللغات المفسرة وقادر على المنافسة مع بيئات JIT.

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

WASI: القطعة المفقودة لتشغيل Wasm خارج المتصفحات

تحصل وحدة Wasm في المتصفح على واجهة النظام من JavaScript — يعرض المضيف واجهات برمجة تطبيقات للوصول إلى DOM، الشبكة، والتخزين. خارج المتصفح، لا يوجد مضيف JavaScript. هذه هي الفجوة التي صمم WASI — واجهة نظام WebAssembly — لسدها.

يحدد WASI سطح واجهة برمجة تطبيقات قائماً على القدرات للوصول إلى نظام الملفات، الساعات، توليد الأرقام العشوائية، مآخذ الشبكة، ومتغيرات البيئة. يمكن لملف Wasm ثنائي مترجم ضد WASI فتح الملفات، قراءة متغيرات البيئة، والكتابة إلى stdout باستخدام واجهة موحدة — وتقرر بيئة تشغيل المضيف عند الإنشاء أي القدرات ستمنح فعلياً. يعمل نفس الملف الثنائي على Wasmtime على خادم Linux وفي مضيف Wasm داخل المتصفح دون إعادة تجميع؛ فقط منح القدرات يختلف.

WASI Preview 2، الذي تم الانتهاء منه في عام 2024 ويشهد اعتماداً واسعاً لبيئة التشغيل خلال 2025–2026، هو التقدم الأكثر أهمية. يقدم نموذج المكونات — طريقة لتأليف وحدات Wasm متعددة بواجهات مطابقة للأنواع باستخدام لغة تعريف واجهة جديدة تسمى WIT (Wasm Interface Types). بدلاً من تمرير مؤشرات الذاكرة الخام بين الوحدات، تعرض المكونات واجهات برمجة تطبيقات مطابقة للأنواع بشدة. يمكن لمكون يعالج الصور أن يعلن أنه يقبل image: png-image ويعيد thumbnail: jpeg-image، ويمكن لبيئة تشغيل Wasm ربطه بأي مكون آخر يتحدث نفس الأنواع، بغض النظر عن اللغة التي تم تجميع كل منها منها. هذه هي القطعة التي تجعل "تجميع من Rust، استدعاء من Python" قابلاً للتأليف فعلياً بدلاً من أن يكون ممكناً نظرياً فقط.

بيئات التشغيل والمنصات

نضج نظام بيئات التشغيل بشكل كبير منذ الأيام الأولى للتجريب المقتصر على node.

Wasmtime، الذي يحتفظ به Bytecode Alliance — هيئة معايير أعضاؤها يشملون Mozilla، Fastly، Intel، Microsoft، وGoogle — هو التطبيق المرجعي لـ WASI. مكتوب بـ Rust، يستخدم مولد كود Cranelift للتجميع المحسّن. Wasmtime هو بيئة التشغيل الأساسية لـ Fastly Compute@Edge ويستخدم على نطاق واسع لتضمين Wasm في تطبيقات الخادم. CLI (wasmtime run module.wasm) يجعل اختبار الملفات الثنائية Wasm محلياً أمراً بسيطاً.

WasmEdge، مشروع CNCF Sandbox، يستهدف أحمال العمل السحابية الأصلية والذكاء الاصطناعي. لديه دعم من الدرجة الأولى لاستدلال نموذج ONNX عبر تطبيق أصلي wasi-nn، مما يجعله بيئة التشغيل المفضلة لحالات استخدام الذكاء الاصطناعي على الحافة. يتكامل WasmEdge مع containerd ويمكن استخدامه كبديل خفيف الوزن لبيئة تشغيل حاوية كاملة لأحمال عمل Wasm في مجموعات Kubernetes — نمط نشر يتجنب حمل مساحة مستخدم Linux الكاملة لكل حمل عمل.

Wasmer يتخذ نهجاً مختلفاً: يعطي الأولوية للتضمين اللغوي الأصلي، مع SDKs لـ Rust، Python، Go، Java، PHP، وRuby تتيح لك إنشاء واستدعاء وحدات Wasm من كود اللغة المضيفة بأقل قدر من الكود النمطي. Wasmer أيضاً يشحن WASIX — امتداد لـ WASI يضيف خيوطاً متوافقة مع POSIX، إنشاء عمليات، وبدائيات أنابيب، مما يمكن المزيد من البرامج الشبيهة بـ Unix من التجميع إلى Wasm بدون تعديل.

Spin، المبني من قبل Fermyon، هو إطار تطبيقات رأيي للخدمات المصغرة Wasm. حيث أن Wasmtime هو بيئة تشغيل تقوم بتضمينها، Spin هو منصة تبني عليها — حدد مكوناتك في ملف بيان spin.toml، نفذ المعالجات في Rust أو Go أو Python، ويدير Spin توجيه HTTP، تخزين المفاتيح والقيم، الوصول إلى SQL، والنشر/الاشتراك عبر واجهات برمجة تطبيقات Wasm الأصلية. يقوم Fermyon Cloud بتشغيل تطبيقات Spin مباشرة؛ يمكن للإطار أيضاً النشر على Kubernetes عبر Spin Operator.

على جانب المنصة، Cloudflare Workers كان رائداً في Wasm-at-the-edge كخدمة إنتاجية. يستخدم Workers عزل V8 مع دعم Wasm لتحقيق أوقات بدء بارد أقل من 5 ملي ثانية عالمياً — وهو رقم لا يمكن لوظائف Lambda القائمة على الحاويات الاقتراب منه. Fastly Compute@Edge يذهب أبعد من ذلك: كل مثيل Compute هو وحدة Wasm، بدون أي بيئة تشغيل JavaScript على الإطلاق، مما يتيح تنفيذ منطق معالجة الطلبات في أقل من ملي ثانية على عقد حافة Fastly.

حالات استخدام حقيقية في عام 2026

أنظمة الإضافات هي بلا شك أكثر حالات استخدام Wasm نجاحاً خارج المتصفح من حيث اتساع النشر. Extism (بواسطة Dylibso) هو نظام إضافات مفتوح المصدر مبني على Wasm: قم بتضمين مضيف Extism صغير في تطبيقك، ويمكن لأي طرف ثالث كتابة إضافات في Rust أو Go أو Python أو TypeScript تعمل في بيئة Wasm معزولة ذات قدرات معلنة. مشاريع مثل محرر Zed، WasmCloud، وعدة إضافات قواعد بيانات تستخدم هذا النمط. يحل نموذج العزل Wasm مشكلة ثقة مؤلف الإضافة التي ابتليت بها أنظمة الإضافات الأصلية لعقود.

وظائف الحافة هي النشر الأعلى حجماً. يعالج Cloudflare Workers مليارات الطلبات يومياً باستخدام وحدات Wasm التي كتبها العملاء في Rust وC++ إلى جانب Workers JavaScript. تتراوح حالات الاستخدام من مصادقة الطلبات وتوجيه A/B إلى تحويل الصور وإعادة كتابة HTML على الحافة — منطق كان سيتطلب بخلاف ذلك رحلة ذهاب وإياب إلى خادم المصدر.

استدلال الذكاء الاصطناعي على الحافة هو حالة استخدام ناشئة حيث تتقاطع قابلية نقل Wasm ودعم wasi-nn في WasmEdge. يمكن تجميع نماذج ONNX الصغيرة — مصنفات الصور، نماذج التضمين، تصنيف النص — في حزم Wasm ذاتية الاحتواء ونشرها على عقد الحافة دون إدارة تبعية لكل عقدة. يدعم WasmEdge تسريع الأجهزة عبر الخلفيات OpenVINO وTensorFlow Lite، مما يحافظ على زمن استدلال تنافسي مع النشر الأصلي للنماذج في نطاق أقل من 100 مليون معلمة.

أدوات CLI المحمولة المبنية كملفات Wasm ثنائية يتم توزيعها كملفات فردية تعمل على أي منصة تحتوي على بيئة تشغيل Wasm — بدون بنى خاصة بالمعمارية، بدون مشاكل الربط الديناميكي. مشروع wasi-vfs يسمح بحزم نظام ملفات افتراضي في الملف الثنائي، مما يمكن الأدوات التي تتصرف مثل الملفات القابلة للتنفيذ المرتبطة بشكل ثابت ولكنها تُجمع مرة واحدة من شجرة مصدر واحدة.

أين لا تزال هناك حواف خشنة

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

نضج سلسلة الأدوات يختلف بشكل كبير حسب اللغة. Rust لديه دعم ممتاز لـ Wasm — cargo build --target wasm32-wasi يعمل لمعظم الكريتات، والنظام البيئي مُختبر جيداً. تحسن إخراج Wasm في Go في Go 1.21–1.24 لكنه لا يزال ينتج ملفات ثنائية كبيرة وله دعم WASI محدود خارج الهدف التجريبي GOOS=wasip1. Python عبر CPython-wasm أو Pyodide يعمل، لكن المترجم الثنائي وحده يبلغ 20–30 ميغابايت. اللغات التي تحتوي على جامعي قمامة تضيف حملاً زائداً لوقت التشغيل — يجب تجميع GC نفسه في وحدة Wasm، وبدون كومة يديرها المضيف، تختلف أنماط استخدام الذاكرة عن النشر الأصلي.

تصحيح الأخطاء لا يزال مؤلماً. يمكن تضمين معلومات تصحيح DWARF في ملفات Wasm الثنائية، وأدوات مثل wasm-pack وأدوات المطورين في المتصفح تدعم خرائط المصدر لـ Rust وC++. لكن تصحيح الأخطاء خطوة بخطوة لوحدات Wasm في بيئة تشغيل خادم — تعيين نقاط التوقف، فحص إطارات المكدس، مراقبة الذاكرة — ليس سلساً بعد مثل تصحيح الكود الأصلي أو البايت كود JVM. التجربة تتحسن لكنها متأخرة عن سلاسل الأدوات الأصلية بعدة سنوات من الصقل.

سطح API WASI لا يزال غير مكتمل لتطبيقات الخادم العامة. الإدخال/الإخراج غير المتزامن (عبر wasi-io و wasi-http في WASI Preview 2) متاح لكن النظام البيئي للمكتبات التي تستهدفه ضعيف. المطورون الذين ينقلون كود خادم موجود إلى Wasm غالباً ما يجدون أن تبعياتهم تفترض واجهات POSIX التي إما لا يوفرها WASI أو يغلفها بقدر كافٍ من الاحتكاك لتتطلب عملاً كبيراً في النقل.

إلى أين يتجه Wasm

توحيد نموذج المكونات هو أهم تطور قصير المدى. مع انتشار اعتماد WASIp2 عبر بيئات التشغيل — Wasmtime، WasmEdge، Wasmer، وتطبيقات محرك JS في المتصفحات — تصبح القدرة على تأليف مكونات Wasm مطابقة للأنواع من أنظمة لغوية مختلفة دون احتكاك FFI أساساً حقيقياً للمنصة. الأدوات حول توليد واجهة WIT تنضج بسرعة في مشاريع cargo-component و wit-bindgen التابعة لـ Bytecode Alliance.

تقارب eBPF و Wasm هو تطور طويل الأجل يستحق المتابعة. كلتا التقنيتين تقدمان تنفيذ كود معزول داخل بيئة مضيفة — eBPF في نواة Linux، Wasm في بيئات تشغيل مساحة المستخدم. مشاريع مثل bpf-wasm تستكشف استخدام Wasm كبديل أكثر أماناً وقابلية للنقل لبرامج eBPF الأصلية للمراقبة والشبكات المجاورة للنواة. مجموعات التعليمات مختلفة، لكن الأهداف المعمارية — التنفيذ المتحكم فيه بالقدرات، المعزول، عالي الأداء للكود غير الموثوق — متطابقة.

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