在「Claude 為什麼是 Electron App？」一文中，Drew Breunig 提出疑問：
Claude 花了 2 萬美元購買了一個代理群組，實作（有點像）一個用 Rust 編寫的 C 編譯器，但桌面版的 Claude 卻是個 Electron App。
如果程式碼是免費的，為什麼不是所有 App 都是原生的？
然後他爭辯說，答案是大型語言模型（LLM）還不夠好。它們可以完成 90% 的工作，但仍有大量的細節需要人工打磨，因此成本增加。
但我認為那不是真正的原因。真正的原因是：原生開發已無可提供。
API 方面，原生 App 早已輸給網頁 App。原生 API 非常難用，而且作業系統廠商竭盡所能讓你不想為他們的平台開發原生 App。這解釋了在 LLM 時代之前 Electron 興起的現象，但這也是 LLM 現在解決的問題：如果這曾是開發原生 App 的真正障礙，現在它已不復存在。
接著是外觀和一致性。很久以前，也許是 90 年代末和 2000 年代，原生開發曾處於領先地位。它曾經看起來很棒，很一致，而且一切都確實有效：越多的 App 使用原生外觀和感覺，跨 App（我們以前稱之為程式）的使用者體驗就越好。
然而，如今，原生開發和網頁一樣糟糕，甚至更糟。一致性基本上蕩然無存。任何東西都可以看起來像任何東西，按鈕沒有邊框，沒有對比度，也沒有慣例。例如，Apple 似乎是憑感覺而不是任何可衡量的準則來放置交通燈按鈕和圓角。
外觀可以是好的，但也可以是壞的，然後你就被困在與平台一致但普遍糟糕的使用者介面中（Liquid Glass 咳咳）。它也變太快了：你今天製作的 App，明年當 Apple 決定再次改變外觀和感覺時，就會顯得格格不入。已經沒有所謂的原生外觀了。
理論上，原生 App 可以更深入地與作業系統整合。這聽起來不錯，但實際上意味著什麼？幾乎沒有好的互通檔案格式；所有東西都鎖在個別的 App 中，大多數服務都轉移到網路上，而作業系統在建立良好的共享基礎方面卻做得不夠好。你可以與作業系統提供的日曆整合，但不能與網路日曆整合。嗯，當然你可以做到，但在網路上更容易；原生開發對此一點幫助都沒有。
最後，懷念原生開發的人的最後希望是效能。他們覺得原生 App 會更快。嗯，它們可以更快，但這並不意味著它們就會更快。網頁 App 也可以更快，但在實務上，沒有人在乎。Slack 沒有技術原因需要載入 80 MiB 才能在螢幕上顯示 10 個頻道名稱和 3 則訊息。問題不在於網路！這是選擇做得不好。你為什麼認為當公司決定轉向原生開發時情況會有所不同？
別誤會我的意思：寫這篇文章讓我毫無喜悅。我不認為網頁是解決方案。我只記得過去原生開發表現優於平均水準的美好時光，我們都因此受益，而現在這些時光已逝，這讓我感到悲傷。
我只是不認為自欺欺人地認為軟體唯一的問題是 Electron，一旦我們用 SwiftUI 重寫 Slack 就一切都會變得美好，這是沒有生產力的。真正問題在於缺乏關懷。還有那些隨便的程式碼；你可以用任何技術堆疊來建構它。