observability بومی با @nestjs/observe

یه SDK رسمی جدید به اسم @nestjs/observe هم معرفی شده که برخلاف ابزارهای APM عمومی که HTTP server رو patch می‌کنن، مستقیم از طریق آپشن instrument توی چرخه‌ی عمر خود Nest جا می‌گیره؛ یعنی observability یه شهروند درجه‌یک فریم‌ورک شده، نه یه افزونه‌ی بیرونی.

پکیج‌های اقماری هم هم‌راستا شدن

پکیج‌های رسمی جانبی هم با همین ریتم آپدیت شدن؛ مثلاً @nestjs/config مستقیم به نسخه‌ی ۱۲.۰.۰ پرید (نسخه‌ی ۵ اصلاً وجود نداره)، کاملاً ESM شده، و validation محیطیش هم به‌جای کد اختصاصی Joi، حالا روی Standard Schema سوار شده.

و یه پچ سریع بلافاصله بعدش

طبق معمول انتشارهای بزرگ، همون روز یا خیلی زود بعد از ۱۲.۰.۰، یه نسخه‌ی ۱۲.۰.۱ هم منتشر شد که چندتا اصلاحیه‌ی کوچیک روی همین انتشار تازه اعمال کرده. تا لحظه‌ی نوشتن این خبر، ۱۲.۰.۱ آخرین نسخه‌ی موجود روی npm برای پکیج‌های اصلی NestJSه؛ پس اگه همین الان پروژه‌ی جدیدی با Nest 12 شروع می‌کنی، مطمئن شو که همین نسخه رو نصب کردی.

جمع‌بندی

NestJS 12 دقیقاً همون آپدیتیه که کاربرهای این فریم‌ورک سال‌ها منتظرش بودن: ESM بدون اجبار، آزادی انتخاب کتابخونه‌ی validation، و ابزارهای مدرن‌تر برای تست و بیلد. اگه پروژه‌ات هنوز روی نسخه‌ی ۱۱ ـه، عجله‌ای برای آپگرید نیست؛ ولی وقتی آماده بودی، nest upgrade --dry-run بهترین نقطه‌ی شروعه تا قبل از هر تغییری، دقیقاً بدونی قراره چه چیزهایی عوض بشه.

متد debounceId() مشخص می‌کنه این بازه‌ی زمانی برای کدوم resource حساب بشه، و maxWait سقف می‌ذاره که اگه event خیلی زیاد و پشت‌سرهم fire بشه، اجرای کار برای همیشه عقب نیفته. این debounce فقط رو همون listener اعمال می‌شه؛ بقیه‌ی listener های همون event همچنان هر بار اجرا می‌شن. یه نکته‌ی مهم: یه listener که #[DebounceFor] داره، نمی‌تونه هم‌زمان ShouldBeUnique رو implement کنه؛ dispatcher یه LogicException پرتاب می‌کنه، چون uniqueness اولین dispatch رو نگه می‌داره ولی debounce آخرین رو.

Queue::forward(): مسیردهی مجدد صف از یه نقطه

این متد جدید همه‌چیزی که به یه صف dispatch می‌شه رو به یه صف دیگه، یه connection دیگه، یا هر دو، منتقل می‌کنه؛ همه‌ی این‌ها از یه نقطه‌ی مرکزی تو service provider، بدون نیاز به تغییر کلاس‌های job یا محل‌های dispatch:

این forward ها از همون hook ای که Queue::route() استفاده می‌کنه عبور می‌کنن، پس مهم نیست job از چه مسیری به صف می‌رسه؛ همیشه اعمال می‌شه.

بهبودهای Process

سه تا اضافه‌ی مربوط به facade Process:

Process pool های iterable: قبلاً foreach روی ProcessPoolResults عملاً هیچی رو iterate نمی‌کرد (چون این کلاس هیچ پراپرتی public ای نداشت)، یعنی حلقه‌ای که برای چک کردن exit code نوشته می‌شد، بی‌صدا هیچی رو چک نمی‌کرد. حالا هر دو کلاس IteratorAggregate رو implement می‌کنن.

Exception جدا برای idle timeout: یه idle timeout حالا ProcessIdleTimedOutException خودش رو پرتاب می‌کنه، جدا از ProcessTimedOutException:

این تفکیک مهمه چون این دو حالت معنی کاملاً متفاوتی دارن: یکی یه پروسه‌ی گیرکرده‌ست، اون یکی فقط کنده.

Assertion های جدید برای Process fake: assertRanCount(2)، assertRanInOrder([...])، و متد recorded() برای فیلتر کردن جفت‌های پروسه/نتیجه‌ی ثبت‌شده با یه callback.

اضافات Eloquent Builder

• orWhereKey() و orWhereKeyNot() به whereKey() اضافه شدن؛ جایگزین بهتری برای orWhereIn('id', ...) تو کوئری‌هایی که نیاز به شرط primary key تو یه شاخه‌ی or دارن.
• wherePivot() و orWherePivot() حالا یه closure قبول می‌کنن که یه builder scope‌شده به مدل pivot بهش پاس می‌شه؛ یعنی scope های تعریف‌شده رو یه کلاس pivot سفارشی، مستقیم از کوئری رابطه قابل‌فراخوانی می‌شن.
• inOrderOf() حالا enum ها رو تو لیست مقادیرش قبول می‌کنه.

دیده‌شدن بهتر Queue Worker

یه event جدید به اسم JobReleased حالا موقعی که یه job از handler خودش یا از middleware ای مثل WithoutOverlapping به صف برگردونده می‌شه، fire می‌شه. تا قبل از این، JobReleasedAfterException فقط release هایی که به‌خاطر throw شدن یه exception اتفاق می‌افتادن رو پوشش می‌داد؛ یعنی release ناشی از overlap کاملاً نامرئی بود.

Worker ها هم حالا وقتی صفی که ازش مصرف می‌کنن pause می‌شه، یه پیام تو خروجی چاپ می‌کنن، و همین‌طور وقتی resume می‌شه. از وقتی API پاز صف تو Laravel 13.25 اومد، یه worker پاز‌شده فقط تولید خروجی رو متوقف می‌کرد و شبیه یه hang به نظر می‌رسید؛ این آپدیت این ابهام رو برطرف می‌کنه.

بقیه‌ی رفع باگ‌ها و بهبودها

• پشتیبانی از Guzzle 8 در کنار Guzzle 7.
• دستور db:seed --class=SpecificSeeder حالا همون خروجی پیشرفت RUNNING/DONE رو نشون می‌ده که seeder های تودرتو از قبل داشتن.
• یه دسته بهبود امنیت/پایداری Redis: چک‌های صف pause‌شده دیگه رو کلاستر cross-slot read انجام نمی‌دن، pruning تگ‌های کش همه‌ی master node ها رو اسکن می‌کنه و دیگه رو تگ‌های قدیمی loop بی‌نهایت نمی‌زنه، یه pipeline یا transaction fail‌شده اتصال رو قابل‌استفاده نگه می‌داره.
• درایور صف Cloud متد managedQueues() رو expose می‌کنه، و long-poll های timeout‌شده‌ی cloud agent حالا retry می‌شن.
• throwUnless() دیگه تو یه حالت خاص که باید throw می‌کرد، بی‌صدا هیچ کاری نمی‌کنه.
• تنظیم readonly=false تو Microsoft SQL Server رعایت می‌شه، و quote های تکی تو attribute های JSON path پستگرس escape می‌شن.

نکات آپگرید

طبق اعلام رسمی، هیچ breaking change ای برای اپلیکیشن‌های معمولی انتظار نمی‌ره. فقط دو نکته‌ی ریز رو باید بدونی: یه listener که #[DebounceFor] داره، اگه هم‌زمان ShouldBeUnique رو هم implement کنه، حالا یه LogicException می‌گیره؛ و internal های whereKey()/whereKeyNot() ادغام شدن، که فقط اگه Eloquent builder رو extend کرده باشی و این متدها رو override کرده باشی برات مهمه.

جمع‌بندی

اگه بخوایم Laravel 13.26 رو خلاصه کنیم: تمرکز اصلی رو مهاجرت تنبل بین storage ها (read-through disks)، کنترل بهتر روی صف‌ها (debounce برای listener، forward برای مسیردهی مجدد، دیده‌شدن بهتر worker)، و صیقل دادن جزئیات Process و Eloquent builder گذاشته. مثل چند نسخه‌ی اخیر، آپگرید نسبتاً بی‌دردسره و می‌شه بدون نگرانی زیاد بهش رفت.

یکی از جذاب‌ترین بخش‌های Wasp، مدل ارتباطی client-server شه. به‌جای این‌که خودت endpoint بسازی و بعد جدا یه fetch call بنویسی، فقط یه تابع سرور رو تعریف می‌کنی و Wasp خودش یه hook تایپ‌شده تو کلاینت تولید می‌کنه:

نکته‌ی مهم اینجاست که تایپ‌های TypeScript بین سرور و کلاینت به‌صورت خودکار sync می‌شن؛ اگه ساختار داده‌ای که از سرور برمی‌گرده عوض بشه، همون لحظه تو کلاینت هم خطای type-check می‌گیری، بدون این‌که خودت مجبور باشی این هماهنگی رو دستی نگه داری.

قابلیت‌های آماده که معمولاً باید خودت بسازی

Wasp خودش رو «batteries-included» معرفی می‌کنه، و این ادعا با فهرست قابلیت‌هاش پشتیبانی می‌شه:

• Auth کامل: ایمیل/پسورد، گوگل، گیت‌هاب، اسلک، مایکروسافت، همه با پیکربندی چند خطی.
• Background jobs: برای کارهایی که نباید request رو بلاک کنن.
• ارسال ایمیل: بدون نیاز به تنظیم دستی SMTP یا SDK جدا.
• Type-safety کامل full-stack: از دیتابیس تا کامپوننت React.
• Deploy با یه دستور: wasp deploy می‌تونه اپ رو مستقیم رو زیرساخت‌های پشتیبانی‌شده بالا بیاره.

نکته‌ی مهم: بدون lock-in

برخلاف پلتفرم‌هایی مثل Firebase یا Supabase که کدت به سرویس اونا وابسته می‌شه، Wasp ادعا می‌کنه هیچ lock-in ای نداره. خروجی کامپایل، کد خام React و Node.js و Prisma است که می‌تونی مستقیم تو پوشه‌ی .wasp/ ببینیش. یعنی اگه یه روز تصمیم گرفتی از Wasp CLI فاصله بگیری، کد تولیدشده رو برمی‌داری و مستقل ازش ادامه می‌دی؛ بدون runtime اختصاصی یا لایه‌ی مخفی سمت سرور.

چرا این روزها خودش رو «فریمورک عصر AI» معرفی می‌کنه

نکته‌ی جالب اینه که Wasp این روزها تمرکز بازاریابیش رو گذاشته رو این‌که برای کدنویسی با agent های هوش مصنوعی بهینه‌ست. استدلالشون اینه: چون Wasp یه توصیف سطح‌بالا و declarative از کل اپلیکیشن داره (نه هزاران فایل پراکنده‌ی boilerplate)، یه agent کدنویس می‌تونه ساختار کامل اپ رو خیلی سریع‌تر «بفهمه» و تغییرات درستی اعمال کنه. خود پروژه یه سری plugin و skill هم برای ابزارهایی مثل Claude Code منتشر کرده که مستقیم دانش Wasp رو به agent اضافه می‌کنه.

جالبه که این رویکرد هیچ ارتباطی به یه provider خاص هوش مصنوعی نداره؛ Wasp خودش هیچ AI داخلی نداره و اگه بخوای یه ویژگی AI به اپت اضافه کنی (مثلاً چت‌بات)، باید مدل دلخواهت (OpenAI، آنتروپیک، یا یه مدل local) رو مثل یه dependency معمولی Node.js وصل کنی؛ چیزی که خودشون توش دخالتی ندارن.

کجا این فریمورک جای خودش رو پیدا می‌کنه

Wasp دقیقاً یه خلأ خاص رو پر می‌کنه: جایی بین انعطاف کامل ولی کاردستی Next.js یا Remix (که همه‌چیز رو خودت وایر می‌کنی)، و انتزاع بالا ولی وابسته‌به-سرویس Firebase یا Supabase (که برای هر چیزی به یه پلتفرم شخص ثالث وابسته‌ای). اگه دنبال یه تجربه‌ی شبیه Rails یا Laravel هستی، ولی می‌خوای تو دنیای TypeScript و React بمونی، Wasp دقیقاً همین رو ارائه می‌ده.

معایب و محدودیت‌ها

طبیعتاً این سطح از انتزاع هزینه هم داره. اکوسیستم Wasp نسبت به Next.js یا حتی Nuxt خیلی کوچیک‌تره؛ تعداد پروژه‌های واقعی، منابع آموزشی، و توسعه‌دهنده‌های آشنا محدودتره. یادگیری DSL اختصاصیش هم یه گام اضافه‌ست، هرچند سینتکسش نسبتاً ساده‌ست. و چون فریمورک هنوز رسماً تو مرحله‌ی beta است (با این‌که برای ساخت بیش از ۵۰ هزار پروژه استفاده شده)، برای پروژه‌های خیلی بزرگ‌مقیاس یا سازمانی، ممکنه بلوغ لازم رو نداشته باشه. علاوه بر این، طبیعت «opinionated» فریمورک یعنی برای اپلیکیشن‌هایی که ساختارشون خیلی از الگوی معمول CRUD/auth/jobs فاصله داره، ممکنه بیشتر از این‌که کمک کنه، محدودت کنه.

جمع‌بندی

اگه داری یه SaaS یا اپلیکیشن full-stack نسبتاً استاندارد می‌سازی (auth، دیتابیس، چند تا صفحه، شاید یه سری background job) و می‌خوای سریع‌تر از صفر شروع کنی، بدون این‌که هفته‌ها وقت صرف wiring کردن قطعات مختلف کنی، Wasp ارزش امتحان کردن داره؛ مخصوصاً که رایگان، متن‌باز، و بدون lock-in است. اگه پروژه‌ت نیاز به کنترل خیلی دقیق روی هر جزئیات معماری داره، یا از قبل تیمی داری که با Next.js یا Nuxt راحته، احتمالاً همون مسیر آشناتر منطقی‌تره.

وقتی یه کاربر دیگه یه task جدید اضافه کنه، Collection سمت کلاینت به‌صورت خودکار آپدیت می‌شه و کامپوننت React (به لطف useTracker) دوباره رندر می‌شه؛ همه‌ی این‌ها بدون این‌که خودت مستقیم WebSocket handler بنویسی یا polling بزنی. این دقیقاً چیزیه که Meteor رو برای اپلیکیشن‌های real-time (چت، داشبورد زنده، ابزارهای همکاری تیمی) جذاب می‌کنه.

MongoDB به‌عنوان دیتابیس پیش‌فرض

Meteor از اول با MongoDB طراحی شده و این وابستگی عمیقه؛ نه یه انتخاب سطحی. سیستم reactivity، سینک شدن Collection ها بین سرور و کلاینت، و حتی امکان اجرای query های MongoDB مستقیم تو کلاینت (با یه minimongo که تو حافظه‌ی مرورگر اجرا می‌شه)، همه بر پایه‌ی مدل داده‌ی MongoDB ساخته شدن. اگه پروژه‌ت نیاز به یه دیتابیس رابطه‌ای مثل PostgreSQL داره، می‌شه با یه‌کم کار اضافه بهش وصلش کرد، ولی دیگه از خیلی از مزیت‌های خودکار Meteor بی‌بهره می‌مونی.

مزیت‌ها

سرعت توسعه‌ی اولیه: برای پروتوتایپ کردن سریع یه اپ real-time، کمتر فریمورکی می‌تونه به سرعت Meteor برسه؛ چون خیلی از کارهایی که معمولاً باید دستی پیاده‌سازی کنی (WebSocket، sync داده، hot code push) از قبل آماده‌ست.

Hot code push: Meteor می‌تونه آپدیت‌های جدید رو به کلاینت‌های متصل، بدون نیاز به رفرش کامل صفحه، پوش کنه.

بسته‌بندی کامل: بیلد، bundling، و حتی deploy (با Galaxy، سرویس هاستینگ خود Meteor، یا Docker) همه از قبل تو اکوسیستم فریمورک هماهنگ شدن.

معایب و محدودیت‌ها

وابستگی سنگین به MongoDB: اگه تیمت یا پروژه‌ت به یه دیتابیس رابطه‌ای نیاز داره، Meteor دیگه اون تجربه‌ی یکپارچه رو نمی‌ده.

اکوسیستم کوچیک‌تر و کم‌رونق‌تر: Meteor دیگه اون momentum اوایل دهه‌ی ۲۰۱۰ رو نداره. تعداد کتابخونه‌ها، تعداد سؤال‌های Stack Overflow، و تعداد پروژه‌های جدیدی که باهاش شروع می‌شن به‌طور محسوسی از React یا Vue خام (چه برسه به Next.js یا Nuxt) کمتره.

سایز باندل کلاینت: به‌خاطر minimongo و DDP client که باید رو مرورگر لود بشن، سایز باندل اولیه‌ی Meteor معمولاً بزرگ‌تر از یه اپ ساده‌ی React یا Vue است.

منحنی یادگیری غیرمستقیم: مفاهیمی مثل Collection، publication/subscription، و method call (روش استاندارد Meteor برای mutation) یه مدل ذهنی جدا از چیزیه که تو REST یا GraphQL معمول یاد می‌گیری؛ یعنی دانشش کمتر قابل‌انتقاله به پروژه‌های دیگه.

کجا هنوز منطقیه

اگه داری یه اپ کاملاً real-time می‌سازی (مثل یه ابزار همکاری زنده، یه چت، یا یه داشبورد که باید فوری آپدیت بشه)، و مشکلی با MongoDB به‌عنوان دیتابیس اصلی نداری، Meteor هنوز می‌تونه سرعت توسعه‌ی بالایی بهت بده؛ خصوصاً برای تیم‌های کوچیک یا MVP هایی که سرعت رسیدن به بازار مهم‌تر از انعطاف بلندمدت معماریه.

برای پروژه‌های عمومی‌تر که نیاز به real-time فوری ندارن، یا تیمت ترجیح می‌ده از یه استک رابطه‌ای و ابزارهای مدرن‌تر مثل Next.js یا Nuxt استفاده کنه، احتمالاً امروز گزینه‌های بهتری نسبت به Meteor پیدا می‌کنی؛ نه به این خاطر که Meteor بد شده، بلکه چون بقیه‌ی اکوسیستم جاوااسکریپت از اون موقع به‌طور قابل‌توجهی رشد کرده و خیلی از ایده‌های خوب Meteor (مثل full-stack بودن) رو به روش‌های مدرن‌تری پیاده کردن.

سی‌شارپ

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

• 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 حتماً صبر کن تا نسخه‌ی پایدار نوامبر منتشر بشه؛ ولی برای آشنایی زودهنگام با تغییرات و کاهش ریسک آپدیت آینده، امتحانش کردنش الان ارزش داره.

معایب: اکوسیستم کوچیک‌تر از 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 هستن و شرکت‌های واقعی باهاشون محصولات واقعی می‌سازن. تفاوت واقعی بیشتر به این برمی‌گرده که تیمت با کدوم فلسفه راحت‌تره و پروژه‌ت به کدوم مزیت بیشتر نیاز داره، نه این‌که کدوم «بهتره».

Vue از یه مدل fine-grained reactivity استفاده می‌کنه؛ سیستم دقیقاً می‌دونه کدوم بخش از template به کدوم متغیر وابسته‌ست، پس وقتی یه مقدار عوض می‌شه، فقط همون بخش خاص آپدیت می‌شه، بدون نیاز به اجرای دوباره‌ی کل تابع یا محاسبه‌ی diff:

این تفاوت معماری یعنی Vue معمولاً بدون نیاز به optimization دستی (مثل useMemo یا useCallback تو React) عملکرد خوبی می‌ده، در حالی که تو اپ‌های React بزرگ، مدیریت re-render های غیرضروری خودش به یه مهارت جدا تبدیل می‌شه.

سینتکس و ساختار فایل

React از JSX استفاده می‌کنه؛ یعنی HTML مستقیم داخل جاوااسکریپت نوشته می‌شه. این یعنی منطق و ساختار تو یه فایل و یه زبون هستن، که برای بعضی‌ها طبیعی‌تره و برای بعضی دیگه ادغام دو دنیای متفاوت به نظر می‌رسه.

Vue از Single-File Component ها (فایل‌های .vue) استفاده می‌کنه که سه بخش جدا داره: <template> برای HTML، <script> برای منطق، و <style> برای CSS، همه تو یه فایل ولی از هم مجزا. این ساختار برای کسایی که از پس‌زمینه‌ی HTML/CSS سنتی میان، معمولاً آشناتر و راحت‌تر برای شروعه.

منحنی یادگیری

Vue معمولاً به‌عنوان فریم‌ورک ساده‌تر برای شروع شناخته می‌شه؛ مستندات رسمیش هم به همین دلیل معروفه که خیلی واضح و گام‌به‌گامه. مفاهیم پایه (directive هایی مثل v-if، v-for، v-model) خیلی شبیه HTML گسترش‌یافته هستن و برای کسی که تازه شروع کرده، ورودی نرم‌تری فراهم می‌کنن.

React برای شروع هم سخت نیست، ولی چون خودش فقط کتابخونه‌ی UI است، رسیدن به یه استک کامل (routing، state management، فرم‌ها، styling) یعنی باید چند تا کتابخونه‌ی جدا رو هم یاد بگیری، و هر کدوم فلسفه‌ی خودشون رو دارن. همین‌طور مفاهیمی مثل closure، dependency array تو useEffect، و re-render logic، برای تازه‌کارها معمولاً چالش‌برانگیزترن.

اکوسیستم و بازار کار

اینجا React به‌وضوح جلوتره. اکوسیستمش بزرگ‌تره، تعداد کتابخونه‌های شخص ثالث بیشتره، و تو بازار کار (به‌خصوص تو شرکت‌های بزرگ آمریکایی و اروپایی) تقاضای بیشتری داره؛ خیلی از این تقاضا هم به خاطر React Native برای توسعه‌ی موبایله که مستقیم از همون دانش React استفاده می‌کنه.

Vue تو کشورهایی مثل چین و بعضی جاهای اروپا و آسیا محبوبیت بالایی داره، و اکوسیستمش هم به‌طور پیوسته در حال رشده (مخصوصاً بعد از معرفی Vue 3 و Composition API)، ولی از نظر حجم موقعیت شغلی جهانی، هنوز از React عقب‌تره.

Next.js و Nuxt: وقتی فریم‌ورک‌های بالادستی وارد می‌شن

امروز خیلی از پروژه‌های واقعی مستقیم از React یا Vue خام استفاده نمی‌کنن، بلکه از یه meta-framework روی همون پایه استفاده می‌کنن. برای React، Next.js استاندارد de facto شده؛ server-side rendering، routing فایل-محور، و بهینه‌سازی‌های image/font رو به‌صورت آماده می‌ده. برای Vue، معادلش Nuxt است که همون فلسفه رو دنبال می‌کنه. اگه داری یه پروژه‌ی جدید شروع می‌کنی، احتمالاً سؤال واقعی‌ت نه «React یا Vue»، بلکه «Next.js یا Nuxt» است، چون این‌ها تصمیمات معماری بیشتری رو از قبل برات گرفتن.

کدوم رو انتخاب کنیم

اگه تیمت از قبل با جاوااسکریپت راحته و می‌خواد از یه اکوسیستم بزرگ، فرصت شغلی بیشتر، و قابلیت اشتراک کد با موبایل (از طریق React Native) بهره ببره، React انتخاب امن‌تریه؛ مخصوصاً برای پروژه‌های بزرگ و تیم‌های بزرگ که به انعطاف معماری نیاز دارن.

اگه دنبال یه منحنی یادگیری ملایم‌تر، مستندات واضح، و یه استک هماهنگ و رسمی (بدون نیاز به تصمیم‌گیری‌های زیاد درباره‌ی کتابخونه‌ها) هستی، یا تیمت کوچیک‌تره و می‌خوای سریع‌تر به نتیجه برسی، Vue گزینه‌ی راحت‌تریه.

نکته‌ی آخر اینه که از نظر عملکرد خام، هر دو فریم‌ورک برای اکثریت قریب‌به‌اتفاق پروژه‌ها به‌اندازه‌ی کافی سریع هستن؛ تفاوت عملکردشون تو دنیای واقعی به‌ندرت فاکتور تعیین‌کننده‌ست. انتخاب واقعی معمولاً بیشتر به تجربه‌ی تیم، اکوسیستم مورد نیاز، و فلسفه‌ی توسعه‌ای که باهاش راحت‌تری برمی‌گرده، نه یه برتری فنی قطعی یکی نسبت به اون یکی.

پشتیبانی #[Delay] تو batch و bulk dispatch

جاب‌هایی که با attribute #[Delay] تأخیرشون رو مشخص می‌کردن، وقتی جدا dispatch می‌شدن درست کار می‌کردن، ولی Bus::batch() و Queue::bulk() فقط پراپرتی $delay رو می‌خوندن و این attribute رو نادیده می‌گرفتن. حالا هر دو مسیر یکسان رفتار می‌کنن.

چند صف هم‌زمان تو queue:clear

حالا می‌شه چند تا اسم صف رو با کاما جدا کرد، دقیقاً همون رفتاری که تو queue:work و queue:listen از قبل بود.

Laravel 13.23 (27 جولای 2026)

درایور لاگ ماهانه

درایور daily برای اپ‌هایی که لاگ زیاد تولید می‌کنن مناسبه؛ ولی اپ‌های کوچیک‌تر با یه پوشه پر از فایل‌های تقریباً خالی مواجه می‌شدن. درایور جدید monthly دقیقاً بین single و daily قرار می‌گیره و یه فایل به ازای هر ماه تقویمی می‌سازه:

پیش‌فرض نگه‌داری برای daily هنوز ۱۴ فایله، ولی برای monthly فقط ۳ فایل.

پشتیبانی از SES tenant تو SES v2

اگه از Amazon SES tenants استفاده می‌کنی (که reputation و تنظیمات رو بین گروه‌های مختلف فرستنده ایزوله می‌کنه)، حالا می‌شه هدر X-SES-TENANT-NAME رو مستقیم از خود mailable ست کرد:

کلوز ->using() برای تغییر ستون تو PostgreSQL

PostgreSQL بدون یه cast صریح، از تغییر نوع یه ستون به یه نوع ناسازگار امتناع می‌کنه. حالا می‌شه این cast رو مستقیم تو migration مشخص کرد:

این کلوز فقط برای PostgreSQL اعمال می‌شه؛ بقیه‌ی grammar ها نادیده‌اش می‌گیرن.

مقایسه‌ی timing-safe برای secret بای‌پس maintenance mode

مقایسه‌ی secret تو middleware و بوت‌استرپ maintenance mode از === به hash_equals() تغییر کرد؛ یه بهبود دفاع‌در-عمق، نه رفع یه باگ عملاً قابل سوءاستفاده.

Laravel 13.24 (4 آگوست 2026)

تشخیص رنگ غالب تصویر و پشتیبانی از HEIC

API تصویرسازی لاراول حالا می‌تونه رنگ غالب یه تصویر رو تشخیص بده، و از این رنگ به‌عنوان پس‌زمینه‌ی پیش‌فرض تو متدهای contain() و rotate() استفاده می‌کنه. علاوه بر این، ورودی AVIF و HEIC، خروجی toHeic()، و پشتیبانی از هر دو فرمت تو قانون validation تصویر هم اضافه شده.

متد modelKeys() روی Eloquent query builder

یه متد کمکی جدید برای گرفتن سریع کلیدهای مدل از یه کوئری، بدون نیاز به pluck('id') دستی.

قانون validation جدید array_keys

یه قانون جدید که کلیدهای غیرمنتظره‌ی یه آرایه رو رد می‌کنه، همراه با یه placeholder به اسم :unexpected تو پیام خطا.

رفع باگ کندی validation روی wildcard

قانون‌های تو دل الگوهای foo.*.bar تو آرایه‌های بزرگ، یه رفتار expansion درجه‌دومی (quadratic) داشتن که می‌تونست یه request رو بیش از یک دقیقه معطل کنه. این باگ حالا رفع شده.

Laravel 13.25 (11 آگوست 2026)

توقف همه‌ی صف‌ها با یه دستور

قبلاً باید هر صف رو جدا-جدا و بر اساس نام pause می‌کردی، که تو یه دیپلوی با دوجین worker پخش‌شده رو صف‌های مختلف، کار خسته‌کننده‌ای بود. حالا هر دو دستور یه فلگ --all می‌گیرن:

همون قابلیت رو فساد هم داره:

این سوییچ سراسری کاملاً مستقل از pause های تکی عمل می‌کنه؛ یعنی resumeAll() فقط فلگ سراسری رو پاک می‌کنه و صف‌هایی که جدا pause کرده بودی، pause شده باقی می‌مونن. این طراحی عمدیه تا یه اسکریپت دیپلوی به‌طور تصادفی صفی که یکی عمداً نگه داشته رو دوباره فعال نکنه.

artisan dev با یه رابط ترمینال جدید

قبلاً artisan dev از پکیج concurrently استفاده می‌کرد که همه‌ی پردازش‌ها رو تو یه فید مشترک قاطی می‌کرد. حالا از یه رابط جدید به اسم @laravel/multiplex استفاده می‌کنه که هر پردازش تب جدا خودش رو داره، امکان جست‌وجو، ری‌استارت جدا، و ری‌استارت خودکار در صورت کرش رو می‌ده:

توجه داشته باش که این ویژگی فعلاً فقط رو مک و لینوکس کار می‌کنه (ویندوز به همون concurrently قدیمی برمی‌گرده) و حداقل نسخه‌ی Node.js لازم برای این مسیر جدید، نسخه‌ی ۲۲.۱۳ است.

برگردوندن مستقیم Image از یه route

کلاس Image حالا اینترفیس Responsable رو پیاده‌سازی می‌کنه، پس می‌شه مستقیم از یه route برگردوندش:

هدر Content-Type هم متناسب با فرمت خروجی pipeline تنظیم می‌شه، نه فرمت فایل اصلی. علاوه بر این، Image::fromStream() هم اضافه شده که یه instance رو مستقیم از یه stream resource می‌سازه.

withoutCookies() روی response ها

به‌جای زنجیره کردن withoutCookie() برای هر کوکی جدا، حالا یه فرم جمع هم هست:

کمک‌کننده‌ی schema جدید foreignUlidFor()

foreignIdFor() و foreignUuidFor() از قبل بودن؛ حالا سه‌تایی کامل شده:

Request::all() حالا اولویت رو به input می‌ده

قبلاً وقتی یه فیلد input و یه فایل آپلودی هم‌نام بودن، آرایه‌ی نهایی، شیء UploadedFile رو نگه می‌داشت. حالا این ترتیب برعکس شده و مقدار input برنده می‌شه؛ file() تحت تأثیر این تغییر قرار نمی‌گیره.

جمع‌بندی

اگه بخوایم این چهار نسخه رو تو یه جمله خلاصه کنیم: تمرکز اصلی روی صف‌ها (پشتیبانی کامل‌تر از #[Delay]، pause سراسری، رویدادهای observability بیشتر)، بهبودهای مربوط به تصویر (HEIC، رنگ غالب، برگردوندن مستقیم از route)، و صیقل دادن تجربه‌ی توسعه‌دهنده با artisan dev بوده. هیچ‌کدوم از این چهار نسخه breaking change جدی برای اپلیکیشن‌های معمولی نداشتن، پس آپدیت کردن نسبتاً بی‌دردسره؛ فقط اگه از #[BindWhen] استفاده می‌کنی، حواست به نیاز PHP 8.5 باشه.

همین عدم قطعیت باعث شده خیلی از توزیع‌های لینوکس بزرگ (مثل Debian و Fedora) و کلود پرووایدرهای بزرگ (AWS با Amazon ElastiCache و Google Cloud با Memorystor) به سمت پشتیبانی از Valkey حرکت کنن یا حداقل گزینه‌ی Valkey رو کنار Redis ارائه بدن.

کدوم رو باید انتخاب کنی

اگه یه پروژه‌ی جدید رو از صفر شروع می‌کنی و لایسنس متن‌باز کاملاً آزاد (BSD) برات اهمیت داره، یا می‌خوای مطمئن باشی که هیچ تغییر لایسنسی تو آینده گریبانت رو نمی‌گیره، Valkey انتخاب منطقی‌تریه؛ مخصوصاً که پشتوانه‌ی چند تا از بزرگ‌ترین شرکت‌های زیرساخت دنیا رو داره و توسعه‌ش هم فعاله.

اگه از قبل با Redis کار می‌کنی و به ابزارها، افزونه‌ها یا سرویس‌های خاصی که مستقیم از Redis Ltd. میان وابسته‌ای (مثل Redis Enterprise یا بعضی ماژول‌های اختصاصی)، یا اصلاً لایسنس براتون مسئله‌ی حادی نیست، ادامه دادن با Redis همچنان گزینه‌ی معتبریه؛ خصوصاً که با AGPL نسخه‌ی ۸، دوباره به یه مسیر متن‌باز برگشته.

نکته‌ی عملی آخر: چون این دو پروژه از یه نقطه‌ی مشترک شروع شدن، مهاجرت بین‌شون (تو هر جهتی) هنوز نسبتاً کم‌دردسره، پس تصمیم امروز لزوماً برای همیشه قفل نمی‌شه. اگه مطمئن نیستی، شروع با Valkey ریسک کمتری داره؛ چون برگشتن به Redis همیشه یه گزینه‌ی باز باقی می‌مونه.

یعنی حتی اگر هیچ‌کدام از قابلیت‌های جدید را استفاده نکنی، باز هم احتمالاً تفاوت را حس می‌کنی.

Turbopack حالا تا ۹۰٪ حافظه‌ی کمتری مصرف می‌کند

یکی از بزرگ‌ترین تغییرات Next.js 16.3 مربوط به Turbopack است.

تا قبل از این نسخه، یکی از شکایت‌های رایج درباره‌ی dev server پروژه‌های بزرگ، مصرف بالای حافظه بود.

روی یک پروژه‌ی کوچک شاید متوجه نشوی، اما وقتی پروژه چند صد Route، تعداد زیادی dependency و فایل‌های زیاد دارد، مصرف RAM می‌تواند خیلی سریع بالا برود.

در Next.js 16.3 دو قابلیت مهم به‌صورت پیش‌فرض فعال شده‌اند:

• Disk Cache برای توسعه
• Memory Eviction

ترکیب این دو باعث شده Turbopack بتواند بهتر تصمیم بگیرد چه چیزهایی را در حافظه نگه دارد و چه چیزهایی را از RAM خارج کند.

نتیجه در بعضی پروژه‌های بزرگ چشمگیر بوده است.

البته مثل همیشه این عددها را نباید کورکورانه برای همه‌ی پروژه‌ها انتظار داشت. نوع پروژه، تعداد Routeها، dependencyها و نحوه‌ی استفاده از Server Componentها تأثیر زیادی دارند.

اما جهت تغییر مشخص است: Turbopack دیگر فقط دنبال سریع‌تر شدن نیست، بلکه می‌خواهد در پروژه‌های واقعی منابع کمتری مصرف کند.

به نظر من این یکی از آن تغییراتی است که توسعه‌دهنده‌هایی که لپ‌تاپ معمولی دارند بیشتر از همه حسش می‌کنند.

چون سریع بودن فقط این نیست که یک build چند ثانیه زودتر تمام شود؛ اگر سیستم وسط کار شروع کند به swap کردن و کند شدن، آن سرعت روی کاغذ چندان کاربردی نیست.

Buildهای سریع‌تر با FileSystem Cache

همان Cacheای که از Next.js 16.1 برای dev معرفی شده بود، حالا وارد مرحله‌ی بعدی شده و برای next build هم فعال شده است.

ایده ساده است:

اگر قبلاً چیزی محاسبه شده و هنوز معتبر است، دوباره از صفر انجامش نده.

این موضوع مخصوصاً در CI مهم است.

در پروژه‌هایی که مرتب build می‌شوند، زمان زیادی صرف کارهای تکراری می‌شود. حالا Turbopack می‌تواند بخشی از این خروجی‌ها را ذخیره کند و در buildهای بعدی دوباره استفاده کند.

طبق تست‌های تیم Next.js، بعضی پروژه‌ها در CI تا ۵.۵ برابر build سریع‌تر داشته‌اند.

جدول مقایسه زمان Build

این تغییر برای تیم‌هایی که روزانه چندین deploy انجام می‌دهند، شاید از هر قابلیت ظاهری دیگری مهم‌تر باشد.

چون چند ثانیه در یک build شاید مهم نباشد، اما وقتی صدها بار تکرار می‌شود، تبدیل به زمان واقعی تیم می‌شود.

TypeScript 7 و Type Checking سریع‌تر

Next.js 16.3 هم‌زمان با نسل جدید TypeScript آمده است.

TypeScript 7 یک تغییر مهم دارد: بخش‌هایی از آن با یک پیاده‌سازی Native بازنویسی شده که هدفش سرعت بالاتر در type checking است.

طبق اعلام تیم TypeScript، این نسخه می‌تواند در بعضی سناریوها چند برابر سریع‌تر باشد.

برای استفاده از آن در پروژه‌ی Next.js کافی است نسخه‌ی dependency را تغییر بدهی:

البته اینجا یک نکته وجود دارد.

سرعت بالاتر همیشه به معنی این نیست که همه‌ی پروژه‌ها دقیقاً همان نتیجه را می‌بینند. پروژه‌هایی با Type پیچیده، monorepoها یا dependencyهای سنگین ممکن است تفاوت بیشتری حس کنند.

اما برای پروژه‌هایی که TypeScript بخش بزرگی از زمان build را می‌گیرد، این تغییر ارزش بررسی دارد.

رندر سمت سرور سریع‌تر با Native Node.js Streams

یکی از تغییرات فنی جالب Next.js 16.3 در لایه‌ی رندرینگ App Router اتفاق افتاده است.

برای اینکه مرورگر بتواند محتوا را به‌صورت تدریجی دریافت کند، Next.js از Streamها استفاده می‌کند. این مدل باعث می‌شود لازم نباشد کاربر تا آماده شدن کل صفحه صبر کند و بخش‌های آماده‌شده زودتر ارسال شوند.

اما یک مشکل وجود داشت.

در محیط Node.js، Streamهای داخلی Node با Web Streams که در استانداردهای جدید وب استفاده می‌شوند، یکسان نیستند. در نتیجه بخشی از زمان و منابع صرف تبدیل بین این دو مدل می‌شد.

در Next.js 16.3 این مسیر تغییر کرده و در لایه‌ی رندرینگ App Router از Native Node.js Streams استفاده می‌شود.

نتیجه؟

کاهش overhead در SSR.

طبق بنچمارک‌های تیم Next.js، اپلیکیشن‌ها در شرایط بار بالا می‌توانند تا ۲۲٪ درخواست بیشتری را با همان شرایط پردازش کنند.

یعنی:

این تغییر شاید چیزی نباشد که هنگام توسعه‌ی روزمره فوراً ببینی، اما روی سرویس‌هایی که ترافیک بالا دارند، تفاوتش خودش را نشان می‌دهد.

این هم از آن دسته تغییراتی است که معمولاً کاربران متوجه وجودش نمی‌شوند؛ فقط متوجه می‌شوند سایت در فشار بالا بهتر دوام می‌آورد.

مستندات نسخه‌بندی‌شده برای AI Agentها

یکی از مسیرهایی که Next.js در نسخه‌های جدید جدی‌تر دنبال می‌کند، آماده کردن پروژه‌ها برای ابزارهای هوش مصنوعی است.

چند سال پیش اگر کسی می‌گفت فریمورک باید برای AI Agentها بهینه شود، احتمالاً خیلی‌ها تصور می‌کردند منظور فقط autocomplete داخل ادیتور است.

اما الان موضوع بزرگ‌تر شده.

Agentها قرار است کد بخوانند، تغییر بدهند، تست اجرا کنند و حتی تصمیم‌های معماری پیشنهاد کنند.

مشکل اینجاست که یک Agent بدون اطلاعات کافی درباره‌ی پروژه، ممکن است تصمیم‌هایی بگیرد که با ساختار پروژه هماهنگ نیست.

مثلاً:

• از API اشتباه استفاده کند.
• الگوی قدیمی پروژه را نادیده بگیرد.
• قوانین داخلی تیم را رعایت نکند.

Next.js 16.3 با اضافه کردن پشتیبانی بهتر برای Versioned Docs این مسیر را ساده‌تر می‌کند.

ایده این است که Agent بتواند به اطلاعات دقیق‌تر و هماهنگ با نسخه‌ی مورد استفاده‌ی پروژه دسترسی داشته باشد.

یعنی اگر پروژه روی Next.js 16.3 است، Agent لازم نیست از اطلاعات مربوط به نسخه‌های قدیمی‌تر استفاده کند.

این تغییر شاید امروز برای همه ضروری نباشد، اما اگر با ابزارهایی مثل Cursor، Claude Code یا Agentهای مشابه کار می‌کنی، اهمیتش بیشتر می‌شود.

درخواست‌های Prefetch کمتر، کنترل بهتر روی شبکه

یکی از بخش‌هایی که در Next.js همیشه بین سرعت و مصرف منابع تعادل ایجاد می‌کرد، Prefetch بود.

Prefetch یعنی قبل از اینکه کاربر روی یک لینک کلیک کند، Next.js حدس بزند که احتمالاً کاربر به آن صفحه می‌رود و بخشی از اطلاعات را از قبل دریافت کند.

این کار باعث Navigation سریع‌تر می‌شود.

اما یک مشکل دارد.

اگر تعداد لینک‌ها زیاد باشد، ممکن است درخواست‌های زیادی ایجاد شود؛ حتی برای صفحاتی که کاربر هیچ‌وقت باز نمی‌کند.

در Next.js 16.3 رفتار Prefetch بهینه‌تر شده تا درخواست‌های غیرضروری کمتر شوند.

هدف این نیست که Prefetch حذف شود؛ چون هنوز یکی از دلایل اصلی حس سریع بودن Next.js است.

هدف این است که هوشمندتر عمل کند.

یعنی:

• اطلاعات مهم زودتر آماده شوند.
• درخواست‌های بی‌مصرف کمتر شوند.
• فشار روی سرور و شبکه کاهش پیدا کند.

Cache بهتر برای Static Assetها

فایل‌های استاتیک مثل:

• تصویرها
• فایل‌های CSS
• JavaScript bundleها
• فونت‌ها

معمولاً باید مدت زیادی Cache شوند.

اما تنظیمات اشتباه Cache می‌تواند مشکل‌ساز شود.

اگر خیلی کوتاه باشد، کاربر مدام فایل‌های تکراری دانلود می‌کند.

اگر خیلی طولانی باشد، ممکن است نسخه‌ی قدیمی فایل نمایش داده شود.

Next.js 16.3 در این بخش رفتار Cache فایل‌های استاتیک را بهتر کرده تا استفاده از منابع شبکه منطقی‌تر شود.

این تغییر شاید در پروژه‌های کوچک دیده نشود، اما در سایت‌هایی که حجم زیادی Asset دارند، می‌تواند روی سرعت واقعی کاربران تأثیر بگذارد.

Custom Error Boundaries

مدیریت خطا در اپلیکیشن‌های بزرگ همیشه یک بخش مهم بوده است.

وقتی یک صفحه یا یک بخش از UI خراب می‌شود، اینکه کل برنامه از کار بیفتد تجربه‌ی خوبی نیست.

React و Next.js مدت‌ها امکان Error Boundary داشتند، اما Next.js 16.3 کنترل‌های بیشتری برای ساخت تجربه‌ی خطای بهتر ارائه می‌دهد.

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

مثلاً:

• یک بخش از داشبورد خراب شود.
• اما منوی اصلی همچنان کار کند.
• کاربر بتواند دوباره تلاش کند.

این مدل در اپلیکیشن‌های بزرگ اهمیت زیادی دارد.

Built-in Glob Imports؛ وارد کردن فایل‌ها ساده‌تر می‌شود

یکی دیگر از تغییرات کوچک اما کاربردی، اضافه شدن قابلیت Glob Import داخلی است.

گاهی در پروژه‌ها لازم است تعداد زیادی فایل را بر اساس یک الگو وارد کنی.

مثلاً:

• همه‌ی فایل‌های Markdown یک پوشه
• همه‌ی کامپوننت‌های یک مسیر
• همه‌ی فایل‌های ترجمه

قبلاً معمولاً برای این کار سراغ ابزارهای جانبی می‌رفتیم.

حالا Next.js پشتیبانی بهتری برای این سناریوها فراهم کرده است.

این قابلیت شاید به تنهایی دلیل آپدیت نباشد، اما در پروژه‌های Content-heavy یا سیستم‌های بزرگ مدیریت فایل، کار را راحت‌تر می‌کند.

Instant Navigation؛ نزدیک‌تر شدن Next.js به حس SPA

تا اینجا بیشتر درباره‌ی تغییرات زیرساختی صحبت کردیم.

اما بخشی که احتمالاً کاربران نهایی بیشتر حس می‌کنند، Navigation جدید است.

یکی از چالش‌های همیشگی Next.js این بوده:

چطور سرعت SPA را داشته باشیم، بدون اینکه مزیت‌های Server Components و Server Rendering را از دست بدهیم؟

Next.js 16.3 تلاش می‌کند این فاصله را کمتر کند.

Partial Prefetching

در نسخه‌های قبلی، Prefetch همیشه یک تعادل سخت داشت.

اگر زیاد Prefetch کنی:

• درخواست زیاد می‌شود.
• داده‌ی اضافی مصرف می‌شود.

اگر کم Prefetch کنی:

• Navigation کندتر حس می‌شود.

Partial Prefetching راه وسط است.

به جای اینکه کل Route را از قبل آماده کند، فقط بخش‌هایی که برای شروع Navigation لازم هستند را دریافت می‌کند.

مثلاً Shell صفحه سریع آماده می‌شود و بخش‌های سنگین‌تر بعداً می‌رسند.

نتیجه چیزی شبیه اپلیکیشن‌های SPA است، اما با معماری Server-Driven.

Instant Insights؛ فهمیدن اینکه Navigation واقعاً چه اتفاقی می‌افتد

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

آیا مشکل از:

• دریافت داده از API است؟
• Server Component زمان زیادی می‌برد؟
• Bundle سمت کلاینت بزرگ است؟
• Prefetch درست انجام نشده؟
• Cache کار نکرده؟

در Next.js 16.3 ابزارهای بهتری برای مشاهده‌ی رفتار Navigation اضافه شده تا توسعه‌دهنده بتواند دقیق‌تر بفهمد هنگام جابه‌جایی بین صفحات چه اتفاقی می‌افتد.

این همان چیزی است که در پروژه‌های بزرگ اهمیت پیدا می‌کند.

در پروژه‌ی کوچک شاید بگویی:

«این صفحه فقط یک ثانیه دیرتر باز می‌شود.»

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

Navigation Inspector؛ دیدن مسیر واقعی جابه‌جایی صفحات

وقتی یک کاربر روی یک لینک کلیک می‌کند، اتفاقات زیادی پشت صحنه رخ می‌دهد.

Next.js باید:

• Route را پیدا کند.
• داده‌های لازم را آماده کند.
• Cache را بررسی کند.
• Server Componentها را پردازش کند.
• نتیجه را به کلاینت برساند.

Navigation Inspector کمک می‌کند این مسیر واضح‌تر دیده شود.

این ابزار مخصوصاً برای زمانی کاربردی است که احساس می‌کنی یک Route باید سریع باشد، اما در عمل نیست.

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

این تغییر شاید برای همه‌ی توسعه‌دهنده‌ها روزانه استفاده نشود، اما برای Debug کردن پروژه‌های بزرگ ارزش زیادی دارد.

بهبود Incremental Static Regeneration (ISR)

ISR یکی از قابلیت‌هایی است که باعث شد Next.js در سال‌های اخیر بین سایت‌های محتوایی و اپلیکیشن‌های ترکیبی محبوب شود.

ایده ساده است:

صفحه را Static تولید کن، اما اجازه بده بعداً بدون Build کامل به‌روزرسانی شود.

مشکل همیشه این بوده که Cache و Revalidation در پروژه‌های بزرگ می‌تواند پیچیده شود.

Next.js 16.3 روی رفتار ISR هم بهبودهایی آورده تا مدیریت این سناریوها قابل پیش‌بینی‌تر شود.

این موضوع مخصوصاً برای سایت‌هایی که:

• محتوای زیاد دارند.
• تغییرات مداوم دارند.
• ولی نمی‌خواهند هر تغییر باعث Build کامل شود.

مهم است.

تست راحت‌تر با Playwright Test Helper

تست کردن Navigation و رفتارهای سمت سرور همیشه کمی سخت‌تر از تست کردن کامپوننت‌های ساده بوده است.

چون باید رفتار واقعی مرورگر، شبکه، Route و Rendering را هم در نظر بگیری.

Next.js 16.3 یک helper جدید برای Playwright ارائه کرده تا نوشتن تست‌های مرتبط با اپلیکیشن‌های Next.js راحت‌تر شود.

این یعنی تست کردن مواردی مثل:

• Navigation
• Loading State
• Error State
• رفتارهای App Router

کمتر نیاز به کد تکراری دارد.

برای تیم‌هایی که تست E2E جدی دارند، این تغییر کوچک نیست.

بهبودهای AI؛ Next.js برای دوره‌ی Agentها آماده‌تر می‌شود

اگر بخش‌های مختلف Next.js 16.3 را کنار هم بگذاری، یکی از پیام‌های واضح این نسخه این است:

فریمورک‌ها دیگر فقط برای انسان‌ها نوشته نمی‌شوند.

بخش زیادی از کدنویسی آینده احتمالاً با کمک Agentها انجام می‌شود.

اما یک Agent خوب فقط با داشتن یک مدل زبانی ساخته نمی‌شود.

باید:

• ساختار پروژه را بفهمد.
• قوانین تیم را بداند.
• بداند از چه الگوهایی استفاده کند.
• بداند کدام API مربوط به کدام نسخه است.

برای همین Next.js روی چند بخش کار کرده است.

AGENTS.md؛ قراردادن قوانین پروژه برای Agentها

اگر با ابزارهای AI کار کرده باشی، احتمالاً این مشکل را دیده‌ای.

هر بار باید توضیح بدهی:

«در این پروژه از Server Component استفاده کن.»

«این پوشه را تغییر نده.»

«برای API از این الگو استفاده کن.»

«قبل از تغییر، تست‌ها را اجرا کن.»

فایل AGENTS.md قرار است همین اطلاعات را به شکل استاندارد در اختیار Agent قرار دهد.

در واقع یک فایل راهنما برای هوش مصنوعی پروژه است.

چیزی شبیه README، اما با مخاطب متفاوت.

README برای انسان‌هاست.

AGENTS.md برای Agentها.

Skills؛ اضافه کردن توانایی‌های مشخص به Agent

یک Agent عمومی همه چیز را نمی‌داند.

گاهی می‌خواهی یک Agent دقیقاً برای یک کار خاص آماده باشد.

مثلاً:

• ساخت Componentهای UI
• کار با Database
• نوشتن تست
• مدیریت API

Skills این امکان را می‌دهد که توانایی‌های مشخص‌تری تعریف شود.

این مدل باعث می‌شود Agent به جای اینکه هر بار از صفر تصمیم بگیرد، یک مسیر مشخص داشته باشد.

Versioned Docs برای جلوگیری از اشتباه Agentها

یکی از مشکلات رایج ابزارهای AI این است که ممکن است اطلاعات قدیمی استفاده کنند.

مثلاً یک Agent ممکن است کدی پیشنهاد دهد که برای Next.js 14 درست بوده، اما در Next.js 16 روش بهتری وجود داشته باشد.

Versioned Docs کمک می‌کند Agent اطلاعات هماهنگ با نسخه‌ی واقعی پروژه دریافت کند.

این موضوع در فریمورک‌هایی مثل Next.js که مرتب تغییر می‌کنند، اهمیت زیادی دارد.

قابلیت‌های آزمایشی Next.js 16.3

همه‌ی تغییرات این نسخه برای استفاده‌ی عمومی آماده نیستند.

چند قابلیت هنوز Experimental هستند.

React Compiler مبتنی بر Rust

React Compiler یکی از پروژه‌هایی است که هدفش بهینه‌سازی خودکار React است.

ایده این است که کامپایلر بتواند بخشی از بهینه‌سازی‌هایی را انجام دهد که قبلاً توسعه‌دهنده باید دستی انجام می‌داد.

چیزهایی مثل:

• جلوگیری از Render اضافی
• مدیریت بهتر Memoization
• بهینه‌سازی محاسبات

نسخه‌ی Rust-based React Compiler تلاش می‌کند این فرآیند را سریع‌تر و مقیاس‌پذیرتر کند.

البته چون هنوز Experimental است، احتمالاً نباید همین فردا آن را روی Production فعال کرد.

اما مسیر آینده مشخص است.

React دارد بیشتر به سمت یک مدل Compiler-driven حرکت می‌کند.

Network Resilience؛ مقاوم‌تر شدن در برابر مشکلات شبکه

اپلیکیشن‌های واقعی همیشه در شرایط ایده‌آل اجرا نمی‌شوند.

کاربر ممکن است:

• اینترنت ضعیف داشته باشد.
• اتصال لحظه‌ای قطع شود.
• درخواست‌ها timeout شوند.

Network Resilience تلاش می‌کند رفتار اپلیکیشن در این شرایط بهتر شود.

هدف این نیست که مشکل شبکه جادویی حل شود.

هدف این است که برنامه در برابر این اتفاق‌ها رفتار قابل پیش‌بینی‌تری داشته باشد.

آیا باید همین حالا به Next.js 16.3 آپدیت کنیم؟

مثل همیشه جواب به پروژه بستگی دارد.

اگر یک پروژه‌ی حساس Production داری که چند هفته است بدون مشکل کار می‌کند، بهتر است طبق روال معمول:

• نسخه را در محیط تست بررسی کنی.
• Build را چک کنی.
• تست‌ها را اجرا کنی.
• بعد منتشر کنی.

اما اگر:

• پروژه‌ی بزرگی داری.
• RAM زیادی در dev مصرف می‌شود.
• CI Build طولانی است.
• از App Router استفاده می‌کنی.
• با ابزارهای AI کار می‌کنی.

Next.js 16.3 احتمالاً یکی از آن آپدیت‌هایی است که ارزش امتحان کردن دارد.

چیزی که این نسخه را جالب می‌کند این نیست که یک API عجیب اضافه کرده.

اتفاق مهم‌تر این است که تقریباً همه‌جا کمی بهتر شده.

Turbopack سبک‌تر شده.

Buildها سریع‌تر شده‌اند.

SSR بهینه‌تر شده.

Navigation روان‌تر شده.

و ابزارهای AI حالا بیشتر بخشی از اکوسیستم Next.js محسوب می‌شوند.

به نظر من Next.js 16.3 بیشتر از اینکه یک نسخه‌ی «با چند قابلیت جدید» باشد، یک قدم برای بالغ‌تر شدن فریمورک است.

قدم بعدی احتمالاً فقط سریع‌تر کردن اپلیکیشن نیست؛ بلکه ساختن محیطی است که انسان و Agent بتوانند کنار هم راحت‌تر محصول بسازند.

چه زمانی باید از template.tsx استفاده کنیم؟

زمانی که عدم حفظ State و اجرای مجدد کد با هر تغییر صفحه رفتار مطلوب ما باشد!

۱. انیمیشن‌های ورود و خروج (Enter/Exit Animations)

یکی از کاربردی‌ترین سناریوها، صفحاتی مثل ورود و ثبت‌نام (Sign In / Sign Up) است. اگر در این صفحات وکتورها، المان‌های گرافیکی انتزاعی یا انیمیشن‌های موشن (مثلاً با Framer Motion) دارید و می‌خواهید کاربر با رفتن از فرم Sign In به Sign Up، دوباره اجرای کامل انیمیشن‌ها و ریست شدن حالت‌ها را تجربه کند، template.tsx گزینه انتخابی شماست.

۲. لاگ‌برداری و Analytics بر اساس بازدید صفحه

اگر نیاز دارید با هربار ورود کاربر به هرکدام از صفحات فرعی، یک useEffect اجرا شده و اطلاعاتی مثل Page View ارسال شود.

۳. ریست شدن فرم‌ها یا Stateهای وابسته به Route

وقتی می‌خواهید با جابه‌جایی بین مسیرها، حالت‌های ورودی کاربر کلاً پاک شوند.

نمونه کد عملی

برای تعریف پروپ‌های کامپوننت در ری‌اکت و نکست، استفاده از type ساختار تمیزتر و یکدست‌تری ایجاد می‌کند:

چرا باید با احتیاط از آن استفاده کرد؟

استفاده بی‌مورد از template.tsx به جای layout.tsx می‌تواند روی تجربه کاربری و عملکرد برنامه تأثیر منفی بگذارد:

• افت فریم و انیمیشن‌های اضافی: اگر المان‌های سنگینی درون Template قرار دهید، با هر جابه‌جایی کوچک فریم‌ها مجدداً ساخته می‌شوند که می‌تواند باعث Perceived Latency (حس کندی) شود.

• از دست رفتن Scroll Position یا حالت‌های داخلی: فرم‌ها یا کامپوننت‌هایی که انتظار دارید حالتشان حفظ شود، با هر Navigation کلاً ریست خواهند شد.

خلاصه تصمیم‌گیری

• اگر می‌خواهید هدر، فوتر، Sidebar یا Stateها ثابت بمانند ➔ از layout.tsx استفاده کنید.

• اگر می‌خواهید با هر تغییر مسیر، انیمیشن‌ها مجدداً اجرا شده و Effectها ریست شوند ➔ از template.tsx استفاده کنید.

قانون اعتبارسنجی base64

نحوه استفاده

چرا این ویژگی مهم است؟

• رشته باید به درستی decode شود
• پس از decode و encode مجدد، باید دقیقاً همان رشته اولیه تولید شود
• این یعنی اشتباهات Padding یا کاراکترهای اضافی به راحتی شناسایی می‌شوند

اتریبیوت زمینه‌ای #[RequestAttribute]

مشکل چیست؟

راه‌حل جدید

فرمت‌های خروجی بیشتر برای کامپوننت Image

چه چیزی اضافه شده؟

• toPng()
• toGif()
• toAvif()
• toBmp()

مثال استفاده

اصلاح باگ مهم

Application Builder قابل شخصی‌سازی

چه تغییری ایجاد شده؟

Subsplit کامپوننت Concurrency

سایر اصلاحات و بهبودها

پایگاه داده

• Callbackهای Rollback: callbackهای تراکنش‌های دیتابیس حالا به درستی فراخوانی می‌شوند (PR #60777)
• Lost Connection: یک پیام خطای جدید برای از دست دادن اتصال شناسایی شده که امکان reconnect خودکار را فراهم می‌کند (PR #60819)
• Question Marks: علامت سوال در Grammar::whereColumn() به درستی escape می‌شود (PR #60832)

لاگ و کش

• LogManager: ارسال enum به LogManager::forgetChannel() دیگر TypeError نمی‌دهد (PR #60801)
• RedisTaggedCache: متد decrement() حالا enum keys را به درستی مدیریت می‌کند (PR #60821)

رشته‌ها و Utilityها

• Str::wordWrap(): حالا رشته‌های multibyte را به درستی مدیریت می‌کند (PR #60814)

اتریبیوت‌ها و Dependency Injection

• Contextual Attribute Caching: کش کردن اتریبیوت‌های زمینه‌ای دیگر بین propertyهای یک کلاس تداخل ایجاد نمی‌کند (PR #60815)
• Concurrency Exception: پارامترهای falsey در exceptionهای concurrency حفظ می‌شوند (PR #60822)

دستورات و Pipeline

• Serve Command: پارس کردن پورت host در دستور serve اصلاح شده است (PR #60828)
• Pipeline Hub: یک undefined index در Pipeline\Hub::pipe() برطرف شده است (PR #60802)

Jobها و Queue

• InvalidPayloadException: پیام‌های این exception حالا نام job و queue را شامل می‌شوند که دیباگ را آسان‌تر می‌کند (PR #60799)

مقایسه با نسخه‌های قبلی

• Developer Experience: اتریبیوت‌های جدید مثل #[RouteKey] و #[RequestAttribute] کد را خواناتر و نگهداری آن را آسان‌تر می‌کنند
• Validation: اضافه شدن قانون base64 نشان می‌دهد که لاراول به نیازهای واقعی توسعه‌دهندگان گوش می‌دهد
• Image Processing: پشتیبانی از فرمت‌های مدرن مثل AVIF نشان‌دهنده به‌روز بودن لاراول با استانداردهای وب است

مزایا و معایب به‌روزرسانی

• کاهش کد boilerplate با اتریبیوت‌های جدید
• اعتبارسنجی دقیق‌تر با قانون base64
• انعطاف‌پذیری بیشتر در پردازش تصاویر
• دیباگ آسان‌تر با پیام‌های خطای بهتر

• این یک نسخه مینور است و تغییرات breaking change ندارد
• برای استفاده از ویژگی‌های جدید، باید PHP 8.1 یا بالاتر داشته باشید (به دلیل استفاده از Attributes)

جمع‌بندی نهایی و نگاه شخصی

سوالات متداول

برای output هم:

چون immutable هست، ساختن چند variant از یه عکس تمیزه:

دو driver داره — GD و Imagick — و می‌تونی per-image هم انتخاب کنی:

یه نکته‌ی مهم: خود intervention/image به‌عنوان suggested dependency اضافه شده، نه required. یعنی باید خودت نصبش کنی:

ویژگی WithoutMiddleware

یه attribute جدید اضافه شده که counterpart ویژگی #[Middleware] هست. تا الان می‌تونستی روی کل controller یه middleware بذاری و برای بعضی method ها استثنا بدی. حالا این کار رو می‌تونی با attribute بکنی:

یه نکته‌ی ظریف: از ReflectionAttribute::IS_INSTANCEOF استفاده می‌کنه، یعنی subclass های اون middleware هم automatically exclude می‌شن.

پیشوند جداگانه برای Session در Redis

اگه هم SESSION_DRIVER و هم CACHE_STORE هر دو به Redis اشاره می‌کنن، تا الان session ها از همون prefix که برای cache تنظیم کردی استفاده می‌کردن. این debug کردن Redis keyspace رو مشکل می‌کرد.

حالا می‌تونی توی config/session.php یه prefix جداگانه بذاری:

cache store قبل از اعمال session prefix کلون می‌شه، پس این تغییر روی cache key ها تاثیر نمی‌ذاره.

incrementEachQuietly و decrementEachQuietly

Eloquent قبلاً incrementQuietly() و decrementQuietly() داشت که یه column رو بدون trigger کردن model event تغییر می‌دادن. این نسخه نسخه‌ی multi-column اینا رو اضافه کرده:

وقتی داری یه batch operation انجام می‌دی و نمی‌خوای event هایی مثل saved یا updated fire بشن، این دقیقاً چیزیه که می‌خوای.

Enum به‌عنوان کلید WithoutOverlapping

WithoutOverlapping middleware برای queue jobs الان مستقیم enum قبول می‌کنه:

قبلاً باید enum رو به string تبدیل می‌کردی. این تغییر backward compatible هست.

بقیه چیزهای کوچیک ولی مفید

چند چیز دیگه که کمتر headline می‌گیرن ولی در عمل کاربرد دارن:

make:migration حالا timestamp prefix هایی می‌سازه که collision-free و مرتب هستن — مشکل قدیمی که دو migration همزمان ساخته‌شده اسم تکراری می‌گرفتن.

#[SensitiveParameter] به parameter هایی که secret حمل می‌کنن اضافه شده، یعنی password ها و token ها دیگه توی stack trace نمایش داده نمی‌شن.

Storage::assertEmpty() اضافه شده که توی test ها مفیده.

Str::containsAll() دیگه برای آرایه‌ی خالی true برنمی‌گردونه — یه bug قدیمی که رفتار غیرمنطقی داشت.

Number::forHumans() دیگه برای عددهای خیلی کوچیک منفی، -0 برنمی‌گردونه.

upgrade کردن

تغییر breaking ای وجود نداره. اگه می‌خوای از Image facade استفاده کنی، فقط intervention/image رو نصب کن. بقیه‌ی تغییرات opt-in هستن یا bug fix.

فعال کردنش یه flag می‌خواد:

برای CI هم می‌شه از این استفاده کرد: کافیه پوشه‌ی .next رو بین runها کش کنی. وقتی Turbopack اون دایرکتوری رو اول build پیدا کنه، از کار قبلی استفاده می‌کنه به‌جای اینکه همه‌چیز رو از صفر compile کنه.

React Compiler با Rust

React Compiler از نسخه‌ی ۱۶.۰ توی Next.js stable بوده، ولی تا الان فقط به‌عنوان یه Babel transform اجرا می‌شد. مشکل اینجا بود که Babel روی پروژه‌های بزرگ سنگین می‌شد و build رو کند می‌کرد.

تیم React یه پورت native از این compiler با Rust نوشته، و تیم Turbopack سریع این رو integrate کرده. نتایج اولیه روی پروژه‌هایی مثل v0 نشون می‌ده که compile time بین ۲۰ تا ۵۰ درصد بهتر می‌شه. فعلاً experimental هست:

import.meta.glob

Turbopack حالا از API ای که Vite معروفش کرده پشتیبانی می‌کنه:

این به‌جای اینکه مجبور بشی اسم همه‌ی فایل‌ها رو hardcode کنی، هر فایلی که با pattern مطابقت داشته باشه رو import می‌کنه. نتیجه یه object هست که key‌هاش path فایل‌هاست:

می‌تونی با eager: true همه‌شون رو بلافاصله import کنی، یا فقط چند export خاص رو بگیری، یا pattern‌های منفی بگذاری. file watcher هم بهش وصله — اگه فایلی اضافه یا حذف شد، خودش recompile می‌کنه.

یه نکته: این feature فقط روی Turbopack کار می‌کنه. اگه هنوز با --webpack build می‌گیری، اینجا نیست.

HMR سریع‌تر و runtime کوچیک‌تر

دو بهبود دیگه که کمتر headline می‌گیرن ولی در عمل احساس می‌شن: اول اینکه HMR subscription tracking بهتر شده — با یکی کردن چند subscription در جاهایی که قبلاً جداگانه بودن، dev server cold start روی اپ‌های پیچیده بیش از ۱۵ درصد سریع‌تر شده. دوم اینکه runtime code ای که Turbopack به هر route اضافه می‌کنه کوچیک‌تر شده — چون حالا فقط کدی که واقعاً استفاده می‌شه (مثل WebAssembly loader یا worker support) شیپ می‌شه، نه همه‌چیز یکجا.

یه feature کوچیک‌تر هم برای monorepoها اومده: با turbopackLocalPostcssConfig: true می‌تونی per-package پیکربندی PostCSS داشته باشی به‌جای اینکه همه از root config بخوننن.

اگه الان روی Next.js 16.x هستی، این آپدیت شاید مهم‌ترین چیزیه که از نظر DX روزانه حسش می‌کنی — نه یه feature جدید، بلکه اینکه وقتی ساعت‌ها روی پروژه کار می‌کنی، IDE و dev server با هم دیگه دعوا نمی‌کنن سر رم.

Skills: وقتی داک کافی نیست

Skills برای workflow‌های چندمرحله‌ای‌اند — جایی که داک‌ها تنها نمی‌تونن agent رو از اول تا آخر هدایت کنن. سه Skill جدید اضافه شده:

next-dev-loop: به agent دسترسی به dev loop کامل می‌ده — مرورگر، console، network، و درخت React. بعد از هر ویرایش می‌تونه ببینه صفحه هنوز کار می‌کنه یا نه.

next-cache-components-adoption: Cache Components رو توی پروژه فعال می‌کنه و یه feature در یه زمان پیش می‌ره. دو mode داره: incremental که یه PR مکانیکی می‌سازه و بقیه رو می‌ذاره برای بعد، و direct که همه‌ی route‌ها رو یه‌جا روی یه branch تغییر می‌ده.

next-cache-components-optimizer: یه route رو برای instant navigation بهینه می‌کنه با یه حلقه‌ی observe-fix-iterate روی static shell. قبل و بعد از هر تغییر screenshot می‌گیره؛ اگه تصاویر یکسان باشن، تغییر rollback می‌شه.

Agent Browser با React introspection

next-browser که توی ۱۶.۲ اضافه شده بود حالا merge شده توی agent-browser — یه CLI همه‌منظوره که فراتر از Next.js هم کار می‌کنه.

نسخه‌ی ۰.۲۷ یه چیز مهم اضافه کرده: React DevTools introspection. Agent‌ها الان می‌تونن درخت کامپوننت رو لیست کنن، یه کامپوننت خاص رو inspect کنن، re-renderها رو profile کنن، و ببینن چی یه render رو نگه داشته.

Actionable errors: خطا با دستورالعمل

وقتی Cache Components فعاله، یه await روی سرور یه انتخابه. Instant Insights این انتخاب رو به‌عنوان یه error با سه fix مشخص نشون می‌ده: Stream با <Suspense>، Cache با "use cache"، یا Block با export const instant = false.

اما مهم‌تر از خود error، یه دکمه‌ی «Copy prompt» اضافه شده. این دکمه fix انتخاب‌شده رو بسته‌بندی می‌کنه توی یه پرامپت آماده برای agent: شناسایی کد مشکل‌دار، خوندن داک مربوط، اعمال pattern، و تایید نتیجه توی مرورگر از طریق next-dev-loop.

همین fix menu توی terminal هم هست. next build و next dev هر دو خطاها رو با گزینه‌های labeled و لینک به بخش مربوطه از داک‌ها output می‌کنن — یعنی agent‌هایی که dev overlay ندارن و فقط terminal رو می‌خونن همون اطلاعات رو می‌گیرن.

هر error یه صفحه‌ی مجزا روی nextjs.org/docs/messages داره که برای خوندن توسط agent‌ها نوشته شده. هر صفحه همون ساختار رو داره: Patterns، Trade-offs، و Gotchas — یه چیزی که agent‌ها توی اولین تلاش احتمالاً بهش توجه نمی‌کنن.

MCP server: کوچیک‌تر و متمرکزتر

MCP server قبلاً یه knowledge base داخلی داشت. با اینکه bundled docs الان همون کار رو می‌کنه، اون ابزارها حذف شدن. در عوض، دو ابزار جدید اضافه شده: get_compilation_issues برای کل پروژه، و compile_route برای یه route خاص. agent‌ها اغلب next build می‌زدن فقط برای چک کردن compilation — این ابزارها همون سوال رو از dev server در حال اجرا جواب می‌دن، خیلی سریع‌تر.

Docs as Markdown

یه چیز ساده ولی کاربردی: به هر URL از داک‌های Next.js یه .md اضافه کن تا نسخه‌ی Markdown صفحه رو بگیری. همین برای صفحه‌های error هم کار می‌کنه.

ایندکس کامل روی /docs/llms.txt هست، و /docs/llms-full.txt همه‌ی صفحات رو توی یه فایل bundle می‌کنه — طبق convention استاندارد llms.txt.

یه قدم به سمت agent-first development

اگه بخوای خیلی ساده بگی چی اضافه شده: Next.js داره سعی می‌کنه agent‌ها رو مثل یه نوع developer جدید در نظر بگیره — با نیازهای متفاوت. Agent به داک‌های به‌روز نیاز داره نه training data قدیمی، به خطاهای actionable نیاز داره نه فقط error message، و به یه feedback loop نیاز داره که بتونه بعد از هر تغییر runtime رو چک کنه.

فعلاً هنوز preview هست. اگه می‌خوای همین الان امتحان کنی:

و بعد ببین کدوم بخش از workflow توسعه‌ات واقعاً بهتر می‌شه — یا نمی‌شه.