1. kkeethのエンジニア雑談チャンネル
  2. No.386 「Next.js の領分の話..

はい!第386回は Next.js について最近感じていることを感想レベルでお話しました💁


ではでは(=゚ω゚)ノ


ーーーーー

🔗 LINKS

実践Next.js—— App Routerで進化するWebアプリ開発

https://gihyo.jp/book/2024/978-4-297-14061-8


♫ BGM

騒音のない世界「チャレンジャー」

https://soundcloud.com/baron1_3/challenger

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

サマリー

今日は、Next.jsの領域と初心者の視点について話しています。Next.jsの進化やReactとの関連性を考えると、Next.jsの領域はどうなるのか気になります。フロントエンドフレームワークであるNext.jsについて、フレームワークの使用目的や選択肢について述べられています。

Next.js書籍の出版
はい、みなさんこんにちは。kkeethことくわはらです。本日もやっていきましょう。
kkeethのエンジニア雑談チャンネル。この番組では、ウェブ業界やエンジニアリング、いろんな技術についての情報を、雑談形式で発信していきたいと思います。
で、今日はタイトルにありますNext.jsの領分のお話と、ちょっとデカめなタイトルにしてるんですけど、
副題として素人の表層レベルの感想という、自分の個人的な発言も一応しておきますけど、
あんまり僕Next.jsを詳しく触ってないのと、僕はまだレジスルーターしか触った経験がないので、
あんまりアップルーターの話ができないっていうのが一番の理由ではあるんですけど、
最近のリアクトの進化とか、Next.jsの進化とか、歩み方みたいなのを見ると、
Next.jsの領分ってどうなんだろう?みたいな思うところがあって、それを表層レベルでダラダラ喋ろうかなっていう感じです。
昨日か一昨日かな、竹ペペさんって方がまた新しく書籍出ますよってことをツイートされていて、
ツイートじゃないですね、Xでポストされていて、
実践Next.js、アップルーターで進化するウェブアプリ開発という本が3月16日に刊行になりますと。
おめでとうございます。
前回の、確かテストの話を書籍書かれていて、それもすごく参考になりましたね。
MSWを使ってMockを使いつつ、リアクトベースでどうやってテストを書いていくかみたいな、
フロントエンド周りのテストのノウハウとか、あれこれを書いていただいてて、
すごく参考になるし勉強になるなっていうので、さすがの一言だったんですけど、
ついにNext.jsの書籍が出された。
これもちょっと期待してますので、僕も買って読みたいなと思ってますが、
フロントエンドの書籍のお話はちょっといきなり雑談から入るんですけど、
あんまりですね、これ買ってどうなんだろうっていう気はしてますが、
絶対にそうもないと思います。
少なくとも今現時点でNext.jsのアップルーターに関する、
ちゃんと名前が売れた方でしっかり書かれた書籍ってまだないはずなので、
これはかなり良いとは思っていますが、
書籍ってやはり執筆して、しっかり書籍として一般に本屋で買えるところまで、
割とラグがあるので、はっきりとすぐに使えなくなる可能性もゼロじゃないなっていうところがあります。
なのでそこに関しての期待値をするんではなくて、
Next.jsに関してのしっかりとした理解とか、
設計開発の仕方でどうなんだろうみたいなことを僕は期待してこの本を買おうかなと思っています。
そういう思想とか設計論っていうところは、
おそらく他でも流用できるし、
そんなにNext.jsの根本的に変わるものではないはずです。
そんなことをしたら多分ユーザーグループたちが、
メタ社とかにうわーって意見をしそうな気がします。
バーセル社とマリアクトのコアコミッターの方々とかの
最近の機能の追加の仕方だったり、
フレームワークライブラリの進化の仕方は、
ちゃんとユーザーコミュニティに意見を聞いて、
シャドウをリリースしたりとか、
先にデブ環境的なものを出しておいて、
それを触ってもらってどうなのっていう意見をもらってたら、
やっぱり導入するかっていうのを決めているので、
そういう感じでちゃんとコミュニティと歩みながら進めるので、
ドラスティックに変わることはそんなないと思います。
という意味で、よりレイヤーの低い思想レベルのところで
リアクトサーバーコンポーネント
この書籍を参考にするのは良いですけど、
アップルーターの理解とか、
今のNext.jsの機能について知りたいのであれば、
公式ドキュメント一択がいいと思います。
そういうスタンスで読むのがいいのかなと思いますね。
特にフロントエンド周りなんて、
変化しまくる領域ではあるし、
今後も変わらないと思います。
ただリアクトネクストがずっとまだまだ、
頭一つも二つも抜けていく世界観はあんま変わらない気がしてまして、
その意味で、書籍としての価値は十分高いかなとは思いますね。
僕はその辺を期待しています。
付録にプリズマとかも書いてありますけど、
プリズマも変わる可能性がありますしね。
今でこそって書いてありますけど。
書籍とかのスタンスは置いておいて、
で、Next.jsの話に戻るんですけど、
こんな感じで書籍が出るぐらい、
出版社もアップルーターに関する書籍は出して良いだろうと、
判断をしたってことですよね。
本題に戻ります。Next.jsの両文の話ですけど、
確かバージョン17でしたっけ?
リアクトサスペンスが入ったのって。
で、そこから今の18でサーバーコンポーネンツがちゃんと
オンレディとなって使えるようになったし、
今も使っているプロジェクトがあると思います。
サーバーコンポーネンツという機能は、
もうすでにバーセル社とちゃんと連携しながら
こういうのを出しますよっていうのを伝えつつやってたっぽくてですね。
それは公式ドキュメントにもその辺の片鱗が見えたし、
そういう記述があったので、
間違ってなければそういう記述があったと
記憶をしてるんですけど。
ので、Next.jsもアップルーターっていうものを作って
リアクトサーバーコンポーネンツに対応したものが
そんなにタイムラグなく、
割と早めにリリースされたなっていう印象も
皆さんもあると思いますけど、
最初から歩み寄ってたっていうのがあります。
まさにそのアップルーターが登場した背景っていうのも
新機能リアクトサーバーコンポーネンツっていうところからだと思いますね。
逆に言うと、これが使える、リアクトサーバーコンポーネンツを使って
上手いことやれるフレームワークっていうのが
今はNext.jsしかないんじゃないか。
昔のPagesRooterとの差分がある意味そこだっていう話で、
PagesRooter、名前の通り画面ですね。
画面ごとにルーティングをする、分岐をするっていうところで、
その代わり、画面にフォーカスを置くと
やっぱりコンポーネントは増えていくよね
っていう傾向は全然あると思います。
そうするとコンポーネント増えるってことは
1ページとかに関する情報量、
ドムどっかが増えてくるので
ページ自体が重くなりますし
僕ら開発者側の方としても
各それぞれのページの管理っていうのが大変になってきますね。
コンポーネント増えますから。
そもそもユーザーのハードウェアレベルで
スマートフォンのスペックも上がったり
ブラウザーで読み込めるスピードとか
処理できる端末のスペックも上がってるので
あんま気にしなくても良くなってきたとはいえ
なんだかんだ側の方に
ダウンロードさせて
JavaScriptの量が増えるっていうのは
やっぱりよろしくないので
コンポーネントを減らせるなら
それに越したことはないよねと。
従来のやつだと
結局いろんなコンポーネントとかも
全てブラウザー側で計算処理をさせてやるってことですけど
計算した結果っていうのを返して
側の方は来たものに装飾をするだけっていうのが
本来は良い。
それがウェブフロントエンドのミッションではありますので
それができるようになったっていうのが
リアクトサーバーコンポーネントですね。
もちろんクライアント側で処理するものもありますけど
これは明らかにバックエンドでやった方が良いなとか
この処理重いからバックエンド側に倒したいなっていうのを
ページ単位ではなくてコンポーネント単位でできるようになったというのが
リアクトサーバーコンポーネントですね。
ページ単位っていうのは
Next.jsの方で確かやってた気がします。
彼らも元々は
プリレンダリングっていう
手法を入れたフレームワークですよっていうのを
自分たちに名乗り始めた背景があります。
今はだから
UseClientDirectiveみたいなのを使って
サーバーとクライアントどっちのコンポーネントなんですか
っていうのを切り替えをするので
コンポーネント単位で細かく
これがバックエンドこれがフロント側みたいなところで
処理を分けれるっていうのはすごくありがたいんですけど
バックエンドに回すってことは
フロントエンドの
エンジニアとしても
もうそろそろバックエンド側の方の意識をしなきゃいけないとか
Next.jsが
今後どこまで進むか分からないですけど
BFF側の話まで
手を出し始めたり
もうBFF作るとしたら
Next.jsのアップルーター側で
コンポーネントとかページを書いていくっていう
事例も増えていっているように
僕の印象ではありますね
という意味で
領域領分がちょっとずつバックエンド側に寄ってきていて
それだったら
フルスタックフレームワークみたいなやつがあるので
それを使ったらどうなんだろうっていうのが
僕も何度も言ってますけど
そんな気がしてます
ブリッツって言われるものだったり
レッドウッド.jsみたいなもの
その2つしか僕はまだ知らないんですけど
があります
昔ながらのフルスタックのフレームワークではなくて
Next.jsのフレームワークの位置づけと役割
いろんな領域ごとに
ライブラリをガーッと1つに集約して
アプリケーションを作れる
フレームワークっていう風に思ったらいいです
昔ながらの1つの言語
1つのドーンとしたデカいフレームワークの中で
側もやるし
バックエンドもやるしルーティングもやるし
いわゆるSVなんちゃらモデルでやっていた
っていう時代ではなく
それぞれに関してはそれぞれの本来使っていたものを
ガチャンと1つにまとめた
クライアント側はリアクトで書きますし
バックエンド側はO2だったり
プリズマ使って隙間定義したり
ネスト.jsを使って
バックエンドのところも1つの
型定義ファイルで管理したり
全部まとめて1フレームワークで使う
みたいなのが今のフルスタックフレームワークに
僕は見えてます
昔とは違うんですけど
より一元管理できてるからやりやすいんじゃないか
って気はしてて
ネクストはあくまでやっぱりクライアント側のほうですね
ビューのほうをどう
管理まとめていくか
っていうところに重きを置いている
ただ開発者として柔軟に
パフォーマンスも良く
ユーザー帯型を高くするために
どこまで手を広げるかっていうので
少しずつバックエンド側にもやはり手を出す
手を出すというか結果必要だったから
そっちの機能を追加したという風に
されてもいいかもしれない
なんですかね
どこまで彼らは量分を広げていくかっていうのが
今後僕はちょっと悩ましくて
本来欲しかったのは
バックエンド側の処理はバックエンドのAPIに全部任せして
僕らはとにかく来たデータ
JSONに関して効率的に管理し
ちゃんと状態管理ですね
を便利にしたいというところで
フレームワークを入れていると思っています僕は
結局は
データとアルゴリズムの2つですね
これをどう楽というか
簡単にできるか
というところに僕らエンジニアの
主観というかアプリケーション開発の
エンジニアとしての
主題があると思っていてこれは今後ずっと
変わらないと思うその意味で
クライアント側の方に対して
フレームワークを入れたいのに
Next.jsはバックエンド側の方まで機能としてはある
ただ使わなくていいんだったら
それを別に
入れて使わないという選択肢もあるんですけど
結果でもNext.jsをインストールするという
話は変わらないので
最初から搭載されていないものの方が
軽いし早い可能性が
大いにあるという意味で
他のフレームワークを使うという選択肢は
Next.jsの選択肢と評価
全然あるなと思っています
今の選択肢としていくとやっぱり
Remixになっちゃうんだろうなという感触ですね
Remixの方がいいと思っているのは
僕が観測している世界観が
今日本でしかないし
僕のコミュニティの界隈で
Remixのワードがよく出るなという感じです
他にもたくさんありますけど
僕がやるとしたらやっぱり
Quickなんですよ
Nextを使うと
そこまでいかなきゃいけないとなるので
それならば従来通りの
リアクト単体で使うのもどうなの?
という話はありますよね
ビートがすごく便利になってきたし
バンドラーとしてWebpackが大変だったところ
ビートというものが台頭してきて
スピードもそうですし
設定周りもだいぶ楽になったというので
今はかなりビート推しなんだろうな
という感触があります
その上でリアクトサーバーコンポーネンツは
リアクトにまだ乗っかっているので
そういう話はありますが
リアクトレベルであれば
僕は目つむってもよいかなという感じは
しみますね
何もしなかった今まで通りのコンポーネンツの
使い方にはなります
Nextはそれをラップしているものなので
使わないのに冗長なコードを
たくさんインストールさせるという体験は
よろしくない感触があります
僕はスピード中なので
あとはNextというよりばバーセル社という
バーセルのタイドというところに
一末の不安を感じているエンジニアさんも
いらっしゃるしこれはもう説明するまでも
ない気がします
バーセルのタイドというところに不安があるから
Nextどうなのという話とか
反応もあってそれも一つですね
バーセルに課金するか
というのもありますけど
それはイコールもNextと
侵入しますというスタンスなので
僕はあんまりいい感触ではないなと思います
エンジニアとしてはちゃんと
技術選定をプロとしてやりたいし
変えることができる選択肢を
残しておいてほしいけど
Nextを使った時点で
ほぼここから抜け出すのは大変で
またプラットフォームレベルから置き換えるの?
という議論をするので
インパクトがでかいですよね会社としても
というので
今後もNextは
まだ一興の時代は変わらないとは思いますけど
進化しているけど
裾野を広げすぎている
感触があってもうもはや
フロントエンドのフレームワークじゃないという風に
僕はやっぱり捉えているので
やるプロジェクトの
複雑さとか規模感とか
そのタフなプロジェクトに
耐えれるかっていう意味で
選択をする可能性は全然まだ選択肢は
それはありますが
Nextという機能がたくさん
あるからとかNextのクオリティが
高いからっていうので意思決定を
するのは僕はもう違うなっていう
感触なので改め
ちょっと批判的な判断で
Nextを見るのは一つありかなという
とはいえ竹ペペさんの書籍
見つつもう一回
ちょっと評価をしようかなと僕は理解が全然浅くて
明らかに竹ペペさんの方が
深い理解をして
この書籍にまとめられてくださっている
はずなのでそれ見ながら反抗程度に
見つつ評価をしていこうかな
はい今後のフロントエンドの進化
っていうのはどうなんだろうっていうのは今もずっと
妄想してますし結構
生成経済を今ジェミニと
ビングとチャットGPTと
毎日こう議論しながら
どうなんだろうっていうのを
自分の中で妄想してますけど
当分リアクトネクストは変わらないし
もうそろそろリアクトで集約
してもいいかなって気がしている
ところだったんでそうなると
強すぎるのもちょっと僕としては
難色があるのでせめて
2強になってほしいんですけど今のところ
2強になるものがないなっていう
感触ですちょっとネクスト
リュージェイスが
僕の中で落ち気味に
見えてはいますのでね
この辺はもうすぐ出るでしょう
ステートオブジェイス
2024去年のサーベイが
もうそろそろ出てくれると思うので
あれを期待してます結局世界の
エンジニアはどう評価をしているかっていうのが
数字として出るのでそれを見つつ
また判断したいと思います
それを見ながらまた配信していけたらなと思ってます
出るのを楽しみにしましょう
はい今回はこんなところで終わって
いきたいと思いますいつも聞いてくださり
本当にありがとうございます
ではまた次回の主力でお会いしましょう
バイバイ
14:39

コメント

スクロール