效能稅：為什麼開發者正離開 JetBrains 轉向輕量化編輯器

對於許多開發者而言，選擇整合開發環境 (IDE) 不僅僅是偏好問題——它是日常工作流程中至關重要的一部分。多年來，JetBrains 一直是專業開發的黃金標準，提供了一套全面的工具，處理從深度靜態分析到複雜除錯的所有事務。

然而，開發者社群中日益增長的觀點顯示，「全方位」的方法正開始遇到瓶頸。隨著高效能、輕量化編輯器與重量級 IDE 之間的差距擴大，許多人發現，等待啟動畫面或重新索引週期的認知成本已不再值得其功能集。

這種轉變在 Hacker News 上最近的一次熱門討論中得到了體現，一名開發者詳細描述了他們與 JetBrains 的「分手」，轉而使用新的 Zed 編輯器。

「重量級」工具的摩擦感

開發者離開 JetBrains 的主要不滿點並非缺乏功能，而是效能開銷。當一個工具被設計為「萬能」解決方案時，它通常會帶來資源稅，進而干擾開發者的心流狀態。

常見的痛點包括：

• 啟動與專案載入： 「極差」的啟動時間和啟動畫面可能會在開始工作時造成心理障礙。
• 索引疲勞： 持續且往往不透明的程式碼庫重新索引過程會佔用 CPU 核心並減慢整個系統。
• UI 遲鈍： 即便是使用現代硬體，簡單的任務（例如建立新檔案或查看建議框）也可能感覺到延遲。
• 資源消耗： 高 RAM 使用量和記憶體洩漏，導致必須每天重新啟動 IDE。

一位擁有高階機器（Ryzen 9950x, 64GB RAM）的開發者指出，即使使用頂級硬體，WebStorm 仍然「慢得令人痛苦」，在進行 git commits 時的程式碼分析需要數分鐘，而 TypeScript 錯誤的重新整理則需要長達 30 秒。

「速度優先」編輯器的崛起

相比之下，像 Zed、Helix 和 Neovim 這樣的編輯器正透過優先考慮響應速度而獲得關注。其目標是消除思考與其在螢幕上呈現之間的差距。

"One moment, I'm happily working away in a terminal. One second later, I'm looking at a full-featured editor with all the tooling I want. That's the performance bar, the expectation."

這種「即時啟動」的體驗正在成為新的基準。對於經常在專案之間切換或依賴以終端機為中心的工作流程的開發者而言，能在秒級時間內開啟專案是一項轉型式的生產力提升。這使得一些人開始採用「混合」方法：使用輕量化編輯器處理大部分工作，並僅在特定的、複雜的除錯任務中保留重量級 IDE。

AI 整合的衝突

除了效能之外，在 AI 如何整合到開發體驗中，也存在著日益增長的緊張關係。雖然 AI 助手很強大，但許多開發者發現 JetBrains 產品目前的實作方式過於侵入性。

批評者認為，AI 建議往往會弄亂 UI 或干擾打字流，有些人將這種體驗描述為「令人討厭」或「品味不佳」。開發者明顯希望 AI 成為一種支援性工具——可以透過側邊欄或連接器來存取——而不是一種將建議推送到程式碼行中間的干擾力量。

反對意見：真正 IDE 的價值

儘管存在挫折感，許多開發者仍對 JetBrains 保持忠誠，認為文字編輯器——無論多快——都無法取代完整的 IDE。工具的深度，特別是除錯器 (debugger) 和執行互動式即時堆疊編輯 (live stack editing) 的能力，仍然是其重要的吸引力。

一些使用者也建議，效能問題可以透過配置來緩解。調整 JVM 設定、增加分配的 RAM（例如 Xms=4g），以及使用 ZGC (Z Garbage Collector) 可以顯著改善環境的流暢度。對於這些使用者而言，為了獲得整合工具集的巨大威力，付出幾秒鐘的載入時間作為代價是值得的。

結論：編輯器的未來

「重型 IDE」與「輕量編輯器」之間的爭論，反映了開發者與程式碼互動方式的更廣泛轉變。隨著 Language Server Protocols (LSP) 和 LLM 的興起，簡單的文字編輯器與完整 IDE 之間的界線正在模糊化。

隨著開發者日益優先考慮心流與響應速度，傳統 IDE 的必須做出激進的效能優化，否則將面臨將用戶群體流失到將速度視為一等公民功能的新一代工具的風險。