ويباسمبلي هرب من المتصفح. في 2026، أصبح بهدوء بيئة التشغيل لكل شيء

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

ما لم يتوقعه أحد تمامًا هو أن الاستخدامات الأكثر أهمية لـ WebAssembly ستحدث خارج المتصفح بالكامل.

كيف هرب WASM من الصندوق الرملي

التطور الرئيسي كان WASI — واجهة نظام WebAssembly، التي اقترحها Bytecode Alliance في عام 2019 ووصلت إلى مواصفات مستقرة 2.0 في عام 2024. أعطى WASI لوحدات WebAssembly واجهة موحدة للتفاعل مع النظام المضيف: قراءة الملفات، إنشاء اتصالات الشبكة، الوصول إلى متغيرات البيئة. يبدو هذا عاديًا، لكن له تأثير عميق: وحدة WASM المترجمة بدعم WASI يمكن تشغيلها في أي مكان يوجد فيه WASI runtime — ليس فقط في متصفح، بل على خادم، على الحافة، على جهاز IoT، في محرك قاعدة بيانات.

صاغ سليمان هايكس، مبتكر Docker، الأهمية بوضوح في منشور أصبح مقتبسًا على نطاق واسع: "إذا كان WASM+WASI موجودًا في 2008، لما كنا بحاجة لإنشاء Docker. هذا يوضح مدى أهميته." الوعد كان بثنائي محمول عالمي — ترجمة مرة واحدة، تشغيل في كل مكان، مع صندوق رملي أمني مدمج.

أين يعمل WASM في عام 2026

Edge computing والوظائف بدون خادم. Cloudflare Workers يدعم WASM منذ 2018، لكن في 2026 هو بيئة التشغيل الأساسية لوظائف الحافة الحساسة للأداء. Fastly Compute، Fermyon Spin، وWasmer Edge جميعهم يشغلون أعباء عمل WASM على عقد الحافة الموزعة عالميًا. الجاذبية هي مزيج من وقت بدء التشغيل (بدء بارد أقل من ملي ثانية، مقابل 50–200 مللي ثانية لوظيفة Node.js)، العزل الأمني (كل وحدة تعمل في صندوق رملي خاص بها مع أذونات واضحة)، وقابلية النقل (نشر نفس الثنائي لدى أي مزود).

قابلية توسعة قاعدة البيانات. SingleStore، DuckDB، والعديد من قواعد البيانات الأخرى تدعم الآن وظائف معرفة من قبل المستخدم مكتوبة كوحدات WASM، مما يسمح بتنفيذ منطق مخصص داخل محرك الاستعلام مع الوصول إلى العمليات الموجهة وبدون تحميل زائد للذهاب والإياب إلى عملية خارجية. دعم WASM UDF في PostgreSQL، الذي استقر في 2025، فتح هذه الإمكانية لقاعدة البيانات مفتوحة المصدر الأكثر انتشارًا في العالم.

أنظمة الإضافات. Zed (محرر الكود)، Extism (إطار عمل إضافات تستخدمه عشرات التطبيقات)، وعدد متزايد من أدوات المطورين يستخدمون WASM كبيئة تشغيل للإضافات. الميزة على أنظمة الإضافات الأصلية التقليدية هي العزل: إضافة سيئة السلوك لا يمكنها تعطيل العملية المضيفة أو الوصول إلى موارد خارج أذوناتها. هذا هو النموذج الذي تستخدمه Shopify لملحقات التطبيقات المخصصة وFigma لنظام الإضافات الخاص بها.

أدوات CLI محمولة. نموذج مكون WASM (الموحد في 2024) مكن التكوين: يمكنك بناء أداة CLI كمجموعة من مكونات WASM التي تستورد وتصدر واجهات محددة الأنواع، ثم دمجها بغض النظر عن اللغة التي كتبت بها أصلاً. مكون Rust يمكنه استدعاء واجهة مكون Python دون أن يعرف أي منهما لغة تنفيذ الآخر. هذا يتيح جيلًا جديدًا من الأدوات المستقلة عن اللغة.

نموذج المكون يغير الحسابات

نموذج مكون WASM يستحق اهتمامًا خاصًا لأنه يحل مشكلة ابتليت بها البرامج متعددة اللغات لعقود. سابقًا، إذا أردت استدعاء مكتبة مكتوبة بـ Rust من Python، كان عليك التعامل مع FFI، الذاكرة المشتركة، تحميل التسلسل، أو استدعاءات العمليات الفرعية. نموذج المكون يستبدل كل هذا بلغة تعريف واجهة آمنة الأنواع ومستقلة عن اللغة (WIT — WebAssembly Interface Types) يمكن لمترجمات Rust، Python، JavaScript، Go، C، وغيرها استهدافها.

النتيجة هي أن المطور يمكنه كتابة مكتبة معالجة نصوص عالية الأداء في Rust، عرضها كمكون WASM مع واجهة WIT محددة الأنواع، واستدعاؤها من Python بدون كود FFI زائد. الثنائي يعمل في صندوق رملي، الواجهة يتم فحص أنواعها عند الحدود، ونفس المكون يعمل في كل مكان يوجد فيه WASM runtime.

ما لا يزال مفقودًا

نمو WASM خارج المتصفح يأتي مع قيود حقيقية. دعم جمع القمامة (Garbage Collection) وصل فقط إلى حالة مستقرة في 2024، مما جعله سابقًا غير ملائم للغات مثل Python وJava التي تعتمد عليه. الخيوط والذاكرة المشتركة تعمل لكن بها محاذير حول العمليات الذرية تختلف حسب المنصة. قصة الأدوات تحسنت بشكل كبير — wasm-pack، cargo-component، وcomponentize-py كلها موجودة — لكن التجربة لا تزال متخلفة عن التطوير الأصلي من حيث تصحيح الأخطاء، التنميط، ورسائل الخطأ.

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

المسار

خط الاتجاه واضح. Wasmtime (الذي يديره Bytecode Alliance) يتم دمجه في كل شيء من مزودي السحابة إلى أدوات CLI إلى قواعد البيانات. نموذج المكون يكتسب تبنيًا أسرع من أي مواصفة سابقة لـ WASM. بائعي المتصفح متوافقون على الميزات المستقبلية بما في ذلك جمع القمامة، تبديل المكدس للكوروتين، وتحسينات إدارة الاستثناءات.

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