大概一年前，我在 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。

糟透了的报错

本来想给你看看这些报错，但现在应用又加载不出来，所以……

（补一句，好吧现在又能加载了……没错，这种纯纯的垃圾报错就是常态。在一个正常的系统里你期待的那种类型安全的错误处理，这里根本没有。）