Rails、Laravel、Next.js の代わりに Elixir Phoenix を選んだ理由

 (akarshc.com)
7 ポイント 投稿者 GN⁺ 2025-10-18 | 3件のコメント | WhatsAppで共有
  • Phoenix LiveView は、アプリケーションの速度と開発速度の両面で高い効率性を提供する
  • フロントエンドとバックエンドをそれぞれ保守する必要がなく、1つの言語でモノリシックに扱える点が利点
  • Rails Hotwire や Laravel Livewire も検討したが、リアルタイム性やバックグラウンド処理の実装にはより多くの設定が必要
  • Elixir の Phoenix フレームワークは Ruby on Rails の優雅さを保ちながら、はるかに優れた性能を提供し、Oban によるバックグラウンド処理が標準で組み込まれており、馴染みやすくクリーンな構文を備えている
  • LiveView は WebSocket ベースでリアルタイムの双方向更新を提供し、従来のサーバーレンダリングとフロントエンド中心フレームワークのバランスを取り、必要に応じて Alpine.js や JavaScript ライブラリをフック経由で利用できる
  • Elixir/Erlang ベースの高速な開発速度、高い同時実行性、単一言語でほとんどを書けること、コンパイラによる事前のバグ検出、耐障害性アーキテクチャなどが最終選択の決定的要因

なぜ Phoenix LiveView を選んだのか

  • コーディングの目的は問題を最適な方法で解決することであり、自分にとって最も重要な要素はアプリケーションの速度と開発効率だった
  • React や Next.js を Laravel と組み合わせたり、Inertia.js を Laravel と併用したりする場合、フロントエンドとバックエンド両方のスタックを維持管理しなければならない
  • ソロ開発者として、2つの異なる場所で状態を管理する時間はなく、すべてをまとめて扱える堅牢なモノリシックソリューションが必要だった

  • 代替案の比較: Laravel Livewire、Rails Hotwire、Next.js

    • Laravel Livewire と Rails Hotwireは、JavaScript に大きく依存せずにフロントエンド作業を簡素化する優れたツール
    • Next.js によるフル JavaScript スタックも検討したが、バックエンドで JavaScript を使うことは好まなかった
    • Rails Hotwire は、Rails で MVP を素早く構築できる能力によって特に注目していた
    • しかし、バックグラウンド処理、リアルタイム更新、双方向通信が必要で、これは Rails や Laravel でも可能ではあるものの、より多くの設定作業が必要だった

  • Elixir、Phoenix、LiveView の決定的な長所

    • ElixirとPhoenixは、Ruby on Rails の優雅さを保ちながら、はるかに高い性能を提供する
    • Obanによる組み込みのバックグラウンドジョブ、親しみやすく読みやすい構文、そしてLiveViewのリアルタイム双方向通信が強み
    • LiveViewは、サーバーレンダリング方式とフロントエンドが重いフレームワークの間で理想的なバランスを取っている
    • WebSocket によるリアルタイム更新と、JavaScriptライブラリ（例: Alpine.js）との連携が可能
    • Phoenix は Oban の組み込みにより、バックグラウンドジョブの宣言と自動復旧が容易

  • Elixir/Erlang の利点

    • ElixirはErlang上に構築されたコンパイル言語で、WhatsApp や Discord のような大規模同時実行システムの基盤
    • 高い同時実行性、耐障害性、障害からの自動復旧を提供する

最終的に選んだ理由

  • 高速な開発と高い同時実行性のサポート
  • 単一言語でほぼすべてを実装可能
  • 可読性の高いコードを書ける
  • コンパイラが本番環境に到達する前に、ほとんどのバグを捕捉してくれる
  • 耐障害性アーキテクチャによりアプリがほとんどダウンせず、アプリの安定性を保証

結論とアドバイス

  • Phoenix が必ずしもRails、Laravel、Next.js より優れているわけではない
  • どのフレームワークも優れており、それぞれさまざまなプロジェクトで使った経験がある
  • 自分の特定の状況とプロジェクト（Hyperzoned.com）には Phoenix が最も適していた
  • すでに知っているものを超えて探求してみることで、次の問題を解決するより良く効率的な方法が見つかるかもしれない
  • 学びを止めないこと

関連記事

3件のコメント

 
clastneo 2025-10-23

JSPと同じ理由で、ある程度の水準を超えると使えないと感じます。
 
GN⁺ 2025-10-18
Hacker Newsの意見

  • Rails、Livewire、Phoenix、React向けにCKEditor連携を自分で試した経験がある。その中では、開発者体験としてはPhoenixが最も印象的だった。フレームワークの設計が非常によくできていて、統合作業が本当にシンプルだった。RailsやReact、特にNext.jsでは、こうした満足感はまったく得られなかった。Next.jsはルーター変更も頻繁すぎて、そのたびに変わるので信頼しづらい。LivewireはPhoenixに似た感触はあるが、相対的に直感性に欠け、機能も不足している。たとえばLivewireはコンポーネントスロットをサポートしていないが、Phoenixは問題なく処理できる。スロットがないとテンプレート構造が崩れ、コードも不必要に複雑になる。興味があれば ckeditor5-phoenix GitHub を参照してほしい

    • PHP（Laravel）とjQueryの組み合わせも2025年までは依然として実用的だと思う。ただ、Livewireは個人的には使いたくない。Node.jsは生産性が落ちることもあるが、より強力な機能が必要なときには有用だ。async/await、socket.io、TypeScriptもすべて使える。Next.jsはSEOと対話的UIの両方が必要な場合には便利ではあるが、実際にその両方が同時に必要なWebサイトがどれだけあるだろうか。LinkedInのようなサービスくらいではないかと思う

    • LivewireがPhoenixのコピーだとは思わない。名前だけ見ればそれっぽいが、両プロジェクトはほぼ同時に始まったと理解しているし、Livewireのほうがむしろ古いプロジェクトだ。Hotwireがその中では最も遅く登場した。両プロジェクトは異なるアプローチを取っていて、PHPとElixirは性質があまりにも違う。Livewireもかなり有用だと思う。PHPではWebSocketを簡単には使えないためHTTP中心で動くが、たいていの状況ではそれでも十分だ。むしろLiveViewのWebSocketは過剰なこともある

    • Railsでの問題体験について具体的に知りたい。どの部分が大変だったのか聞いてみたい

    • Railsを使ううえでどんな点が難しかったのか気になる

    • Livewire 4ではコンポーネントスロットがサポートされる予定だ。ただし、まだ数週間先の話だ。新バージョンではパフォーマンスや開発体験の向上もあるらしい

  • この記事は、著者が自分の選んだフレームワークを擁護し、他のフレームワークの機能を意図的に無視しているように見える。Phoenixの利点として挙げられている点はRailsにもすべてある。また、RailsがフロントエンドとのWebSocket通信をサポートしていないかのようなニュアンスを出しているが、Railsでここ3年アプリを作ってきた人なら完全に誤りだと分かるはずだ。もちろんPhoenixやLiveViewも良いツールなのは間違いないが、私がRailsを使い続けている理由はHotwire Nativeにある。モバイルとWebアプリの両方を短時間で一人で作れるので、生産性の面で非常に大きな利点がある

    • Rubyはあまり使ったことがないが、コミュニティ以外でRuby on RailsがElixir & Phoenixより優れている点が気になる。BEAMプラットフォームのおかげで、ソフトリアルタイムシステム、耐障害性、NIFs、actor model、膨大な数の軽量プロセス、考えやすい並行性、関数型プログラミング、OTP、停止しないGCなど、理論上はPhoenixのほうが圧倒的に良いと思っている。もちろん好きなものを使えばいいし、Hotwire Nativeも一度試してみるつもりだ

    • RailsでもWebSocketでフロントと通信できるのは明らかだ。実際、私はRails開発者だが、大量の持続的なソケット接続が必要ならPhoenixを選ぶ。PhoenixならGigalixirのようなサービスで、はるかに安く簡単に10万件のソケット接続を扱える。自前でインフラを管理するなら話は変わるが、Herokuでは数千件の接続ですら難しく、料金面でも負担が大きい

    • 記事のどこでRailsがフロントとのWebSocket通信をサポートしないと言っていたのか気になる。元文では「RailsとLaravelでもできることだが、セットアップに少し時間がかかる」としか書いていない。これはまったく別のニュアンスだ

    • Rails + Hotwireの組み合わせも本当に強力で、Hotwire Nativeまで加わればさらに良い。この記事の要点はPhoenixとLiveViewのほうが優れているということではなく、LiveViewの構造（サーバー主導の状態、プロセス分離、軽量チャネルなど）が特定の状況に適しているという点だ。両方のエコシステムは似た問題を異なる形で解いている。Railsは規約と段階的強化、PhoenixはBEAMの並行性と耐障害性でアプローチしている。結局重要なのは、どの構造が自分の作るプロダクトにより適しているかだ

    • Hotwire Nativeは以前に聞いたことがあるが、その後はあまり話題を見なかった気がする。実際のモバイルアプリで使った経験や、サポートやドキュメント、実装の完成度が気になる

  • 私もElixirに対して著者に負けないくらい前向きな感情を持っているが、CTOとして3年間本番環境で運用した結果、規模が大きくなるほど物足りなさも大きくなった。BEAM（並行性、耐障害性）は約束どおりに機能したし、Ecto、Oban、リモートiex、人材プールもすべて素晴らしかった。しかし、開発者体験（DX）は徐々にボトルネックになった。30万行規模の大規模プロジェクトで、次のような問題があった:

    • コンパイル時間: コードを1行変えるだけでも開発環境で10秒以上コンパイルがかかり、集中が何度も途切れた
    • ツーリング: ElixirLSの補完が信頼できず、関数名やスキーマフィールドを検索するのに時間を取られた
    • LiveView: 複雑なUIには向かず、結局Reactフロントエンドを導入せざるを得ず、GraphQLとスタック分割という複雑さがそのまま戻ってきた
      長期的に使うスタックを考えているなら、3年のRetrospective を読むと参考になるはずだ

    • Elixirで開発環境のコンパイルが1回10秒超というのはかなり驚きだ。ElixirはRailsより利点が多いとばかり聞いていたので、実務でこうしたケースがよくあるのか気になる

    • 私もElixirを学びながら似たような経験をした。言語自体は気に入ったが、WindowsでWSLを使って作業しているとLSPがよく壊れて不便だった。公式LSP が近いうちにリリースされる予定なので、この点が大きく改善されることを期待している

    • LiveViewでもReactでも、フロントエンドがうまく管理されないと大規模アプリではすぐにコードが散らかる。人数が増えるほど、コードレビューや不要なロジックの整理が必須になる。この点はどのフレームワークでも同じだと思う。今後も改善の余地は本当に大きい

  • 「バックグラウンドジョブ、リアルタイム更新、双方向通信を軽くサポートするのはRailsやLaravelでも少し設定を足せば全部できる」と主張しているが、Railsは標準でSolid Queue（ジョブ）とSolid Cable（リアルタイムメッセージング）をサポートしている

    • 最近Railsに移った立場からすると、SolidQueueは本当に簡単で、初期設定だけですぐ使える。Solid Queue Dashboard まで付ければ全体の状況を一目で把握することもできる

    • リアルタイムメッセージングだけで見れば、Solid Cableの設定はLiveViewより面倒だと感じる。LiveViewはレンダリングまで面倒を見てくれるので、RailsのSolidCable開発よりかなり先を行っていると思う

    • すべての機能はRailsでも実現できる。実に美しいフレームワークだし、Phoenixだともっと簡単で快適になる。ぜひ一度試してみてほしい

    • RailsとElixirの両方を実務で使った立場から言うと、この二つのシステムは決して同等ではない。Obanは使い方が明確で、再実行も単にDBカラムを更新すればOban supervisorがうまく処理してくれる。Solid Queueには成功したジョブを簡単に再実行する方法がない。テーブル数も多すぎて管理が大変だ。Obanは単純に2つのテーブルを管理するだけで、同じアプリの中で自然に動く。一方のSolid Queueは、複数のブログを参考にしながら設定値を変えないとまともに動かない。デフォルト設定が不足している。Erlang/Elixirの特性のおかげで、Obanはとてもシンプルに作られているのに非常に優秀に動作し、開発者として嬉しくなる。Solid Queueは仕方なく使っている

  • 長年Rails開発をしてきたが、最近はPhoenix/Elixirが標準スタックになっている。RailsはいまだにCRUDアプリを素早く作るには本当に最高で、その点では群を抜いて優秀だ。しかし、複雑さが増し時間が経つほど、総合的にはPhoenix/Elixirのほうがより良いツールになる

    • LLMの登場以降、こうしたシンプルなアプリは数分で生成できるようになった。ただ、気を配るべき主要な部分については、Phoenixのほうがより多くの制御権を与えてくれる感覚がある

    • どの点がより合っているのか、何がより優れていると感じるのか、もう少し具体的に聞いてみたい

  • 「私たちは問題を最適な方法で解決するためにコードを書く」という一文からは、本人の情熱が感じられる。私は解決できればそこそこで満足するタイプなので、Railsにとどまるほうが自分には合っている気がする

    • その一文を見て吹き出してしまった。現実的には、コードを最適化することばかり考えて書いていると、結局仕事は遅く進む。私にとってコーディングは生計を立てる手段でもあり、ときには趣味として楽しむものでもある

  • Elixirはコミュニティ規模が小さいと言われるが、最先端のライブラリでかなり高いレベルに挑戦している。昔ある開発者が「少ないほど良い」と言っていたのを思い出す。elixir-dbvisor/sql のような良いオープンソースも多い

    • 一方でJSエコシステムは規模が大きすぎてしんどく感じる。10個のライブラリがそれぞれ独立して存在し、誰も標準に従わない。アメリカの大型スーパーでメニューを選ぶとか、Vercelのチェーンレストランで選択を強いられるようなものだ

  • Elixirの真価を感じたいなら、Saša Jurićの講演動画を全部見ることを勧める

    • Saša Jurićは『Elixir in Action』の著者で、この本も本当に素晴らしい

  • この記事はフレームワーク全体というよりPhoenix LiveViewに焦点を当てた内容だ。実際、Phoenixで生成時オプションからLiveViewを外しても、デフォルトのLVコードがあちこちに残る点が嫌だ

    • 私もLiveViewが非常に強い作法を持ち、ボイラープレートが多い点には共感する。Elixirの簡潔さや表現力が好きなのに、LiveViewはその逆に感じられる

  • Elixirを選ばなかった唯一の理由は型チェッカー不在だった。何か変化があったのか気になる
 
colus001 2025-10-18

Livewire が面白いのは事実ですが、UI が少しでも複雑になると地獄になります。その瞬間から Phoenix は強みを一気に失ってしまいます。サイクルが長くなるほどつらくなるので、私はあまりおすすめできませんね。