00:04
はい、7月16日土曜日ですね。
遅刻は朝9時をまいりました。
本日の土曜日、ちょっとまだ曇りですね。
昨日雨降ってましたし。
おはようございます。ひめみんのkkeethことくわはらです。
では本日も朝活をやっていきたいと思います。
あら、本日は坂木ボラさんですね。
おはようございます。ご参加ありがとうございます。
では、今日もタイトルにある通り
Weekly Frontend Roundup from Tokyoっていうサイトから
今回はボリューム369ですね。
10個の記事があるので
とりあえずタイトルと概要を読んで
そこから自分何を読むかっていうのを決めていこうかなと思います。
では行きましょう。まず一つ目ですね。
一つ目はソフトウェアエンジニアリングの
The Soft Partsってところで
ソフトウェアエンジニアのソフトスキルについて書かれた記事ですね。
Google Chromeのシニアスタッフエンジニアリングマネージャーっていう方がいて
そのマネージャーとして10年間を通して
学んだソフトスキルっていうのを紹介しているそうですね。
ちょっとボリューミーですけど
役に立つアイディアがたくさん載っているそうです。
二つ目はMOAS Thoughts on SPAsですね。
SPAに関する考えってところで
ノーランシによるSPAに関する考えをまとめていると。
特にコアウェブバイタルとか
コードキャッシュとかサービスワーカーといったアイディアに対して
SPAとMPAを比較して
その長所とか
端緒、欠点とかを解説しているようということでした。
このMOAS Thoughts on SPAsは
まさに僕が昨日読んだ記事ですね。
結構面白かったし
試験も結構書いてあったので
割と勉強になるというか
参考になるなと思いました。
もちろん異論もあるでしょうし
SPAとMPAにとって
自分たちの考えとかあったりするので
これが正解ではあるという意味ではないですけど
考え方を改めて
MPAを再強化したり
逆にSPAというところの再強化をするという意味で
いい記事だったなと思いました。
では続いて
3つ目ですね。
3つ目はThe Many Definitions of
Server-Side Rendering
という記事ですね。
様々なサーバーサイドレンダリングの定義
というところを語っていますと。
これは
そもそもSSRとは何ぞや
というところから入って
様々なアプリケーションフレームワークで実装されている
サーバーサイドレンダリングの
ドキュメントを取り上げて
そのサーバーサイドレンダリングをどのように定義しているか
といっていきましょうというところでした。
コンポーネントフレームワークのSSRと
アプリケーションフレームワークでのSSR
それぞれを明確にしていきましょうというところですね。
これも結構面白そうですね。
では続いて
4つ目ですね。
4つ目はState is Hard
Why SPA will persist
というところですね。
SPAとMPAそれぞれについて特徴と問題点
メリット・デメリットを交差するようということですね。
これらをどのように採用していくか
またそれぞれどのようにそれらへ向き合っていくべきか
というところでした。
これあれですね。
たぶん2つ目の記事
03:00
More Thoughts on SPAs
同じノーランシーの書かれた記事
じゃなかったかなと思ってますね。
さっきの記事の続きの記事だったような
記憶があります。
続いて
5つ目ですね。
シッピング・プロダクション
本番へのデプロイ方法について解説しています。
既存の様々な方法について紹介して
それのメリット・デメリットも紹介しています。
またどのようにデプロイの方法を
検討していけば良いかについても
アドバイスもしてますよというところですね。
はい。
ここはこれで気になるけど
ちょっと技術的な内容が多そうな気がするので
ちょっと読むかは考えますね。
はい。
残り5つですね。
インプリーフなところです。
6つ目の記事ですけど
Mathematical Notation for JavaScript Developers
Explained
数学表記を
JavaScriptで表現するにはどのように
実装すれば良いかというところでした。
これちょっと専門的な記事っぽい気がするので
今回はちょっと発表しようかな。
内容的に僕は数学好きなので
気になりますけど。
続いてJavaScript Hydration
is a workaround not a solution
ですね。
ハイドレーションの仕組みについての解説を行って
そのオーバーヘッドを明らかにしましょうというところでした。
はいはい。
次に8つ目ですね。
8つ目はTwo lines of CSS
Boosts
7x Rendering
パフォーマンスの話ですね。
7倍パフォーマンス
レンダリングのパフォーマンスが速くなるよ
つってますね。
2行のCSSでパフォーマンスを改善する
アイディアとその仕組みを紹介するというところでした。
これはちょっと
タイトルに吊られそうだなと思いましたね。
はい。
この2つ目の記事は
Prestige Writing
ですね。
Prestigeさんが扱う制約とか
ターンとかプレステージの考え方を
ライティングに寄与するアイディアというのを考察しています。
というところですね。
フロントエンド関係あるのかな
って気になりますけど
アイディア考察というところだけは
軽く眺めたくなった感じです。
はい。
ラスト10個目ですね。
10個目はAbortControllerIsYourFriend
ですね。
アボートコントローラーの使用と
利用方法について解説するよという風に言ってます。
はい。
以上10個でしたね。
軽くそれぞれの記事の
中身をパーッと見ていくんですが
なるべくソースコードとかが
出てこないもののほうが
音読はしやすいので
そっちのほうがいいのかなと思ったりしていますね。
かつ
この時間に読み切れるかどうかというのも重要だったりしますけど
はい。
えーっと
どれもだいたい
えーっとですね
ソースコード出てこないですね。確かに。
で
重たくないものも結構
多かったりするので
ざっくりと
適当に選んでいきますね。
えーいま一番気になったのは
やっぱタイトルにつられました。
さっきのCSSの端ですね。
06:01
Two lines of CSS that boosts 7x rendering performance
っていう字ですね。
そっからちょっと読んでいこうかなと思います。
これも短いので、多分一瞬で終わるので
他のところ
他の記事読んでいこうかなと思います。
ではですね、えーっと
いきますが
えー
ここではくだらないことを抜きにして
パフォーマンスを約7倍
向上させるために追加すべき2行のCSSに
直接フォーカスさせていきましょう
という話でした。
で、その2つのラインっていうのが
ありますけど、1つはですね
コンテンツビジビリティをオートにしてください
というのが1つですね。
で、2つ目は
イントリンシックか
イントリンシックサイズっていうのを
プロパティがCSSにあるらしいですけど
これを1ピクセルスペース5000ピクセルで
設定してくださいということですね。
僕全然分かんなかったけど
こんなプロパティがそもそもあったんですね。
コンテンツビジビリティはもちろん知ってたんですけど
コンテイントリンシックサイズってのは
僕ちょっと知りませんでした。
で、これを
1ピクセルスペース5000ピクセルに
してくださいっていうことでしたね。
で、なんでこれが必要なのか
ということなんですけど
最近のウェブサイトは
最適かつ高性能である必要があり
ウェブ上のユーザーの注意力っていうのは
非常に短くなっていますと。
はい。
で、えっと
まだ全然知らないですね。
ドハーティスレシュット
っていう方がいらっしゃるらしいんですけど
その方によると
レスポンスタイムの指揮値は基本的には
400ミリ秒とされてますよと言ってますね。
はい。
インスタグラムなどのウェブサイトが
この指揮値以上の時間をかけているとしたらどうでしょうと
このようなサイトにはもう誰も戻ってこないでしょうと
言ってます。
それはどうなんでしょうね。
言うてい待つ人もいるでしょうし
なんだかんだインスタグラムとフェイスブックはこれからも
使われ続ける気はしますけど
少なくとも不満はたまるでしょうね。
400ミリ秒もかかってしまっていたら。
はい。
パフォーマンスは最近
どんどんどんどん
速くなってきている印象があるし
ユーザーからの要求も高くなっている印象も
正直強いなと。
結構シビアな話だなと思いますね。
はい。ではどのような場合に使用するんでしょうか
というとこですけど
最も一般的な使用例としては
アプリケーションのマウントでレンダリングする
必要がある巨大なデータのリストグリッドが
あればいいですよと言ってますね。
はあ、データが巨大なときですか。
で、例えばですけど
使用書であったりとか
ドキュメントであったりとか
旅行ブログなどの静的なウェブサイトなどと言いますね。
うーん
結構いろんなとこでも全然使えそうな
という感じがしますね。
で、How does it work なので
どのように機能するんですか
というところですけど
ブラウザーはContentVisibilityAuto
で適用したクラスで
レンダリング作業をスキップして
賢く振る舞いますと言ってますね。
はい。で、ブラウザーは
レンダリングするために
DOMのレイアウトを知る必要がまだありますと。
で、Viewportにない要素はレンダリングされず
09:01
ブラウザーには指定した
ContentIntrinsicSize
というのを持つ空のボックスというのが
表示されますと。
要約するとすべてのレンダリングが
Viewportに到達するまで延期され
ブラウザーは指定された幅、高さ、スタイルで
実際のレイアウトをレンダリングしますと言ってます。
で、PS推進ですね。
で、Viewportの
外にないレイアウトというのは
ハイトゼロを持つので
遅延されたレイアウトが
Viewportに来たときに
ContentIntrinsicSizeというのが
必要な理由だよと言ってますね。
あー、なるほどですね。
まあ確かに重なるもんね。
まあでもハイトゼロか。
そのため、ContentIntrinsicSizeが
適切に指定されないと
スクロールバーがおかしな方向に
移動してしまうみたいな欠点もありますよと
言ってますね。
なるほどですね。これはちょっと気になったし。
実際にちょっと僕も
自分の開発している
プロジェクトでの
プロジェクトだと思いましたね。
もちろん開発の中で入れて
本番に入れるかちょっと分からないですけど
本番に入れても問題なさそうだったら
そのまま入れちゃいたいと思いましたね。
気になるのはやっぱりブラウザ対応ですよね。
ブラウザ対応ですけど
ContentVisibilityは
CSSコンテインメントスペックに依存していますと。
で、ContentVisibilityというのは
この記事の出筆時点では主に
Chromiumテックでサポートされていますと
言ってますね。
まあこれでも普通に
コンテンツVisibilityだと思ったりしましたけど
ちょっと試しに見てみましょうか。
Can I useで、でもContentVisibilityは
普通に
見れる気がしましたけど
ContentVisibility
はい。
ありましたね。CSSコンテンツVisibilityですけど
IEは全滅
Firefox全滅
Edgeは85以上なら
いける。Chromeも
85以上ならいけるのでEdgeと
Chromeの最新であればいける。
Safariの全滅ですね。これはiPhone Safariも
もちろん全滅。で、Operaが
確かにChromiumなのでいけますね。
71以上であればいけるというので
最新であればいけるということでした。
なるほどですね。
Firefoxが
ダメっていうのとSafariがダメっていうので
結構シビアですね。
ちょっと現実的じゃなくなりましたね。
もったいないけど
これは使えないかもなー
わかりました。はい。
一応記事戻りますね。
しかしコンテンツVisibilityの
サポートっていうのはハイエンドのシステムで
持っていて損はない機能ですけど
ウェブ開発の進捗に伴いすぐにすべてのブラウザで
サポートされるようになるでしょうと
言ってます。ただ、ネガワクバっていうのを
指令しめてるので
対応してほしいなと思いますけど
Firefoxが対応しない
はちょっと重い気が僕はしてたりしますね。
はい。
で、
あればオルタネイティブっていうところですね。
はい。
大体手段というところですけど
もし使えないのであれば
JavaScriptのパフォーマンスを向上させるために
リストの仮想化などの大体手段が一応なくはないですけど
ちなみにそのリスト
12:00
Visualizationっていうのが
別の記事のリンクが貼られてますね。
はい。
この読んだ記事は後ほどのせます。
Twitterでツイートしますので
そこから記事のリンクをたどってもらえれば嬉しいなと思います。
はい。で、
戻りますとJSで何か手段はあるんですけど
2行のCSSでできることを
100行のJSを書いてそれをメンテナンスしたい人は
いないでしょうと言ってますので
ぶっちゃけ入れないでしょうっていう話ですね。
はい。さらに読むと一応JSでできることは
ありますよと。
リアクトウィンドウとリアクトバーチャライズ
とってみたいな
ライブラリーがあるので
その辺を使っても別にできなくはないよと言ってますね。
はい。というところでした。
あとはFurther Readingsということで
他の記事が貼られてますね。
WebDevのコンテンツビジビリティのサポートみたいなところの
記事リンクと
DeveloperModular.orgですね。
これはMDNですね。
そのほうにコンテンツビジビリティの使い方のところを
貼ってあるのでそこも見てください。
Regardsっていうところで
締められてます。
というところでした。
一旦CSSのchipsですね。
連打にパフォーマンスを上げるchipsでした。
コンテンツビジビリティをオートにして
コンテンツイントリンシックサイズの
1ピクセル5000ピクセルにしてくださいというところでした。
ただブラウザサポートがあまりされてないので
ちょっと
現実的じゃないなという気はしますね。
Chromiumブラウザでしか
使えないというのがかなり言いたいなと思いましたけど。
時間の問題っちゃ時間の問題ですし
自分のアプリケーションがChromiumしか
対応しませんって言ってやれば
いいかもしれないですね。
以上1つ目の記事でした。
では2つ目の記事ですね。
2つ目の記事何読もうかなって
ちょっと悩んだんですけど、せっかく
SPAの記事をたくさん読んだのでそのまま
SPAの記事を読んでいこうかなと思いますね。
一番気になったのは
ソフトエンジニアリング
ザソフトパーツってやつですね。
ソフトエンジニアに対するソフトスキルの話ですけど。
こちらかなりボリューミーなんで
明日以降
読んでいこうかなと思います。
多分2日くらいかかる気がしますので
今日は発材しますね。
SPAの記事です。
State is hard.
Why SPAs feel persist?
という記事を読んでいこうかなと思いますね。
昨日に引き続き
ノーラン氏が書かれている
ブログ記事ですね。
では行きましょう。
ウェブ開発について書いていると
盲人と象という
例え話があるらしいですね。
全然まだ知らないですけど。
盲人と象の例え話のような記事になることがあります。
あ、あれか。
目が見えない人が
象の一部を触って
それを自分たちの知っている範囲で
観測している範囲で
これはこれだみたいなことを言っているけど
実は象ですよみたいなことですよね。
画像があったりするんですけど。
私が熱心に
ミキについて説明すると
他の誰かがいやそれはしっぽだと
言っているし
一方象の背中に乗っている人は一体何が起こっているんだろう
みたいな不思議に思っている。
今言った具体例ですね。
あります。
これ結構言い得てみような
15:00
画像なので、普通に盲人と象で
調べてみていただけると出てくると思います。
見たことある方も多分多いと思います。
Eコマースサイトであったり
生産工場アプリであったり
ストリーミングサイト
ビデオゲーム
ハイブリッドモバイルアプリ
実際の宇宙船のダッシュボード
私たちはみんな
Webテクノロジーを使って
様々な種類の製品を使っているので
自分がやっていることを説明するための
共通のボキャブラリーを持つことさえ
難しくなってきているよと言っています。
またWeb開発の
各サブディスプリン
というのは非常に奥が深いため
トンネル上に視野が狭くなったり
他の人々が行うツールや制約で
作業していることを忘れがちになります。
ユーザーもそうですし
運用者もそうですし
開発者もそうですけれども
いろんなコンテキストとか状況がある中で
いろいろなことをやっているので
共通のワードとかボキャブラリーを
持つことがかなり難しいということを説明しています。
でもこれが
ブログのいいところであったりします。
像を感じるという問題を解決するのに
役立ちますと言っています。
例えば欠陥があったとしても
我々自身の視点を提供し
人間の集合意識を呼び覚まして
残りの着物を描写する
というような手助けをすることができるようと
言っています。
2つの記事
以上リンクが
貼られています。
2Postというリンクがあるんですけど
これはこの人の同じ記事ですね。
この人の書かれている
Morrison SPAという記事と
もう1個なんだっけ
SPAのバランスがもう崩れてきているよね
という話ですね。
この2つの記事があるんですけど
いわゆるシングルページ
アプリケーションについての記事と
MPAですね。
マルチページアプリケーションですね。
新しい定義と
ウェブサイトを構築する際にどちらを選択する
理由についてちょっと不器用な
手探り状態ですけど一応記事を書いてみました。
私の目標は
私自身の視点と
多少の偏見を
表に出し他の人がコメントやフィードバックで
そのギャップを埋めることだと言ってますね。
あくまで問題提起をしているけど
自分の中で正解を
語っているというわけではないですよという話ですね。
一応この記事も
結構面白かったので
読んでいただくといいのかなと思いましたね。
多分背景が分かったりするので。
1つ目の方の記事ですね。
なんだっけ
The Balance Has Shifted Away From SPS
この記事がスタートで
ここはちょっと短かったんですけど
これについてもうちょっと深掘りしたり
補足をした記事というのが
さっき言ったBalance Has Shifted Away From SPSというやつですね。
それの続きの記事が
これなんで
この記事はこの3点セットという感じですね。
私はこのテーマについていくつかの
偏見を抱いていますと。
ご自身で偏見だと言ってますね。
今回3つの偏見を
述べてますね。
1つは私は通常
人間口角よりパフォーマンスに重視していますと。
18:01
例えば不格好でも直感的ではないとしても
よりパフォーマンスの高い解決策というのを
選び回していますね。
2つ目がブラウザが
どのように動作するかというのを
理解し独自の
質的なソリューションを
考案するよりもブラウザ的な方法に
依存するのが好きだと言っています。
この時にはブラウザに
沿った実装するのが好きだ
ということですね。
3つ目、私はユーザーランドで
起きていることにほとんど注意を払っていないと
言ってます。
ある意味で金属に近い状態に
とどまっていると。
ブラウザの視点から世界を見ることが私は好きなんです
と言ってます。ソースコードでなくてコンパイル
されたコードを見せてくださいと言ってますね。
なるほど。
かなり面白い。
確かにこれは偏見と言われても仕方ない
かもしれないですね。
僕らはやっぱりプログラマブルに書きたいと
思う人もいますし、やっぱり可動性の方を
支持するという方もいらっしゃいますし、
いろんな設計理論に基づいて設計するのが
実装するのが美しいという方も
いらっしゃいます。ここは結構違いますけど
この人はとにかくブラウザに沿った
行動格というところが
思想にあるらしいですね。
はい。
このトピックについて考えたり
他の人が書いたものを
読んだりして、一つ印象に残っているのは
SPAの大きな魅力っていうのは
多くの問題を引き起こす可能性のある
同じもの。
つまり
状態だということですね。
SPAの大きな課題はやっぱり状態ですよね。
SPAが好きな人というのは
SPAがナビゲーションの間に状態を維持するという
事実をよく称賛しています。
例えば次のようなことですね。
次のようなことですが、また3つ出てくるんですけど
一つは検索入力があるとします。
入力した後は
別の場所をクリックして移動しても
次のページには入力されたテキストがまだ残っています。
2つ目は
スクロール可能なサイドバーがあるよ
途中までスクロールしていて
何かクリックして、次のページには
最後のスクロールの位置のサイドバーが残っていますよ
スクロールの位置を保存しておこうという
3つ目は
拡張可能なカードのリストがある
そのうちの1枚を展開して
別の場所をクリックすると
次のページでまだその1枚が展開されたままになっている
という感じです。
いろんなユーザーが動作した状態を
とにかく維持しているということですね。
これはステート管理というよりも
画面の
展開した後の状態という感じです。
このような例というのは
いわゆるネストされたルートだったりすると
特に複雑なデスクトップUIで
特に重要であることに注目してくださいよ
と言っていますね。
UIの他の部分が変わっても
状態を維持するサイドバーとかヘッダー
フッターを思い浮かべてください。
UIではナビゲーション時に
ビューポート全体をほぼ
変更することが一般的ですけど
その問題は遥かに少ないというのが
興味深いところですよねと言っています。
状態を管理するということは
ソフトウェアを書く上で最も難しいことの
21:01
一つだと言っていますね。
これは確かにそうだと思いますけど。
そして多くの点で状態管理の側面
というのはSPAにとって大きな恩恵ともなります。
特に
ナビゲーション間の状態の映像化について
自動的に行われますよと言っていますね。
MPAでは
ページのアンロード時にこの状態を
何らかの永続的な形式、ローカルストレージでもいいですし
インデックスデビでもいいし
他の外部ストレージでもいいですけど
にシミュラライズをして
ページのロード時に
ハイドレーションをしなきゃいけないよということですね。
一方で
状態が決して
吹き飛ばされない
という事実というのはまさにメモリーリークに
つながるものなので
これもドキュメント化して
LSPAについての
付き物の問題だと言っていますね。
メモリーリークは
それも実装次第という感はありますけど
まあ言うて
ずっと悩み続けなきゃいけない課題ではある
という事実ですね。
さらに状態が
基地の良い初期値から逸脱すればするほど
バグに遭遇する可能性はもちろん高くなります。
そのため
動作が不安定なSPAはしばしばリフレッシュが必要になるよ
と言っていますね。
そうだなという感じはありますね。
状態がカオスになればなるほど
それはバグになるでしょうというのは
もちろんその通りなので
状態管理はなるべくシンプルにしたいところはありますよね。
なるべく状態管理そのものの
ロジックが複雑化しないように
本当はしたいところではあったりはしますね。
しかし興味深いことに
NPAのナビゲーションが常に新鮮な状態になる
とも限りません。
以前の記事で述べたように
バックフォワードキャッシュですね。
そうされています。
バックフォワードキャッシュというのが
この議論をより微妙なものとか
ちょっと複雑なものにしていますよと言っています。
続いて
キャッシュコンテンツというところの
セクションですね。
キャッシュの内容ですけども
最近のブラウザでは
バックフォワードキャッシュですね。
略してBFキャッシュと今後言いますと。
同じオリジンのページ間を
移動する際に
前のページと次のページのキャッシュを
移動しますと。これによって標準的な
NPAページを行ったり来たりする際の
ロード時間が大幅に短縮されますと言っています。
ある意味で
この観点というかこの点が
NPAを再評価していいんじゃないの
というところの議論の
発端になります。
先ほど述べていたもともと
読んでいた2つの記事があるんですけど
SPAとNPAのところで
NPAをもう1回再評価していいんじゃないの
という発端というか
大きな理由の1つがこのバックフォワードキャッシュによって
ページ完成位というところが
かなり高速になったので
SPAのシームレスさというところが
SPAを選択する唯一の
理由であるんだったらNPAを
改めて再評価してもいいんじゃないの
というのがこの人の議論だったんですけど
というところでした。
バックフォワードキャッシュというのが結構大きな理由の
1つだよという話ですね。
しかしこのキャッシュは具体的に
どのように機能するのでしょうかと
NPAのページであっても非常に動的である可能性が
ありますと。ページが
24:01
動的に変更されたり
ドムの状態が変わったり
JavaScriptの状態が変わったりした場合はどうなるんでしょうかと。
ブラウザは実際何をキャッシュしているのかというのが結構重要ですよね
という話をしています。
これを検証するために
私は簡単なテストページを書きますと。
テストページの
リンクもありますので
これも記事のリンクをたどってもらえるといいと思います。
以上この記事の中では
そのテストページの
動作的な動画が載っているんですけど
これはさすがに僕しか見えないので
追ってみてくださいということですね。
この簡単なテストページの中では
様々な方法で状態を設定することができます。
ドムの状態もそうだし
JavaScriptのヒープの状態ですね。
あとはスクロールの状態とか
保存します。
次に別のページのリンクをクリックしたり
戻るボタンを押したりして
ブラウザが何を記憶しているかを
確認するような
アプリケーションになっていますよということですね。
その結果ブラウザは多くのことを記憶している
というのが結構分かりましたよと。
様々なブラウザですね。
デスクトップのChrome Firefox Safari
とかAndroidのChrome Firefox
iOSのSafariですね。
この人が以上テストしましたと。
全てのブラウザで同じ結果を得られたんですね。
なかなか面白いですね。
戻るボタンを押した後も完全なページの状態が
維持されています。
以下はビデオによるデモです。
面白いですね。
Android ChromeとiOS Safariでも
同じ状態を保たれたというのは
なかなか面白いなと思いました。
時間が短くなってきたんですけど。
ちょっと急ぎます。
メインドキュメントとサブローラーの
両方のスクロール位置というのが
保持されていることに注意してくださいと。
さらに驚くべきことに
どもど表現されていないJavaScriptの状態ですね。
ここはボタンがクリックされた回数とかも
一応保存しているんですけど。
というものも保存されていますと。
一応別にこれは画面の中に出していないらしいですけどね。
さて、はっきりさせておきたいのは
これは通常のいわゆる
全身的なナビゲーションにおける
状態の維持の問題を
解決するものではないよということも
言っておきますと。
MPAが状態をシリアライズする
必要があることについて
上記で述べたって言うんですけど
キャッシュされない全てのナビゲーションに
当てはまる話だよと言ってますね。
またこの動作はブラウザによって
微妙に異なる可能性があり
そのヒューリスティックはあなたのウェブサイトでは
機能しないかもしれないと言ってますね。
しかしブラウザがこれだけのものをすぐに使える
というのはもちろん素晴らしいことなので
使ってもいいんじゃないのという話です。
最後はコンクルージョンです。
結論の話ですね。
微妙な差異がもちろんあると思いますね。
完全に全く同じ機能を
ブラウザが提供することは
今後もあり得ないと思いますけど
とはいえほぼほぼ同じようなことが
できているという事実は結構面白いなと思いました。
結論です。
SPA技術とMPA技術
あるいはこの2つの混合的な技術を
採用する理由はもちろんたくさんありますけど
全てを構築しようとするものの
ニーズと制約に依存するというところですね。
それはおっしゃる通りだと思いますね。
ここ数回の記事では
我々が気づかないうちに
足元で起きているMPAの興味深い変化に
27:00
改めて光を当てようとしてみました。
これらの変化というのは
とても重要であり
SPAとMPAのどちらのアーキテクチャを
採用するかを決める際の判断材料になるかもしれません。
ナビゲーションAPIのような
実験的なブラウザAPIというのが
あって
これらはフォーカスやスクロール管理といった
他連の問題も解決しようとさえしています。
もちろんフレームワークも
SPAとMPAの両方で技術的革新を続けていますよ
と言っていますね。
SPAがアプリケーション開発の多くの側面を
きちんと簡素化
シンプル化しているということ
つまり状態が一箇所ですね。
メインスレッドあとはナビゲーション間で
持続的に維持するということは
SPAの最大の強みであると同時に
予測可能な問題の厳選でもあるということですね。
パフォーマンスやアクセシビリティの
専門家というのは
指摘し続けることができますけど
結局のところ開発者が同等のMPAよりも
SPAをコーディングする方が簡単だと
信じるのであれば
SPAは作り続けられるでしょうと言っていますね。
これはそうだと思いますし
当分みんなまだまだSPAを作るんじゃないかな
と思いますね。
MPAの画面完成率のパフォーマンスが
上がったというところだけで
MPAをやりますかというと
それも別の問題だと気がしますし
それだけでMPAを使うかというと
そうではないなという気もしますのでね。
MPAの機能を
向上させるということは問題を解決するための
一つの方法に過ぎないと言っています。
SPAの開発者のためのツールとかガイダンスだったり
あとは教育的な改善だったりですね。
他の方法からアプローチすることも
同じ最終目標に向かって努力することはできます。
とあるツールが枯れ
別のツールが発展している
というようなことも
全然現実ではあり得ますしそういう戦国もあるかもしれませんけど
謙虚でいることが
とても重要で
誰もが異なる制約の下で
働いていて
ウェブ開発に対する考え方もそれぞれ異なることも
忘れちゃいけませんと言っています。
そのため私はSPAはすぐにはどこにも行かないし
おそらくウェブが存在する限り
魅力的な開発パラダイムで
あり続けるという結論に達しましたよと言っています。
ある開発者は
ある視点を選び
とある開発者は別の視点を選ぶ。
大きくて美しい像はのしのしと前進続けることでしょう
と言っています。
最終的にそのたとえを
で締めるんですね。
本の記事は終了しました。
なかなか面白かったですね。
資材に富んだ
記事だったと思いますけど
結論的には
SPAなんだろうな
というところは僕も変わらないですけど
ただMPAに対する技術の進歩というのも
確かにずっと
無視し続けていたら過言ではないですね。
なので改めてMPAの方の技術進化
というところを追い直すとか
そのためのウェブ技術どんなものがあるのか
というのを見ていくのはすごくいい話だと思うので
ちょっと気になったなと思います。
ナビゲーションAPIもそうですし
さっきの別の記事ですけどね
コンテンツの話もそうですし
バックフォワードキャッシュの話とかもそうですけど
割と全然知らなかったものなので
この辺を改めて見てはどういうメリットで
メリットがあるのかというのを知っておくのは
本当にいいことだと思いますし
改めてSPアーキテクチャについての問題提供をするという
なかなか面白い記事だったと思うので
30:00
今日はちょっと読んでみましたというところです。
では今回の発話は以上にしたいと思います。
明日からは
ちょっと技術的な話ではなくて
ソフトスキルみたいな話の記事を改めて
読んでいこうかなと思っています。
確かに記事開いたんですけど
スクロール量がめちゃめちゃ多いので
または明日どころか
3日くらいにかけて読む可能性はちょっとありますけど
読んでいきたいと思いますので
ご興味ある方は聞いてみていただければなと思います。
では本日の発話はこちらで
以上にしたいと思います。
今日も休みの日ですね
土曜日から、しかも土曜日の朝9時からですね
ご参加いただいた皆さんありがとうございました。
まだ明日もゆるーっと読んでいきますので
もし興味ある方はご参加いただければ
すごく嬉しいなと思います。
では良い休日をお過ごしいただければなと思います。
では終了します。
お疲れ様です。
