約1年前にSmol TalkというWebアプリでPhoenix LiveViewを採用するという高くつく技術選定をしてしまい、今では後悔している。その理由を自分用のメモとして書き留めておく。

はっきり言っておくが、これは間違いなく自分のスキル不足でもある。ただ、学習コストに見合う価値はまったくなかったとも思っている（少なくともJS/Pythonをすでに使いこなせる人間にとっては）。

やったこと

カスタマイズ可能な要約パイプラインプラットフォームが必要だった。以前からElixirとLiveViewには憧れがあって、ちょうど一緒に作ってくれる友人もいた。だから、やろうと答えた。

Elixir/LiveViewの気に入っていたところ

• シンプルなモノリスでのサーバーサイドレンダリングという発想が昔から好きだった
• HTMLの差分を高速かつ簡単にレンダリングできるはず（いわばReact Server Componentsのようなもの）
• 特にORMとのうまい連携で、フィールドのCRUDビューが自動的に作れる点
• Elixirはフォールトトレラントで高速だと聞いていた
• ジョブランナーとしてのObanの評判が良かった

現実

不安定さ・遅さ

ページの読み込みがとにかく死ぬほど遅かった。

そしてページ読み込みの20？30？％くらいは失敗した。データベースの問題ではないと思う。単に大量のUIをレンダリングするのがクソほど遅いだけだ。

まるでダイヤルアップ回線に戻ったような気分だった。

エコシステムの未成熟さ

アプリにはその時点で最先端（SOTA）のものを選べた。依存関係36個のうち20個（55%）が0.xバージョンだったと数えている。

条件付きフォームが作れなかった

これは確かに依存関係の選び方にも関係しているのだろうが、ある要素の条件に応じて別のUI要素を表示したり追加できるようにしたかった。そのために1週間もクソみたいにコードをあれこれいじくり回した挙句、諦めて、これなしでは不可能だという結論に至った……

JSの追加

少しでもクライアントサイドのインタラクティビティを持たせたいなら、基本的にJSが必要になる。LiveViewにはJSコンポーネントにデータを渡すための便利な仕組みもあるが、コンポーネントを書き始めると、もっともっと書きたくなって、結局PhoenixをただのAPIバックエンドとしてしか使わなくなる。だったら最初からSPAとして書いた方がマシだ。

ひどすぎるエラー

このエラーをお見せしたいところだが、今はアプリ自体が読み込めないので

（追記：はい、今は読み込めるようになった……そして、そう、この手の完全にゴミみたいなエラーが平常運転だ。まともなシステムなら期待されるような型安全なエラーハンドリングは一切ない。）