fix

src/contents/20240328-syohyo-jissenn-next/index.md

@@ -46,6 +46,7 @@ App Router のメリットを理解しつつも、学習コストに割り合わ
 SSRはいわゆるクライアントサイドしか書いたことない人間からすると、全くわからない新しい概念がたくさん登場して大変であった。
 例えば、express の管理だったり、認証への理解だったり、Node.js そのものの理解だったりが壁になっていた。
 サーバーでReactを実行するという言葉の意味も全く理解できなかった。
+何が嬉しいねん。
 そんなことを関連会社にいた知人に相談へ持ち込んだら [redux-pluto](https://github.com/recruit-tech/redux-pluto) なるもっと訳のわからないものを提案されて怖かったのも覚えている。
 今となっては redux-pluto が目指していたものを理解できるが、インターン生からプログラミングを教わっていただけの初心者からすると、いきなりこんなもの渡されてどうにかできるものではなかった。
 一方で何も理解せずにいい感じに動いてくれる Next.js は本当に素晴らしかった。
@@ -68,7 +69,7 @@ RSCが入ってきて、getServerSideProps は使わなくなり、設定より
 そのような苦労や勉強の引き換えに手に入れたのはUXだ。
 今のNext.jsはUXを追求するのためのライブラリになってしまったと思う。
 だが、自分はPages Routerでもあまり困っていなかったし、Webサイトが早ければ早いのは理解できるが、それに引き換える学習コストが高すぎると思っていた。
-それに App Router だろうが、本当に遅いときはどうしようもないのだから解決しようがないし、あまり効果がないように思っている。
+それに App Router だろうが、DBやAPIGWの裏側が本当に遅いときはどうしようもないのだから解決しようがないし、あまり効果がないように思っている。
 無理やり解決する場合も自分は CDN のレイヤーで戦えるのでそれで対応してしまえばいいと思っていたし、反対にApp Router以降のNext.jsはCDNと相性が悪いしで、むしろ嫌いだった。
 だから自分は App Router 以後のNext.jsはなるべく使いたくなかった。