大約一年前，我在 Smol Talk 這個網頁應用上選用了 Phoenix LiveView，做了個代價高昂的技術決定，現在非常後悔。這裡簡單記一下原因，算是寫給自己的筆記。

先說清楚，這絕對是我的技術不夠好，但學習曲線也真的完全不值得（對一個本來就熟 JS / Python 的人來說）。

我做了什麼

我們需要一個可客製化的摘要處理流程平台。我一直很欣賞 Elixir 和 LiveView，剛好有個朋友願意一起做。所以我就答應了。

我當初為什麼喜歡 Elixir / LiveView

• 我一直很喜歡簡單的單體式伺服器端渲染這個想法
• 應該能快速又輕鬆地渲染 HTML 差異（有點像 React Server Components）
• 特別是跟 ORM 整合得好時，能讓欄位的 CRUD 視圖自動產生
• Elixir 聽起來容錯性很好、速度也很快
• Oban 作為任務執行工具的口碑很好

現實狀況

不穩定／速度慢

頁面載入慢得離譜。

而且大概有 20？30？% 的頁面載入會失敗。我很確定不是資料庫的問題，就只是要渲染大量 UI 時他媽的慢。

感覺就像在用撥接上網一樣。

生態系不成熟

我們的應用程式用的都是當時最先進的東西。我算了一下，36 個依賴裡有 20 個（55%）還是 0.x 版本。

做不出條件式表單

這當然跟我們選的依賴套件有關，但我想要的是能根據其他欄位的條件，動態出現或新增一些 UI 元件。我們為了這個瞎搞了一整週的程式碼，最後放棄，結論是如果不……就做不到……

加上 JS

想要任何客戶端互動，你基本上還是得寫 JS。LiveView 提供了一些不錯的方式把資料傳進 JS 元件，但只要你一開始寫元件，就會想越寫越多，最後基本上只是把 Phoenix 當成 API 後端在用。那還不如一開始就寫 SPA 算了。

爛透的錯誤訊息

我本來想貼這些錯誤給你看，但現在應用程式又載入不了，所以……

（補充：好吧現在又載入了……對，這種徹底的垃圾訊息就是常態。完全沒有你在一個正常系統中會期待的那種型別安全的錯誤處理。）