Next.jsがReactの上に敷いてくれているレールを深掘る
from
@dll7: なんか、モダン開発って言うと、マイクロサービスで作ってBFFが必要そうな見せ方をしているけど、世の中のサービスの95%はモノリスのAPIとSPAで十分なはずだよ。 工数増えるだけだし初心者しか居ないチームこそ複雑なアーキテクチャは避けるべき
@takamura1227: わかりみだなぁ。Vite React（ts）で、routerとかつかわずに、マルチページにしておくくらいで、充分なことが多そう。reactも、なるべくJSXだけで薄暗いしておくのが吉。 @about_hiroppy: app routerでパフォーマンス改善のために色々複雑なことができるようになったけど、そのサービスそこまで複雑にしてチューニングする必要ある？みたいな線引きを作っておかないとただ負債になりそうな予感するんだよな @yoshikikoji: 僕はこれからのWebサイトは二極化がどんどん進んでいくと思っていて、簡単なサイトはノーコード、大規模なサイトはNext.jsのようなフレームワークで作られていくんだろうなと思っています。そうするとNext.jsは高度な要求に答えていかなければならなくなるので、なんとなくtoo muchに感じるかもしれないです。しかしそれは大規模サイト向けに必要とされる機能かもしれないので、見ないふりをしていると大規模サイトの開発に関わることができなくなってしまうかもしれません。 @yoshikikoji: 少なくとも僕らが受ける案件がどんどん規模が大きくなっていっている中で、やっぱNext.jsにしておいてよかったみたいな意見は頻繁に出ます。むしろ困っていることに対してきちんと課題解決するような機能が発表されているように感じています。 @yoshikikoji: Jamstack = 静的サイトの時代はもう終わっていて、多種多様なレンダリング手段や、クライアント・エッジ・サーバーの任意の場所で最適に動かしていく…みたいなのがこれからのJamstackなのかなと思います。 @takepepe: Core Web Vitals で INP が重要になってきたら Selective Hydration が自明に有利なので、それだけでも App Router に移行していかないとあかんのよね。難しいとか抜きに。 @f_subal: 「Next.js がレールを敷いてくれない機能の一覧」という文章を書いている Next.jsがReactの上に敷いてくれているレール
@yuta0801: Viteで真面目にSSRをやってみれば、いかにNext.jsに甘やかされていたのかがよくわかるし、軽い気持ちでViteを使おうとか思わなくなるよ フロントエンド最適化はほぼ全てSSRの上に成り立ってるからSSRを乗り越えないと実質何もできないこともわかるし、SSRをするだけでもカスタムサーバーとルーターとサーバーバンドルが必要でフレームワークを再発明するところまでを実際にやってみると、なぜNext.jsが推奨されるかが心の底から理解できる @yuta0801: Viteは簡単に使えて、configとplugin機構がよくできているから割と自由かつprogressiveに拡張できそうでいいじゃんって思ってもSSRをしとうとした途端、何もかも足りなくなるので、アプリケーション開発に使うツールとして完全にレイヤーが異なるもの 関連
@mizchi: 古のSSR自作勢としてはSSRフルスクラッチはフレームワーク自作と同じぐらいの罪の重さがある 作りたいものに対して理解しなければならないメンタルモデルは比較的大きい 収束
アプリケーションアーキテクチャではなく、あくまでもユーザーがリクエストを送ってサーバーからレスポンスが返却される領域に関して期待している形。
その部分をそれぞれの現場で半端に最適化するのはナンセンスなので、突き詰めるつもりがなければ素直に Next.js が良い。
けれどもApp Routerでなんでも出来るというのは大きな意味があるし、最適化についての悩みも減る 構成例