یه کار که تقریباً هر پروژه‌ی Laravel ای در یه نقطه‌ای بهش نیاز داره اینه که تصویر آپلودشده رو resize کنه، فرمتش رو عوض کنه، یا یه thumbnail ازش بسازه. تا الان برای این کار حتماً باید یه package جداگانه نصب می‌کردی — معمولاً intervention/image — و بعد خودت wrapper می‌نوشتی. Laravel 13.20 که ۱۴ جولای ۲۰۲۶ منتشر شد، این کار رو داخل خود فریم‌ورک آورده.

Image facade: پردازش تصویر first-party

یه Image facade جدید اضافه شده که یه API immutable برای تبدیل تصاویر داره. immutable یعنی هر transformation یه instance جدید برمی‌گردونه — یعنی می‌تونی از یه تصویر چند variant مختلف بسازی بدون اینکه مشکل side effect داشته باشی.

رایج‌ترین حالت استفاده اینه که مستقیم از request بگیری:

$request->image('avatar')
    ->cover(200, 200)
    ->toWebp()
    ->store('avatars');

ولی می‌تونی از هر جایی image بسازی:

Image::fromPath('/path/to/photo.jpg');
Image::fromUrl('https://example.com/photo.jpg');
Image::fromBytes($bytes);
Image::fromStorage('photos/avatar.jpg', 's3');
Storage::disk('s3')->image('photos/avatar.jpg');

transformationهایی که در دسترسن:

$image->cover(200, 200);    // crop و resize با هم
$image->contain(800, 600);  // resize بدون crop
$image->crop(200, 200);
$image->resize(1024, 768);
$image->scale(1200, 800);
$image->rotate(90);
$image->blur(10);
$image->sharpen(10);
$image->grayscale();
$image->flip();
$image->flop();
$image->orient();           // EXIF rotation رو اعمال می‌کنه

برای output هم:

$image->toWebp();
$image->toJpg()->quality(80);
$image->optimize();          // WebP با quality 70
$image->optimize('jpg', 85);

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

$image = $request->image('photo');

$image->cover(200, 200)->toWebp()->store('thumbnails');
$image->grayscale()->toWebp()->store('grayscale');

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

$image->usingGd();
$image->usingImagick();

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

composer require intervention/image

ویژگی WithoutMiddleware

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

#[Middleware(EnsureTokenIsValid::class)]
class UserController
{
    public function index()
    {
        // middleware اینجا اعمال میشه
    }

    #[WithoutMiddleware(EnsureTokenIsValid::class)]
    public function profile()
    {
        // اینجا اعمال نمیشه
    }
}

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

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

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

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

'prefix' => env('SESSION_PREFIX', Str::slug(env('APP_NAME', 'laravel')).'-session-'),

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

incrementEachQuietly و decrementEachQuietly

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

$user->incrementEachQuietly(['posts_count' => 1, 'points' => 10]);
$user->decrementEachQuietly(['credits' => 3, 'tokens' => 2]);

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

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

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

public function middleware(): array
{
    return [new WithoutOverlapping($this->category)];
}

قبلاً باید 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.

یه سوال جدی هست که بیشتر و بیشتر آدم‌ها می‌پرسن — خصوصاً کسایی که تازه شروع کردن: الان که Claude Code یه component کامل React رو توی ده ثانیه می‌نویسه، الان که GPT یه API endpoint رو با تمام error handling‌اش تحویل می‌ده، واقعاً باید بشینم data structure یاد بگیرم؟ باید algorithm بفهمم؟ باید بدونم HTTP دقیقاً چطور کار می‌کنه؟

جواب صادقانه: بله. ولی نه به همون دلیلی که فکر می‌کنی.

مدل کد می‌نویسه، تو تصمیم می‌گیری

یه چیزی که توی استفاده از AI coding tools خیلی زود مشخص می‌شه اینه که کیفیت خروجی مستقیماً به کیفیت input تو وابسته‌ست. اگه ندونی چی می‌خوای، مدل هم نمی‌دونه. اگه ندونی معماری درست چیه، خروجی مدل ممکنه technically بی‌نقص باشه ولی برای پروژه‌ات کاملاً اشتباه.

یه مثال ساده: از Claude Code می‌خوای یه caching layer بسازه. اگه ندونی فرق Redis و یه in-memory cache ساده چیه، نمی‌دونی کِی از کدوم بخوای. اگه ندونی race condition یعنی چی، نمی‌فهمی که خروجی مدل این مشکل رو داره یا نه. اگه ندونی TTL چطور کار می‌کنه، نمی‌تونی بگی آیا مدل اون رو درست تنظیم کرده یا نه.

مدل کد می‌نویسه. تو تصمیم می‌گیری این کد چیه و چرا.

review کردن بدون فهمیدن ممکن نیست

یه اشتباه رایج اینه که فکر می‌کنیم «می‌خونیم» کد AI رو. ولی خوندن بدون درک، review نیست — یه نگاه انداختنه که حس خوبی می‌ده ولی هیچ چیزی رو تضمین نمی‌کنه.

وقتی AI یه function می‌نویسه که O(n²) complexity داره و تو نمی‌دونی این یعنی چی، می‌گی «خوبه، merge می‌کنم» — و شاید واقعاً هم خوب باشه. ولی وقتی data ات از ده هزار record به یه میلیون رکورد می‌رسه، اون function سرور رو می‌خوابونه. این اتفاق نه به‌خاطر اینه که مدل اشتباه کرد — مدل چیزی نوشت که برای context ای که داشت معقول بود. اشتباه اینجا بود که کسی که review کرد نفهمید مشکل کجاست.

debugging جایی‌ه که اصول واقعاً مهم می‌شن

هر چیزی که AI می‌نویسه، در یه لحظه‌ای اشتباه می‌کنه — یا مدل اشتباه می‌کنه، یا کد توی production با شرایطی مواجه می‌شه که مدل پیش‌بینی نکرده بود. اون لحظه، تنها کسی که می‌تونه مشکل رو پیدا کنه و درستش کنه توئی.

debugging یه مهارتیه که بدون فهمیدن اصول ممکن نیست. نمی‌تونی race condition پیدا کنی اگه ندونی thread یعنی چی. نمی‌تونی memory leak رو trace کنی اگه lifecycle object ها رو نفهمی. نمی‌تونی بفهمی چرا request تایم‌اوت می‌شه اگه ندونی TCP handshake چطور کار می‌کنه.

AI توی debugging هم کمک می‌کنه — ولی فقط اگه بدونی چه اطلاعاتی بهش بدی. اگه ندونی دنبال چی می‌گردی، error log رو copy می‌کنی توی chat و امیدوار می‌شی مدل جواب بده. گاهی می‌ده. ولی این یه روش قابل اعتماد نیست.

یه نقطه‌ی ظریف درباره‌ی سرعت

یه غلط‌فهمی وجود داره که «اصول یاد گرفتن» یعنی زمان زیادی می‌بره و در آخر هم مستقیماً استفاده نمی‌شه. ولی اصول قراره چیزی باشن که دیگه بهشون فکر نمی‌کنی — اتوماتیک تبدیل می‌شن به شهود.

وقتی یه توسعه‌دهنده باتجربه یه codebase جدید رو می‌بینه، می‌فهمه مشکل architecture کجاست — نه به‌خاطر اینکه یه checklist داره، بلکه چون دیده‌ها و تجربه‌هاش به یه حس تبدیل شدن. این همون چیزیه که با AI codingهای سطحی از دست می‌ره.

هرچقدر اصول قوی‌تر باشن، از AI هم بهتر استفاده می‌کنی. چون prompt های بهتری می‌نویسی، خروجی رو بهتر ارزیابی می‌کنی، و زودتر می‌فهمی کِی باید از مدل کمک بخوای و کِی باید خودت فکر کنی.

اصول چه چیزی نیستن

اینجا یه تفاوت مهم هست که باید مشخص بشه: یاد گرفتن اصول با حفظ کردن syntax یه زبان یا دونستن تمام APIهای یه فریم‌ورک فرق داره. دومی رو الان واقعاً AI بهتر از تو می‌دونه. اگه نمی‌دونی Array.reduce چطور کار می‌کنه، بپرس. اگه نمی‌دونی کدوم CSS property برای این استفاده می‌شه، بپرس.

ولی اینکه چرا state management پیچیده می‌شه، چرا database query ات کند شده، چرا این race condition فقط توی production اتفاق می‌افته — اینا رو باید بفهمی. اینا قراره بخشی از طرز فکر تو بشن، نه اینکه هر بار از صفر از مدل بپرسی.

جواب سوال اول

پس چرا باید اصول یاد بگیری؟

نه برای اینکه AI کدت رو بنویسه و تو باید بدونی که نوشته. نه برای اینکه شاید یه روز AI نباشه — هست و بیشتر هم می‌شه.

بلکه چون کار یه توسعه‌دهنده همیشه بیشتر از نوشتن کد بوده. طراحی سیستم، تصمیم‌گیری، تشخیص مشکل، ارزیابی trade-off ها — اینا هنوز جایی هستن که ابزار جایگزین فکر نمی‌شه. AI سرعت رو بالا می‌بره، ولی اگه نقطه‌ی شروع ضعیف باشه، فقط سریع‌تر به جای اشتباه می‌رسی.

اصول یاد می‌گیری تا بتونی از AI درست استفاده کنی — نه به‌رغم اینکه AI هست.

یک چیزی هست که کمتر کسی درباره‌اش حرف می‌زنه: AI coding tools می‌تونن به همون اندازه که کمک کنن، اگه باهاشون درست کار نکنی، اوضاع رو بدتر کنن. نه چون بد هستن — بلکه چون وقتی یه ابزار خیلی قوی داری و هنوز ندونی کِی ازش استفاده کنی، ممکنه در نهایت بیشتر وقتت صرف debug کردن چیزی بشه که خودت می‌تونستی سریع‌تر بنویسیش.

۲۰۲۶ از یه نظر نقطه‌ی عجیبیه. ابزارها از هر زمان دیگه‌ای بهترن، ولی noise هم از همیشه بیشتره. هر هفته یه agent جدید، یه model جدید، یه ادعای جدید که «این بار متفاوته». وسط این سروصدا، یه workflow سالم ربطی به اینکه از کدوم tool استفاده کنی نداره — ربط داره به اینکه چطور باهاشون فکر کنی.

اشتباه اول: context دادن به‌جای فکر کردن

آدم‌ها یه عادت دارن که بلافاصله وقتی به مشکل می‌خورن، می‌رن سراغ AI. این بد نیست — ولی مشکل اینه که اگه قبلش پنج دقیقه با خودت فکر نکرده باشی، مدل هم نمی‌دونه دقیقاً دنبال چی هستی. نتیجه یه جواب generic می‌شه که یا کامل نیست یا با context پروژه‌ات جور نیست.

یه قانون ساده: قبل از اینکه سراغ AI بری، یه جمله بنویس که مشکل رو توصیف کنه. فقط یه جمله. اگه نتونستی، یعنی هنوز نمی‌دونی مشکل چیه — و مدل هم نخواهد دونست.

اشتباه دوم: agent بدون context

agentها — Hermes، Claude Code، Codex — وقتی می‌دونن پروژه چیه، قبلاً چی شده، و چه محدودیت‌هایی وجود داره، خیلی بهتر کار می‌کنن. ولی بدون این context، حتی یه agent خوب هم می‌تونه چیزی بسازه که technically درسته ولی با معماری پروژه‌ات جور نیست.

راه‌حل‌هایی مثل skill file ها برای همین اومدن: به‌جای اینکه هر بار از اول توضیح بدی، یه بار درست توضیح می‌دی و می‌ذاریش جایی که agent هر وقت لازم بود بخونتش. این ساده‌ترین روشیه که workflow ات رو از «هر بار از صفر» به «agent می‌دونه کجاست» تبدیل می‌کنه.

اشتباه سوم: باور کردن خروجی بدون review

این شاید از همه‌شون خطرناک‌تره. مدل‌ها اشتباه می‌کنن — و اشتباهاتشون معمولاً خیلی مطمئن به نظر می‌رسن. کدی که مدل نوشته رو نخونده commit نکن. نه به‌خاطر اینکه کد بد باشه — بلکه چون review کردن کد همونی هست که باعث می‌شه تو بفهمی چی ساخته شده. اگه این رو skip کنی، چند هفته دیگه یه codebase داری که نمی‌دونی داخلش چیه.

این یه قانون نیست که هر خط رو خودت بنویسی. قانون اینه که هر خطی رو که merge می‌کنی، بدونی چیکار می‌کنه.

یه workflow که در عمل کار می‌کنه

یه الگوی ساده که در عمل جواب داده:

برای کارهای کوچیک (یه function، یه refactor کوچیک، یه bug): مستقیم از chat استفاده کن. context لازم نیست زیاد باشه، نتیجه سریعه، و راحت review می‌شه.

برای کارهای متوسط (یه feature جدید، یه سرویس): یه prompt با جزئیات کافی بنویس — معماری، محدودیت‌ها، output مورد انتظار. بعد خروجی رو بگیر و review کن. اگه چیزی جا افتاده یا جور نیست، iteration کن.

برای کارهای بزرگ و پیچیده: اینجاست که agent ها معنی پیدا می‌کنن. یه agent مثل Hermes یا Claude Code می‌تونه یه task چندمرحله‌ای رو مدیریت کنه — ولی فقط اگه بهش context کافی بدی، skill های مرتبط بهش دادی، و حواست به کارش باشه. «بذار agent همه چیز رو بسازه و من بعداً نگاه کنم» یه workflow نیست — یه روش برای ساختن چیزیه که نمی‌فهمیش.

درباره‌ی دسترسی و مرزها

یه چیزی که از تجربه‌ی مستقیم یاد گرفتم: به agent هایی که به filesystem دسترسی دارن، sudo ندید. نه به‌خاطر اینکه agent بد نیت داره — بلکه چون وقتی یه task پیچیده انجام می‌ده و اشتباه می‌کنه، sudo یعنی اشتباهش جبران‌ناپذیره. یه دیتابیس محلی پاک می‌شه. یه پوشه حذف می‌شه. این چیزیه که «بعید نیست» — اتفاق می‌افته.

محدود کردن دسترسی یه لایه‌ی safety net هست، نه بی‌اعتمادی به ابزار.

درباره‌ی مدل‌ها و هزینه

اکثر کارهای روزانه‌ی یه توسعه‌دهنده‌ی معمولی به بهترین و گران‌ترین مدل نیاز ندارن. توضیح یه مفهوم، بررسی یه کد، نوشتن یه test، refactor کوچیک — اینا رو مدل‌های ارزون‌تر هم خوب انجام می‌دن.

جاهایی که مدل قوی‌تر فرق می‌کنه: وقتی task پیچیده‌ست و نیاز به چندین مرحله reasoning داره، وقتی context بزرگه، یا وقتی agent باید خودش تصمیم بگیره چه مرحله‌ای بعدی باشه. برای بقیه، مدل ارزان‌تر کافیه — و ترکیب ابزارهایی مثل 9Router با agentها می‌تونه هزینه رو به حداقل برسونه.

یه جمله خلاصه

workflow سالم با AI یعنی تو هنوز توسعه‌دهنده‌ای — ابزار هم بیشتر شده. یعنی هنوز می‌فهمی چی می‌سازی، هنوز review می‌کنی، و هنوز تصمیم می‌گیری. AI سرعت رو بالا می‌بره — ولی اگه فقط سرعت بالا بره بدون اینکه بفهمی داری کجا می‌ری، سریع‌تر گم می‌شی.

یه حقیقت ساده از همون اول: اگه شش ماه پیش لینوکس نصب کردی روی یه ماشین معمولی، احتمالاً الان روی Wayland هستی — حتی اگه ندونی. Fedora 40+، Ubuntu 24.04+، Arch، GNOME 49، و KDE Plasma 6 همه به‌صورت پیش‌فرض به Wayland رفتن. این دیگه یه بحث «آینده‌ی Linux» نیست. این وضعیت الان هست.

سوال واقعی اینه که چرا این اتفاق افتاد، چه چیزی هنوز نشکسته، و چه کسی نباید عجله کنه.

X11 چه مشکلی داشت

X11 در ۱۹۸۴ طراحی شد — و معماریش دقیقاً همون‌قدر که از اون زمان انتظار داری، قدیمیه.

مدل کار اینه که یه X server مرکزی وجود داره. هر برنامه برای رندر کردن چیزی به صفحه، یه درخواست می‌فرسته به X server، X server اون رو به compositor می‌ده، compositor نهایی می‌کنه. مشکل اینه که این X server مرکزی همه چیز رو می‌بینه: هر کیبورد فشرده‌شده، هر حرکت ماوس، هر پنجره‌ای که بازه. هر اپلیکیشن هم می‌تونه از X server بخواد ورودی اپ‌های دیگه رو بخونه. یعنی keylogger نوشتن روی X11 یه کار ده خطیه.

اوایل ۲۰۲۵ سه آسیب‌پذیری بحرانی (CVE-2025-62229، CVE-2025-62230، CVE-2025-62231) توی X.Org پیدا شد — باگ‌هایی که بعضی‌هاشون از بیست سال پیش توی کد بودن. اینا isolated incident نبودن؛ نشونه‌ی یه codebase چهل‌ساله‌ان که maintenance-only شده. هیچ توسعه‌ی فعالی روی X.Org اتفاق نمی‌افته — فقط security patch.

مشکل معماری دیگه‌ای هم وجود داره: رندرینگ کند. هر frame باید از برنامه به X server و بعد به compositor بره — این double-buffering بی‌دلیل توی hardware مدرن کاملاً غیرضروریه و توی بعضی حالت‌ها باعث tearing می‌شه.

Wayland چطور متفاوته

Wayland یه «سرور» مرکزی نداره. هر اپلیکیشن مستقیم به یه off-screen buffer رندر می‌کنه، و compositor مستقیم با driver کار می‌کنه تا frame نهایی رو به مانیتور بفرسته. واسطه نیست.

نتیجه‌های عملی این معماری:

امنیت: هر اپلیکیشن فقط ورودی‌های خودش رو می‌بینه. keylogger نوشتن روی Wayland از طریق protocol عملاً غیرممکنه. البته XWayland — که X11 appها رو روی Wayland اجرا می‌کنه — همچنان این ایزوله‌سازی رو نداره، ولی native Wayland appها ندارن.

رندر تمیزتر: چون compositor مستقیم با GPU کار می‌کنه، screen tearing توی حالت‌های معمولی اتفاق نمی‌افته. توی سیستم‌های با refresh rate بالا یا HiDPI این فرق محسوسه.

نه یه display server، بلکه یه protocol: این نکته مهمه. Wayland خودش یه نرم‌افزار نیست — یه spec هست. GNOME با Mutter، KDE با KWin، Hyprland، Sway — هر کدوم پیاده‌سازی جدا دارن. این یعنی تجربه‌ی Wayland از یه compositor به compositor دیگه می‌تونه فرق کنه.

وضعیت واقعی ۲۰۲۶

اگه از GNOME یا KDE Plasma استفاده می‌کنی، Wayland الان default هست و برای اکثر کارها بدون دردسر کار می‌کنه. طبق یه survey از ۳۹۲۳ کاربر Arch در ژانویه ۲۰۲۵، ۸۰ درصد روی Wayland بودن. GNOME از نسخه‌ی ۴۹ (۲۰۲۵) X11 session رو کاملاً حذف کرده. KDE Plasma 6.8 که اواخر ۲۰۲۶ یا ۲۰۲۷ میاد هم همین کار رو خواهد کرد.

NVIDIA که قبلاً مشکل‌سازترین قسمت بود، با driver series 495+ وضعش خیلی بهتر شده. اکثر کاربران NVIDIA الان می‌تونن Wayland رو بدون دردسر زیادی اجرا کنن — ولی اگه GPU قدیمیه (GTX 1000 series و قدیمی‌تر)، ممکنه همچنان مشکل داشته باشی.

چه کسی نباید عجله کنه

Wayland برای همه مناسب نیست — حداقل نه الان:

اگه از SSH X forwarding (ssh -X یا ssh -Y) برای باز کردن GUI برنامه‌های remote استفاده می‌کنی، Wayland این رو natively پشتیبانی نمی‌کنه. باید از راه‌حل‌های دیگه مثل RDP یا VNC استفاده کنی.

اگه از ابزارهای automation روی desktop استفاده می‌کنی — xdotool، wmctrl، AutoKey — اینا روی Wayland کار نمی‌کنن چون Wayland به appها اجازه نمی‌ده ورودی سیستمیک simulate کنن.

اگه از window manager های سبک مثل i3، openbox، یا fluxbox استفاده می‌کنی، نسخه‌های Wayland بعضی‌هاشون بالغ نیستن. Sway جایگزین i3 روی Wayland هست، ولی feature parity کامل نداره.

اگه از VNC برای remote desktop استفاده می‌کنی، X11 network transparency همچنان این use case رو راحت‌تر می‌کنه.

setup چقدر سخته

برای کاربر معمولی با GNOME یا KDE، عملاً هیچ setup ای لازم نیست — چون اگه لینوکس مدرن نصب کردی، احتمالاً از قبل روی Wayland هستی. چک کردنش ساده‌ست:

echo $XDG_SESSION_TYPE   # باید "wayland" برگردونه

اگه X11 هست و می‌خوای Wayland امتحان کنی، توی login screen (GDM یا SDDM) می‌تونی session نوع رو عوض کنی — بدون نیاز به نصب چیزی. بعد از login کافیه echo $XDG_SESSION_TYPE بزنی و ببینی.

اگه بخوای برگردی، همون راه رو از login screen برعکس کن.

X11 appها چی می‌شن

اکثر X11 appها روی Wayland از طریق XWayland کار می‌کنن — یه X server که به‌عنوان یه Wayland client اجرا می‌شه. در عمل، بیشتر برنامه‌ها بدون تغییر کار می‌کنن. محدودیت‌ها از همون security model میان: appهایی که global pointer position یا synthetic input نیاز دارن زیر XWayland هم مشکل دارن.

جمع‌بندی واقع‌بینانه

Wayland برای اکثر کاربران لینوکس دسکتاپ الان انتخاب بهتریه — نه چون X11 خراب شده، بلکه چون Wayland معماری تمیزتر، امنیت ساختاری بهتر، و پشتیبانی از display مدرن (HiDPI، variable refresh rate) رو از اساس حل می‌کنه.

ولی اگه workflow ات به X forwarding، GUI automation، یا window manager هایی که Wayland equivalent ندارن وابسته‌ست، X11 هنوز گزینه‌ی درست‌تره. و این انتخاب هیچ ایرادی نداره — هر دو همزمان در دسترسند و X11 حداقل تا ۲۰۲۸ patch خواهد خورد.