اگر امروز برای اجرای اپلیکیشنهای جاوااسکریپت هزینه پردازشی میپردازید، مصرف CPU در حالت بیکار برای برنامههای کوچک شما ۵ برابر کمتر میشود. این عدد، نتیجهی یک جراحی عمیق در قلب Bun 1.4 است که در ۲۰ اوت ۲۰۲۶ منتشر شد. این بهروزرسانی یک چرخش معماری بنیادین است؛ تیم توسعه برای باز کردن قفل بهینهسازیهای عمیقتر، محیط اجرا را از زبان Zig به Rust بازنویسی کرده است. Bun اکنون به یک جعبهابزار کامل برای ساخت و تست اپلیکیشنهای فولاستک جاوااسکریپت و تایپاسکریپت تبدیل شده است.
برای سالها، اکوسیستم جاوااسکریپت تحت سلطه Node.js بود، اما نیاز به سرعت بیشتر در راهاندازی و کاهش سربار منابع، توسعهدهندگان را به سمت جایگزینها کشاند. محیط اجرا (Runtime) — شبیه به موتور یک ماشین است که کدها را میگیرد و به دستورات قابل فهم برای سختافزار تبدیل میکند — در Bun حالا با هدف جایگزینی مستقیم استاندارد صنعت بازطراحی شده است. همانطور که در تحلیلهای قبلی ما دربارهی بهینهسازیهای سطح پایین در زبانهای سیستمی اشاره کردیم، حذف لایههای اضافی مدیریت حافظه کلید اصلی افزایش سرعت است. برای شروع، کاربران میتوانند آن را از طریق دستور curl -fsSL https://bun.sh/install | bash نصب کنند.
بازنویسی با Rust و بهرهوری منابع
به نقل از گزارش رسمی bun.com، مرکز ثقل این نسخه، مهاجرت به Rust است. Bun v1.4 همچنین بیش از ۲۹۰۰ مشکل را برطرف کرده است. این محیط اجرا با جایگزینی تخصیصکنندههای حافظه و استفاده از یک مورد واحد به نام mimalloc و پیادهسازی یک رشتهی پاککننده (scavenger thread) که حافظه را در زمانهای بیکاری آزاد میکند، ردپای مصرفی خود را بهشدت کاهش داده است. پیش از این، Bun از دو تخصیصکننده استفاده میکرد: libpas متعلق به JavaScriptCore و mimalloc. اکنون JavaScriptCore در Bun منحصراً از mimalloc بهره میبرد که بازپسگیری حافظه را بهبود میبخشد. تیم توسعه همچنین mimalloc را با قابلیتهای پاکسازی جزئی صفحات (partial page clearing) و بهبود صفر کردن تنبل (lazy zeroing) گسترش داده است. این رویکرد در ترکیب Rust و TypeScript برای دستیابی به کارایی حداکثری، مشابه معماری Syncular در مدیریت دادههای SQL است که از پیوند این دو زبان برای بهینهسازی استفاده میکند.
طبق اعلام تیم توسعه، مصرف CPU در محیط عملیاتی برای اپلیکیشنهای بزرگی مانند Claude Code از ۲۴٪ (p99) به ۱۰٪ و از ۵.۸٪ (p50) به ۲.۵٪ کاهش یافته است. برای برنامههای کوچک «Hello World»، مصرف CPU در حالت بیکار ۵ برابر کمتر از نسخه ۱.۳ است. این دستاورد از طریق بهینهسازی تایمرهای جمعآوریکننده زباله (Garbage Collector) — شبیه به یک مامور نظافت که متغیرهای بلااستفاده را از حافظه پاک میکند تا جا برای دادههای جدید باز شود — تغییر نحوه بازدید JavaScriptCore از ریشههای Strong (از لیست پیوندی به لیست پیوندی از آرایههای قطعهبندی شده) و کاهش فراخوانیهای futex حاصل شده است.


مصرف حافظه نیز بهبودهای مشابهی داشته است. اپلیکیشنهایی که از سرورهای HTTP استفاده میکنند، کاهش مصرف بین ۱۳٪ تا ۴۸٪ را تجربه میکنند. برای مثال، مصرف حافظه در Fastify از ۲۳۳ مگابایت در نسخه ۱.۳ به ۱۲۰ مگابایت در نسخه ۱.۴ رسیده است. Express از ۱۶۹ به ۹۲ مگابایت و node:http از ۱۳۵ به ۸۱ مگابایت کاهش یافت. Elysia با ۴۰٪ کاهش به ۵۵ مگابایت رسید. خودِ Bun.serve از ۴۵ به ۳۶ مگابایت و سرور توسعه Vite از ۲۶۸ به ۲۳۳ مگابایت سقوط کرد.
رندرینگ سمت سرور در Next.js App Router نیز اصلاح شد؛ الگویی که در نسخه ۱.۳ با استفاده از React.cache و fetch بدون ذخیره (no-store) بدون محدودیت رشد میکرد، اکنون در ۴۰۰۰ صفحه روی ۲۳۸ مگابایت تثبیت میشود، در حالی که عدد مشابه برای Node برابر ۴۱۰ مگابایت است.

سرعت راهاندازی نیز شتاب گرفته است. در ویندوز، Bun ۲.۵ برابر سریعتر اجرا میشود (۱۵.۵ میلیثانیه در برابر ۳۹ میلیثانیه) و حافظه کمتری در پیک مصرف میگیرد (۱۶.۸ مگابایت در برابر ۴۶.۵ مگابایت). در لینوکس، زمان راهاندازی نصف شده (۵.۱ در برابر ۱۰.۹ میلیثانیه) و مصرف حافظه به کمتر از نصف کاهش یافته است (۱۴.۶ مگابایت در برابر ۳۳ مگابایت). اندازه فایلهای باینری نیز در لینوکس و ویندوز تا ۱۷٪ کوچکتر شدهاند. برای مثال، نسخه لینوکس x64 از ۸۸.۵ مگابایت به ۷۷ مگابایت و نسخه ویندوز x64 از ۹۳.۹ مگابایت به ۸۴.۸ مگابایت کاهش یافت. باینریهای macOS رشد اندکی حدود ۱ مگابایت داشتند.
پر کردن شکاف سازگاری با Node.js
Bun 1.4 تعداد ۱،۵۱۷ تست جدید از مجموعه تستهای Node.js را اضافه کرده که بزرگترین جهش از نسخه ۱.۰ است. این تستها روی هر کامیت اجرا میشوند تا پایداری تضمین شود. چندین ماژول هسته اکنون تقریباً تمام تستهای Node را پاس میکنند:
- node:quic: نرخ موفقیت ۹۹٪
- node:http, fs, cluster, timers, zlib, vm, and stream: نرخ موفقیت ۹۷٪
- node:events, trace_events, and sqlite: نرخ موفقیت ۱۰۰٪

این سازگاری به اکوسیستم گستردهتر نیز سرایت کرده است. Playwright اکنون روی Bun اجرا میشود و از connectOverCDP()، دستور playwright test با فایل playwright.config.ts، فلگ --ui و مرورگر Chromium در ویندوز پشتیبانی میکند. Next.js 16.3 با دستور bun --bun next build و استفاده از Turbopack و کامپایلر React کار میکند. vitest نیز اکنون تحت Bun اجرا میشود، از جمله قابلیت --coverage با استخرهای threads و forks.
بستههای دیگری که اکنون بدون تغییر کار میکنند عبارتاند از:
- Nuxt: اتصال HMR و Nuxt DevTools از طریق
nuxt dev. - زیرساخت: testcontainers و dockerode (بهویژه متد
container.exec()). - شبکه: https-proxy-agent، socks-proxy-agent و crawlee از طریق proxy-chain.
- APIها: @grpc/grpc-js و ConnectRPC (در پشت Envoy و AWS ALB).
- ابر/پایگاهداده: amqplib برای RabbitMQ، @aws-sdk/client-s3 برای آپلودهای استریم و TypeORM با تنظیمات دکوراتور tsconfig.json.
- ابزارها: nock برای رهگیری درخواستها، Fastify inject()، light-my-request و piscina. همچنین happy-dom دیگر باعث خرابی
console.logنمیشود.
APIهای جدید Node.js پیادهسازی شده در Bun شامل worker_threads (با گزینههای resourceLimits، stdout، stderr و eval)، ws (رویدادهای 'upgrade' و 'unexpected-response') و socket.upgradeTLS({ isServer: true }) برای STARTTLS سمت سرور است. همچنین node:repl، node:trace_events و node:domain اکنون پیادهسازی شدهاند و node:cluster سوکتهای شنود را بین ورکرها به اشتراک میگذارد.
ابزارهای قدرتمند داخلی جدید
Bun در حال گسترش کتابخانه استاندارد خود است تا نیاز به افزونههای نیتیو شخص ثالث را از بین ببرد. کتابخانه جدید Bun.Image فرمتهای JPEG، PNG، WebP، GIF و BMP را مدیریت میکند و برای تغییر اندازه PNG به JPEG (تبدیل PNG 1080p به JPEG 400x400)، ۱.۳۸ برابر سریعتر از کتابخانه محبوب sharp است. این ابزار همچنین از HEIC، AVIF و TIFF در مک و ویندوز پشتیبانی میکند و پروفایلهای رنگی ICC مانند Display P3 را حفظ میکند. برای تبدیل JPEG به WebP نیز ۱.۱۹ برابر سریعتر است.
Bun.WebView اتوماسیون مرورگر بدون نیاز به Puppeteer یا Playwright را فراهم میکند. در مک از WebKit سیستم و در مک، لینوکس و ویندوز میتواند کروم، کرومیوم یا اج را هدایت کند. این ابزار از EventTarget ارثبری میکند، اسکرینشاتها را به صورت Blob برمیگرداند و متد .cdp() را برای دستورات خام پروتکل ابزارهای توسعه کروم ارائه میدهد. این قابلیت دسترسی مستقیم به منابع سیستم، تضاد جالبی با محدودیتهای Sandbox در مرورگرها ایجاد میکند که در آن افزونههای نیتیو برای عبور از سدهای امنیتی مرورگر به کار میروند.
سایر اضافات مهم عبارتاند از:
- Bun.markdown: یک پارسر با پیچیدگی زمانی خطی که خروجی HTML (از طریق
.html())، المانهای React (از طریق.react()) یا خروجی ترمینال ANSI (از طریق.render()) میدهد. این ابزار از جداول GFM، خطزنی، لیستهای تسک و لینکهای خودکار پشتیبانی میکند. خروجی HTML پاکسازی (sanitize) نمیشود و تگهای خام HTML و hrefهای javascript: عیناً منتقل میشوند. - Bun.cron(): ثبت کارهای زمانبندی شده مستقیماً در سیستمعامل (crontab در لینوکس، launchd در مک و Task Scheduler در ویندوز). این ابزار از سینتکس استاندارد ۵ فیلدی cron و نام روزها پشتیبانی میکند. کارها میتوانند از طریق فایل یا تابع ثبت شوند و هرگز همپوشانی نمیکنند. متد
Bun.cron.parse()برای یافتن تاریخ UTC بعدی متناظر وجود دارد. - Bun.Terminal: یک ترمینال مجازی داخلی برای اجرای bash، vim یا htop از طریق جاوااسکریپت بدون نیاز به
node-pty. این ابزار در لینوکس، مک و ویندوز کار میکند. - bun run --parallel: اجرای همزمان چندین اسکریپت بسته با خروجی پیشونددار. این قابلیت از glob-matching (مثلاً
bun run --parallel "build:*") و فیلتر کردن ورکاسپیس با--filterپشتیبانی میکند و جایگزین ابزارهایی مثلnpm-run-allوconcurrentlyمیشود. فلگ--sequentialاسکریپتها را یکی یکی با همان خروجی پیشونددار اجرا میکند.
تجربه توسعهدهنده و ابزارها
قابلیت مشاهدهپذیری با پروفایلینگ مبتنی بر Markdown بازسازی شده است. فلگهای --cpu-prof-md و --heap-prof-md به توسعهدهندگان اجازه میدهند توابع داغ و نشت حافظه را مستقیماً در ترمینال یا از طریق یک مدل زبانی بزرگ (LLM) تحلیل کنند. برای پروسههایی که نمیتوان در آنها فلگ پاس داد، میتوان از BUN_CPU_PROFILE=1 استفاده کرد. پروفایلر Heap بزرگترین اشیاء، انواع منحصربهفرد و زنجیرههایی که آنها را زنده نگه داشتهاند شناسایی میکند.
برای توسعهدهندگان React، دستور bun build --react-compiler کامپایلر خودکار-ممویزیشن React را مستقیماً در پارسر ادغام میکند. در یک کدبیس بزرگ با ۸۶۰ کامپوننت، این روش ۱۹ برابر سریعتر از پلاگین Babel است.

رابط خارجی توابع یا FFI (Foreign Function Interface) نیز بهینهسازی شده است. با انتقال FFI به JavaScriptCore و استفاده از کامپایل JIT برای نقاط فراخوانی داغ، bun:ffi اکنون تا ۳ برابر سریعتر است. یک فراخوانی no-op از ۲.۱۳ نانوثانیه به ۰.۷۰ نانوثانیه و new CString(ptr) از ۹۲.۵ نانوثانیه به ۲۴.۱ نانوثانیه کاهش یافت. نوع آرگومان جدید buffer_length تضمین میکند که طول TypedArray و اشارهگر همیشه مطابقت داشته باشند. مقدار returns: "cstring" اکنون یک رشته ساده برمیگرداند و NULL را به null تبدیل میکند.

ابزارهای توسعه دیگر شامل موارد زیر است:
- --no-orphans: Bun زمانی که والدش میمیرد خارج میشود و تمام فرزندان را در لینوکس، مک و ویندوز SIGKILL میکند.
- --no-env-file: نادیده گرفتن بارگذاری خودکار
.envدر محیط تولید یا CI. - استکتریسهای Async: خطاها در
fs.promises،fetch()، S3، DNS یا crypto اکنون به جای فریمهای نیتیو، بهawaitدر کد کاربر اشاره میکنند. - bun build --metafile-md: تحلیل باندل را به صورت Markdown مینویسد تا تورم وابستگیها، بزرگترین ماژولها و زنجیرههای import شناسایی شوند.
بازسازی استریم و شبکه
استریمهای Readable، Writable و Transform اکنون نیتیو هستند و ۱۰۰٪ تستهای پلتفرم وب را پاس میکنند. در بنچمارکهای توان عملیاتی، خط لوله دانلود Bun 1.4 به ۱،۵۱۹ مگابایت بر ثانیه رسید که در برابر ۲۰۴ مگابایت بر ثانیه در Node.js 26، برتری مطلق است. آپلودها به ۱۷۹ مگابایت بر ثانیه و انتقالهای subprocess به ۷۵۱ مگابایت بر ثانیه رسیدند. سرعت ترنسکدینگ (decode-encode) به ۱۳۲ مگابایت بر ثانیه رسید.
Bun 1.4 همچنین CompressionStream و DecompressionStream نیتیو را معرفی کرده است. سرعت بازگشایی فشردهسازی به ۲،۲۹۱ مگابایت بر ثانیه رسید، در حالی که عدد Node برابر ۴۹۱ مگابایت است. TextEncoderStream و TextDecoderStream اکنون حدود نصف حافظه Bun 1.3 (به ترتیب ۴۴ و ۵۶ مگابایت) را مصرف میکنند، در حالی که توان عملیاتی بالایی (۱،۹۶۳ مگابایت بر ثانیه برای انکودینگ) دارند.
پشتیبانی آزمایشی از HTTP/3 به Bun.serve() اضافه شده است. در بنچمارکهای مسیرهای استاتیک، HTTP/3 حدود ۲.۷ برابر سریعتر از HTTPS/1.1 بود. همچنین fetch() اکنون از پروتکلهای HTTP/2 و HTTP/3 از طریق فلگهای آزمایشی مانند --experimental-http3-fetch یا BUN_FEATURE_FLAG_EXPERIMENTAL_HTTP2_CLIENT=1 پشتیبانی میکند.
بهبودات شبکه دیگر شامل موارد زیر است:
- Response/Request.clone(): دیگر هر تکه (chunk) را در شاخه دوم کپی نمیکند و تکهها را با نسخه اصلی به اشتراک میگذارد. این کار پیک حافظه برای یک بدنه ۶۴ مگابایتی را از ۳۱۱ مگابایت (Bun 1.3) به ۲۲۰ مگابایت (Bun 1.4) کاهش داد.
- سرویسدهی دایرکتوری: مسیرهای
Bun.serve()اکنون میتوانند یک دایرکتوری را با استفاده ازsendfileسرویس دهند و هدرهای Content-Type، ETag و Range را خودکار مدیریت کنند. در لینوکس، ازopenat2باO_RESOLVE_BENEATHاستفاده میکند تا از خروج symlinkها از دایرکتوری جلوگیری شود. - درخواستهای Range/Conditional: پشتیبانی از 206 Partial Content برای جلو و عقب بردن ویدیو و 304 Not Modified برای درخواستهای شرطی (If-None-Match, If-Modified-Since). همچنین در صورت شکست پیششرطها، کد 412 برمیگرداند.
- فشردهسازی fetch(): گزینه جدید
compressاز gzip، deflate، br و zstd برای بدنههای درخواست با سطوح فشردهسازی اختیاری پشتیبانی میکند. - TLS Session Resumption: یک کش LRU با ۳۲ ورودی برای نشستهای کلاینت BoringSSL، زمان اتصال مجدد را به 1 RTT کاهش میدهد.
- استفاده مجدد از اتصال:
fetch()اکنون اتصالات را از طریق پروکسیهای HTTPS و برای درخواستهایی با گزینههای TLS سفارشی (مانند گواهینامههای کلاینت) بازاستفاده میکند.
مدیریت بسته و تست
دستور bun install اکنون از یک استور مجازی جهانی از طریق --linker=isolated پشتیبانی میکند که نصبهای گرم را در محیطهای CI تا ۷ برابر سریعتر میکند، زیرا بستهها را به جای کپی کردن، از کش سیملینک (symlink) میکند. دستورات جدید شامل bun audit fix برای ارتقای بستههای آسیبپذیر (با --latest برای نسخههای Major)، bun dedupe برای حذف نسخههای تکراری از bun.lock و bun prune برای حذف بستههای بلااستفاده یا devDependencies برای نسخههای تولیدی است.
همچنین bun pm diff تغییرات بین نسخههای بسته را نشان میدهد و حتی فایلها را پیش از مقایسه un-minify میکند. bun pm licenses اکنون میتواند وابستگیها را بر اساس لایسنس در قالب JSON لیست کند. bun update اکنون وابستگیهای ترانزیتی را نیز بهروز میکند.
تستها با bun test --parallel تکامل یافتهاند و فایلهای تست را بین پروسههای ورکر توزیع میکنند. فلگ جدید --timings از زمانبندی «اولین پردازش طولانیترین زمان» (longest-processing-time-first) برای بالانس کردن شاردهای CI بر اساس زمان واقعی (wall time) به جای تعداد فایل استفاده میکند. همچنین از --shard=M/N برای تقسیم تستها بین چندین رانر CI پشتیبانی میکند.

این نسخه همچنین --isolate را معرفی میکند که هر فایل تست را در یک شیء جهانی (global object) تازه اجرا میکند تا از نشت وضعیت (state leakage) جلوگیری شود. Bun 1.4 چندین مشکل پایداری در ایزولاسیون، از جمله نشت تایمرهای جعلی، پروسههای فرزند یتیم و اثر process.chdir() بر فایلهای بعدی را برطرف کرده است. افزونههای نیتیو (N-API) اکنون در فایلهای ایزوله به درستی کار میکنند و دیباگر اکنون بریکپوینتها را در فایلهای بارگذاری شده تحت --isolate شناسایی میکند.
تحلیل: جابجایی جنگ محیطهای اجرا به هسته
با بازنویسی در Rust، Bun دیگر فقط در سطح راحتی API رقابت نمیکند، بلکه بر سر بهرهوری بنیادین موتور در حال رقابت است. کاهش ۵ برابری مصرف CPU در حالت بیکار، یک پیروزی حیاتی برای محاسبات Serverless و Edge است، جایی که هر میلیثانیه اجرا و هر بایت حافظه مستقیماً روی هزینه تاثیر میگذارد. پیادهسازی process.on("memoryPressure") در مک، لینوکس و ویندوز به اپلیکیشنها اجازه میدهد پیش از آنکه سیستمعامل پروسه را بکشد، کشها را آزاد کنند. در مک این کار از EVFILT_MEMORYSTATUS، در لینوکس از یک تریگر PSI و در ویندوز از CreateMemoryResourceNotification استفاده میکند.
برای یک توسعهدهنده معمولی، ملموسترین ارزش، کاهش «خستگی از ابزارها» (tooling fatigue) است. با گنجاندن پردازش تصویر، پارسر مارکداون و زمانبندی cron، Bun خود را به عنوان تنها ابزاری که یک توسعهدهنده نیاز دارد معرفی میکند و احتمالاً دهها وابستگی کوچک npm را زائد میکند. اضافه شدن Bun.JSON5، Bun.JSONL، Bun.XML و Bun.TOML استک را بیشتر یکپارچه میکند. سایر ابزارهای داخلی مانند Bun.Archive برای فایلهای tar و Bun.sliceAnsi() برای برش متون ترمینال، جایگزین چندین بسته کاربردی رایج شدهاند.
گام بعدی شما
- مجموعههای تست فعلی Node.js خود را با
bun test --parallelاجرا کنید تا ببینید آیا هسته Rust سرعت فوری ایجاد میکند یا خیر. - پیادهسازی آزمایشی HTTP/3 را در محیط Staging تست کنید تا بهبود سرعت پاسخدهی را ارزیابی کنید.
- اگر از سرویسهای Edge یا Serverless استفاده میکنید، مصرف CPU را در حالت Idle مانیتور کنید تا کاهش هزینهها را مشاهده کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.




گفتگو