在〈Why is Claude an Electron App？〉一文中，Drew Breunig 提出了這樣的疑問：

Claude 花了兩萬美元讓一群 agent 用 Rust（算是）實作了一個 C 編譯器，但桌機版的 Claude 卻是個 Electron App。

如果寫程式碼已經不用錢了，為什麼不是所有 App 都是原生的？

接著他主張，答案在於 LLM 還不夠強。它們只能完成 90% 的工作，剩下仍需要大量的人工打磨，因此成本還是很高。

但我認為那並不是真正的原因。真正的原因是：原生已經沒有任何優勢可言。

就 API 而言，原生 App 很久以前就輸給網頁 App 了。原生的 API 難用到不行，而作業系統廠商更是竭盡所能讓你不想為他們的平台開發原生 App。這解釋了在 LLM 出現之前 Electron 為何會崛起，但這也正是 LLM 現在已經解決的問題：如果那曾是開發原生 App 的真正障礙，現在已經不存在了。

再來是外觀與一致性。曾有一段時間，或許是在九〇年代末到二〇〇〇年代，原生是領先的。它外觀好看、風格一致，而且真的能正常運作：越多 App 採用原生的外觀與操作體驗，整體的使用者體驗就越好（那時候我們還把 App 叫做程式）。

然而到了現在，原生已經跟網頁一樣糟，甚至更糟。一致性基本上蕩然無存。任何東西都可以長成任何樣子，按鈕沒有邊框、沒有對比，也沒有任何慣例可言。舉例來說，Apple 擺放紅綠燈按鈕和決定圓角大小的方式，看起來完全是憑感覺，而不是依據任何可量化的設計規範。

外觀有可能好看，但也可能很難看，而一旦難看，你就被困在那個符合平台一致性、卻整體很糟的 UI 裡（咳，Liquid Glass）。而且它還變得太頻繁：你今天做好的 App，到了明年 Apple 又決定要改一次外觀與風格時，看起來就會顯得格格不入。已經沒有什麼所謂的原生外觀了。

理論上，原生 App 可以在更深的層次與作業系統整合。這聽起來很美好，但在實務上又代表什麼？幾乎沒有什麼好用的、可互通的檔案格式；所有東西都被鎖在各自的 App 裡，大多數服務都搬到了網頁上，而作業系統也沒有建立起一個好的共同基礎。你可以跟作業系統內建的行事曆整合，卻無法跟網頁版行事曆整合。好吧，當然你還是可以，但那在網頁上反而更容易；原生在這方面根本幫不上忙。

最後，懷念原生的人們僅存的希望就是效能。他們覺得原生 App 會比較快。嗯，的確有可能，但不代表就一定會。網頁 App 也可以很快，但在實務上，根本沒人在乎。Slack 需要載入 80 MiB 才能在畫面上顯示 10 個頻道名稱和 3 則訊息，這背後沒有任何技術上的理由。問題不在於網頁！爛成這樣是一種選擇。你憑什麼認為，當公司決定轉向原生後，情況就會有所不同？

別誤會：寫下這些話我一點也不開心。我也不認為網頁就是解方。我只是還記得原生曾經表現得比平均好上許多的美好時光，而我們都因為使用它而受惠，想到那樣的時光已經過去，就讓我感到難過。

我只是覺得，自欺欺人地以為軟體唯一的毛病就是 Electron，只要用 SwiftUI 把 Slack 重寫一遍就會從此充滿蝴蝶與獨角獸般的美好，是沒有意義的。真正的問題在於不用心。而那些粗製濫造的東西，用什麼技術堆疊都做得出來。