در سال ۲۰۲۶، بون، دنو و نود.جیاس سه رانتایم جدی و هرکدام با دلایل خاص خود

در بیشتر تاریخ سمت سرور جاوااسکریپت، بحث runtime تقریباً حل‌شده بود: همه از Node.js استفاده می‌کردند. ساخته‌ی رایان دال در سال ۲۰۰۹ آن‌قدر dominant بود که «runtime جاوااسکریپت» و «Node.js» عملاً مترادف شده بودند. آن دوران تمام شده. تا سال ۲۰۲۶، سه runtime یعنی Node.js 22، Bun 1.2 و Deno 2.0 همگی برای تولید آماده هستند و تفاوت‌های معناداری با هم دارند. انتخاب بین آن‌ها دیگر یک بحث تئوری نیست.

Node.js 22: هنوز dominant، بالاخره مدرن‌شده

Node.js 22 که در آوریل ۲۰۲۴ منتشر شد و هم‌اکنون در وضعیت LTS قرار دارد، مهم‌ترین انتشار Node.js در سال‌های اخیر است. ویژگی اصلی برای اکثر توسعه‌دهندگان، --experimental-strip-types است: اجرای مستقیم فایل‌های TypeScript بدون مرحله build. این کامپایل کامل TypeScript نیست - Node.js حاشیه‌نویسی typeها را حذف می‌کند و جاوااسکریپت باقی‌مانده را اجرا می‌کند، بدون type-checking. از syntax خاص TypeScript مثل enum یا decoratorها بدون flagهای اضافی پشتیبانی نمی‌کند. اما برای حالت رایج TypeScript که به هر حال transpile می‌کنید، مرحله کامپایل را از چرخه توسعه حذف می‌کند.

Node.js 22 همچنین یک test runner داخلی بالغ (node:test) دارد که اکنون به اندازه‌ای توانمند است که بسیاری از پروژه‌ها می‌توانند برای موارد ساده از Jest یا Vitest صرف‌نظر کنند. پیاده‌سازی داخلی fetch، WebCrypto و WebStreams اکنون پایدار هستند. این runtime به اندازه Bun سریع نیست، اما برای اکثر workloadهای تولیدی به اندازه کافی سریع است و سازگاری با اکوسیستم بی‌نظیر است - هر بسته npm که وجود دارد با Node.js کار می‌کند، چون برای همین ساخته شده.

دلیل ماندن روی Node.js ساده است: هزینه مهاجرت صفر، حداکثر سازگاری با اکوسیستم و سابقه ۱۵ ساله در تولید. اگر تیم شما یک codebase Node.js کارآمد دارد و گلوگاه سرعت runtime نیست، تغییر دادن فقط تغییر به خاطر تغییر است.

Bun: واقعاً سریع، واقعاً آماده تولید

Bun 1.0 در سپتامبر ۲۰۲۳ با هیجان قابل توجه و شک منطقی راه‌اندازی شد - runtimeهای سریع جاوااسکریپت زیادی راه‌اندازی شده‌اند و نتوانسته‌اند جذب کنند. یک سال بعد، Bun 1.1 پشتیبانی از ویندوز را اضافه کرد. تا Bun 1.2 (اوایل ۲۰۲۵)، runtime مهم‌ترین شکایت‌های پایداری را برطرف کرده بود و در تعداد فزاینده‌ای از شرکت‌ها در تولید مستقر می‌شد.

Bun با Zig نوشته شده و از JavaScriptCore - موتور جاوااسکریپت اپل، از WebKit - به جای V8 استفاده می‌کند. این انتخاب معماری پیامدهایی دارد. زمان راه‌اندازی Bun در بنچمارک‌ها ۴-۸ برابر سریع‌تر از Node.js است. bun install نصب بسته‌ها را ۲۰-۳۰ برابر سریع‌تر از npm install انجام می‌دهد، عمدتاً به این دلیل که Bun از فرمت باینری lockfile و کش تهاجمی استفاده می‌کند. برای تجربه توسعه‌دهنده - اجرای تست‌ها، hot-reload، نصب وابستگی‌ها - تفاوت سرعت بلافاصله قابل توجه است.

Bun همچنین یک bundler و test runner داخلی دارد. bun test فایل‌های تست سازگار با Jest را بدون پیکربندی اجرا می‌کند. bun build برای مرورگر یا edge باندل می‌کند. این‌ها افکار ثانویه نیستند - ویژگی‌های درجه یک هستند و چندین ابزار را از درخت وابستگی یک پروژه جاوااسکریپت معمولی حذف می‌کنند.

مبادله: رفتار JavaScriptCore در موارد لبه‌ای با V8 متفاوت است و برخی بسته‌های npm که به داخلی‌های V8 وابسته هستند، در Bun به درستی کار نمی‌کنند. سطح سازگاری بزرگ است و در حال بهبود است - Bun APIهای Node.js را تهاجمی دنبال می‌کند و اکثر بسته‌ها کار می‌کنند - اما موارد لبه‌ای وجود دارند. اگر یک برنامه Node.js سنگین از بسته‌ها اجرا می‌کنید، قبل از مهاجرت تست کنید.

Deno 2.0: مشکل npm حل شده (تا حد زیادی)

Deno در سال ۲۰۱۸ توسط رایان دال - همان کسی که Node.js را ساخت - به‌صراحت به عنوان پاسخی به آنچه «۱۰ چیزی که از Node.js پشیمانم» می‌نامید، معرفی شد. با یک مدل مجوز (بدون دسترسی به فایل‌سیستم یا شبکه بدون اجازه صریح)، پشتیبانی داخلی TypeScript، بدون پوشه node_modules و importهای مبتنی بر URL به جای npm راه‌اندازی شد.

چشم‌انداز منسجم بود اما مشکل عملی واقعی بود: npm 2.3 میلیون بسته دارد و Deno نمی‌توانست آن‌ها را اجرا کند. Deno 2.0 که در اکتبر ۲۰۲۴ منتشر شد، این مشکل را برطرف کرد. اکنون از بسته‌های npm با مشخص‌کننده‌های npm: پشتیبانی می‌کند، اکثر کدهای سازگار با Node.js را خارج از جعبه اجرا می‌کند و با کد Deno 1.x سازگار است. پوشه node_modules اختیاری باقی می‌ماند - Deno وابستگی‌ها را در کش خود مدیریت می‌کند - اما می‌توانید در صورت نیاز برای سازگاری آن را فعال کنید.

Deno همچنین JSR، JavaScript Registry را به عنوان جایگزینی برای npm عرضه کرد. JSR اولویت با TypeScript است، از versioning مبتنی بر URL استفاده می‌کند و مستندات API را الزامی می‌کند. این جایگزینی برای 2.3 میلیون بسته npm نیست، اما در حال رشد است و سیگنال کیفیت بسته بالاتر است زیرا JSR برای انتشار به منبع TypeScript و مستندات نیاز دارد.

مدل مجوز Deno همچنان متمایزترین ویژگی آن است. اجرای deno run script.ts بدون flag به اسکریپت هیچ دسترسی به فایل‌سیستم، شبکه یا محیط نمی‌دهد - هر قابلیت را به‌صراحت اعطا می‌کنید. این یک بهبود امنیتی معنادار برای اسکریپت‌هایی است که کد غیرقابل اعتماد اجرا می‌کنند یا داده‌های حساس پردازش می‌کنند. برای اکثر موارد استفاده وب سرور، به هر حال همه مجوزها را اعطا می‌کنید، اما مدل شما را مجبور می‌کند در این مورد عمدی عمل کنید.

عملکرد: اعداد صادقانه

بنچمارک‌های runtime بدنام هستند که به راحتی قابل دستکاری هستند و حامیان هر runtime می‌توانند اعدادی تولید کنند که به نفع انتخابشان باشد. تصویر کمتر مورد مناقشه تقریباً به این شکل است:

• زمان راه‌اندازی: Bun سریع‌ترین است (۴-۸ برابر سریع‌تر از Node.js)، Deno نزدیک به آن، Node.js کندترین.
• توان عملیاتی HTTP (سرور ساده): Bun در بنچمارک‌های ساده ۲۰-۴۰٪ از Node.js جلوتر است. Deno مشابه Node.js است. تحت بار واقعی با workloadهای سنگین I/O، شکاف به طور قابل توجهی کاهش می‌یابد.
• سرعت نصب بسته: Bun ۲۰-۳۰ برابر سریع‌تر از npm است. Deno (بدون node_modules به طور پیش‌فرض) عملاً آنی است. Node.js با pnpm بهبود معناداری نسبت به npm دارد اما همچنان کندتر از Bun است.
• سرعت build/bundle: bundler بومی Bun در اکثر پیکربندی‌ها سریع‌تر از esbuild است. Deno از esbuild به صورت داخلی استفاده می‌کند. Node.js به یک ابزار خارجی نیاز دارد.

برای فرآیندهای سرور طولانی‌مدت، تفاوت‌های زمان راه‌اندازی ناپدید می‌شوند. برای توابع serverless، ابزارهای CLI و ابزارهای توسعه‌دهنده، مزیت راه‌اندازی Bun واقعی و قابل مشاهده توسط کاربر است.

کدام یک را استفاده کنیم

پاسخ صادقانه بستگی به این دارد که چه می‌سازید:

از Node.js 22 استفاده کنید اگر یک codebase موجود را نگهداری می‌کنید، به حداکثر سازگاری با اکوسیستم npm نیاز دارید، یا تجربه عملیاتی تیم شما در Node.js عمیق است. TypeScript stripping جدید برای توسعه مفید است اما دلیلی برای تغییر از Deno یا Bun نیست اگر قبلاً آنجا هستید.

از Bun استفاده کنید برای پروژه‌های جدید که عملکرد راه‌اندازی و تجربه توسعه‌دهنده مهم است - ابزارهای CLI، مجموعه تست‌ها، اسکریپت‌هایی که در CI/CD اجرا می‌شوند، یا خدماتی که راه‌اندازی ۴-۸ برابر سریع‌تر به هزینه‌های cold-start کمتر در محیط‌های serverless ترجمه می‌شود. ماهیت همه‌کاره Bun (runtime + bundler + package manager + test runner) همچنین یک استدلال معنادار است اگر می‌خواهید پیچیدگی toolchain را کاهش دهید.

از Deno استفاده کنید اگر وضعیت امنیتی مهم است - اگر اسکریپت‌هایی اجرا می‌کنید که داده‌های حساس را مدیریت می‌کنند و مدل مجوز با اعطای قابلیت صریح را می‌خواهید - یا اگر پروژه‌های جدیدی می‌سازید که توسعه TypeScript-first و استانداردهای کیفیت بسته JSR جذاب هستند. پشتیبانی Jupyter notebook Deno همچنین آن را برای کاوش داده در TypeScript جذاب می‌کند.

تکه‌تکه شدن واقعی است اما فلج‌کننده نیست. هر سه runtime به اندازه کافی از یک زبان صحبت می‌کنند که تغییر در صورت اشتباه بودن انتخاب اولیه امکان‌پذیر است. سرمایه‌گذاری ده ساله اکوسیستم جاوااسکریپت در بسته‌های npm به این معنی است که حتی Bun و Deno که برای فراتر رفتن از npm ساخته شده‌اند، به عنوان یک ضرورت عملی بر سازگاری با npm همگرا شده‌اند. بر اساس آنچه پروژه شما در حال حاضر بیشتر به آن نیاز دارد انتخاب کنید - عملکرد، امنیت یا پایداری - و در صورت تغییر شرایط دوباره بررسی کنید.