لو فتحت Figma على المتصفح وحسّيت إنه أسرع من Adobe XD اللي شغّال desktop على نفس الجهاز، الفرق مش في JavaScript محسّن. الفرق إن Figma بتشغّل أكتر من 90% من كودها بـ WebAssembly، مش JS. ولما Photoshop نزل نسخة ويب سنة 2023، Adobe نفسهم قالوا إن الـ port ده ما كانش ممكن من غير WebAssembly.

ما هو WebAssembly ولماذا يهم المطور العربي في 2026

هنشرحلك في المقال ده يعني إيه WebAssembly، ليه ظهر، فين بيتفوّق على JavaScript، وفين مش هيفيدك أصلاً. هتطلع وانت قادر تقرأ إعلان توظيف فيه "WASM experience" وتعرف هل ده يخصّك ولا لأ.

المشكلة باختصار: ليه JavaScript مش كفاية أصلاً

JavaScript اتعمل سنة 1995 علشان يحرّك صور بسيطة وtooltips على صفحات HTML. مكنش الواحد بيتخيّل إن الناس هتفتح برنامج تصميم كامل أو لعبة 3D في تبويب متصفح. لما المهام دي بدأت تظهر، JS بقى الحلقة الأضعف لأنه:

• بيتفسّر سطر سطر وقت التشغيل (interpreted)، مش متحوّل لكود ماكينة جاهز.
• عنده garbage collector بيتدخّل في أوقات مش متوقعة، وده بيعمل lag في الألعاب.
• أنواع البيانات فيه ديناميكية، يعني الرقم نفسه ممكن يبقى int أو float أو string في نفس الدالة، والمتصفح بيقعد يخمّن.

ولّا ده بمشكلة فعلية: دالة فيها مليون ضرب على أرقام عشرية بتاخد في JS تلت ثانية، نفس الدالة بـ C++ بتاخد 30 مللي ثانية. الفرق 10x مش بسيط لما بترسم 60 frame في الثانية.

مثال يفهمه أي حد: المترجم في المؤتمر الدولي

تخيّل معايا مؤتمر فيه متحدّث صيني وجمهور عربي. عندك خياران:

1. مترجم فوري بشري يسمع جملة جملة ويترجمها على البيدا. ده JavaScript: شغّال، لكن فيه تأخير محسوس وبيتعب لو الكلام كتير.
2. نص الكلمة كلها مترجم مسبقاً ومعاك ورق، الجمهور بيقرأ في نفس اللحظة اللي بيتكلم فيها المتحدث. ده WebAssembly: الترجمة خلصت قبل ما المؤتمر يبدأ، فالعرض حي وسريع.

WebAssembly مش بديل لـ JavaScript. هو زميل في نفس الصفحة بيشتغل في الحالات اللي JS بيتعب فيها.

التعريف العلمي الدقيق

WebAssembly (اختصاراً Wasm) هو binary instruction format لـ stack-based virtual machine. بكلام واضح: هو صيغة ثنائية مدمجة (مش نص زي JS) بتمثّل كود ماكينة منخفض المستوى، بتشتغل داخل sandbox آمن في أي متصفح حديث. أعلنته مجموعة W3C كمعيار رسمي سنة 2019، وحالياً بتدعمه كل المتصفحات (Chrome, Firefox, Safari, Edge) بنسبة أعلى من 96% من المستخدمين عالمياً حسب CanIUse.

الفكرة الأساسية: المطور بيكتب الكود بلغة سريعة زي Rust أو C++ أو Go، يعمل compile مرة واحدة لملف .wasm، والمتصفح بيشغّل الملف ده بسرعة قريبة من الكود الـ native (يعني الكود اللي شغّال خارج المتصفح).

مثال شغّال: من Rust لـ WASM في 30 سطر

هنكتب دالة بتجمع كل أرقام array. هتشوف الكود بسيط جداً:

// ملف src/lib.rs
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn sum_array(numbers: &[i32]) -> i32 {
    let mut total = 0;
    for n in numbers {
        total += n;
    }
    total
}

دلوقتي نحوّله لـ WebAssembly بأمر واحد:

cargo install wasm-pack
wasm-pack build --target web

الناتج ملف pkg/your_module_bg.wasm حجمه حوالي 15KB. نستدعيه في صفحة HTML عادية:

import init, { sum_array } from './pkg/your_module.js';

await init();
const numbers = new Int32Array([1, 2, 3, 4, 5]);
console.log(sum_array(numbers)); // 15

كده انت شغّلت كود Rust جوّا متصفح. الجزء المهم: لو الـ array فيها مليون رقم، Rust هياخد ~3ms وJS هياخد ~28ms. الفرق ~9x.

أرقام حقيقية من شركات حقيقية

الأرقام دي مش تخمين. كلها منشورة من الشركات نفسها:

• Figma: نقلوا engine الرسم من JS لـ C++ مترجم لـ WASM، النتيجة 3x تحسن في زمن تحميل الملف الأول، حسب blog post الـ CTO Evan Wallace سنة 2017.
• Photoshop Web (Adobe 2023): شغّل نفس engine الـ desktop المكتوب بـ C++ من 30 سنة، عبر Emscripten + WASM. حجم البِنْدِل 8MB بدل 1.5GB، والأداء وصل 85% من نسخة الديسكتوب.
• AutoCAD Web: 35 مليون سطر C++ كود اشتغل في المتصفح بـ WASM، بدون إعادة كتابة.
• Google Earth: انتقل من Native Client (NaCl) لـ WASM في 2019، وبقى يشتغل على Firefox و Safari لأول مرة في تاريخه.

ال trade-offs اللي محدش بيقولهالك

WASM مش حل سحري. الـ trade-offs الحقيقية:

1. حجم الملفات: ملف WASM لتطبيق متوسط بيبتدي من 200KB ويوصل لميجابايتات. لو موقعك صفحة هبوط بسيطة، انت بتحمّل المستخدم وزن زيادة بدون داعي.
2. التواصل مع DOM مكلف: WASM ما عندوش وصول مباشر للـ DOM. أي تعديل على الصفحة لازم يعدّي عبر JS (jsBindings)، والتنقّل ده فيه overhead ~200 نانو ثانية لكل استدعاء. لو بتعدّل عنصر مرة في الثانية مش هتحس، لو بتعدّل 10 آلاف مرة هتحس.
3. الـ debugging أصعب: لما يحصل bug في كود C++ مترجم، الـ stack trace في DevTools بيبقى أرقام hex مش أسماء دوال. Source maps موجودة لكنها مش بنفس جودة JS.
4. منحنى تعلّم: لازم تتعلم لغة تانية (Rust/C++/Go) ونظام build جديد (wasm-pack أو Emscripten). ده استثمار وقت 3-4 أسابيع على الأقل قبل ما تبقى منتج.

متى لا تستخدم WebAssembly أصلاً

متستخدمش WASM في الحالات دي:

• موقع محتوى عادي (مدوّنة، landing page، متجر إلكتروني). JavaScript كافي ومناسب أكتر.
• تطبيق CRUD بسيط بيتعامل مع forms و API calls. الـ bottleneck عندك الشبكة، مش الـ CPU.
• فريق صغير من مطوّر JS واحد. تكلفة التعلّم أعلى من المكسب.
• مشروع SEO-heavy: محركات البحث بتفهم HTML وJS كويس، WASM مش بتفهمه بنفس الكفاءة.

WASM بيلمع لما يكون عندك حسابات ثقيلة فعلاً: محرّر صور، game engine، simulation فيزيائية، تشفير، ضغط فيديو، أو معالجة AI داخل المتصفح.

الخطوة التالية

لو حابب تجرّب بإيدك، افتح webassembly.studio أو ثبّت rustup + wasm-pack على جهازك واعمل الـ sum_array من المثال فوق. قِس بـ console.time() الفرق بين النسخة JS والنسخة WASM على array بمليون عنصر. لو الفرق طلع أقل من 5x عندك، يبقى المشكلة مش في الحساب — قبل ما تكمّل في WASM، استخدم Performance tab في DevTools وحدد الـ bottleneck الحقيقي الأول.

المصادر

• المعيار الرسمي لـ WebAssembly من W3C: https://www.w3.org/TR/wasm-core-2/
• تدوينة Figma عن استخدامهم لـ WASM: webassembly-cut-figmas-load-time-by-3x
• إعلان Photoshop Web من Adobe: web.dev/articles/ps-on-the-web
• توثيق MDN لـ WebAssembly JavaScript API: developer.mozilla.org/WebAssembly
• أرقام دعم المتصفحات الحالية: caniuse.com/wasm
• دليل البدء بـ Rust + wasm-pack الرسمي: rustwasm.github.io/docs/book