اگر امروز برای هر تغییر کوچک در کد، دقایق زیادی را منتظر پاسخ GitHub Actions می‌مانید، این خبر برای شماست. یک کدبیس با ۱۰۳۶ فایل، زمان کامپایل خود را از ۱۴.۳ ثانیه به ۰.۸۱ ثانیه رساند.
تیم Outlyne (یک ابزار ساخت وب‌سایت) این جهش ۱۷.۶ برابری را با مهاجرت به کامپایلر React مبتنی بر Rust به دست آورد. این اقدام بلافاصله پس از انتشار پشتیبانی رسمی تیم oxc در ۴ اوت ۲۰۲۶ صورت گرفت.
برای سال‌ها، اکوسیستم React برای تبدیل کدها به Babel متکی بود. Babel انعطاف‌پذیر است، اما چون با جاوااسکریپت نوشته شده، با مقیاس گرفتن پروژه‌ها اغلب به یک گلوگاه تبدیل می‌شود. ورود پشتیبانی رسمی تیم oxc از کامپایلر React مبتنی بر Rust، محاسبات را برای بیلد‌های در مقیاس بالا تغییر داد.
تصور کنید خط لوله CI شما شبیه به یک بزرگراه است؛ Babel مثل یک کامیون کند است که با هر بار Push کردن کد، ترافیک ایجاد می‌کند. اما کامپایلر Rust شبیه به یک سیستم ریل سریع‌السیر است که مسیر را تقریباً در لحظه باز می‌کند. این موضوع اکنون حیاتی است، زیرا توسعه نرم‌افزار به کمک عامل‌ها (Agents) حجم تغییرات کد را به‌شدت بالا برده و هر دقیقه انتظار در GitHub Actions به یک مرکز هزینه قابل توجه تبدیل شده است. همان‌طور که تیم Outlyne اشاره کرد، انتظار برای CI فشار بیشتری بر «مغزهای مدیریت وظایفی که همین حالا هم بیش از حد تکه‌تکه شده‌اند» وارد می‌کند.
کالبدشکافی عملکرد
به نقل از گزارش blog.master.dev، بیشترین سود حاصل از این تغییر در فاز کامپایل متمرکز شده است. بوشِن، مدیر پروژه oxc، اشاره کرده که این ابزار در بنچ‌مارک‌های اولیه «بیش از ۱۰ برابر سریع‌تر از Babel» است.
اگرچه بخش کامپایلر جهشی ۱۷.۶ برابری داشت، اما بهبود زمان کل بیلد (Build) به دلیل وجود سایر فرآیندهای بیلد که همچنان در حال اجرا هستند، متواضع‌تر بود. نتایج دقیق برای Outlyne به این شرح است:
- سرعت کامپایلر (تک‌رشته‌ای): از ۱۴.۳ ثانیه به ۰.۸۱ ثانیه
- سرعت کل بیلد: از ۲۲.۱ ثانیه به ۹.۳ ثانیه (تقریباً ۲.۴ برابر سریع‌تر)
حل مشکل «Bailout» یا توقف بهینه‌سازی
فراتر از سرعت خام، کامپایلر Rust شکاف‌های سازگاری بحرانی را پر می‌کند که در نسخه ۱.۰ Babel وجود داشت. در نسخه قبلی، برخی الگوهای جاوااسکریپت باعث می‌شدند کامپایلر دچار «Bailout» شود؛ به این معنی که کامپایلر بهینه‌سازی را برای آن کامپوننت‌های خاص به‌کل رها می‌کرد.
بر اساس مستندات، سه اصلاح کلیدی اکنون اجازه می‌دهد بخش‌های بیشتری از کد بهینه شوند:
- منطق Try/Catch: نسخه جدید از هر نوع منطق شرطی داخل بلوک‌های try/catch پشتیبانی می‌کند. این مورد پیش از این، در زمان انتشار نسخه پایدار ۱.۰، یک مانع سخت (Hard Blocker) برای بسیاری از کاربران بود.
- Props تخریب‌شده (Destructured): مقداردهی مجدد به یک prop تخریب‌شده در کامپوننت که سپس در یک closure تودرتو استفاده می‌شود، اکنون کاملاً پشتیبانی می‌شود. برای مثال، الگویی مانند
value = value ?? "this is a fallback"در داخل کامپوننتی که سپس در یک هندلرonClickلاگ می‌شود، پیش از این نادیده گرفته می‌شد. - کلیدهای محاسباتی (Computed Keys): استفاده از کلیدهای پویا برای ویژگی‌های اشیاء دیگر باعث Bailout نمی‌شود. این مورد هنگام استفاده از کتابخانه‌هایی مثل
clsxبرای تولید نام کلاس‌های پویا (مثلاً[items-${itemCount}]: itemCount > 0) بسیار رایج است.
برای تیم Outlyne، این اصلاحات سازگاری کامپایلر را برای ۷ تابع دیگر در سراسر اپلیکیشن آن‌ها گسترش داد: ۵ مورد به لطف بهبود try/catch و ۲ مورد به دلیل کلیدهای محاسباتی اشیاء.
همگام‌سازی زنجیره ابزارها
یکی از آزاردهنده‌ترین مسائل دوران Babel، «شکاف پوشش» (Coverage Gap) بود. توسعه‌دهندگان اغلب متوجه می‌شدند که لینتر آن‌ها (Oxlint) از نسخه‌ای متفاوت از کامپایلر نسبت به خط لوله بیلد استفاده می‌کند.
این تضاد منجر به تناقضات گیج‌کننده‌ای می‌شد. تیم Outlyne یک Issue اشتباه در oxc ثبت کرد زیرا یک کامپوننت در لینتر خطایی نمی‌داد اما همچنان در زمان بیلد بهینه نمی‌شد. مشخص شد که Oxlint از نسخه oxc-transform-react v0.145.0 استفاده می‌کرد که از آن الگو پشتیبانی می‌کرد، در حالی که فرآیند بیلد با نسخه v0.144.0 تست می‌شد.
با انتقال کل زنجیره ابزارها به oxc-transform-react مبتنی بر Rust، اکنون لینتر و فرآیند بیلد از دقیقاً یک منطق واحد استفاده می‌کنند. این امر تضمین می‌کند که اگر کامپوننتی در محیط توسعه بهینه شده است، در محیط Production نیز بهینه باقی بماند.
مسیرهای پیاده‌سازی
برای کسانی که از Vite v8+ استفاده می‌کنند، این انتقال ساده است. نسخه ۶.۱.۰ پلاگین @vitejs/plugin-react قابلیت «پشتیبانی آزمایشی از کامپایلر بومی React» را اضافه کرده است.
کاربران می‌توانند با پاس دادن { compiler: true } به پلاگین در تنظیمات Vite، این قابلیت را فعال کنند. این کار به آن‌ها اجازه می‌دهد oxc-transform-react را نصب کرده و @rolldown/plugin-babel را از وابستگی‌های dev در package.json حذف کنند و بدین ترتیب حجم زیادی از تنظیمات زائد را دور بریزند.
برای توسعه‌دهندگانی که از React Router در حالت Framework استفاده می‌کنند، فرآیند متفاوت است. از آنجایی که React Router از پلاگین Vite مخصوص خود استفاده می‌کند، تیم توصیه می‌کند از @acusti/vite-plugin-react-compiler استفاده شود. این پلاگین مینیمال اجازه می‌دهد کدبیس بدون توجه به بقیه خط لوله بیلد، کامپایل شود و جایگزین نیاز به vite-plugin-babel ، babel-plugin-react-compiler و @babel/preset-typescript می‌گردد.
محدودیت‌های باقی‌مانده
با وجود پیشرفت‌ها، کامپایلر Rust هنوز کامل نیست. دو الگوی خاص همچنان باعث می‌شوند کامپایلر از بهینه‌سازی کامپوننت‌ها صرف‌نظر کند:
- پرتاب خطا (Throw) از داخل یک بلوک try.
- استفاده از عملگرهای انتساب منطقی مانند
??=،&&=یا||=.
با این حال، چون زیرساخت ابزارها اکنون بر پایه Rust است، انتظار می‌رود این اصلاحات بسیار سریع‌تر از آنچه در اکوسیستم «بن‌بستِ» Babel اتفاق می‌افتاد، منتشر شوند.
این چرخش نشان‌دهنده یک روند گسترده‌تر در ابزارهای وب است: مهاجرت کل استک بیلد جاوااسکریپت به Rust برای همگامی با حجم عظیم کدهایی که توسط عامل‌های هوش مصنوعی تولید می‌شوند. هدف دیگر فقط رسیدن به «سرعت کافی» نیست، بلکه حذف کامل اصطکاک در فرآیند بیلد است.
توسعه‌دهندگان باید تنظیمات فعلی Vite خود را بازبینی کنند تا ببینند آیا هنوز بارهای زائد Babel را حمل می‌کنند یا خیر. مهاجرت به یک کامپایلر بومی Rust اکنون مستقیم‌ترین مسیر برای کاهش هزینه‌های CI و سرعت بخشیدن به چرخه‌های تکرار (Iteration Cycles) است.
گام بعدی شما
- تنظیمات Vite خود را بررسی کنید تا ببینید آیا هنوز وابستگی‌های قدیمی Babel را حمل می‌کنید یا خیر.
- اگر از React Router استفاده می‌کنید، پلاگین
@acustiرا برای تست سرعت بیلد امتحان کنید. - الگوهای
try/catchدر کدهای خود را بازبینی کنید تا ببینید کدام بخش‌ها اکنون قابلیت بهینه‌سازی دارند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو