مایکروسافت یازدهم آگوست، هفتمین preview از .NET 11 رو منتشر کرد؛ آخرین ایستگاه‌های preview قبل از نسخه‌ی نهایی که قراره نوامبر ۲۰۲۶ به‌عنوان یه نسخه‌ی Standard Term Support (STS) عرضه بشه. این preview تغییرات قابل‌توجهی تو کتابخونه‌ها، runtime، SDK، سی‌شارپ، ASP.NET Core، MAUI، Entity Framework Core، اف‌شارپ، و Windows Forms داره.

کتابخونه‌ها

چند تا اضافه‌ی جالب تو این بخش هست: پشتیبانی از نوع‌های اعشاری IEEE 754 و یه نوع generic برای اعداد مختلط (Complex<T>)، که برای کارهای علمی و محاسباتی مفیده. علاوه بر این، فشرده‌سازی HTTP request (نه فقط response که قبلاً بود) و کنترل قابل‌تنظیم برای eviction اتصالات HTTP هم اضافه شده. تو حوزه‌ی شبکه، API های جدیدی برای resolve کردن رکوردهای DNS اومده، و تو حوزه‌ی فایل، پشتیبانی از رمز عبور برای فایل‌های ZIP و چند تا API جدید برای ساخت، استخراج، و متادیتای ZIP هم اضافه شده.

Runtime

تمرکز اصلی رو بهبود Runtime Async بوده؛ با بهینه‌سازی‌های جدید تو tiering و tail-await که مستقیم به سرعت اجرای متدهای async کمک می‌کنه. یه نکته‌ی فنی جالب دیگه اینه که CoreCLR روی WebAssembly حالا کل test suite کتابخونه‌ها رو پاس می‌کنه؛ یعنی بلوغ اجرای .NET رو خود Wasm داره جدی‌تر می‌شه. بهبودهایی هم تو JIT، code generation، NativeAOT، و ابزارهای diagnostic اومده.

SDK

اینجا چند تا تغییر عملی برای کار روزمره هست:

• NativeAOT حالا به‌صورت پیش‌فرض تو دستور dotnet فعاله؛ یه قدم بزرگ به سمت این‌که compile کردن به native code استاندارد بشه، نه یه گزینه‌ی جانبی.
• MSBuild server به‌صورت پیش‌فرض فعاله؛ که یعنی build های بعدی معمولاً سریع‌تر انجام می‌شن چون از یه پروسه‌ی از قبل بالا استفاده می‌کنن.
• dotnet test چند تا قابلیت جدید گرفته: فلگ‌های سطح-اجرا مثل --timeout و --maximum-failed-tests، پشتیبانی از پروژه‌های Microsoft.Build.Traversal، بهبود گزارش‌گیری رو Microsoft.Testing.Platform، و پشتیبانی از دستگاه و محیط MAUI.
• اپ‌های file-based (همون قابلیت جدید اجرای مستقیم فایل‌های .cs بدون پروژه) حالا دستور dotnet reference و رفع چند باگ up-to-date-check رو هم دارن.
• publish کردن container حالا runtime های native پلتفرم رو ترجیح می‌ده.

سی‌شارپ

از نظر زبانی، چهار تا ویژگی مهم اضافه شده:

• break و continue با برچسب (labeled)؛ یعنی می‌شه مشخص کرد کدوم حلقه از چند تا حلقه‌ی تودرتو باید break یا continue بشه، بدون نیاز به flag های دستی.
• الگوهای union (union pattern) حالا هم خود union و هم مقدار داخلیش رو match می‌کنن.
• بهبود exhaustiveness checking برای type parameter هایی که به یه closed type محدود شدن.
• تغییراتی تو «Unsafe Evolution»؛ شامل یه حالت سازگاری (compat mode) و رفتار nameof تو کد unsafe.

ASP.NET Core

بخش Blazor بیشترین تغییرات رو گرفته:

• توقف خودکار circuit های Blazor موقع بی‌فعالیتی؛ که مصرف منابع سرور رو برای سشن‌های رهاشده کاهش می‌ده.
• یه ویژگی جدید به اسم CacheView برای کش کردن خروجی Blazor SSR.
• چند تا analyzer جدید برای Blazor که مشکلات رایج رو زودتر گزارش می‌کنن.
• QuickGrid حالا InitialItemIndex و ScrollToItemAsync رو پشتیبانی می‌کنه؛ یعنی کنترل بهتری رو موقعیت اسکرول و آیتم اولیه‌ی grid داری.
• ابزار wasm-tools به Emscripten 6 آپدیت شده.

علاوه بر این، Razor حالا attribute های literal رو برای پارامترهای کامپوننت از نوع union قبول می‌کنه، validation localization به‌صورت built-in اضافه شده، کلاینت SignalR .NET حالا بعد از redirect هم می‌تونه auth رو refresh کنه، و OpenAPI پشتیبانی از Server-Sent Events تو نسخه‌ی OpenAPI 3.2 رو گرفته.

.NET MAUI

چند تا قابلیت جدید و کاربردی:

• احراز هویت با passkey به‌صورت cross-platform؛ یعنی دیگه لازم نیست پیاده‌سازی جدا برای هر پلتفرم بنویسی.
• XAML Incremental Hot Reload؛ که سرعت دیدن تغییرات UI موقع توسعه رو بهبود می‌ده.
• الگوهای route جدید برای Shell.
• binding های RelativeSource که با AOT سازگارن.
• پشتیبانی از backend های platform-specific شخص ثالث.
• TabbedPage حالا رو پلتفرم‌های اپل از همون معماری handler استفاده می‌کنه که بقیه‌ی کنترل‌ها استفاده می‌کنن.

Entity Framework Core

بهبودهایی تو ترجمه‌ی کوئری LINQ، بهبود provider مربوط به Azure Cosmos DB، بهبود migration ها، و پشتیبانی از نوع Half رو SQLite اضافه شده.

اف‌شارپ

چهار تا بهبود کوچیک‌تر ولی مفید: binding های computation expression حالا داخل یه let ساده هم کار می‌کنن، attribute ها داخل ماژول‌ها و namespace های recursive درست resolve می‌شن، پیام تشخیصی واضح‌تری برای type abbreviation های generic اضافه شده، و یه باگ مربوط به محاسبه‌ی سایز StructLayout برای union های struct بدون داده رفع شده.

Windows Forms

تمرکز این بخش رو Dark Mode بوده؛ پنج تا pull request مستقیم به بهبود ظاهر تو حالت تاریک اختصاص داشته (شامل ToolTip، HelpProvider، LinkLabel، TabControl تودرتو، و آیکون‌های چک تو ToolStrip). علاوه بر این:

• یه حالت اختیاری جدید به اسم VisualStylesMode برای شخصی‌سازی بیشتر ظاهر کنترل‌ها.
• جلوگیری از فلاش سفید موقع باز شدن فرم‌ها تو dark mode، با تأخیر انداختن نمایش فرم تا زمانی که استایل‌ها اعمال بشن.
• توقف رندر موقع تغییرات دسته‌ای (bulk) رو کنترل‌ها، مثل تغییر هم‌زمان موقعیت و سایز.
• ظاهر toggle-switch برای CheckBox و RadioButton.
• رفع چند باگ پایداری، شامل یه کرش GDI+ تو SplitContainer و یه exception تو اسکرول ToolStrip.

این preview تو چه فضایی منتشر شده

نکته‌ی جالب اینه که واکنش جامعه‌ی توسعه‌دهنده‌ها به کل چرخه‌ی .NET 11 (نه فقط این preview) صرفاً مثبت نبوده. بعضی توسعه‌دهنده‌ها نسبت به افزایش پیچیدگی زبان سی‌شارپ و سرعت انتشار نسخه‌های بزرگ ابراز نگرانی کردن. همچنین، نقشه‌ی راه ASP.NET Core تو .NET 11 تمرکز زیادی رو «Agentic AI» گذاشته (از جمله پشتیبانی از Model Context Protocol تا اپلیکیشن‌های .NET بتونن به‌عنوان ابزار برای agent های هوش مصنوعی عمل کنن)؛ جهتی که بعضی توسعه‌دهنده‌ها معتقدن داره روی نیازهای اصلی و پایه‌ای framework سایه می‌ندازه.

چطور امتحانش کنیم

برای شروع، کافیه SDK نسخه‌ی .NET 11 رو نصب کنی. اگه رو ویندوز با Visual Studio کار می‌کنی، مایکروسافت توصیه می‌کنه از آخرین نسخه‌ی Visual Studio 2026 Insiders استفاده کنی؛ از Visual Studio Code هم با extension مربوط به C# Dev Kit می‌شه استفاده کرد. یادت باشه این هنوز preview است، نه نسخه‌ی نهایی، پس برای production حتماً صبر کن تا نسخه‌ی پایدار نوامبر منتشر بشه؛ ولی برای آشنایی زودهنگام با تغییرات و کاهش ریسک آپدیت آینده، امتحانش کردنش الان ارزش داره.

اگه از چند تا ابزار agentic (Claude Code، Cursor، Codex، Cline) هم‌زمان استفاده می‌کنی و خسته شدی از این‌که هر کدوم rate limit جدا داره، یا هر وقت quota یکی تموم می‌شه مجبوری دستی سوییچ کنی، OmniRoute دقیقاً برای همین مشکل ساخته شده. این یه AI gateway متن‌باز و local-first است که همه‌ی provider های مختلف (اوپن‌ای‌آی، آنتروپیک، گوگل، دیپ‌سیک و خیلی‌های دیگه) رو پشت یه endpoint واحد و سازگار با API اوپن‌ای‌آی جمع می‌کنه.

چیه دقیقاً و چطور کار می‌کنه

به‌جای این‌که هر ابزار کدنویسیت رو جدا به هر provider وصل کنی، فقط یه بار base URL ابزارت (مثلاً Claude Code یا Cursor) رو به یه آدرس local (پیش‌فرض localhost:20128/v1) اشاره می‌دی. OmniRoute پشت این آدرس، درخواست رو می‌گیره، بر اساس قوانین routing که خودت تعریف کردی (یا حالت auto) تصمیم می‌گیره کدوم provider جواب بده، و پاسخ رو به فرمتی که ابزارت انتظار داره (چه فرمت OpenAI، چه Claude، چه Gemini) برمی‌گردونه.

نصبش هم ساده‌ست:

npm install -g omniroute
omniroute

بعد از اجرا، هم API و هم یه داشبورد وب رو همون پورت ۲۰۱۲۸ بالا میان.

عدد و رقم‌های پروژه

طبق آمار رسمی خود پروژه، OmniRoute از ۱۳ فوریه‌ی ۲۰۲۶ (کمتر از چهار ماه پیش) شروع به کار کرده و در همین مدت کوتاه به بیش از ۲۰ هزار ستاره‌ی گیت‌هاب، حدود ۲۸۰۰ فورک، و مشارکت بیش از ۳۵۰ توسعه‌دهنده رسیده؛ با ۲۷۱ نسخه‌ی منتشرشده و بیش از ۴۰۰۰ pull request مرج‌شده. کل پروژه زیر لایسنس MIT هست، یعنی کاملاً متن‌باز و بدون محدودیت استفاده‌ی تجاری.

قابلیت‌های اصلی

Auto-fallback چندلایه: اگه یه provider به rate limit بخوره یا quota ش تموم بشه، OmniRoute تو چند میلی‌ثانیه، بدون این‌که کارت متوقف بشه، به provider بعدی سوییچ می‌کنه. این fallback سه‌لایه‌ست (سطح provider، سطح connection/کلید، سطح مدل)، یعنی یه کلید API خراب کل provider رو از کار نمی‌ندازه.

۱۷ استراتژی routing: از «اول رایگان‌ها رو مصرف کن» گرفته تا «همیشه ارزون‌ترین گزینه» یا «بار رو بین چند کلید پخش کن»، می‌شه دقیقاً مشخص کرد اولویت routing بر چه اساسی باشه.

فشرده‌سازی توکن: با ترکیب چند تا موتور فشرده‌سازی (که خودشون بهش می‌گن RTK و Caveman)، خروجی ابزارها و context تکراری رو قبل از رسیدن به مدل فشرده می‌کنه؛ طبق ادعای پروژه، بین ۱۵ تا ۹۵ درصد صرفه‌جویی تو مصرف توکن، بسته به نوع کار.

استفاده از quota رایگان: پروژه ادعا می‌کنه بیش از ۹۰ provider با پلن رایگان رو ردیابی می‌کنه و مصرف رایگان رو به‌صورت pool-deduped (بدون شمارش تکراری) جمع می‌زنه؛ رقمی که خودشون حدود ۱.۵ میلیارد توکن رایگان در ماه اعلام می‌کنن.

پشتیبانی از MCP و A2A: خود gateway به‌عنوان یه سرور MCP هم عمل می‌کنه (بیش از ۱۰۰ ابزار در قالب چند ده scope)، و از پروتکل A2A هم پشتیبانی می‌کنه؛ یعنی یه agent می‌تونه مستقیم خود OmniRoute رو به‌عنوان یه ابزار کنترل کنه، نه فقط ازش عبور کنه.

نکته‌ی مهم قبل از استفاده‌ی جدی

قبل از این‌که این ابزار رو رو یه workflow حساس یا production تکیه بدی، چند تا نکته رو باید در نظر بگیری. اول، مسیر کردن ترافیک از طریق gateway خودت، پردازش، شرایط استفاده، یا نگه‌داری داده‌ی provider اصلی رو حذف نمی‌کنه؛ داده‌ت هنوز به همون provider (مثلاً OpenAI یا آنتروپیک) می‌رسه، فقط از یه لایه‌ی اضافه عبور کرده. دوم، این ابزار خودش یه نقطه‌ی حیاتی تو مسیر درخواست‌هات می‌شه؛ اگه down بشه، تنظیماتش خراب بشه، یا دیتابیس local ش (SQLite) کرش کنه، همه‌ی ابزارهایی که ازش عبور می‌کنن تحت تأثیر قرار می‌گیرن. برای همین، برای استفاده‌ی جدی، حتماً باید persistence، بک‌آپ، و کنترل دسترسی مناسب رو خودت تنظیم کنی.

یه نکته‌ی دیگه هم اینه که چون این پروژه خیلی تازه و به‌شدت پرتغییره (۲۷۱ نسخه تو کمتر از چهار ماه)، بهتره قبل از هر آپدیت، یه نسخه‌ی مشخص رو pin کنی و رفتار ابزارهای کدنویسیت رو (streaming، tool call، context طولانی) بعد از هر آپدیت جدا تست کنی، نه این‌که فقط بر اساس لیست مدل‌ها قضاوت کنی که همه‌چیز درست کار می‌کنه.

جمع‌بندی

اگه خسته شدی از مدیریت دستی چند تا کلید API و برخورد مکرر با rate limit وسط کار، OmniRoute یه راه‌حل عملی و رایگانه که با یه دستور نصب می‌شه و تقریباً با هر ابزار agentic معروفی (Claude Code، Cursor، Codex، Cline، Copilot) سازگاره. ولی برای پروژه‌های production یا تیمی، بهتره اول یه دوره‌ی ارزیابی جدی (تست کیفیت پاسخ، latency، failover واقعی) قبل از تکیه‌ی کامل روش انجام بدی؛ چون production-ready بودن این ابزار، بیشتر به تنظیمات و تست‌های خودت بستگی داره تا صرفاً نصب و راه‌اندازیش.

اگه اسم WebAssembly (یا به اختصار Wasm) رو شنیدی و کنجکاو شدی دقیقاً چیه، جواب کوتاهش اینه: یه فرمت باینری برای اجرای کد با سرعت نزدیک به native، مستقیم تو مرورگر (و جاهای دیگه). ولی این جواب کوتاه نمی‌گه چرا این تکنولوژی این‌قدر مهمه. برای فهمیدنش بهتره از مشکلی شروع کنیم که Wasm حلش می‌کنه.

مشکلی که جاوااسکریپت نمی‌تونست حلش کنه

جاوااسکریپت تنها زبونیه که مرورگرها به‌صورت native اجرا می‌کنن. برای دهه‌ها، اگه می‌خواستی چیزی تو مرورگر اجرا بشه، مجبور بودی یا مستقیم جاوااسکریپت بنویسی، یا زبون دیگه‌ت رو به جاوااسکریپت compile کنی (مثل TypeScript). مشکل اینجاست که جاوااسکریپت یه زبون dynamically-typed و interpreted هست؛ حتی با موتورهای JIT فوق‌پیشرفته‌ای مثل V8، برای کارهای سنگین محاسباتی (پردازش تصویر، فیزیک بازی، رمزنگاری، پردازش صوت و ویدیو) هنوز به سقف عملکرد زبون‌های کامپایل‌شده مثل C++ یا Rust نمی‌رسه.

WebAssembly این محدودیت رو برمی‌داره. به‌جای این‌که مجبور باشی کد C++ یا Rust ت رو به جاوااسکریپت ترجمه کنی (که هم کند و هم ناقصه)، می‌تونی مستقیم به یه فرمت باینری فشرده و بهینه compile‌ش کنی که مرورگر می‌تونه تقریباً به همون سرعت کد native اجراش کنه.

چند تا ویژگی کلیدی

فرمت باینری، نه متنی: برخلاف جاوااسکریپت که یه متن قابل‌خوندنه، Wasm یه فرمت باینری فشرده‌ست. این یعنی هم فایلش کوچیک‌تره (دانلود سریع‌تر)، هم parse کردنش برای مرورگر سریع‌تره؛ چون نیازی به تحلیل سینتکس متنی نیست.

Sandboxed و امن: کد Wasm دقیقاً مثل جاوااسکریپت، تو یه محیط ایزوله (sandbox) اجرا می‌شه. نمی‌تونه مستقیم به فایل‌سیستم یا شبکه دسترسی پیدا کنه، مگه از طریق API هایی که خود جاوااسکریپت در اختیارش می‌ذاره. یعنی امنیتش مستقل از این‌که کد اصلی با چه زبونی نوشته شده، حفظ می‌شه.

مستقل از زبان مبدأ: Wasm خودش یه زبون برنامه‌نویسی نیست که مستقیم باهاش کد بنویسی (هرچند می‌شه). بیشتر یه target compilation است؛ یعنی زبون‌هایی مثل C، C++، Rust، Go، و حتی بخش‌هایی از پایتون می‌تونن بهش compile بشن.

نزدیک به سرعت native: چون فرمتش از قبل به یه ساختار شبیه assembly نزدیکه (برای همین اسمش Wasm است)، مرورگر نیازی به تفسیر خط‌به‌خط نداره و می‌تونه خیلی سریع‌تر از جاوااسکریپت معمولی اجراش کنه.

یه مثال ساده

فرض کن یه تابع محاسباتی سنگین به Rust داری:

#[no_mangle]
pub fn fibonacci(n: u32) -> u64 {
    if n <= 1 {
        return n as u64;
    }
    let mut a = 0u64;
    let mut b = 1u64;
    for _ in 2..=n {
        let temp = a + b;
        a = b;
        b = temp;
    }
    b
}

با ابزاری مثل wasm-pack، این کد به یه فایل .wasm compile می‌شه که می‌شه مستقیم تو جاوااسکریپت import و صداش زد:

import init, { fibonacci } from './pkg/my_wasm_module.js';

async function run() {
    await init();
    console.log(fibonacci(50)); // اجرا با سرعت نزدیک به native
}

run();

از دید جاوااسکریپت، fibonacci فقط یه تابع معمولیه، ولی پشت صحنه داره یه باینری کامپایل‌شده و بهینه اجرا می‌شه، نه کد تفسیرشده‌ی جاوااسکریپت.

کجاها واقعاً استفاده می‌شه

ابزارهای سنگین که به مرورگر آوردن: Figma بخش زیادی از موتور رندرش رو با WebAssembly پیاده کرده تا بتونه performance شبیه یه اپلیکیشن دسکتاپ رو تو مرورگر ارائه بده. AutoCAD نسخه‌ی وب خودش رو با پورت کردن دهه‌ها کد C++ به Wasm ساخته.

بازی‌ها و موتورهای گرافیکی: موتورهایی مثل Unity و Unreal Engine امکان export کردن بازی به WebAssembly رو دارن، که یعنی بازی‌های نسبتاً سنگین می‌تونن مستقیم تو مرورگر، بدون نصب هیچ پلاگینی، اجرا بشن.

پردازش تصویر و ویدیو: ابزارهایی مثل ffmpeg.wasm امکان encode/decode کردن ویدیو مستقیم تو مرورگر رو می‌دن، بدون این‌که فایل به سرور آپلود بشه؛ هم سریع‌تره، هم حریم خصوصی کاربر حفظ می‌شه.

اجرای زبون‌های دیگه تو مرورگر: پروژه‌هایی مثل Pyodide، پایتون رو کامل به WebAssembly compile کردن، یعنی می‌تونی کد پایتون واقعی رو مستقیم تو مرورگر، بدون سرور، اجرا کنی.

فراتر از مرورگر: WebAssembly دیگه محدود به مرورگر نیست. با استانداردی به اسم WASI (WebAssembly System Interface)، می‌شه Wasm رو مستقل از مرورگر، رو سرور یا edge computing هم اجرا کرد. کلادفلر Workers و Fastly Compute دقیقاً از همین قابلیت استفاده می‌کنن تا کد رو تو صدها دیتاسنتر مختلف، با startup time خیلی کمتر از یه کانتینر معمولی، اجرا کنن.

چیزی که WebAssembly نیست

یه سوءتفاهم رایج اینه که فکر کنیم Wasm قراره جای جاوااسکریپت رو بگیره. این‌طور نیست؛ Wasm نمی‌تونه مستقیم به DOM دسترسی داشته باشه یا event handler ثبت کنه. برای هر تعامل با صفحه (کلیک، تغییر استایل، دستکاری DOM)، هنوز باید از جاوااسکریپت به‌عنوان واسط استفاده کنی. Wasm بیشتر مکمل جاوااسکریپته تا جایگزینش؛ جاهایی که محاسبات سنگین لازمه، کار رو به Wasm می‌سپاری و بقیه‌ی تعامل با کاربر همچنان با جاوااسکریپت انجام می‌شه.

کِی واقعاً بهش نیاز داری

اگه داری یه اپلیکیشن وب معمولی می‌سازی (فرم، داشبورد، فروشگاه آنلاین)، به احتمال زیاد هیچ‌وقت مستقیم با WebAssembly سروکار پیدا نمی‌کنی؛ جاوااسکریپت (یا فریمورک‌های روش) کاملاً کافیه. Wasm زمانی وارد بازی می‌شه که یه بخش خاص از اپلیکیشنت واقعاً محاسبات سنگین داره (پردازش تصویر/صوت/ویدیو، رمزنگاری، فیزیک، parsing فایل‌های حجیم) و همون بخش داره performance اپ رو محسوس کند می‌کنه. تو اون حالت، می‌تونی فقط همون بخش خاص رو به Rust یا C++ بنویسی و به Wasm compile کنی، بدون این‌که مجبور بشی کل اپلیکیشن رو از جاوااسکریپت خارج کنی.

اگه امروز بخوای یه پروژه‌ی فرانت‌اند جدی بسازی، احتمالاً دیگه مستقیم سراغ React یا Vue خام نمی‌ری؛ سراغ یه meta-framework می‌ری که routing، server-side rendering، و بهینه‌سازی‌ها رو از قبل برات حل کرده. مشکل اینجاست که الان پنج تا گزینه‌ی جدی داری، هر کدوم با فلسفه‌ی متفاوت. تو این مقاله هر پنج تا رو از نظر کاربرد، مزیت، و محدودیت بررسی می‌کنیم.

Next.js (روی React)

Next.js امروز استاندارد de facto دنیای React است؛ توسعه‌ش رو Vercel هدایت می‌کنه و از App Router (مبتنی بر React Server Components) به‌عنوان معماری اصلیش استفاده می‌کنه.

مزیت‌ها: اکوسیستم و کامیونیتیش بزرگ‌تر از هر meta-framework دیگه‌ست؛ تقریباً هر مشکلی که باهاش مواجه بشی، قبلاً یه نفر دیگه هم باهاش مواجه شده و جواب رو جایی نوشته. React Server Components به‌طور واقعی حجم جاوااسکریپتی که به مرورگر می‌فرسته رو کم می‌کنه، چون بخشی از کامپوننت‌ها فقط رو سرور اجرا می‌شن. یکپارچگی خیلی خوبی با Vercel داره (deploy تقریباً بدون تنظیم اضافه)، و از static generation، server-side rendering، و incremental static regeneration به‌صورت هم‌زمان و قابل‌انتخاب پشتیبانی می‌کنه.

معایب: منحنی یادگیری App Router (مخصوصاً تفاوت Server Component و Client Component، و قوانین مربوط به این‌که کجا می‌شه از useState یا event handler استفاده کرد) برای تازه‌کارها گیج‌کننده‌ست. وابستگی معنوی و عملی به Vercel هم یه نگرانیه؛ هرچند می‌شه رو زیرساخت‌های دیگه هم deploy کرد، ولی بعضی ویژگی‌ها (مثل ISR بهینه) بهترین تجربه رو رو خود Vercel می‌دن. build time هم برای پروژه‌های بزرگ می‌تونه کند بشه.

کجا مناسبه: پروژه‌های تجاری بزرگ، محصولاتی که نیاز به SEO قوی دارن، تیم‌هایی که از قبل با React راحتن و می‌خوان بیشترین منابع آموزشی و کامیونیتی رو در اختیار داشته باشن.

Nuxt (روی Vue)

Nuxt همون نقشی که Next.js برای React بازی می‌کنه رو برای Vue بازی می‌کنه، با همون تیم اصلی Vue پشتش (Evan You هم مستقیم درگیرشه).

مزیت‌ها: تجربه‌ی توسعه‌ی خیلی هماهنگ و «batteries-included»؛ auto-import برای کامپوننت‌ها و composable ها، file-based routing، و Nitro (لایه‌ی سرور خودش) که به تنهایی deploy رو رو تقریباً هر پلتفرمی (Vercel، Netlify، Cloudflare Workers، یا حتی یه سرور Node ساده) بدون تغییر کد ممکن می‌کنه. مستندات و پیام‌های خطاش معمولاً واضح‌تر و کاربرپسندتر از Next.js هستن. Vue's Composition API هم به‌طور طبیعی با معماری Nuxt جفت می‌شه.

معایب: اکوسیستم کوچیک‌تر از Next.js، یعنی احتمال این‌که به یه مشکل خیلی خاص برخوردی که کسی قبلاً حلش نکرده، بیشتره. بعضی ویژگی‌های پیشرفته (مثل معادل دقیق React Server Components) هنوز به بلوغ Next.js نرسیدن. تقاضای بازار کار هم به‌طور کلی از React و Next.js کمتره.

کجا مناسبه: تیم‌هایی که از قبل Vue استفاده می‌کنن یا اون رو ترجیح می‌دن، پروژه‌هایی که می‌خوان انعطاف deploy رو (بدون قفل شدن رو یه پلتفرم خاص) حفظ کنن، و کسایی که یه تجربه‌ی توسعه‌ی هماهنگ‌تر و کم‌دردسرتر می‌خوان.

SvelteKit (روی Svelte)

SvelteKit فرق بنیادی‌تری با بقیه داره، چون خود Svelte هم یه فلسفه‌ی متفاوت داره: به‌جای virtual DOM، Svelte موقع build کد رو به جاوااسکریپت خالص و بهینه compile می‌کنه.

مزیت‌ها: چون Svelte خیلی از کار رو موقع build انجام می‌ده (نه runtime)، باندل خروجی معمولاً خیلی کوچیک‌تر و اجرا سریع‌تره؛ برای اپ‌هایی که performance رو سخت اندازه می‌گیرن این مزیت محسوسه. سینتکس Svelte هم به‌طور کلی مختصرتر و به HTML/CSS/JS استاندارد نزدیک‌تره، پس برای خیلی‌ها یادگیریش سریع‌تره. SvelteKit خودش هم adapter های رسمی برای deploy رو پلتفرم‌های مختلف داره.

معایب: اکوسیستم به‌طور قابل‌توجهی کوچیک‌تر از React و Vue است؛ تعداد کتابخونه‌های آماده، مثال‌ها، و متخصصینی که بشه استخدام کرد کمتره. بازار کار هم برای Svelte محدودتره، پس اگه هدفت جذب نیرو یا پیدا کردن شغله، این یه ریسکه. بعضی ابزارهای شخص ثالث (مخصوصاً کتابخونه‌های UI بزرگ) دیرتر یا هیچ‌وقت پشتیبانی از Svelte اضافه نمی‌کنن.

کجا مناسبه: پروژه‌هایی که performance و سایز باندل واقعاً حیاتیه (مثل اپ‌های موبایل-محور یا با شبکه‌ی ضعیف)، تیم‌های کوچیک که می‌خوان سریع یاد بگیرن و بسازن، و کسایی که از پیچیدگی اضافه‌ی اکوسیستم‌های بزرگ‌تر خسته شدن.

Remix (روی React)

Remix هم رو React ساخته شده، ولی فلسفه‌ش با Next.js فرق داره؛ Remix تمرکز خیلی زیادی روی استانداردهای وب (مثل Web Fetch API) و مدل قدیمی‌تر ولی قوی‌ترِ «فرم‌های HTML به‌عنوان روش اصلی mutation» داره. از سال ۲۰۲۴ به بعد، Remix و React Router به هم نزدیک‌تر شدن و تیمشون هم زیر چتر Shopify فعالیت می‌کنه.

مزیت‌ها: مدل data loading و mutation ش (با loader و action) خیلی ساده و قابل‌پیش‌بینیه، و به‌شدت رو progressive enhancement تمرکز داره؛ یعنی اپلیکیشن حتی بدون جاوااسکریپت هم (تا حد زیادی) کار می‌کنه، چون از فرم‌های HTML استاندارد استفاده می‌کنه. برای اپلیکیشن‌هایی با فرم‌های زیاد و تعامل سرور-محور، این مدل خیلی طبیعی‌تر از حالت‌های پیچیده‌ی client-side state حس می‌شه. نزدیکی به استانداردهای وب هم یعنی دانشی که یاد می‌گیری قابل‌انتقال‌تره.

معایب: اکوسیستمش نسبت به Next.js کوچیک‌تره، و بعد از ادغام با React Router، مسیر و آینده‌ی پروژه یه‌کم برای بعضی توسعه‌دهنده‌ها مبهم به نظر رسیده. پشتیبانی از React Server Components هم هنوز به بلوغ Next.js نرسیده.

کجا مناسبه: اپلیکیشن‌های فرم‌محور و data-heavy (مثل داشبورد ادمین یا پنل‌های مدیریتی)، تیم‌هایی که به progressive enhancement و استانداردهای وب اهمیت می‌دن، و پروژه‌هایی که می‌خوان از پیچیدگی مدل Server/Client Component فاصله بگیرن.

TanStack Start (روی React)

TanStack Start جدیدترین بازیگر این میدونه، از همون تیمی که TanStack Query و TanStack Router رو ساختن (Tanner Linsley). برخلاف بقیه که از یه framework بزرگ شروع کردن، TanStack Start از یه router کاملاً type-safe شروع شده و بهش قابلیت‌های full-stack اضافه کرده.

مزیت‌ها: type-safety فوق‌العاده‌ای داره؛ چون بر پایه‌ی TanStack Router ساخته شده، پارامترهای URL، search params، و حتی loader ها به‌طور کامل با TypeScript type-check می‌شن، چیزی که تو بقیه‌ی framework ها معمولاً باید دستی یا با ابزار جدا مدیریت بشه. ادغام native و روون با TanStack Query هم برای مدیریت state سرور یه مزیت بزرگه، مخصوصاً برای کسایی که از قبل با TanStack Query کار کردن.

معایب: جدیدترین گزینه‌ی این لیسته، یعنی هنوز اکوسیستم، مستندات کامل، و تعداد پروژه‌های production که باهاش ساخته شدن به‌اندازه‌ی بقیه نیست. برای تیم‌هایی که ریسک‌گریزن یا نیاز به یه framework کاملاً جاافتاده دارن، فعلاً انتخاب پرریسک‌تریه.

کجا مناسبه: پروژه‌هایی که TypeScript و type-safety براشون اولویت بالاییه، تیم‌هایی که از قبل با TanStack Query راحتن و می‌خوان همون فلسفه رو تو routing و SSR هم ادامه بدن، و کسایی که راحتن با یه ابزار نسبتاً جدیدتر کار کنن.

جدول مقایسه‌ی سریع

مقایسه‌ی سرعت: واقعیت پشت ادعاهای بازاریابی

یه سؤال رایج اینه: «مگه Vue همیشه از React سریع‌تر تبلیغ نمی‌شد؟» جواب کوتاه اینه که این ادعا برای زمان خودش درست بود، ولی چشم‌انداز از اون موقع عوض شده. ارزش داره این موضوع رو جدا و دقیق‌تر بررسی کنیم.

چرا Vue اول خودش رو «سبک‌تر و سریع‌تر» معرفی کرد

Vue (مخصوصاً نسخه‌های ۱ و ۲) از همون ابتدا مستقیم رو سایز باندل کوچیک‌تر و overhead کمتر نسبت به Angular و React اون دوره تمرکز کرد؛ و این ادعا واقعی بود. بخش زیادیش هم به همون مدل fine-grained reactivity برمی‌گشت که قبلاً توضیح دادیم: چون Vue دقیقاً می‌دونه کدوم بخش از UI به کدوم داده وابسته‌ست، لازم نیست مثل React یه virtual DOM کامل رو diff کنه؛ همین یعنی overhead کمتر بدون نیاز به بهینه‌سازی دستی.

چیزی که از اون موقع تغییر کرده

React فاصله رو کم کرده: React مدرن، با tree-shaking بهتر، و مخصوصاً با React Server Components (که بخشی از کامپوننت‌ها اصلاً جاوااسکریپتی به مرورگر نمی‌فرستن)، دیگه همون داستان باندل سنگین ۲۰۱۵ نیست.

Svelte وارد بازی شد و جلوتر افتاد: رو بنچمارک‌های معروف framework (مثل js-framework-benchmark)، این روزها معمولاً Svelte/SvelteKit جلوتر از هر دوی React و Vue قرار می‌گیره؛ نه Vue. دلیلش اینه که Svelte حتی از فلسفه‌ی Vue هم یه قدم جلوتر رفته: به‌جای این‌که یه reactivity engine رو runtime داشته باشه (حتی fine-grained)، خود Svelte موقع build کد رو مستقیم به جاوااسکریپت خام کامپایل می‌کنه و کل runtime رو حذف می‌کنه.

تفاوت React و Vue امروز خیلی کوچیکه: رو بیشتر بنچمارک‌های امروزی، React و Vue تو یه سطح قرار می‌گیرن؛ اختلافشون معمولاً چند درصده و بین نسخه‌های مختلف بنچمارک هم جابه‌جا می‌شه. چیزی که واقعاً فرق می‌کنه، رفتار پیش‌فرضه نه سقف عملکرد: React می‌تونه به همون سرعت Vue برسه، ولی نیاز به بهینه‌سازی دستی داره (useMemo، useCallback، React.memo)، در حالی که Vue این کار رو به‌صورت خودکار انجام می‌ده. یعنی داستان دقیق‌تر اینه که «Vue به‌سختی می‌شه به‌طور تصادفی کندش کرد»، نه این‌که «Vue همیشه سریع‌تره».

چرا تو دنیای واقعی این تفاوت‌ها کمتر اهمیت دارن

نکته‌ی مهم اینه که تو اکثر پروژه‌های واقعی، خود runtime engine (چه React، چه Vue، چه Svelte) به‌ندرت گلوگاه اصلی performance است. چیزهایی مثل سایز باندل کلی، استراتژی server-side rendering، بهینه‌سازی تصویر و فونت، و مقدار جاوااسکریپتی که واقعاً به کلاینت فرستاده می‌شه (دقیقاً همون چیزی که Next.js با Server Components و SvelteKit با کامپایل‌کردن موقع build سعی می‌کنن حلش کنن) معمولاً تأثیر خیلی بیشتری رو تجربه‌ی واقعی کاربر می‌ذارن تا میکروبنچمارک‌های خود reactivity engine.

جمع‌بندی سریع

رتبه‌بندی صادقانه برای سرعت خام runtime، امروز چیزی شبیه این است: SvelteKit معمولاً جلوتره (چون overhead رو موقع build حذف می‌کنه، نه runtime)، و React و Vue تقریباً هم‌سطح هستن، جایی که تجربه‌ی تیم و تصمیمات معماری بیشتر از خود engine رو نتیجه‌ی نهایی تأثیر می‌ذارن.

اگه دنبال امن‌ترین انتخاب با بیشترین منابع و کامیونیتی هستی، Next.js همچنان انتخاب پیش‌فرضه، مخصوصاً برای پروژه‌های تجاری بزرگ. اگه تیمت Vue رو ترجیح می‌ده یا می‌خواد انعطاف بیشتری تو deploy داشته باشه، Nuxt گزینه‌ی طبیعیه. اگه performance و سایز باندل برات حیاتیه و حاضری اکوسیستم کوچیک‌تر رو تحمل کنی، SvelteKit ارزش امتحان کردن داره. اگه پروژه‌ت پر از فرمه و به progressive enhancement اهمیت می‌دی، Remix فلسفه‌ی مناسب‌تری داره. و اگه TypeScript و type-safety اولویت اصلیته و راحتی با یه ابزار نسبتاً جدید مشکلی نداری، TanStack Start رو جدی بگیر.

نکته‌ی آخر اینه که هیچ‌کدوم از این‌ها انتخاب «اشتباه» نیستن؛ هر پنج‌تاشون production-ready هستن و شرکت‌های واقعی باهاشون محصولات واقعی می‌سازن. تفاوت واقعی بیشتر به این برمی‌گرده که تیمت با کدوم فلسفه راحت‌تره و پروژه‌ت به کدوم مزیت بیشتر نیاز داره، نه این‌که کدوم «بهتره».