Next.jsは最悪だと断言！開発者が『もう二度と使わない』と怒り爆発する理由とは？
引用元：https://news.ycombinator.com/item?id=45099922
完全に同意！Next.jsは最悪で、二度と使わないし、他のチームにも使うのをやめるよう勧めるよ。Next.jsはほとんどのプロジェクトに不要な抽象化レイヤーが多すぎるんだ。僕が今まで使った中で一番ひどい技術だよ。
Next.jsの荒削りなところはバグじゃなくて、むしろ意図的な機能だと感じてる。全部Vercelのホスティングを使わせるために設計されてるんだよね。
全く同感だね。Next.jsはさらに悪くなるだろう。今、PluralSightとかのオンラインコースがReact関連のほぼ全てのコースでNext.jsを推してるんだ。こんなひどい状況になったのは一体どういう考えからなのか、全然理解できないよ。
みんなが使ってるからって理由で、自分も使うって流れなんだろうね。
「みんなが使ってるから」ってだけじゃない気がするな。Next.jsはcreate-react-appの後継としてreact.dev[1]でも推されてるけど、これは前提からして変だ。何かおかしなことが起こってるよ。
[1] https://react.dev/learn/creating-a-react-app
同じ意見の人がいて嬉しい！Next.jsでアプリ作ったけど、Pocketbaseだけが唯一良かった点だよ。無限の複雑さ、絶え間ない破壊的変更、意味不明なドキュメントで最悪だった。Next.jsはReactよりもひどい。GoとVanilla JSで作ったCMSはDXは劣るけど、何が起こるか予測できる。ReactとNext.jsでは6年経っても何が起こるか常に勘に頼ってる。なんでフロントエンドでこれができないんだ？
代わりに何を使ったの？
Next.jsの多くの抽象化やツールは、OSがもっとうまく、きれいに、そして予測可能にやってくれることをしてるんだ。ENVや.envの複雑なロード階層はWindowsがENV varsを持たない（持たなかった？）せいもあるかもね。inotify、ポート検出、スレッド管理もそうだけど、両OSで同じように動くようにするとNext.jsみたいな再発明の車輪と抽象化の山になっちゃうんだよ。
先月、クライアントのためにアフリカのエンジニアリンググループが作ったNext.jsのアプリに手を出したんだけど、Vercelのホスティングにべったりで他のどこでも動かせなかったよ。NPOだったからVercelを使う余裕がなくて、僕が動かそうとしたけど1週間格闘しても無理だった。「JavaScriptなんだからどこでも動くはず！」って思ったのが甘かったね。スパゲッティコードとライブラリの山を解きほぐせず、コンパイルは通っても出力は欠陥だらけでエラーも出ない。ツールチェーンからデプロイプラットフォームまで、とにかく変なことだらけだったよ。
最近のフロントエンド面接、面白かったよ。30分でReactプロジェクト作らせて、useStateやuseEffectの使い方を見てもらうんだけど、GoogleもChatGPTも使っていい。でもね、候補者の半分以上がNext.jsなしでReactを使えなくて、不可能だとまで言い張る人もいたんだ。信じられないだろ？
多分、基本的なReact経験を見てるんじゃない？だいたいどんな面接も、誰かにとっちゃダメに聞こえるもんだよ。で、君にはどんな面接がうまくいったんだい？
あれってReactの細かい部分のテストって感じだろ？フレームワークからランダムなピースを取り除いて、その周辺をどれだけ知ってるか、ってさ。フレームワークってデカくて複雑だし、運任せにしか思えないな。俺は最近、「これはChatGPTが作ったコードだけど、どこがダメ？どうする？」って質問してるよ。（実際にChatGPTが作ったかどうかは関係ないんだけどね）
4年半、Next.jsとGraphQLでSaaSやってるけど、Pages Routerを使い続けたらほとんど複雑さが消えたよ。最近authをbetter-authっていう別サービスに書き換えたおかげで、Next.jsから完全に乗り換え始めてるんだ（React Router 7かTanstack Routerを検討中）。Next.jsはSSRを簡単にしてくれたけど、結局俺には必要なかったってオチ。マーケティングサイトは静的だし、アプリはクライアントレンダリングだからね。
「数年前のコードベースもまだしっかりしてる」ってのが、俺には一番重要だね。最近、8年前の趣味のJava/Mavenプロジェクトを動かしてみたら、一発でコンパイルしてバッチリ動いたんだ。これを8年前のJavaScriptプロジェクトでやろうとしたら…想像してみてよ、絶対無理だろ？
JavaScript版のSpringって感じがするね。
みんなNext.jsに不満を言うけど、完璧な解決策なんてないんだよ。Nextで問題になる複雑さは、他の方法でも形を変えて出てくるんだ。Remixも競合だけど、それにも独特の癖がある。ViteやTanstack Routerなんかで自分で作ることもできるけど、結局は同じような機能を自分で実装することになるだけ。それはそれでニーズに合うかもしれないけど、みんなにベストな選択肢ってわけじゃない。
＞Windowsには環境変数がない（なかった？）って？いやいや、WindowsはDOSの頃から、ちゃんと標準的な環境変数を持ってるんだよ。
Next.jsは、その荒い部分がバグじゃなくて機能で、Vercelのホスティングを使わせようとしてるって意見に同意だわ。SSRとかもスムーズに導入されるけど、Vercelにお金払わないとこのスムーズさは維持できない気がする。Reactエコシステム全体が企業に乗っ取られちゃったんじゃないかって心配だよ。どうなるか見てみよう。
今のWeb開発ってブログみたいなコンテンツサイトからECサイト、UXデザインや動画編集みたいな複雑なアプリまで、範囲が広すぎでしょ。こんな幅広いソリューションを全部同じ解決策でカバーしようとするのはナンセンスだよ。
BashみたいにKEY=value ./myAppって感じで、実行一回だけに変数スコープさせる機能が「足りない」ってことだな。WindowsのコマンドプロンプトやPowerShellだと、そういう風にはできないんだよな。
完璧な解決策はフロントエンドにReact、バックエンドにPHP, Java, Rubyとかを使うことだよ。サーバーサイドReactなんて、いらん変な機能を追加するだけだ。VCが出資してるVercelはNext.jsをわざと単純にして、みんなからお金を取ろうとしてるんだ。この罠にはみんな気をつけなきゃいけないぞ。
SvelteKitが大好きなのは、自己ホストしやすいし、どこでもサーバーレスでホストできるからだよ。俺はCloudflareにホストしてるんだ。LLMの分野ではみんなNext.jsを推してるみたいだけど、SvelteKitでもすごいことできるし、SvelteKitを使ってる時が楽しいんだ。
ちょっとやりすぎかもしれないけど、Cogent Core[0]ってのがあってさ。これはデスクトップ、モバイル、Webアプリ全部をサポートしてるんだ。2Dも3Dもいけるし、Goでバックエンドもフロントエンド（WASM使ってね）も全部できるんだよ。
[0] https://github.com/cogentcore/core
なんでだよ？MicrosoftのGUIフレームワークもAppleのも、Webブラウザが出てくる前からいろんなユースケースをカバーしてたじゃんか。
完全に分離させたいなら、cmd /C ”set KEY=value && ./myApp”もそこまで悪くないぜ。
Win32やMFCがそんなにすごかったんなら、なんでHTMLはあんなに人気になったんだろうね？
覚えておいてほしいんだけど、Next.jsは最新のReact機能の一部をサポートできる唯一のフレームワークなんだ。だから多くの人にとっては、”みんな最新のReact機能が欲しいはずで、それを手に入れる唯一の方法がNext.jsなら、みんなNext.jsを欲しがるはず”っていう単純なロジックなんだよ。
問題の半分は、コードがどこで動いているのかという誤解から来てるんだ。Next.jsはブラウザ、ミドルウェア、Edge、Node.js、SSRが絡み合ってて、ものすごく複雑なんだよ。だから、本当に合うのは特定の状況だけ。
例えば、グローバルなB2C製品を売っててEdgeがレイテンシを改善する、Vercelに高い金を払ってホスティングしてもらう、バックグラウンド処理がいらない場合、とかね。そうじゃないなら、React-Vite SPAかRailsみたいな普通のSSRで十分だよ。
成熟したやり方でSPAを書くべきだよ。APIはそれに合った言語とフレームワーク（Rails、Spring、今年のMicrosoftの.NETウェブ技術とか、何でもいいよ）で書いて、フロントエンドはTypeScriptで書くべき。2015年に”isomorphic”って言葉を覚えたJavaScript開発者が多いけど、フロントエンドとバックエンドを密結合させる理由は全くないんだ。
俺にとっては、フロントエンドとバックエンドを同じ言語でモノレポにするのが、めちゃくちゃ生産性向上につながるんだ。もちろん、フロントエンドとバックエンドでチームが別なら逆も真だけど、とにかくリリースしたいなら、これ以外の方法は考えられないね。
もっとコメントを表示（1）
コードがどこで動いているかの誤解って話だけど、JavaScriptがどこでも使えるのはメリットだと思ってたけど、今は悪いアイデアだと思ってるよ。うちの会社はInertia.jsとVueを使ってるんだけど、かなり良い体験だよ。モダンなフロントエンドの全てのパワーは得られるのに、アーキテクチャははるかにシンプルなんだ。ルーティングは100%サーバーサイドだし、一般的なAPIは必要ない。
うちは最初Nuxtを試したんだけど、ひどいもんだった。バックエンドサーバーとフロントエンドサーバーの2つになっちゃって、コードがどこで動いてるか訳わからなくて複雑すぎたんだ。今はすごくシンプルだよ。PHPならサーバー、JSならブラウザ。これを疑う必要がないのが、めちゃくちゃ助かってる。
Vercelは、資金難に苦しむ多くのオープンソースプロジェクトに資金提供やスポンサーをしてるんだよ。彼らのフレームワークがプラットフォームに合わせて作られてるのは、それが良い体験になるから。俺は今使ってないけど、良い開発者体験だからみんな有料プランに流れてるんだ。彼らが営利企業で独自の動機があるのは認めるけど、”現代ウェブのガン”ってのは言い過ぎだと思うな。
コードがどこで動いているかの誤解って話だけど、他の言語を見ると、こういうマルチスレッドの問題は通常、標準ライブラリで別のコンテキストや同期パッケージ（ミューテックスやアトミック処理を扱うもの）を提供することで表現されてるんだ。Node.jsやブラウザ側のJS環境には、こういう落とし穴にはまらないようにする標準ライブラリが完全に欠けてるんだと思う。それが下流のパッケージやライブラリの品質を向上させるためにも必要なんじゃないかな。
App Routerはコードがどこで動いてるか分かりにくいのが問題だよな。Pages Routerならこんなことなかったのに。
同感。ボタンのパディング変えるだけで、バックエンド全体が再デプロイされるとかマジありえないだろ。
Vercelはインフルエンサーをうまく使ってバズってるけど、そのせいで悪い評判も出てるんだよね。インフルエンサーってウザいけど、マーケティングには必要な悪みたいなもんか。
僕はそうは思わないな。フロントとバックエンドを同じ言語で書けるのはめちゃくちゃ便利だよ。もう前のやり方には戻りたくないね。Django使ってた時、JavaScriptとPythonで全部重複させるのが本当に大変だったからさ。
フルスタックでリッチなスキーマは、長期的な品質と開発速度にめちゃくちゃ貢献するんだよ。ZodとかArkType、Valibotは全部すごい。
コードの実行場所が分かりにくいって？ファイルの先頭にある”use client”を探せばいいだけだろ。
その状況に同意はできないね。仮にNext.jsと合致したとしても、生産性や保守性の低下に見合うものじゃない。僕はGleamのLustreを使ってて、もう後戻りできないよ。Elmの創業者がNext.jsとは真逆のケーススタディを発表してるから見てみて。https://www.youtube.com/watch?v=sl1UQXgtepE
”PHPならサーバー、JavaScriptならブラウザ”っていう明確な区別が便利だったって？
言語切り替え、特にPHPとの間でコンテキストスイッチする方がよっぽど大変だろ。strlen($var)かvar.lengthかmb_strlen($var)かとかさ。JavaScriptをPHPから出力するの？あと、JavaScriptとPHPでロジックの重複をどう避けるんだよ？特にバリデーションとか。Next.jsならその問題から解放されるんだ。
そうなんだよな。VercelはReact Server Components、Partial Pre-rendering、Edge servers、ストリーミングなんかを駆使して、パフォーマンスを最適化しようとしてるんだ。Next.jsの変に見える設計やAPIの決定は、ほとんどがその目的から来てる。必要なら便利だけど、Edge functionでSSRするだけでも結構いけるからね。
モノレポはどんな技術スタックでもできるよ。フロントエンドとバックエンドを同じ言語で書くこともできるしね。君の生産的なセットアップに文句はないけど、Next.jsがフロントエンドとバックエンドを密接に結合させるのは間違いない事実だ。
SPAなんて書かなくていいんだよ。バックエンドからハイパーメディア送って、HTMX + AlpineとかDatastar使えばそれでOKじゃん。
バックエンド開発者なんだけど、イベント用の一時的なサイトを作るのにフロントエンドを学ぼうと思ってさ。
20種類のフレームワーク見てSSRとかCSRで混乱した結果、Nuxtを選んだんだ。Vueアプリが簡単になると思ってたけど、めちゃくちゃ間違いだったよ。
SupabaseとVercelと連携したら、いろんな問題にぶつかって、Squarespaceで作り直そうかと思ったくらい。
まるで中間管理職の言い草だな。
誰がPHPからJavaScriptを送るんだ？JSONの翻訳とかヌルチェックの重複なんて気にする意味ある？
今の時代、全部コードなんだからさ。言語を変えるって？ほとんどのJSはそのまま使えないし、split()みたいな簡単なものでも変なバグが多いから、みんな結局ユーティリティライブラリからコード使うんだよ。
これって、何年にもわたる履歴書と仕事の安定を追い求めた開発の最終産物なんじゃないかな。
じゃあHTMLは？JavaScript経由でHTMLを書いてるの？
そうじゃないなら、もうすでに複数の言語を使ってるってことじゃん。
OPじゃないけど、記事はasync/awaitのコンテキスト問題についてじゃなかった？
もしミドルウェアAPIのhandle()メソッドがcontext.Contextパラメータを提供してたら、記述されてるデバッグ問題のほとんどは解決してたと思わない？
“use client”の挙動は複雑で、初期レンダーはサーバーだし、子コンポーネントにも継承されるから、“use client”を探すだけじゃダメだよ。公式ドキュメントの説明も難解で、いつ、どこで何がレンダーされてるのか理解するのがめちゃくちゃ大変！特にRSC Payloadによる「調整」とか、プリフェッチ・キャッシュの裏側とか、Next.jsのレンダリングモデルは本当にわかりにくいんだ。
これってWeb開発に内在する問題なんじゃないかな。JavaScript開発者たちは型システムを手にして、強力な型チェックでネットワーク呼び出しを改善できると考え、プログラミングの頂点に達したと思ったんだ。
でも、ある時点で、もうWebアプリじゃなくて、不安定で不正確なランタイムで、速度もなく多くの欠点があるアプリを書く方がマシになる。
Webの最も根本的な部分である相互運用性も失われるしね。
他の言語を特定のオブジェクト方言に合わせることはできるだろうけど、他の型システムを悩ませる問題は、君のシステムでも悩ませるだろうね。
結局、何もないと砂に頭を突っ込んで主張しても、何も良くならないんだよ。
違うよ。インフルエンサーじゃなくて、ベンチャーキャピタルに支援されてるVercelのビジネスプランが問題なんだ。
彼らは主要なWebフレームワークのコアコントリビューターを雇って、自社内で開発を続けさせてる。だから、Webプラットフォームの継続的な改善は、Vercelの投資家たちの気まぐれに大きく左右されるんだ。
彼らは全てのホスティングプロバイダーに平等に対応してるふりをするけど、Next.jsを見てみろよ。常にVercel向けに作られてる。NuxtやSveltekitもいつかこうなるのかな？
Vercelは今やSSR市場全体で戦略的な動きができる立場にある。その力を使うかどうかにかかわらず、その力を振るう立場にあること自体が問題なんだよ。
こんな状況が良い結果を生んだことなんてないし、これからもないだろうね。
最初のカテゴリに当てはまるとしても、VercelとSSRでパフォーマンスボトルネックが解決するとは思えないな。みんながやってるような巨大なバンドルサイズや遅いAPIコールを考えると、プロファイリングや最適化、簡素化といった基本の方が、複雑なアーキテクチャに変えるよりよっぽど効果的だよ。
”Next.jsはフロントとバックエンドを密結合させる”って意見は間違ってると思うよ。Next.jsサーバを直接DBに繋ぐ必要なんてなくて、内部APIと連携させればいいんだ。モノレポで管理したり、最適化されたペイロードやレンダリングキャッシュにだけ使ったり、ほぼ純粋なSPAとしてNextをクライアントコンポーネントの提供だけに使うこともできるしね。結合の密着度は実装者次第だよ。
フィードバックありがとう。MiddlewareのDXの問題はよく分かってるよ。Next.js 15.5でNode runtimeのサポートを大きく進めて、多くの報告された問題を解決したんだ。昔に戻れるなら、”ルーティングMiddleware”か”ルーティングハンドラ”って呼んだだろうな。ログの話だけど、計測と可観測性のためにOpenTelemetryを採用してて、instrumentation.tsっていう規約があるよ。
https://nextjs.org/blog/next-15-5#nodejs-middleware-stable
https://nextjs.org/docs/app/api-reference/file-conventions/i…
返信ありがとう。でも…OpenTelemetryを採用したってことは、扱いにくいログ機能の答えが、さらに複雑なレイヤーを追加することってこと？きっと全てのアプリにOpenTelemetryが必要なわけじゃないよね。なんでlogger().info()がまともに動かないのさ？こんな難しい問題じゃないはずなのに、他の言語やフレームワークはみんなできてんじゃん！
”なんでlogger().info()がまともに動かないのさ？”って話だけど、OpenTelemetryはベンダーフリーでかなり合理的だと思うよ。デバッグモードならコンソールエクスポーターも使えるしね。
Next.jsがプロダクションレベルのアプリを簡単に作れるフレームワークとして設計されてるなら、OpenTelemetryで可観測性を標準化するってのは価値のあるトレードオフじゃないかな？それがやりすぎだと思うなら、たぶんNext.jsのターゲット層じゃないのかもしれないよ。
https://opentelemetry.io/docs/languages/js/exporters/#consol…
ネガティブな意見が多いけど、Next.jsはやってることに見合って本当に素晴らしいよ。数百万のウェブサイトを動かしてるのはすごい。ただ、ネガティブなのは詳細なドキュメントやリファレンスがほとんどないからじゃないかな。ドキュメントは「何があるか」は伝えるけど、「どう使うか」や「よくある落とし穴」が足りないんだ。初心者には優しいけど、APIの実行コンテキストやサーバ環境でのReactの複雑さについて詳細が欠けてる。良いドキュメントは難しいけど、引き続き頑張って！
8年も経つフレームワークなのに、もうバージョン15.xに達してるって問題だと思わない？もしセマンティックバージョニングに従ってるなら、15回も後方互換性のないアップグレードがあったってことになるよね？
やっとまともなサーバサイドMiddlewareをサポートすることにしたんなら、なんでMiddleware関数が一つしか使えないって制限があるんだ？他のちゃんとしたサーバ実装はみんなMiddlewareのチェーンを提供してるじゃん！
もっとコメントを表示（2）
middleware.tsをルートMiddlewareだって考えればいいんじゃないかな。その中で自分でMiddlewareチェーンを作るのは簡単だし、何も問題ないよ。Next.jsがその機能を実装したとしても、結局どこかにルートがあるわけで、同じように動くはずだよ。
なんでNext.jsみたいな重いツールが必要なの？PHPのMonologみたいに、ほとんどのフレームワークには最初から強力なロガーがあるのにさ。
それじゃ前の質問に答えてないじゃん。みんな「ミドルウェア」が特定の意味を持つことや、特定の動作をすることに期待してるんだよ。
Next.jsを簡単に動かしたり監視したりさせないのは、彼らの利益にならないからだよ。それが難しいからこそ、みんな彼らのプラットフォームを使うことになるんだ。目標はスタックを複雑にして、Next.jsを自分で使うのを難しくする、見栄えの良い事前最適化を提供することだね。
OTELの何が具体的に重いんだ？OTELはログの標準と収集の標準だろ。重さは実装次第で変わるよ。PHPのMonolog用ハンドラーもあるし、両立できるんだ。詳しくはこちら: https://github.com/open-telemetry/opentelemetry-php/blob/main/examples/monolog/README.md
ミドルウェアは fn(req) → next(req) の形だよ。ExpressやKoaみたいなフレームワークにはチェーン機能があるけど、Next.jsでは自分でチェーンを組めばいいだけだ。具体的なTypeScriptのコード例も紹介してくれてるよ。ルートは決まってるから、チェーンの実装は簡単だって言ってるね。
Next.jsアプリのセルフホスティングは詳しくないけど、k8sにデプロイするなら、OpenTelemetryコレクターのサイドカーを動かすのは難しくないよ。Prometheusスクレーパーでログやメトリクスを収集するのと同じで、APM、ログ、トレースをOTLPフォーマットで一元管理できるんだ。
この記事の著者は、ドメインの違いを理解せず、どこでも同じ関数呼び出しを適用しようとしてるね。それはうまくいかないよ。Next.jsの誤りは、本質的に違うドメインを混ぜようとすることだ。これをやめれば大丈夫。エッジとSSR、Nodeとクライアントサイドを混ぜるのは混乱のもとで、結果的にフレームワークが複雑になるだけだよ。
Next.jsは使ったことないんだけど、ほとんど自動でコードを修正して移行してくれるツールがあるみたいだね。コマンドは npx @next/codemod@canary upgrade latest だって。
それじゃ、ドメインを混ぜるのが重要なReact Server Componentsも好きじゃないってことになりそうだね。
あのミドルウェアの実装は全然簡単じゃないよ。どこにミドルウェアがあるか管理しないといけないし、reduceRightも分かりにくい。僕はフレームワークが、そういう面倒な部分を標準化して、使いやすくしてくれることを期待してるんだ。だからフレームワークを使うんだよ。
k8sを持ち出すと彼らの主張を裏付けてるじゃん。ロギングはもっと死ぬほど簡単であるべきで、ほとんど何も設定せずできるべき。sidecarコンテナなんて知る必要ないんだよ。
そう、でも例えばテキストファイルにログる代わりにOTELが必要なんだ。それが俺の言いたいこと。Monologにこのツールのハンドラーがあるのは関係ないけど、複雑なレイヤーが一つ増えたってことだよ。
使いやすさと詳細さのバランスを取るのは難しいね。ドキュメントは初心者には優しいけど、APIの実行コンテキストやサーバ環境でのReactの複雑さについては詳細が足りてない。Edge runtimeの扱いもそう。この点についてはアップデートするよ。ドキュメントは存在するものは教えてくれるけど、使い方や落とし穴は教えてくれないって指摘、他にも例ある？revalidateTags/PathsとかuseSearchParamsとかは改善してきたんだけど。問題が無視されてるって話もあるけど、それは変わりつつある。何か見つけたらドキュメントのissueを開いて教えてくれ。ここ数ヶ月で対応してるから。
ドメインを混ぜるのはいいけど、フレームワークが無能なせいで一部のレベルでロギングできないのはダメだね。
OpenTelemetryの設定がマジで大変だったよ。Next.jsでOTELをセットアップするのに、似たような時間を費やしたと思う。実験的ってマークされてるパッケージが多いのも不安だった。pinoのインストゥルメンテーションを動かすのにも苦労したよ。pinoをserverExternalPackagesに追加しないとダメだし、自動インストゥルメンテーションはimportの順序にめちゃくちゃ敏感なんだ。あとpinoのデフォルトエクスポートだけがインストゥルメントされるんだよね。モジュールローカル変数も期待通りに動かず、globalThisを使う羽目になった。それと、この問題にもぶち当たったよ: https://github.com/vercel/next.js/issues/80445。動くには動いたけど、セットアップは最悪だったよ。
でもそれって別にOTELが重いって意味じゃないよ。確かに余計なレイヤーだけど、複雑じゃないし、一度設定すれば後は他のロギングと変わらない。ローカルでテキストファイルにログってもいいけど、Next.jsみたいにクラウド（多分サーバレス）にデプロイする前提だと、テキストファイルにログるだけって選択肢は事実上ないんだ。だからOTELがo11yのOOTBサポートされてる方法としてあるのは、DatadogやNew Relicみたいなベンダー固有のゴミに吸い込まれるよりずっとマシだよ。
ほとんどのアップグレードはかなり楽だったよ。DependabotでCIが通ってマージされるってわけじゃないけど、だいたいは自動codemodを実行すれば終わり。リリースノートと移行ガイドはいつも確認するけどね。うちのアプリケーションの基盤としては、それくらいは当然の作業だと思ってる。
「死ぬほど簡単」ってのは、ターゲットと方法によって全然違うよ。制御できないハードウェアや複数インスタンスでクラウドデプロイするなら、OTELはかなりシンプルだね。インスタンス追跡とか相関IDとか、無料でたくさん得られるから。もし複数の場所にデプロイされるサービスで「死ぬほど簡単」なテキストベースのロギングをしたいなら、ほとんどのOTELドライバーが提供するログ相関機能と同じものを得るために、たくさんの無駄なコードを書くことになるだろうね。だから、単一のVPCにデプロイされるモノリスなアプリを構築してるなら「多分このフレームワークは君には合わない」ってことになるけど、分散型やレプリケートされたものに取り組む状況なら、OTELは過去のベンダー固有の代替品と比べてもかなりシンプルだよ。
そう思うよ、だからまだ不安定で、年に2回もメジャー変更があるんだ。
