俺はReactやNext.jsのユーザーじゃない。他の人は異論があるかもしれないけど、個人的には、伝統的なHTML+CSSのドキュメントに必要に応じてバニラJSをデコレーションすることで、JSへの接触を最小限に抑えたいと思ってる。シンプルなNext.jsのランディングページがFirefoxで壊れるのを見た時は、ちょっと驚いた。さらに悪いことに、失敗モードはすべてのコンテンツを黒い画面と白い文字で覆って、「アプリケーションクライアントサイドエラーが発生しました」って表示されることだった。シンプルなランディングページがレンダリングできないのは驚きだったけど、その原因がJSのフロントエンドフレームワークだと知った時は、まあそういうもんだなって感じた。支持者には意味があるのかもしれないけど、バンドワゴンに乗ってない俺たちには、本当に混乱することがある。

Nextはかなり前に自分たちをダメにしちゃった。VCサイクルを通るものは、結局そうなるんだよね。彼らとそのお金には嬉しいけど、もう使えないな。今はViteをデフォルトオプションにしてるけど、もっと軽量なものがいいな。

返信ありがとう。でも… > OPがログについて言及してるから、計測と可視化のためにOpenTelemetryを取り入れて、instrumentation.tsの規約を作ったってことは、ちょっと不器用なログ機能の答えが、単にもう一つの重い複雑さのレイヤーを追加することになってるみたいだね。確かに、すべてのアプリケーションがOpenTelemetryを必要とするわけじゃないよね。logger().info()が普通に動けばいいのに。そんなに難しい問題じゃないでしょ？他の言語やフレームワークはみんなやってるのに！

もし本当に適切なサーバーサイドミドルウェアをサポートすることに決めたなら、なぜ他のまともなサーバー実装が提供しているように、ミドルウェア関数を一つだけでなく、チェーンにできないの？

ここにいるから、ちょっと言わせて。この記事では、著者がドメインの違いを理解できず、どこでも同じアプローチで関数を呼び出そうとしている。そりゃうまくいかないよ。Next.jsの誤りは、本質的に異なる関数ドメインを混ぜようとすることだ。そんなことはやめれば大丈夫。ドキュメントは役に立たないし、ただ混乱を招くだけだよ。エッジとSSR、Nodeとクライアントサイドを一つに混ぜるのはめちゃくちゃで、その試みは冗長なフレームワークの複雑さを生むだけなんだ。

ストリーミングへの執着が新しい制約の大きな要因だと思う。それに、最低限の共通点をサポートすることも。

たとえ最初のカテゴリに当てはまっても、VercelとSSRを使うことでパフォーマンスのボトルネックが解決されるとは思えない。みんながやってる他のクレイジーなこと（数メガバイトのバンドルサイズ、DBへの何十回もの往復を伴う遅いAPIコールなど）を考えると、基本的なプロファイリングや最適化、シンプル化をする方が、もっと進展があるように思える。

そう、基本的にはそれだね。Vercelは、React Server Components、部分的なプリレンダリング、エッジサーバー、ストリーミングなどの組み合わせを使って、最適化されたパフォーマンスを解決しようとしてる。彼らの一見変わったデザインやAPIの決定は、基本的にそれに帰結するんだ。必要なら、それが存在するのはいいことだよね。でも、エッジ関数でSSRをやるだけでもかなりのところまで行けるよ。

どこかで言われてたけど、これがSSRフレームワークが何十年も持ってきたレイヤーなんだ。もしかしたら、すべてにSPAsを使わないことを学ぶべきかもね。

その状況には同意しないけど、たとえNext.jsと一致することを示していたとしても、それに伴う生産性や保守性の低下には見合わないよね。私はGleamのLustreを使ってて、もう戻る気はないよ。Elmの創設者がNext.jsの真逆についての素晴らしいケーススタディの基調講演をしてたんだ。

そうでなければ、よく知られた道を進んで、react-viteのSPAか、Railsを使った普通のSSRにこだわるべきだよ。大人なやり方でSPAを書こう。APIは、その作業に適した言語とフレームワークで書いてね（Rails、Spring、今年のMicrosoftの.NETウェブ技術の名前、何でも好きなものを選んで）。フロントエンドはTypescriptで書こう。フロントエンドとバックエンドを密結合する理由なんて全くないよ、2015年に「アイソモーフィック」という言葉を覚えたJavaScript開発者が何人いてもね。

これらの問題の半分は、コードが正確にどこで動いているのかの相対的な誤解から来ている。別の言語を見てみると、こういったマルチスレッドの問題は、通常、別のコンテキストや同期パッケージ（ミューテックスやアトミックを扱う）を標準ライブラリで提供することで表現される。Node.jsやブラウザ側のJS環境には、こういった罠に陥らないようにするための標準ライブラリが完全に欠けていると思う。それが、下流のパッケージやライブラリの質を向上させるために強制されるべきものなんだ。

これらの問題の半分は、コードがどこで実行されているかの相対的な誤解から来てる。私はかつて、どこでもJavaScriptが使えるのは利点だと思ってたけど、今はそれが悪いアイデアだと思うようになった。私の会社はInertia.jsとVueを使っていて、かなり良い体験になってる。現代的なフロントエンドレンダリングの力はそのまま得られるけど、全体のアーキテクチャはずっとシンプルなんだ。ルーティングは100%サーバーサイドで、一般的なAPIは必要ない。（注：InertiaはReactやSvelteとも動くよ）最初はNuxtを試したけど、ひどい状況だった。実際のバックエンドサーバーとフロントエンド用のサーバーの2つが必要になって、コードが実際にどこで実行されているのかを理解するのがすごく複雑だった。今は超シンプルだよ。PHPならサーバー上、JSならブラウザ内。これを疑う必要がないのは、私たちにとって大きな助けになってる。

お互いに少し互換性のないツールやライブラリを組み合わせるのは本当に面倒だよ。これが私の仕事。私たちは小さなチームで、私の仕事は物事を最新の状態に保つことなんだ。信じられないくらい時間がかかるよ。ハード依存関係のあるパッケージや、5年前にサポートが終了したパッケージがあるからね。

いや、Laravelは過剰に設計された抽象化が時にはうまくいくことを証明してるよ。Laravelは本番環境で素晴らしく動いてるし、使ったことを後悔したことはない。

あなたの観察は一般的に当てはまるね。「魔法の」フレームワークのデバッグは、シンプルな基本と一貫したデザインから始めるよりも複雑なことが多い。ボーナスとして、依存関係が少なく、ビルドの問題も減って、ページやバイナリが軽くなるよ。

私にとっては二番目に悪い。Sharepointを使ったことがあるよ。

多くの抽象化やNext.jsのツールは、私のOSがもっと良く、クリーンに、予測可能にやってることをやってるよ。Windowsが環境変数を持ってない（持ってなかった？）から、過剰に複雑なENV/.envの読み込み階層が（部分的に）必要なんだろうね。inotifyやポート検出、スレッド管理も同様で、*nixはそれをうまくやってる。だけど、*nixとWindowsの両方で同じように動くインターフェースや機能が欲しいときは、結局Next.jsみたいな再発明されたホイールや抽象化の山に行き着くことになる（結局、いつも漏れちゃうんだけどね）。

代わりに何を使ったの？

Next.jsの経験から言うと、その粗い部分はバグじゃなくて、むしろ特徴だよ。すべてがVercelのホスティングを使う方向に向かってる感じ。

もし私があなたをインタビューしていたら、それはあなたにとってプラスになるポイントだね。実際、その逸話を話すのは、クールエイドを飲んでる会社を見極めるいい方法かも。