Deno و Bun وحرب runtimes جافا سكريبت — لماذا لم يعد Node.js هو الخيار الافتراضي

أنشأ Ryan Dahl Node.js في عام 2009، وغيّر تطوير جانب الخادم بشكل دائم. لأول مرة، يمكن لجافا سكريبت — وهي لغة يعرفها المطورون بالفعل من المتصفح — أن تعمل على الخوادم، مما أتاح استخدام جافا سكريبت على كل الواجهات (full-stack) وخلق نظامًا بيئيًا أصبح في النهاية أكبر سجل حزم في التاريخ بأكثر من 2.5 مليون حزمة على npm. لمدة 15 عامًا، كان Node.js هو الخيار الافتراضي الذي لا يُنازع لأي شخص يريد تشغيل جافا سكريبت خارج المتصفح.

ثم ألقى Ryan Dahl محاضرة في JSConf EU عام 2018 بعنوان "10 أشياء أندم عليها في Node.js"، وأعلن عن Deno. كانت المحاضرة صريحة بشكل غير معتاد لمؤلف ينتقد إبداعه الخاص: نظام الوحدات كان خاطئًا، نموذج الأمان كان غائبًا، package.json و node_modules كانا خطأ، والتصميم الأصلي تراكمت عليه قيود كثيرة لا يمكن إصلاحها دون بداية جديدة. بعد ثلاث سنوات، قدم فريق مختلف Bun — وهو runtime لجافا سكريبت يجعل الأداء هدفه التصميمي المركزي، مبني من الصفر بلغة Zig بدلاً من C++.

Node.js: ثقل الإرث

يعمل Node.js على محرك V8 لجافا سكريبت (نفس المحرك الذي يشغل Chrome) وتراكمت عليه التزامات التوافق مع الإصدارات السابقة لمدة 15 عامًا. نظام الوحدات الخاص به — CommonJS (require/module.exports) — يسبق معيار ES Modules الذي تستخدمه المتصفحات الآن، مما خلق احتكاكًا مزمنًا في قابلية التشغيل البيني لم يُحل بشكل نظيف أبدًا. أضاف Node.js دعم ES Module في الإصدار 12 (2019)، لكن تعايش نظامي وحدات بدلالات مختلفة حول التحميل Synchronous مقابل Asynchronous كان مصدرًا مستمرًا لارتباك المطورين وتفتت النظام البيئي.

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

لا يزال Node.js هو runtime جافا سكريبت الأكثر استخدامًا من جانب الخادم بفارق كبير — النظام البيئي npm مبني حوله، معظم أطر جافا سكريبت تستهدفه أولاً، ومعظم عمليات النشر في الإنتاج تعمل عليه. الإرث لن يختفي. لكنه خلق مساحة للبدائل.

Deno: TypeScript أولاً، أمان افتراضيًا

Deno هو محاولة Ryan Dahl لإصلاح الأخطاء التي ارتكبها مع Node.js. يشغل TypeScript بشكل أصلي — بدون خطوة ترجمة مطلوبة، بدون حاجة إلى tsconfig.json للاستخدام الأساسي — مما يعالج واحدة من أكثر نقاط الاحتكاك شيوعًا في تطوير جافا سكريبت الحديث. يستخدم نظام ES Modules حصريًا، مما يلغي الانقسام CommonJS/ESM. وينفذ نموذج صلاحيات حيث يجب على السكريبتات أن تطلب الوصول إلى نظام الملفات والشبكة والبيئة بشكل صريح: `deno run --allow-net --allow-read server.ts`.

التوافق مع Web API في Deno هو اختيار تصميم مهم. واجهات برمجة التطبيقات القياسية للمتصفح — fetch, WebCrypto, URL, WebSockets, Streams — تعمل في Deno بدون أي polyfills. الكود المكتوب لـ Deno يمكن غالبًا أن يعمل في المتصفحات مع تعديلات بسيطة، مما يتوافق مع الاتجاه الحديث لجافا سكريبت كلغة عالمية بدلاً من متغيرات خاصة بالمنصة. Cloudflare Workers و Vercel Edge Functions و Deno Deploy جميعها تعمل على isolates V8 مع أسطح مشابهة لـ Web API، مما يجعل كود Deno قابلًا للنقل بشكل كبير عبر منصات النشر الطرفية (edge).

نموذج إدارة الحزم مختلف عن npm: Deno يستورد الوحدات مباشرة من عناوين URL (بما في ذلك حزم npm عبر محددات `npm:`)، بدون مجلد node_modules وبدون الحاجة إلى package.json لحالات الاستخدام البسيطة. ملف التكوين deno.json يدير تأمين الاعتماديات عبر import map. هذا النموذج أنظف لكنه يضيف منحنى تعلم للمطورين المدربين على سير عمل npm.

اعتماد Deno كان كبيرًا في مجال الحوسبة الطرفية (edge computing) — Deno Deploy وتكامله مع النظام البيئي لـ Deno منتج تنافسي — لكنه لم يزحزح Node.js في تطبيقات الخادم التقليدية. التوافق مع النظام البيئي npm المضاف في Deno 1.28 (نوفمبر 2022) قلل بشكل كبير من احتكاك الهجرة، لكن معظم أعباء العمل في الإنتاج لا تزال على Node.js.

Bun: السرعة كمبدأ تصميم

Bun يتبع نهجًا مختلفًا. حيث Deno هي قصة الصحة والأمان، Bun هي قصة الأداء. مبني بلغة Zig (لغة برمجة أنظمة مصممة للأداء) وباستخدام محرك JavaScriptCore من Apple (نفس المحرك الذي يشغل Safari، وفي معايير Apple الخاصة، أسرع من V8 لأعباء عمل معينة)، تم تصميم Bun ليكون أسرع runtime لجافا سكريبت متاحًا.

ادعاءات المعايير كبيرة: تُظهر معايير خادم HTTP في Bun إنتاجية أعلى بمقدار 2–4 مرات من Node.js لمعالجات الطلبات البسيطة. تُظهر معايير I/O للملفات مزايا مماثلة. تثبيت الحزم في Bun أسرع من npm أو yarn أو pnpm — عادةً 5–30 مرة أسرع حسب السيناريو — مما يحسن بشكل ملحوظ تجربة المطور في بيئات CI/CD وسير عمل الحاويات.

Bun يضع نفسه أيضًا كمجموعة أدوات شاملة: هو runtime، ومدير حزم (بديلاً عن npm)، وbundler (بديلاً عن webpack أو esbuild)، وعداء اختبارات (بديلاً عن Jest أو Vitest). فلسفة التصميم هي تقليل عدد الأدوات في رصة تطوير جافا سكريبت، والتي تطلبت تاريخيًا تجميع 5–10 أدوات منفصلة لإعداد جاهز للإنتاج.

التوافق مع Node.js يحظى بأولوية عالية في قائمة Bun — يدعم CommonJS و ES Modules، وينفذ معظم واجهات برمجة التطبيقات المدمجة في Node.js، ويمكنه تشغيل معظم حزم npm بدون تعديل. Bun 1.0، الذي أُصدر في سبتمبر 2023، كان أول إصدار جاهز للإنتاج؛ الإصدارات اللاحقة حسنت تدريجيًا التوافق مع Node.js إلى درجة أن معظم تطبيقات Node.js تعمل على Bun دون تغييرات.

ملاحظة حول الأداء

مزايا أداء Bun حقيقية ولكنها تعتمد على السياق. لأعباء العمل I/O-bound — خوادم HTTP، استعلامات قاعدة البيانات، عمليات الملفات — مكاسب Bun على Node.js قابلة للقياس وذات مغزى. لأعباء العمل CPU-bound أو التطبيقات المحدودة بالأنظمة الخارجية (زمن وصول قاعدة البيانات، أوقات استجابة API)، نادرًا ما يكون runtime جافا سكريبت هو عنق الزجاجة، وتغيير runtime يوفر فائدة ضئيلة.

المقايضة بين JavaScriptCore و V8 لها أيضًا فروق دقيقة: مُحسِّن JIT في V8 تم تحسينه على مدى 15 عامًا لأعباء عمل الويب الإنتاجية. خصائص أداء JavaScriptCore تختلف عن V8 بطرق يمكن أن تنتج نتائج مختلفة في معايير محددة مقابل سلوك التطبيق الحقيقي. أرقام "أسرع 2–4 مرات" من معايير Bun تعكس أعباء عمل اصطناعية؛ تسريع التطبيق الإنتاجي عادةً ما يكون 10–30%.

ما الذي يجب استخدامه فعليًا

الإرشادات العملية في عام 2026: Node.js للمشاريع الحالية والفرق ذات سير العمل القائم على npm، حيث تفوق تكلفة الهجرة التحسينات الهامشية في الأداء. Deno للمشاريع الجديدة حيث يكون التطوير TypeScript-first أو النشر الطرفي (edge) أو وضع الأمان أولوية — خاصة المشاريع التي تستهدف Cloudflare Workers أو Deno Deploy أو منصات edge مماثلة. Bun للمشاريع حيث تجربة المطور (تثبيت سريع، تشغيل اختبارات سريع) وزمن بدء التشغيل مهمان، وحيث يكون الفريق مرتاحًا مع نظام بيئي أحدث وأقل اختبارًا في الإنتاج مقارنة بـ Node.js.

المنافسة أيضًا حسّنت Node.js. أوقات بدء تشغيل أسرع في Node.js 20+، ودعم محسّن لـ ESM، ونموذج الأذونات الذي يتم استكشافه في خارطة طريق Node.js هي استجابات مباشرة لـ Deno و Bun. لنظام بيئي لغوي لم يكن لديه منافسة ذات معنى لمدة 15 عامًا، كان الضغط مثمرًا. runtime جافا سكريبت في عام 2026 هو حقًا اختيار، وليس افتراضيًا.