00:03
はい、11月21日月曜日ですね。 時刻は朝9時を回りました。
今日も寒いので、皆さん体調気をつけてくださいね。 はい、おはようございます。
miminokeethこと熊原です。では本日も朝活を始めていきたいなと思います。 本日はですね、昨日の続きです。タイトルありますとおり、
Astro vs. Next.js vs. Remixで、 Which One Should You Use for Your Next Project? っていう記事の続きを読んでいこうと思います。
昨日はですね、この記事のイントロダクション、 ウェブアプリケーションとは何ぞやという話をして、
その後、今回のタイトルにあります、 Next.js, Remix, Astro っていうそれぞれのJavaScriptのフレームワークですけども、
これは何ですかっていう紹介をして、 それぞれの比較をしていった感じですね。
その比較の項目ですけど、大きく分けて6個の項目に分けて、 それぞれの比較をしています。
6個っていうのは、1つパフォーマンス、 続いてハイドレーション、続いてユースケース、
続いてサーバーサイトレンダリング、 続いてEase of Use、使い勝手、
最後、コードスプリッティング、 この6個について分けて比較していこうと。
最後にインテグレーションとかエクセレンシビリティですね、 拡張性だったりとかですね。
とかやって、結論的なキー、テイカーウェイズってところを読んで、 終了になるかなと思っています。
はい、で、昨日はハイドレーションまでを 確か読んでたような気がします。
僕の記憶が間違ってないけれど。 今日はその続きでユースケースからいこうと思います。
昨日まで読んだ感じだと、なんとなくリミックスが僕は ちょっとマイナスポイントに見えてきてしまったなって感じですね。
何ができるかできないかの比較なんですけど、 基本的にリミックスっていうのが、
サーバーサイトレンダリングはサポートしますけど、 逆にそれ以外は何もしないような書き方を本記事でされていて、
実体はよく触ってないからわからないんですけど、 いきましょう。ユースケースに基づく比較です。
大きく4つに分けられていて、1つ目はシングルページの アプリケーションを構築するっていう観点ですね。
ネクストとアストロっていうのは、 シングルページのアプリケーションを構築するには適しています。
リミックスは動的なデータを使うサイトの構築に 適しています。
これは先ほど言った通りですね。 リミックスはSSRの方に重きを置いているので、
動的にデータをどんどん変えているような サイトには優れていると。
ネクストとアストロはシングルページだったり、 ちょっとオーバースペックですけど、
静的サイトを作るときにもいいんじゃないかな と思ったりしました。
2つ目がセッションとクッキーですね。 確かに生き残り読んだわ。読んだけどこのまま言っちゃいます。
セッションとクッキーっていうのは、 その情報を保存するために使われますと。
クッキーはユーザー側またクライアント側の マシンで使用されて、
セッションはサーバーとクライアント側の 両方で補充されるということですね。
セッション懐かしいな。
昔PHPでものおりしっくりアプリケーションを 作っていた時代が僕はあるので、
セッションと聞くといろんなものを思い返して、 なな懐かしさがありますね。
続いて、アストロとネクストJってのは セッションとクッキーをサポートしてないよってことですね。
03:01
よくも悪くもクライアント側の方を担当する フレームワークなんだなって感じです。
しかしLinuxはそのセッションとクッキーの 両方サポートしているので、
それを組み合わせるといろんなような ライブラリーがありますよってことでした。
続いてリアルタイムの マルチユーザーサイトってところですね。
ネクストとアストロっていうのは ポートフォリオサイトとかブログのような
いわゆる静的サイトに向いてて、
Linuxの方は動的データにフォーカスアプリケーションを 構築するのが適していますと。
サーバーサイト連絡にのみサポートしてるんで、
ビルド時に静的ファイルに担当することは もちろんないよってとこですね。
なのでサーバーサイトレンダリングしか やらないっていうことを考えると、
Linuxは多分デプロイ環境とかCACD周りのところまで ちゃんと考慮しなきゃいけないような気がします。
最終的に静的サイトだったりとか、 クライアントだけに行くんだったら
S3にあげてしまったりすれば別に いいんじゃないのっていうところはあったりしますけど、
サーバーサイトレンダリングするんだったら サーバーサイト必要なのでそもそも。
多分裏側の方、バックエンドの方はエクスプレスなんだろう っていう暗黙的な予想がありますけど、
なのでエクスプレスを動かすための箱が必要なので、 ウェブサーバーが必要なので、
そのためのデプロイ環境を用意しなきゃ いけないんだろうなっていうところですね。
まあまあ、よくやるDockerコンテナ化して 全部一発管理するんだろうなっていう感じがします。
はい、続いて4つ目ですね。 4つ目はCSSのサポートです。
ここが結構また大きいポイントでしたね。
AstralとNext.jsはCSSフレームワークと ライブラリーのOut-of-boxのようなサポートをしていますと。
Linuxのスタイリングは少し異なっていて、 ほとんどのスタイリングフレームワーク、
いわゆるURLフレームワークはサポートしていない っていうところが痛いなというふうに読んでて思いました。
またLinuxはCSS組み込みのスタイルシートを リンクするためにはリンクタグを使いますっていうデフォルトのこと。
これでもAstralとNext.jsも普通にビルドしたら 結局リンクタグになるんじゃなかったっけ?
そのままCSSスタイルタグとして 吐き出されるんでしたっけ?
ちょっと覚えてないですけど。
そんな大差ない気はしますけどね。
はい、というところで、ここまで昨日は読んで、
Linux、すげー微妙っていう感じで また結論を言った気がします。
はい、じゃあ今日はその続き、 サーバーサイドレンダリングから入りますが、
サーバーサイドレンダリングめちゃくちゃ短いですね。 一瞬で終わりますね。
SSRとはクライアントサイドの単一ページ、 シングルページアプリケーションっていうのを
サーバー上でプリレンダリングして、 ユーザーのリクエストに応じて
完全にレンダリングされたページを 送信するプロセスっていうのを指します。
サーバーサイドレンダリングっていうのは 非常に重要であり、
サーバーサイドレンダリングされた アプリケーションっていうのは
SEOに優れて高速であるため不可欠でありますと。
高速ですけど、どこに高速化をするかっていうところで 考えると別にSSRが速いというのは
一概には言えないなっていうか、 別に速くないって意味ではないんですけど、
速いは速いんだが、別にSSRじゃなくても いいじゃんっていうところはあったりするので、
どこに高速化を求めるかっていうのは 重要だと思います。
ただもちろんそのSEOの観点はもちろん 皆さんご存じの通りなので、
それは結局やったほうがいいって思う人は 全然いると思いますけどね。
06:00
なのでECみたいなものを作るんであれば 全然考慮したほうがいいとは思いますけどね。
余談でした。
サーバーサイドレンダリングをする アプリケーションっていうのは
通常ページのロード時間が短縮されることが理由です。
まあそりゃそうだよね。
計算処理を全部バックエンド側にぶん投げて、
フロントエンドが来たものをただ出していく っていうところに過ぎないので、
そりゃ早いよねって感じです。
これしか書いてないので、 なんか比較してないなっていう気がしました。
そもそも。
まあ比較にならないんだろうね、たぶん。
ASTROとNEXTJ、NEXTも一応プリレンダリングできるし、
サーバーサイドレンダリングもできるでしょうけど、
ASTROもたぶんできるんじゃないかな。
ただ、REMIXはSSRに特化しているというか、 それにぶん投げているので、
そっちにちょっとだけ長があるんだろうなとは 思いつつですけど、
書かれてないし、言及されてないので、
あんま比較ができなかったんだろうな という予測をします。
で、続いてユースケースですね。
ユースケースじゃないわ。
East of Youthなので使い合ったの比較ですね。
NEXTJS、ASTRO、REMIXっていうのは いずれも学習曲線が低いです。
学習曲線が低いというワードは 僕はもう信用しなくなりました。
これの言っている本質は入門はしやすいけど、
実際アプリケーションを作っていくときは もう皆さんで頑張ってねっていう話なので、
GET STARTEDまでの曲線は確かに低いんだと思います。
ただ、学習曲線はどのフリーマーク見ても、
僕は大体指数関数的にどっかでいきなり フワッと跳ね上がると思っています。
これは僕はあんま信用しないです。
余談でした。
で、これらはすべてREACTベースに構築されており、
REACTの知識があればNEXTJS、ASTRO、REMIXっていうのを セットアップするのに十分ですと。
また、開発者向けのドキュメントが用意されていて、 使いやすくてセットアップも簡単です。
最近というか、数年前からそうですけど、
開発者向けのドキュメントの整備というか、 拡充、充実の度合いっていうのが
かなり上がってきたなってすごく思いました。
いつからだったかはちょっと分からないですけど、
GET STARTEDもそうですし、いろんなユースケースもそうですし、
リファレンスもそうですけど、
かなりですね、ドキュメントにすごく重きを 置かれているっていうような印象がありました。
逆にそれがあるからフリーマークとかライブラリーが しっかり使ってもらえるというか、
人気の一つの要因なんだろうなというのを つくづく感じていますね。
続いていきます。
NEXTにはNEXT.jsのアプリケーションを ブートストラップするための
CREATE NEXT APPみたいなCLIコマンドが付属しています。
ASTROにはアプリケーションを起動するための CREATE ASTRO AT LATEST。
AT LATESTは多分なくてもいい気がしますけど、
CREATE ASTROみたいなコマンドを叩くとやってくれると。
REMIXにはREMIXアプリケーションを起動するための CREATE REMIXというコマンドが付属しています。
ここも確かにそうですよね。
強力なCLIコマンドっていうのがないと、
意外とフリーマーク使われない可能性って あるんじゃないかなと思いますし、
僕もやっぱりすぐ探しちゃいますね。
このアプリケーション、じゃあ実際に ゲットサーチで使いたいんだけどときに、
どうやってやるんだろうってみて、
やっぱりコマンドあるんだったらそれ叩くよね っていうのはやっぱりあるので、
これはそうだなと思います。
でもNEXTに強いのは、が強いのは、
09:01
やっぱCREATE NEXT APPの中のサンプルテンプレートが
かなりバリエーションが豊富っていうのがすごいですよね。
ノーマルのJavaScriptだけのものもあれば、
SASとかOldJSS、もしくはTypeScriptとか、
OldJSSみたいのを導入したいという場合は、 それ用のテンプレートもありますし、
GraphQL対応しているものもあれば、
そういうクラウドもあるんですかね、
AWSか何かだっけ、にも対応したいものもあったりとか、
かなり幅広いパターンですね。
こんなライブラリ組み合わせるでしょみたいな、
よくある組み合わせの組み込んだテンプレートが
CREATE NEXT APPのほうでは用意されているっていうのが、
やはり強いなとか強力だなと思いました。
以上、使い勝手のところでしたけど、
まあなんていうか、
最初の入門のところの使い勝手っていう観点でしたね、これは。
そこはまあ、
比較してもどれもあんま変わらないよねっていうところっていうのは見えましたね。
実際に本当作っていった先の方の話ですよね。
エコシステムどうなのとか、
サードパーティーとの組み合わせはどうなのとか、
キャッシュイング周りどうなのとか、
パフォーマンス、まあパフォーマンスはさっき出ましたね。
だったりとか、まあいろんなところですよね。
設計のしやすさだったりというところが、
やはり肝になると思うんで、
まあそこがちょっと僕は語られてなかったのが、
ちょっと残念だなっていう感じがしますね。
はい、まあいいや。で、次行きましょう。
続いての観点はコードスプリッティングですね。
分割の話です。
コード分割っていうのは、コードを多くのバンドルに分割して、
並列またはオンデマンドでロードできるようにすることです。
これによって残りのコンポーネントが遅延ロードされる間に、
できるだけ少ないJavaScriptを出荷することができます。
ここで取り上げたフレームワークっていうのは、
全てコード分割を有効にした状態で提供されます。
ルーティングのサポートもすぐに利用できますと。
はい、以上だそうで、ここも結局比較になってない気がしますね。
どのフレームワークも同じようなものを提供しているってことなんでしょうね。
考えると、JSのフレームワークって、
皆さんに至り寄ったような機能を備えるっていうところに尽きるんだろうなと思いますし、
皆さん同じものをやっぱり要求するんだろうなっていうのは思いました。
でなると、本当比較対象、むずいですね。
でもやっぱり今まで読んだ感じリミックスさん大丈夫かっていう不安はあります。
というところですね、結局Nextが勝つんだろうなっていうのはなんとなく皆さん思ってるだろうし、
僕の周りの人たちも意外と言っているので、そうなんだろうなと思いますね。
リアクトの画像を崩すほどではないなっていう。
ただ書きやすさとか、リアクトじゃ解決できないとか、
リアクトのアプローチじゃない、新しいアプローチを作っていかない限りは、
なかなか差別化を図るのは難しいだろうなっていう。
リアクトNextの土俵で戦うのは大変だろうなっていう気はしました。
戦うっていう観点はよく分からないですけど、
でもなんだかんだダウンロード数ランキングとかあったりしますし、
こうやって比較記事が出るぐらいですからね。
続いて6個目ですね、最後の観点です。
インテグレーションズ&エクセンシビリティですね。
今回取り上げたフレームワークっていうのは、
基本的にはすべてリアクトベースに構築されています。
つまり統合だったり、プラグインをサポートし、
機能拡張することももちろんできますよと。
12:00
リミックスとAstroっていうものは、
フロントエンドのエコシステムの新山ものであるため、
同じ機能と統合提供しないかもしれません、現時点ではですね。
しかし普及が進んでいけば、
これらの機能も利用できるようになると思いますと。
対応が進んでいけば、
現在のリアクトのエコシステム周りっていうところも、
どんどん導入したり利用できるようになっていくっていうことですね。
それが進めば、もっともっと開発が柔軟になって、
人気も博すかもしれないです。
で、Next.jsは、nextconfig.jsっていうファイルによって、
様々なカスタマイズや拡張可能になりますと。
で、Next.jsのプラグインっていうのは、
このファイルを使って追加することもできますよということですね。
というところで、結局この辺は、
今はNextがやっぱ強いよねっていう話には見えましたね、これは。
ただ、これは時間の問題で、
結局追いついてくると思うので、
そこがどうなるんだろうなっていう感じはしますけどね。
あとは、バンドラーとかですかね。
バンドラー対応、ちゃんとビート対応するとか、あとなんだっけ。
何タラパック、なんだっけ、忘れました。
また新しいやつが出たらしいですね。
ビートよりもさらに速いと言われているバンドラーが出たっていうのを見て、
俺まだ読んでないんですけど、
あの辺、読んでないから触ってないんですけど、もう気になりますね。
どういうところに重きを置いて開発したから、
結果速くなったんだろうっていうのは気になってるところですけど。
開発体験として、ビルド時間とかバンドル時間が速いっていうのが、
多分開発者としての体験はかなり大きいんですよね。
僕らからすると時間が奪われないので。
そっちが強いと人気を博すので、
Next.jsさんは結局確かまだウェブパックだった気がするので、
13僕まだ読んでないので、
次回以降、Next.jsは13の更新記事で読んでいこうかなと思ったりしますけど。
で、ビートとかが対応してるんだったらそこは大丈夫ですけど、
できてないんだったらそこで負ける可能性はあるのかなと思ったりっていうところですね。
はい、では今のでインテグレーションとエクステンシビリティでした。
続いて、最後にキーのテイカーウェイズってところですね。
はい。
重要なポイントっていうふうに訳されましたけど。
いきましょう。
アストロとLinuxっていうのは比較的新しいフレームワークですけど、
素晴らしい機能を備えているのは間違いないと。
将来的には開発者のデフォルトフレームワークになるっていうのも 違いないよっていうふうに仰ってます。
すげえな、デフォルトフレームワークになるってこの方は仰ってますね。
で、しかしNext.jsっていうのはルーティング、SSR、SEOなどのリアクト.jsの制限を全く受けずに、
リアクトを活用する非常に堅牢なフレームワークではありますと。
で、アストロは部分的なハイドレーションだったり、
ビルド人にJavaScriptをほとんど使用しないといった新しい概念を導入します。
ここが早い理由ですよね。
で、加えてアストロはほとんどのJavaScriptのUIライブラリでも動作するため、
どのフレームワークが最も快適かっていうのを選択することもできますと。
あ、ありがとうございます。
ターボパックだわ、ターボパックが早いっていう噂が出てて、お、お、おってなってますね。
で、最後リミックスですね。
リミックスっていうのはクライアントサイドとサーバーサイドの両方のコードを扱うフレームワークであるというような新しいコンセプトも導入していますと。
15:00
で、Next.jsは部分的ハイドレーションやフルスタックフレームワークであるといった概念をサポートしてはいませんが、
プリレンダリングはサポートしますけどね。
SEOだったり、労働時間の短縮だったり、ルーティングに焦点を当てたウェブアプリケーションにはやっぱり優れているっていうところですね。
まあ確かにNext.jsはルーティング周りの方に重きを置いたフレームワークって言われればそうかもしれないですね。
で、リミックスはとにかくバックエンドの方とやり取りをするっていうところに重きを置いている。
まあコンセプト的には今までとちょっと違ったフレームワークっていう感じではしますね。
この辺が重要な観点なので、そのどこを例を取るかっていうところで皆さんが技術選定していただければというところですね。
まあなんか、あそこでもいい感じのおいしいとこ取りをしているような感じにも見えなくはないので、そのエコシステムが充実すると確かにAstroはNext.jsのユーザーのパイを食うかもしれないなっていう感じは少ししました。
はい、というところです。
最後、結論ですね。コンクルージョンです。
じゃあ最後、まとめです。
今回はJavaScriptのコードを出荷しないための高パフォーマンスライブラリであるAstro、クライアントサイドとサーバーサイドの両方のコードを扱うフレームワークであるリミックス、ISR、CSR、SSG、SSRなどなど、いわゆる様々なデータ取得のメソッドを搭載したNext.jsというものを取り上げてきました。
この人はこういう捉え方をするんですね。
Next.jsの捉え方は確かにちょっと難しいし、多機能すぎてどういう風に一言で言うかは難しいんですけど、こういう捉え方をするんですね。
パフォーマンスだったり、そのコードのスプリッティング、ハイドレーション、ユースケース、使いやすさ、統合などの指標を挙げて、今回ちょっと比較してみました。
これを見れば自分のプロジェクトにどのフレームワークを使うか選択することができますということで閉められておりました。
はい、まあなんていうか、批判をするわけではないですけど、個人的には物足りなさで終わってしまった気じゃなというふうにちょっと思いました。
まあじゃあ自分で読んで、自分でコードを書いて、ブログを書くっていう感じはもちろんしますし、それはやりたいのは山々ではあるんですけど。
まあまあでも、じゃあかといって情報がなかったってそういうわけではないし、いろんな観点があってありがたいなと思いましたね。
ただやっぱ比較記事っていうのはやっぱり人の観点によって全然まちまちですので、これ2,3記事ぐらいだとまだ比較はできないなっていう感じはすごくしました。
ただ、ある程度そのいろんな人たちの観点とか視点を持ってフレームワークのキャッチアップに入るっていうのは、今まで何も知らないまま触るのと全然観点が違ってありがたいと思いますね、こういうのって。
ちょっと穿った目線でフレームワークを見るっていうのもある意味別に間違ってはないし、その目線で触っていくっていうのはすごくいいかもしれないですね。
まああら探しをしてしまいがちかもしれないですけど、結果細かいところまで見えてくるっていうのではありがたいと思うので、まあそう感じはしますね。
ただ、そういう観点もあるけど、あくまで技術と触れ合うときはあくまでフラットな目線というか、クリアーな目線でフレームワークと触れ合うのが本当はいいんだろうなと思ったりしますので、そういう観点だけインストールして触っていくのはいいんだろうなと思いました。
ではですね、ちょっと急な発活、スタートモスクで終わりも短くて大変に申し訳ないけど、今日はこちらで終了したいなと思っています。
18:02
はい、月曜日の朝9時から朝早い時からご参加いただき、大変にありがとうございました。
まあ明日は先ほど言った通りですけど、Next.jsの13のリリースを僕ずっと放置したのでいい加減読まなきゃなと思っているので、その辺読んでいこうと思っています。
はい、じゃあ今日もですねご参加いただいた3名の方ですね、いかのこさんとけんじさんとごぞうごふさん、大変にありがとうございました。
また明日もゆるーく読んでいきますので、ご参加いただけば幸いです。
はいじゃあ、11月ももう最終週近づいてきてますので、また今日から1週間頑張っていけたらなと思います。
それでは終了したいと思います。お疲れ様でした。
