00:04
はい、7月14日。時刻は昨日もありました。
いめめのkeeth工学は、おはようございます。
では本日も朝活を始めていきたいなと思います。
本日はですね、タイトルがありますとおり、
The balance has shifted away from SPAsですね。
はい、という記事を読んでいこうかなと思います。
shifted awayを抜けてましたね、タイトル。
では早速ですけども、読んでいきたいと思います。
多分この記事自体はそんなに長くないので、
早めに終わると思います。
なので続いて、この記事を読み終わったら、
これについてのもう一個深い考察である、
モアソーツオン SPAsというところの記事まで
入っていきたいかなと思っております。
はい、じゃあ早速いきましょう。
空気感がある。時代精神ですね。
難しいですね。
SPAsというのはもはや10年前のような
クールキッズではなくなりましたと。
新しいフレームワークですね。
AstroとかQuickとかEldar.jsみたいな
新しいフレームワークっていうのは、
デフォルトで0KBのJavaScriptで
MPAの機能を宣伝しているんですけども、
いわゆるヒストリーAPIであったりとか、
フォーカス管理とかスクロールの復元であったりとか、
コマンドコントロールクリックであったりとか、
メモリーリークなど、
SPAのあらゆる課題を列挙した
ブロック記事が出回っていますと。
SPAに対して危機として非難が見せかけられますと、
その記事の中ではというふうに言ってますね。
それぞれいろんな記事とかがリンク貼ってますね。
続いて入っていきたいと思いますが、
しかしあまり議論されていないのは、
近年MPAがSPAに対してより優位に立てるように
文脈が変化してきたということです。
これはちょっと僕の周りでも観測されてますね。
別にSPAである必要あるのかっていうところが、
改めて議論になってきてるっていうのは
僕の周りは正直実はあってですね。
時と場合とか文脈によってはむしろMPAのほうが
やはりコントローラブルで柔軟性があるんじゃないの
っていうところの話もあったりはするので、
これは結構僕も近い感覚ありますね。
一応、この人が言う具体的なのは4つありまして、
1個1個読んでいくんですけど、
1つ目はですね、Chromeっていうのは
ペイントホールドを実装し、
MPAのページ間を移動する間に
白飛びすることが回せなくなりましたと。
いわゆるフラッシュすることですよね。
減ったっていうことは完全にゼロには
なくならないと思いますけど、結構減ったってことですね。
Safariは結構前から実はすでに実装されてたりするらしいです。
一応その話へのリンクも、
Twitterのリンクですねこれ。
載ってますが、
最後のツイートだと思いますけども、
重い。
出てきてます。
03:00
ちなみにそのペイントホールディングっていう機能があって、
それもChromeの機能なんですけど、
developer.chrome.comっていうブログの中にも
このペイントホールドっていう専門の記事が書かれてますので、
もし興味ある方は見てみてください。
ちょうど今日読むこの2つの記事のリンクもツイートします。
そのSafariのほうもですけど、
webkit does not need metaname color schemaみたいなタグですね。
to do thisということを言ってますね。
thisって言ってるのはそのペイントホールディングっていうものですね。
webkitはもうだいぶ前から実は実装されていて、
it is needed for more than reasons
いくつかの理由があってこれが実装されたよってことですね。
Safari has been doing paint holding in most carriers for years
数年間によってペイントホールディングの実装とか
あの辺の拡張というのは実はSafariがしてきたんだよってことを
この中のエンジンの方がおっしゃってますね。
いやあ、実は知らなかった。
一応Chromeもそれができるようになりましたと。
続いてまたChromeの話ですけど、
Chromeっていうのはback forward cacheを実装しましたと。
現在すべての主要なブラウザがこの最適化というのを行っていて、
MPA内の前後の移動っていうのをほぼ
瞬時に行うことができるようになりましたよと言ってますね。
やっぱりなんだかんだキャッシュ戦略のところだと思うんですけど、
そこがさらに進んでMPAでページ遷移とかの前後が
前後の移動っていうのがほぼ瞬時に行うことができるようになったので、
別にSPAのようにシームレスの体験が
かなり近いことができるようになったよと言ってますね。
続いてサービスワーカーですね。
っていうのがありますと。
これかつては実験的な機能だったんですけど、
現在のモダンブラウザでは事実上ほぼ100%利用可能と言っても過言ではないので、
クライアント側のルーターもおよびその複雑さを実装する必要なく
オフラインナビゲーションというのも可能になりますよと言ってます。
最後シェアエレメントトランジッションですね。
これまた別、それ専用の記事が貼られてますね。
これはGitHubのリポジトリですね。
シェアドエレメントトランジッションというライブラリーかなの記事がありますけど、
ライブラリじゃないな、これ多分Webのベース機能かな。
ただ、なるほど、オーガニゼーションがWICGですね。
そのシェアドエレメントトランジッションというのが受け入れられて、
ブラウザ間で実装されればNPAナビゲーション間のアニメーションというのを行うことも提供されますと。
なのでよりSPAでしかできないと言われたような
ページ間移動の時のアニメーションというところもNPAで全然できるようになってきたよという話ですね。
あとはそのブラウザ間で実装されればさらにそれができるようになったよというふうに言ってます。
以上4つの点に関して考えると、別にSPAじゃなくてもNPAでも全然
僕らの目指したりとか表現したいことができ始めてきているということを言ってますね。
これはSPAにその場所がないと言ってるわけじゃないですと。
リッチ・ハリスという方がおっしゃっていることには、
06:04
移行期のアプリについての素晴らしい講演というのを彼が行っているらしいですね。
そのGreat Talkというところのまたリンクがあって、これはYouTubeのリンクですね。
これもちょっと別で、終わった後にツイートしてみようと思いますね。
リッチ・ハリスの発言は基本的には大体聞いてて損はない気がするので、
素晴らしい講演を行っているんですけど、
SPAを採用したいくつかの理由をその中で解説されていますと。
例えばオーディオとかビデオプレイヤーなど、またはチャットウィジェットのように
ページ道に耐えられるような、どこにでもあるような要素が必要な場合というのが一つですね。
あるいは無限ロードのリストでバックボタンを押すとか、
リストの前の位置に戻るようなものですね。
そういうものにSPAが欲しいなという話ですね。
このような機能を明示的に使用していないチームでも、
未知の要素を理由にSPAを選択することがあります。
未知の要素を理由にSPAを選択するってあるのかな。
何とも言えないです。
とりあえずSPAみたいなところは正直あったりはしますけどね。
今のモダンなJavaScriptフレームワークが、
基本的にはSPAを作るためというのが発端にあったフレームワークばかりなので、
そのフレームワークを使いたいためにSPAにしておくのがいいんじゃないのとか、
もしくはサーバーサイドレンダリングするとかとはありますよね。
逆に言うと今MPAを作るときに今のフレームワークって何を使うかっていうのは、
また結構面白い議論もあると思うんで、
それはそれで考えてみたいと思いますけどね。
いつの日かナビゲーションアニメーションを実装したくなったらみたいな。
最初にやってないときですね。
ナビゲーションするときのアニメーションを実装したくなったらとか、
常時表示型の動画プレイヤーを追加したくなったらとか、
既存のブラウザーABIでサポートされてないカッタマイズが必要になったらとか、
いろんなそういう問いがあったときにとりあえずそういうことを加味して
SPAにしておく方が柔軟性があって対応が効くんじゃないのって話だと思うんですけど。
MPAの選択っていうのはブラウザーABIが十分でない場合に
ページを制御する将来の可能性を事実上立つことになると。
アーキテクチャ上の大きな決断になるっていうことは否めないということですね。
結局のところSPAは完全な制御を可能にするので、
多くのチームがそれを諦めることに躊躇しているのです。
ありますね。
どっちにしろMPAになったら画面遷移するので、
遷移したときにデータがフラッシュして消えてしまうところがどうしたって言い舐めないのもありますけどね。
SPAだからストアがあって、ストアでずっと状態管理をして、
別に厳密に言うと画面遷移じゃなくてJavaScriptでコンテンツを書き換えているだけなので、
そういうことができるし、
ハードウェアの進化があったからこそSPAっていうのが今実現可能になっているのも事実としてはあるんですけど、
改めてMPAにするときどうなんだろうというのはありますが、
MPAは基本完全なる画面遷移でサーバーに1回データを取りに行かなきゃいけないので、
09:02
フロントエンドの今のモダンな機能が完全に立たれてしまうというところは確かに大きいですね。
それがあるので躊躇しているというか、
MPAを選択しないということですよね。
ビジネス的観点とか将来的なことをいろんなものを加味すると、
やっぱりSPAの方が柔軟性があっていいよねっていう話だと思いますけど、
とはいえですね、以前にも同じようなシナリオを見たことがこの人はあると言っていました。
長い間JQueryっていうのがブラウザーが提供したAPIを提供していて、
夜間に熟睡したいチームはJQueryを選択しました。
言いたいことは分かるんですけど、
結果JQueryはフレームワークじゃなくてライブラリなのですけど、
いろんな開発現場がフレームワークとして使ったので、
なんだかんだ熟睡できないチームが多かったんじゃないかなと思ったりはしています。
昔のJQueryの闇を歩いた人はこの意見に対しては不運という、
怪異的に読めるなと思いました。
懐かしい思いです。
戻ります。やがてブラウザーが追いついて、
クエリーセレクターやフェッチなどのAPIを提供するようになると、
JQueryは不要な荷物のように思えてきましたと。
ぶっちゃけるとXHRがクソだるかったので、
簡単にコールできるようになったというのが正直言うと一番の理由じゃないですかね。
なので最近JQueryを使うとしたら、
コンパクトになった実際版のJQueryが出てるんですよね。
そういうのを使うほうがまだいいかもしれないですね。
本当に必要な機能はフェッチ系の処理とか書き方が楽になるので、
もう一個は多分アニメーションですね。
簡単にアニメーションがJQueryで実装できるのでそこの辺も大きいのかなと思いました。
全然CSSで簡単に書けたりするし、アニメートJSみたいなのもあったりするので、
いくらでもJQueryを使わない理由というのはいっぱいありますし、
そもそもJQuery本体が重いというのもあったりしますけどね。
これを作り上げたジョン・レシグってやはり天才だったなというのを思ったりします。
余談が過ぎだしたので本記事に戻ります。
ちなみにジョン・レシグは結局Reactを書いてるらしいです。
まあまあそれは時代の変化だと思います。
戻ります。
SPAでも同じようなことが言えるんじゃないでしょうかというふうに言ってます。
JQuery使わずに別にブラウザのネイティブAPIを使えばいいんじゃないのという話ですね。
説明のためにリッチ氏がSPAが必要なものの例を挙げているということを言ってましたね。
さっきの動画中でも言ってるかもしれないですね。
主に3つ挙げてます。必要なものというのは。
1つはチャットウェジェットを常に表示するということですね。
Shared Element Transitionというのがさっきですね。
これを使用してNPAナビゲーション中にウェジェットを表示しつけるというのが1つです。
2つ目はバックボタンでスクロール位置を復元する無限リストということですね。
ブラウザ戻るボタンのことだと思いますけど。
スクロールしていった位置を復元する無限ローディングのリストですけど。
こちらについてはコンテンツビジビリティを使用して
12:01
必要であればサービスワーカーに頂戴保存することもできます。
最悪ローカルストレージにぶち込んでしまえばというのも正直あったりしますね。
それはちょっと無理やり感はありますが。
続いてナビゲーションの間、再生し続けるオーディオ・ビデオプレイヤーを常に表示するみたいなところですね。
今日NPAでは不可能なんですけど、今後どうなるかというのは何もわからないですし、
Picture-in-PictureというAPIがいつかこれをサポートするかもしれないねというふうに言ってますね。
いろんな例を挙げてましたけど、しかしはっきり言ってSPAが完全になくなるとは正直思えませんというのがこのフィッシャーの意見ですね。
フォトショップやフィグマのようなものをNPAとして合理的に実装できるかは分かりません。
しかし新しいブラウザAPIや機能が次々と登場し、SPAの優位性が徐々に損なわれていけば、
将来的にはより多くのチームがNPAを構築することを選択するようになるでしょうと言ってます。
個人的にはこれだけ多くの選択肢があるのはエキサイティングなことだと思います。
しかもどれも10年前よりずっと良くなっているというところも注目になっていますね。
私は人々がオープンマインドでSPAとNPA、そして移行キーアプリとでも呼ぶのでしょうかね。
その両方というのが将来より良くなるように後押し付けていることを願っていますので、
一旦この記事は締められておりますというところですね。
一旦SPAとNPAのざっくりとした比較をしてみて、NPAも再評価してもいいんじゃないのという話をされてますね。
ただまだまだやっぱりSPAの方が幅広いし表現力も高いし、
これがなくなることはないというところも言及されていて、
どっちを選択するとか、画面によってはアプリケーション全体がSPAじゃなくて、
一部分の画面整理のところはNPAになるというのも全然あっていいと思いますけどね、個人的には。
というところでした。
では一旦今読んだThe Balance has shifted away from SPSというところの記事は終わりで、
フォローアップの記事があります。
Morrison's SPAです。
SPA図というやつですね。
ここに続いての考察が書かれているので、
続いてというかより深いところですかね。
書かれているのでここをちょっと読んでいこうかなと思います。
いきましょう。
前回の記事、SPAからバランスが崩れたというやつですね。
今読んだ記事からそれなりの反響を読んだので、
今回はその続きとしていくつかの点を明確にしたいなと思って読みます。
この記事自体が前の記事からほとんど日が経っていないので、
本当に大反響を読んだのかなと思いました。
では続きましょう。
まず定義の話ですね。
Definitionです。
ある界隈でSPAは俗にJavaScriptを大量に使ったウェブサイトを呼び付けるようになりました。
まあまあ別に否定はしないけど。
JavaScriptがあまり好きじゃない人たちなどにとっては、
こういうSPAに対して否定的な人って結構集まってるよっていうふうに言ってます。
JSが好きじゃない人たちは、
それはSPAが好きじゃないでしょうね。
15:01
しかしこれは私の言うSPAとは全く違います。
つまりクライアントサイドのルーターがあり、
全てのナビゲーションが新しいページをロードするのではなく、
同じHTMLページに留まっているようなウェブサイトです。
それだけだと言っていて、
それがSPAと言うかと言うとちょっと違うよって話をしてますね。
プログラミングモデルやシングルページアプリケーションを
コーディングしているように感じられるかどうかは実は関係はないよと言っていて、
この筆者の方の定義では、
TurboLinksはSPAフレームワークだと言ってます。
TurboLinksってなんだっけ。
GitHubのTurboLinksっていう、
これこそライブラリーかな。
ちょっと僕が不勉強で申し上げました。
TurboLinksっていうのがあるらしいですね。
っていうのはSPAフレームワークです。
例えフレームワークのユーザーとして、
JavaScriptに触れる必要がないとしてもだと言ってますね。
クライアントサイトのルーターがあれば、
それはSPAなんですと言ってます。
やっぱり根幹はルーターですよね、確か。
第2に、私の投稿の要点っていうのはSPAを葬り去り、
その墓の上で踊ることではありませんと。
やっぱり海外の方の表現力面白いな。
私はSPAは素晴らしいと思いますし、
多くのSPAに携わってきました。
SPAには明るい未来が待っていると私は思っています。
私が言いたかったのは、SPAを使う理由が
ナビゲーションを速くするためだけだとしたら、
それは見直す時期が来てるんじゃないかというところですね。
それがさっきのMPAの見直しってところの
結構根本的な理由の一つだというところですね。
MPAはやっぱりローディングがかかってしまうので、
やっぱりシームレスに動くSPAとの体験が
やっぱり全然違いませんってところがあるんですけど、
そのナビゲーションが遅いっていうのを理由に、
SPAが選ばれてるだけだとしたら、
今MPAでも全然いいぞっていう話が出てきてる話ですね。
もちろんそのキャッシュ的な話が結構大きいと思いますけど。
なぜならっていう理由が書かれていて、
なぜならブラウザーのストリーミングHTMLパーサー
っていうのはSPAが完全なJSONまたはHTMLをダウンロードして
手動でDOMに注入するのにかかる時間よりも早く
アバウトなコンテンツを描けるからですと。
この例って言ってますけど、例のリンクはないですね。
この例ではGitHubっていうのはターボリンクスの
SPAナビゲーションよりも新しいHTMLを取得するために
古典的なサーバーのラウンドトリップを
行ったほうがいいということになりますと。
まあまあまあまあそうですよね。
とはいえ私の投稿はいくつかの資料深いコメントや
フィードバックを目指しましたと。
そしてSPAの最近の人気低下には他の理由があるのか、
またある種のウェブサイトではなぜSPAが将来も
魅力的な選択肢であり続けるのかをちょっと考えるようになりました。
文脈とかコミュニティとか場合によっては
SPAっていうのは結構人気が下がってきているっていうのは
事実があってその理由は何なのかっていうのもありますし、
逆にある種のウェブサイトでは全然SPAが今、
今後もずっと使われ続けるっていう事実もあるそうですね。
18:02
それについてちょっと深く考えてみたいなっていうところですけども。
まず一つ目ですね。
コアウェブバイタルズです。
Googleの出したコアウェブバイタルズですね。
これについて一旦セクション切られてますね。
2020年Googleっていうのがコアウェブバイタルズっていうものをですね、
検索ページのランキングの要因にすることを発表しましたと。
これは業界に衝撃を与え、
それまでパフォーマンスをあまり重要視していなかった人たちが
サイトのスピードスコアに最新の注意を払いになったと言っていいと思います。
これ結構僕も衝撃でしたね。
パフォーマンスが悪いサイトはGoogleの検索の中で
上位に表示しないっていうふうに言い出したので、
終わってなりましたねこれは。
いい意味ですよ僕は。
結構これ嬉しかったです、どっちかというと。
やっぱり重いページで自分の時間を使うの嫌ですからね。
コアウェブバイタルズっていうのは、
ページロードに非常に重点を置いていることに注目していることが重要ですよと。
いくつかの要素があるんですけど、
例えばLGPってやつですね。
Largest Contents PaintとFIDですね。
First Input Delayってやつですね。
っていうのがあって、
これはいずれも最初のナビゲーション中の
ユーザーエクスペリエンスのみに適用されますと。
あとはCLSですね。
Communicative Layout Shiftっていうのがあって、
これさっきから出てきているこの英単語3つってやつですけど、
これはあくまでコアウェブバイタルズの中で出てきている観点ですね。
をまとめたものになります。
カテゴライズしたものですね。
っていうのは、
CLSっていうものは最初のナビゲーションと
それ以降に適用されるものになりますよと言ってますね。
Googleっていうのは最初のページ読み込み後の
サイトの速度は実はあまり気にしていませんと。
彼らはGoogleでリンクをクリックして
その後のページを読み込んだときの体験だけを気にしていると言ってますね。
これらの測定基準っていうのが
ユーザーエクスペリエンスの正確な代理であるかどうか
っていうのにも関わらずに
SPAに対して大きく偏っているんですよっていう風にやってます。
はあ、まあそうね。
この基準がそもそも
UXのいい方なのか悪い方なのかっていうのを
それ自体は一つの議論もあるんですけど
これかどうかっていうのは別に気にしていなくて
とにかくSPAに対して大きく偏っているっていうことを言ってますね。
SPAの価値提案全体っていうのは
少なくともパフォーマンスの観点からですね。
価値提案の全体っていうのは
後続のインタラクションが早くなるのと引き換えに
大きな先行コストを支払うということになりますと。
これはあくまで理論上のことですけどね。
これらの測定基準によって
GoogleっていうのはSPAがクライアント側でレンダリングする場合
LCBですね。
多くのJavaScriptをロードする場合
これがFIDですね。
またはクライアント側でコンテンツを徐々にレンダリングする場合
これはCLSですね。
それぞれにペナルティーを課していますよと言ってますね。
なるほどでした。
シンプルなHTMLファイルと
JavaScriptを使用しない古典的なMPAですね。
マルチページアプリケーションっていうのは
21:00
JavaScriptを使用しない古典的っていうのは難しいですね。
基本的に多分MPAでは何かしらJavaScriptを使う気はしますけどね。
使わないものと言ってますけど。
古典的なMPAっていうのは
Core Web Vitalsで非常に高いスコアを獲得します。
そりゃあそうでしょ。
早いもん。
さらにJavaScriptを使わなかったら余計に早いですよね。
ブラウザーのレンダリング解析の
大きいステップを一貫減らせるので。
Quickの開発者である
これ何て言うんだ。
ミスコ・ハーベリーさんですかね。
ヘベリーさん。
ちょっと分からないですけど。
ご自身のフレームワークの設計に影響を与えたものとして
Core Web Vitalsっていうのを明確に挙げていますと。
特にeコマースサイトのように
SEOスコアに非常に敏感なウェブサイトでは
Core Web Vitalsっていうのは
開発者をSPAから遠ざけているよっていう風にやってますね。
そのためにサーバーサイドレンダリングっていうのがあったりしますけど
それを使わない場合であれば
それはeコマースサイトとかしたら
SEOは本気で大事なので
多分SPAじゃなくてMPAに倒すと思いますね。
一応アップデートっていうのも書かれてまして
この投稿では当初CLSっていうのは
最初のナビゲーションのみに適用すると述べていたんですけど
ページ全体に適用されることが判明したと。
これは後から追記してるってことですね。
しかしJSを使用していない
そしてサイズの合わない画像やiフレームとか
サイズの合わないフォントとか
その他の間違いがないなんちゃらかんちゃらみたいな
意味でJavaScriptを使用していないMPAっていうのは
本当に素晴らしいCLSスコアを獲得できるはずだ
ということはまだ理解していただけると思いますと。
それはそうですよね。
JSをゴリゴリ使わないようなMPAは
そりゃ早いでしょうと思います。
一つの大きい要因として
CLSスコアやWebVitalsっていうのがあるよってことですね。
続いての理由2つ目ですね。
あと4分か。
あと4分でこれは全部読み切れないので
どうしようかな。
若干オーバーしたい感もあるから
いけるところまでいきたいと思います。
続いてコードキャッシュですね。
コードキャッシングです。
これは私の投稿で言及するのを忘れていたってことですね。
これは前回の記事のときに言い忘れた
コードキャッシュの話だと思います。
おそらくかなり前のことなので
MPAの関心の高まりに影響を与えることはありえないからです。
これは指摘する価値があると
思っているよって言ってますね。
MPAのページ感を移動するとき
ブラウザは賢いんで
同じJavaScriptを何度も解析して
コンパイすることはないよと。
ChromeでもFirefoxでもSafariでも同じですと。
Iは言及されていないです。
全てのモダンブラウザっていうのは
この機能を多少なりとも備えています。
ちなみにこの最適化っていうのは
スタイルシートのパースにも存在しています。
2012年のWebKitのバグとか
Firefoxのバグとか
いろんなデモとかありますけど
その辺のリンクも貼ってますね。
この辺からも十分神はされていて
多少なりとも
同じものを何度も何度も
パースしたり解析して
コンパイすることはなくなったよと言ってますね。
24:00
つまり複数のMPAページであっても
同じ共有JavaScriptとCSSを使用している場合
その後のナビゲーションの面では
大きな問題になりません。
最悪の場合
ブラウザにHTMLの再解析と
再描画
スタイルとレイアウトの計算の再実行
SPAでいずれ起こることですけど
無効化セットなどの技術により
程度は低くなっていますよと
などなど。
JavaScriptの
再実行を要求することになりますよと
言ってますね。
最悪の場合は再実行することになりますね。
それは再描画するんだから
再解析して再実行することになりますよね。
よくできたMPAでは
各ページにそれほど多くの
JavaScriptを配信する必要はないでしょうけど
同じことを
最悪やらなきゃいけないよねと言ってますね。
はい。
ペイントホールドとバックフォアのキャッシュ
前回の記事で説明したものですけど
そして前述のストリーミングHTML
というのを加えると
SPAのナビゲーションが速いという価値観が
余らなくなった理由が分かると思います。
こういう書き方をすると
あれですけど、逆に言って
MPAでも十分SPAと同じぐらいの
パフォーマンスが出るよという話が
言いたいんだと思いますね。
だからいわゆるSPAの
価値が下がったというよりも
MPAのクオリティが上がってきたというふうに
捉えるのが正しいと思います。
更新されるDOMというのが非常に小さい場合だと
特定のケースではそうかもしれないですねと。
しかしクライアントサイドルーターの
複雑さを追加する価値があるほど
高速になるでしょうかというのは
まだまだ疑問だと言ってますね。
結局ナビゲーションの数が多いと
そうはならんぞというふうに言ってますね。
追記として
SPAナビゲーションに適したユースケースというのは
設定ページであったりとかダッシュボードなど
ルートがネットされた複雑なUIであることを
思いつきました。
Next.jsのレイアウトRFCというのがあるんですけど
これリンクもあるんで
後ほど読んでみてください。
このレイアウトRFCに
これに関する良い図解がありますと
ソフトウェアにおける全てのことと同様に
トレードオフが重要だよというのが言ってますね。
これもまあまあという感じですね。
ただモダンブラウザーは
コードキャッシングの機能がだいぶ
入ってきたというところもあるので
単なる画面遷移するだけだと
さらに使っているJSとかGSSが
同じものであると
SPAと同じぐらいのパフォーマンスが出せる可能性はあるよ
というところで再評価してもいいんじゃないの
という話がありますね。
ただもちろん最悪の場合、いろんなアプリケーションの実装によっては
再評価する必要があるので
その場合であるんだったらSPAのほうが確かに早いかもしれないですね。
結局バンドルしていることになるので。
せっかく出てきたので
Next.jsレイアウトRFCというのがあるんですけど
これは
個人的にはぜひ読んでほしいなと思います。
一応この朝活でも
何週間前か忘れましたけど
ちょっと重いです。
内容もボリューミーなんですけど
ただこれを読んですごく勉強になりますし
今後Nextってこういう方針で行くんだとか
今こういう風な考え方で行くんだ
というのを学べるのでいいと思います。
ただですね
もう一個大きいのは
27:01
今後のNext.jsのレイアウトというところの
アーキテクトが
今の書き方とちょっとドラスティックに変わる面もあるので
そこに対しては結構
怪異的な人もいたりはするので
もし今後Next.jsを使いたいという人は
いろんなことを加味して
読んでおいて損はないんじゃないかな
と思ったりしています。
というところで
残りが
残りセクションは2つですね。
サービスワーカー&オフラインMPAs
と
The Virtues of SPAsですね。
というのがあります。
これどうしようかと思うんですけど
個人的に
この後の会議
会議連発があるので
準備がしたいのですいませんけど
今日の朝方は以上にしたいと思います。
明日
ちょっと続き読みますかね。
結構いい記事だと思うので
明日も読んでいこうと思います。
明日はまた
これ読み終わったらまた続き
何か別の記事読もうと思うので
ガッと探しておきます。
今日もすいませんけど
こんな中途半端なところで申し訳ないんですけど
ぐだぐだと朝方終わりたいと思います。
ご参加いただいた皆さん
大変にありがとうございました。
また明日もSSPAの議論について
お付き合いいただきつつ
何やのかっていうのはまだ検討中なので
もしアイディアとか
こういうの読んでっていうのがあったら
カテゴリーだけでいいので
カテゴリーからざっと検索したりしますので
もしあればご意見いただければなと思います。
では本日も
一日頑張っていけたらなと思います。
あと2日ですね今週も。
はい頑張っていきましょう。お疲れ様です。
