Phoenixフレームワークには、最初からどんなキャッシュが提供されてるの？

LiveViewが大好きなんだ。最近クライアントのプロジェクトで使ってて、すごく…リラックスできる。めっちゃ好きだよ。

specialized hosting どういう意味？私のプライベートなnext.jsフルスタックアプリは、Kubernetesクラスター上でDocker化されて動いてるし、認証にはauth0を使ってるよ。だって、keycloakとか今流行りのDocker化された認証を動かすのが面倒なんだもん。

BEAM仮想マシンについて。軽量で隔離されたプロセス、メッセージパッシング、スーパーバイザー、ホットなランタイムのイントロスペクション、障害の隔離は後から追加されたライブラリじゃなくて、基盤そのものなんだ。アプリを作るなら、以下の要素が必要になるよね：+ 多くの同時ユーザー + リアルタイムUI + バックグラウンドジョブ + ワークフロー + 状態を持つセッション + 分散イベント + 障害の隔離 + 「このアプリは数ヶ月間動き続けるべき」 そういう場合は、BEAMの上に構築されたものが欲しくなるよ。

要するに、LiveViewはウェブ専用だよ。LiveViewをネイティブにする試みはあったけど、すごく難しいし、今のところ（私の知る限り）全部失敗してる。最近考えてたんだけど、carsandbids（Doug DeMuroの車オークションサイト）はBlazorを使ってるみたいだね（少なくとも私が見た限りでは）。これがBlazorの最大の利点の一つだと思う—ネイティブアプリとウェブアプリの両方を作れるのに対して、LiveViewは絶対にそうじゃないから。Microsoftがそれを支払えるから（または少なくとも大規模なインフラをサポートできるスポンサーがいるから）。それに、これは解決するのがすごく難しい問題なんだ。膨大な資金が必要で、AndroidとiOSのSDKを理解できる大きなチームや、純粋なエンジニアリングの課題に取り組む人を雇うための資本が必要だから（だからMSやMetaができるんだ）。エンドユーザーは、LiveView、Blazor、React、Java、SwiftUIなどで作られているかなんて気にしないし、長期的にそれを実現できる企業のリストは非常に少ない。OTPを実装したり、他の言語やランタイムに意味のある形でトランスパイルするのも簡単じゃない問題だし。Erlang、BEAM、OTPは特定の問題のために非常に特異な方法で一緒に作られたもので、もし一緒に開発される必要がなかったら、死んだ言語、ランタイム、プラットフォームになってたはずだよ（ちなみに、全然そんなことはないけどね）。

多くの人がliveviewを好きだよね。逆にblazorを嫌う人も多いし、Microsoftがそれを「新しいwebforms」として扱ってるせいで評判が悪くなってる（実際、レガシーwebformsプロジェクトの公式な移行パスになってる）。blazorの利点は、C#と.NETエコシステムだと思う。もし私が選ばなきゃいけないなら、ほとんどの他の技術よりblazorを選ばないかな。悪い経験があるからね。技術的にはすごく似てるけど、開発体験が大事だと思う。

正直、それはJSフレームワークからコピーされたものだよね。君に同意するけど、時々スコープ付きCSSがあると便利だと思う。

colocated JSが結構好きだな。コンポーネントの中に「フック」コードを定義する方が好きだ。悪用することもできるけど、単に「JSファイルを書くのを避けるため」にテンプレートにcolocated JSを入れることは絶対にしないけど、email_inputコンポーネントのすぐ隣にemail_validator.jsのコードを置くのはいいと思う。モジュール名を継承することが基本的に強制されるから、MyAppWeb.Admin.Components.EmailValidatorがMyAppWeb.Admin.Componentsモジュールにいるのは明らかだしね。実際にどれくらいJSを使うかにもよると思うけど、私のライブビューアプリのほとんどは「ここかそこか」で何かを強化したり、ちょっとしたDOMの操作をするために使ってる。もしどこでもReactコンポーネントを立ち上げて、他の既存のJSコードが山ほどあるなら、あんまり良くないかもね。

Surface、Vue、Svelteはずっとcolocated cssとjsを使ってるよね。これのおかげで、メンテナンスしやすいコードになるし、tailwindみたいな解決策に頼らなくても済む。グローバルスタイルはまだグローバルでいられるけど、コンポーネントレベルのスタイルはコンポーネントレベルに留まるんだ。