Zed یا VS Code؛ ۲۴۱ مگابایت حافظه در برابر اکوسیستم افزونه‌ها

در آزمون Hyperlane روی Apple M5 Max با ۱۲۸ گیگابایت رم، Zed هنگام بازبودن مخزن آزمایشی TypeScript به مصرف ۲۴۱ مگابایت حافظه رسید و VS Code به ۲۷۷۹ مگابایت. این اختلاف دلیل خوبی برای بررسی Zed روی دستگاه کم‌حافظه است؛ اما اگر کارهای اصلی تیم به افزونه‌های مشخص VS Code وابسته باشد، سبک‌تر بودن به‌تنهایی هزینهٔ جابه‌جایی را جبران نمی‌کند.

Zed در مقایسهٔ رسمی خود زمان شروع معمول کمتر از یک ثانیه را مطرح می‌کند و در همان حال می‌پذیرد که مجموعهٔ افزونه‌هایش کوچک‌تر است و افزونه‌های VS Code را مستقیم اجرا نمی‌کند. بنابراین انتخاب به این بستگی دارد که قابلیت‌های داخلی Zed و افزونه‌های خود آن، وظایف ضروری پروژه را پوشش بدهند یا نه. برای پروژهٔ TypeScript با ابزارهای رایج، این پوشش را می‌توان از کارهای روزانه سنجید؛ برای محیطی با ابزارهای اختصاصی باید وابستگی‌ها را جداگانه دید.

۲۴۱ مگابایت دقیقاً چه چیزی را اندازه می‌گیرد؟

عدد حافظه مربوط به یک مخزن تولیدشده و ثابت TypeScript است که ویرایشگرها آن را با یک فایل باز بارگذاری کردند. اندازه‌گیری در macOS حافظهٔ مقیم همهٔ فرایندهای وابسته به هر ویرایشگر را جمع می‌کند و مقدار پایدار را از نمونه‌های دقیقهٔ پایانی می‌گیرد. در نتیجه این عدد فقط حافظهٔ پنجرهٔ اصلی نیست؛ فرایندهایی که همراه محیط کدنویسی اجرا می‌شوند هم در آن سهم دارند.

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

زمان شروع نیز به احتیاط نیاز دارد: در ویرایشگرهای مبتنی بر VS Code پایان زمان‌سنجی اعلام آمادگی محیط کار است، در حالی که برای Zed ظاهرشدن پنجره معیار بوده است. هر دو نقطهٔ پایان به تجربهٔ بازکردن برنامه مربوط‌اند، اما دقیقاً یک رویداد نرم‌افزاری را نشان نمی‌دهند. اگر سرعت آغاز برایتان تعیین‌کننده است، زمان رسیدن به نخستین کار قابل‌انجام در پروژهٔ خودتان معیار عملی‌تری خواهد بود.

TypeScript در Zed چه چیزهایی را بدون افزونهٔ VS Code دارد؟

مستندات TypeScript در Zed پشتیبانی داخلی از TypeScript و TSX، سرور زبان پیش‌فرض vtsls، قالب‌بندی پیش‌فرض با Prettier و اشکال‌زدایی با vscode-js-debug را شرح می‌دهد؛ پیکربندی‌های موجود در .vscode/launch.json نیز برای اشکال‌زدایی در دسترس‌اند. این مجموعه برای کسی که کار اصلی‌اش پیمایش کد، تکمیل خودکار، قالب‌بندی و اجرای اشکال‌زداست، بخش مهمی از نیاز روزانه را پوشش می‌دهد.

بااین‌حال، «پشتیبانی از TypeScript» به معنای یکسان‌بودن همهٔ رفتارها نیست. اگر مخزن به تنظیمات خاص سرور زبان، قالب‌بند یا محیط اجرای آزمون متکی است، نتیجهٔ قالب‌بندی و اشکال‌زدایی را با تنظیمات همان مخزن بسنجید. حتی وقتی هر دو ویرایشگر یک قابلیت را دارند، تفاوت در فرمان اجرا، میان‌بر یا خروجی آن می‌تواند برای گردش‌کار تکراری تیم هزینه ایجاد کند.

اکوسیستم افزونه‌ها کجا به مزیت عملی تبدیل می‌شود؟

راهنمای افزونه‌های VS Code دستور code --list-extensions، نصب افزونه از خط فرمان و ثبت پیشنهادهای افزونه در فایل .vscode/extensions.json را توضیح می‌دهد. این ابزارها کمک می‌کنند اعضای تیم بدانند کدام قابلیت‌ها برای یک مخزن توصیه شده و محیط کاری مشابهی بسازند. افزونه‌ای که فرمان، نمای اختصاصی یا اتصال به سامانهٔ بیرونی فراهم می‌کند، با انتقال صرفِ ترجیحات ویرایشگر جایگزین نمی‌شود.

فهرست نصب‌شدهٔ هر توسعه‌دهنده را باید از فهرست وابستگی‌های ضروری تیم جدا کرد. ممکن است تم، آیکون یا افزونهٔ کمکی فردی هیچ اثری بر تحویل پروژه نداشته باشد، اما یک افزونهٔ لازم برای اشکال‌زدایی، بازبینی کد یا کار با چارچوب پروژه به مرحله‌ای از کار گره خورده باشد. معیار مفید تعداد افزونه‌ها نیست؛ این است که برای هر وظیفهٔ ضروری، قابلیت داخلی، افزونهٔ Zed یا راه دیگری با کیفیت پذیرفتنی وجود دارد یا نه.

در انتقال از VS Code چه چیزی باقی می‌ماند؟

راهنمای مهاجرت Zed واردکردن بخشی از تنظیمات VS Code، از جمله قلم، اندازهٔ متن و قالب‌بندی هنگام ذخیره را شرح می‌دهد، اما افزونه‌ها و میان‌برهای سفارشی را وارد نمی‌کند. می‌توان نقشهٔ کلیدهای شبیه VS Code را انتخاب کرد، ولی همین شباهت به معنی انتقال همهٔ رفتارهای شخصی و تیمی نیست. بنابراین هزینهٔ مهاجرت بیش از یادگرفتن ظاهر یک ویرایشگر تازه است.

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

ماتریس تصمیم برای پروژه، تیم و دستگاه

• پروژهٔ TypeScript با ابزارهای رایج: Zed گزینهٔ جدی است، چون امکانات پایهٔ زبان و اشکال‌زدایی را دارد. تصمیم را به اجرای واقعی فرمان‌های پروژه، قالب‌بندی فایل‌های موجود و کارکرد اشکال‌زدا با پیکربندی مخزن گره بزنید.
• تیم وابسته به افزونه‌های مشخص: VS Code هزینهٔ تغییر کمتری دارد تا زمانی که برای هر قابلیت حیاتی جایگزینی آزموده شود. به‌خصوص افزونه‌ای که کار تیمی مشترکی انجام می‌دهد از افزونهٔ سلیقه‌ای یک نفر مهم‌تر است.
• دستگاه کم‌حافظه: نتیجهٔ آزمون انگیزه‌ای روشن برای امتحان Zed می‌دهد، اما اندازهٔ صرفه‌جویی روی دستگاه شما نامعلوم است. مصرف هر دو ویرایشگر را با همان مخزن، افزونه‌ها و سرویس‌های پس‌زمینهٔ معمول خود بسنجید.

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

آزمون کوتاه پیش از مهاجرت

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

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

بیشتر بخوانید:

• Supabase یا Firebase؛ هزینهٔ قابل‌پیش‌بینی در برابر ابزارهای کامل‌تر
• CapCut یا Descript؛ کلیپ سریع در برابر تدوین با متن
• Shopify یا WooCommerce؛ رایگان‌بودن افزونه هزینهٔ کل را تعیین نمی‌کند