00:06
7月15日金曜日、地獄の朝9時を回りました。
今日の天気はあいにくの曇りですけどね。
みなさんいかがですか?
ひめめのkeethとくわはるです。
では本日も朝活を始めていきたいと思います。
おはようございます。
今日もご参加いただきありがとうございます。
今日は、昨日読んでいた、
Balance has shifted away from SPAsっていう記事の続きである、
More thoughts on SPAsですね。
同じ人が書いた記事なんですけど、その記事の途中まで昨日読んでましたね。
SPAについてバランスが崩れてきて、いろいろ考え直したりする方法とか、
ケースバイケースですけど、コンテキストであったりとか、状況であったり、チームの開発領域であったり、
求めるものによってはむしろMPAの方が良いんじゃないかっていうようなことを、
改めて言及しているという記事があって、それを読んでいたんですね。
それについてもうちょっと深掘りじゃないですけど、書きそびれたものっていうのが今読んでいる、
More thoughts on SPAsという記事なんですね。
昨日それを読んでいて、いくつかの賞に分かれていたんですけど、
まず一つの観点としてはCore Web Vitalsですね。
Googleが出したCore Web Vitalsですけど、スピードとかパフォーマンスが良くないと、
Googleの検索したときに上位風に出てこなくなったよっていうのをGoogleが提唱して、
だいぶそれで結構世界的にもインパクトあったっていう話ですね。
Core Web Vitalsはいろんな3つの観点があって、
その観点に基づいてどれだけパフォーマンスが良くなったかっていうところですね。
逆に言うとパフォーマンスが悪いサイトは基本的にUXが悪いっていう風にGoogleが定義してしまったので、
それはでも確かに僕らも同じかと思うし、
自分の人生をこんなローディングのために使うって正直嬉しくはないですからね。
っていうのがあって、一つCore Web Vitalsっていうのが、
SPAの考える直すポイントとしていいんじゃないのっていうのを一つ言いましたね。
ただ、MPAの方が良いのかって言ったらそういうわけでもないし、ケースバイケースですね。
物によってはまだSPAの方が表現力が高くあったりとか柔軟性があったりとかして、
いいんじゃないのっていう観点もあるので、どっちとも言えないですけど、
ただ一つの観点としてCore Web Vitalsっていうのがやっぱりありますよねっていうのがありますよって言ってました。
続いてコードキャッシングですね。
ソースコードのキャッシュが結構いろいろできるようになったし、
コード自体もモダンブラウザーはかなりキャッシングが大きくなっていて、
それによって単なるページサインするときのパフォーマンスがスピードですよね。
03:00
だけを求めるんであれば、別にMPAでも今はSPAと同等ぐらいのスピード感が出るので、
別にSPAである必要はないよっていう話もしてましたね。
WebKitとかはその辺に関して結構早く対応してたっていうのがあるんですけど、
ブラウザーの何の機能に対して研究したかちょっと覚えてないんですけど、
僕が覚えてないんですけど、ブラウザーの何かの機能があって、
Chromeもそれに対応したというところがあって、
それによってよりMPAでも良くないかみたいなところを話をしていましたね。
以上。一旦その辺のところで読んでて、
今日はその続きですね。
サービスワーカー&オフラインMPAsっていうところから入っていこうと思います。
じゃあまず一回そこを翻訳していきます。
今日はちなみにこの記事ですけど、たぶんもうあと10分くらいですかね。
でもたぶん終わってしまうので、残りの時間はJSERインフォです。
いつも通りのウィクリニュース。
JSERインフォから何かの記事をピックアップして、
どっか読んでいこうと思います。
起きたのが今10分前ですね。
かなりグダグダします。申し訳ないですけど。
じゃあやっていきましょう。
SPAsのサービスワーカー&オフラインMPAsというところから入っていきたいと思います。
私の投稿に対する興味深い反応の一つに、
SPAはプライバシーを守り、全てのユーザーデータをクライアント側に保持するから好きだ。
私のサイトは静的なファイルだけでいいのです。
これは素晴らしいポイントであり、
実際に私がマストドのクライアントであるピナフォアというSPAとして書いた理由の一つではあります。
ピナフォアってなんだ。
ピナフォアというのをSPAとして作ったんですね。
マストドのクライアントが。
マストドのためのクライアントアプリピナフォアというのをSPAとして作ったという風に言ってますね。
その理由の一つが、今回言ってたSPAはプライバシーを守って、
全てのユーザーデータをクライアント側に保持するから好きだという指摘が、
それに近しいというかマッチしてるよというところですね。
全て静的なファイルだけでいいという風に振り切っているというところが、
この人にとっては素晴らしいポイントだという風におっしゃってますね。
なかなか難しいところはありますし、状況によりますね。
SPAだけどサーバーサイト連絡がなかなか必要なサイトとか、
いろいろアプリケーションがあったりすると思うので一概には言えないと思いますけど、
クライアント側は静的にビルドできるんだったら、
それは静的なほうがいいと思いますね。
早いですから。
しかしですけど、私の投稿で述べたように、
SPAアーキテクチャには純粋にクライアント側でユーザーデータを処理するための
唯一の選択肢になるような、こういうのは何もないよと言ってます。
06:02
全てのレンダリングをサービスワーカーに一本する、
完全にオフラインで動作するMPAを発表することももちろんできます。
ちなみにこれは私が見つけた実装例ですというところで、
その実装例のリンクが記事内に貼ってますので、
後ほどこの記事自体を共有しますので、その中から追っていただけると嬉しいなと思います。
しかしですけども、これは私の投稿の中で、
弱い主張の一つであることは認めますと。
なぜなら私の知る限りでは、実際には誰もこれをやっていないからです。
まあそうだよ。全てのレンダリングをサービスワーカーに依存するみたいな。
完全にオフラインでも動作されるMPAを作成するっていうことをやってる人はかなり少ないんじゃないですかね。
僕聞いたこと一回もないですからね。
もちろんサービスワーカーを使ってキャッシングさせるみたいな話はよく聞きますし、
オフラインに対応するところでサービスワーカーを使うのは全然聞きますけど、
それで全部レンダリングすべてをサービスワーカーに依存するみたいなところはあんまり聞いたことがないかもしれないというところですね。
よくやるのはオフラインになったときに何もコンテンツを表示させないというのはUXが悪いので、
何かしら表示させるみたいなのがよくやる話かと思いますね。
続きます。
私が知る限りサービスワーカーを生成するフレームワークのほとんどはクライアント側ルーターも制定しますと。
サービスワーカーは拡張機能ではありますけど物語の主役ではありません。
もし反対の例をしているならぜひ教えてくださいと。
ここは僕も完全同意ですね。
教えてほしいなと思います。
実はこれウェブ開発において非常に未開拓の領域だと思うんです。
私は2016年にこのサービスワーカーファーストのアーキテクチャーをピッチングしていましたと。
そういうアーキテクチャーがあるんですね。
サービスワーカーファーストっていうアーキテクチャー。
結構そのサービスワーカー、名前の通りだと思いますけど、
サービスワーカーに重きを置いた、ファーストって言ってますからね。
サービスワーカーは大前提としたアーキテクチャーというのがあるんですよね。
私は今でもいずれどこかのフレームワークがこのアイディアの探求を始めるのではないかというふうに期待していますと。
最近ノード以外のサーバーサイドJavaScript環境をサポートするフレームワーク、
クレアードフレアワーカーですね、などなどに注目が集まっていますけれども、
サービスワーカーは同じように制約のあるJavaScript環境なので、
理論上はこれが容易になるはずですと。
もしフレームワークがクラウドフレアワーカーの内部からレンダリングできるのであれば、
サービスワーカーでもいいのではないでしょうかというところを注目します。
なるほどですね。
ノード以外のサーバーサイドJavaScript環境って確かにありますよね。
その辺はツールだったりサービスだったりフレームワークだったり、
いくつかあると思うんですけど。
そうですね、その中から内部からレンダリングができるんだったら
09:00
サービスワーカーでいいのかじゃないのかっていうのは確かに一つの議論ではあると思いますね。
ちなみにこのアーキテクチャには一応利点がいくつかあるとおっしゃっていますと。
今回はいつつですね、利点を述べられています。
一つ目ですけど、クライアント側のルーターがないため、
フォーカス管理とかスクロール復元などの実装が不要になりますと言ってますね。
はい、ルーターがないからフォーカス管理、スクロール復元などの実装が不要になるっていうのは本当にそうなのかな。
言うて画面の遷移があると思うんで、遷移したときにブラウザで戻るとか、
1個前の画面に戻ったときにできればスクロール位置を復元したりとかあると思うんですけど、
その辺やらなくていいのか。
ああ、だからサービスワーカーなのでキャッシュしてるから、
キャッシュするときに自然とそこまで持っているからいいって話か。
続いて、ペイントホールドやバックフォワードキャッシュの利点もそのまま読んでおきます。
これがその理由ですね。
続いて3つ目ですけど、同じオリジンを指す複数のブラウザタブを開いた場合、
メインアプリケーションロジックが既にサービスワーカーでブートストラップされているため、
各ページで完全なSP JavaScriptのロードを回避することができますと。
1つのサービスワーカーが同じオリジンの複数のタブを提供しているってことですね。
これはいい話ですね。
別々のタブ開いても1つのサービスワーカーが同じオリジンになって複数のタブを提供してくれるので、
JSのロードっていうのを何度も何度もその複数ページごとでロードしなきゃいけないってことを回避することができるって結構デカいですね。
サービスワーカー自体をブラウザで1つみたいな概念で使いますので、
それは確かに大きいと思います。
続いて4つ目ですね。
サービスワーカーっていうのはRedoubleStreamを使用して、
上記のようにブラウザのProgressiveHTMLパワーさんのリテイムエルフを取ってきますと言ってますね。
サービスワーカーってRedoubleStreamを使ってるんですね。
これは僕ちょっと知らなかったですね。
ちなみにこのRedoubleStreamっていうのはまたリンクが貼ってあって、
Modularのサイトなのでこれあれですね。
やばい、名前出てこない。
みんな大好きなんちゃらっていうMDNのリンクが貼ってるんで、
その中にWebAPIのRedoubleStreamっていうのがあるので見てみてくださいと言いました。
ラストですね。
5つ目はメモリーリークについて言及します。
私は過去に何度もこの問題を指摘しましたが、
確かにこの方法は問題を完全に解決するものではありません。
おそらくリークをサービスワーカーに移動させるだけでしょうと言ってます。
なので結局は解決はしてるわけではないと言ってますね。
しかしサービスワーカーはファースト&フォアゲットモデルなので、
ブラウザーはサービスワーカーを簡単に終了させ、
メモリーを大量に消費したら再起動させることができ、
ユーザーは気づかないかもしれませんと。
しかしこのアーキテクチャにいくつかの欠点はありますと言ってますね。
12:04
このほかでも面白いですね。
メモリーを大量に消費したら再起動させることができる。
サービスワーカーはその辺をコントロールアプリに
アプリケーションを扱うことができるので。
サービスワーカーのファースト&フォアゲットモデルというのを
僕は知らなかったんですけど、こんなのあるんですね。
別に名前がついてる。
実は僕が何も知らなかっただけみたいなのがあるかもしれないですけど。
ファースト&フォアゲットですね。
っていうのがサービスワーカーのモデルなので、
ブラウザーはサービスワーカーを簡単に終了させたりとか、
再起動することもできる。
かつそれをユーザーに気づかないようにやることができるということですね。
裏で実行しておくということですよ。
これでもすごい話だな。
キャッシュだからなせれば立つからね。
現在使って動いてるアプリケーションと、
新しく裏で動かしておいて、
それをキャッシュで保存して持っておくことでしょう。
パワーが必要な機能だと思いますけどね。
一応今5つ挙げました。
サービスワーカーで全部やっていこうというところですね。
アーキテクチャですけど、欠点がありますよとも言ってます。
それについてまた欠点4つですね。
1つは状態というのをまず見ていって、
状態はサービスワーカーとメインスレッドの間で分断されてしまうので、
通信には非同期のポストメッセージが必要になりますというところですね。
確かにそうですね。
メインスレッドと分けますよね、サービスワーカーで普通に考えて。
なので通信には非同期のポストメッセージが必要だと言ってます。
この辺がちょっと制御がめんどくさいというものの一つですね。
次の理由ですけど、2つ目はサービスワーカーからアクセスできるものが必要なため、
インデックスDBやキャッシュを使用して永続的な状態を保存することが制限されます。
同期型のローカルストレージではもちろん使用できませんよと言ってますね。
確かにここはちょっとね、まためんどくさいという。
ローカルストレージに使えたらすごく楽ですからね。
楽なんですけど、あいつは本当に同期的なものなのでサービスワーカーと相性が悪いんです。
なのでインデックスDBとかキャッシュを使って状態を保存することっていうのは結構やり方が制限されるんですよね。
続いて3つ目です。
3つ目の理由は一般にSPAの単純化されたアプリ開発モデル、
全ての状態が一つの場所に保存されてメインスレッドで同期的に利用可能にするという、
いわゆるシンプルに単純化されたアプリ開発モデルっていうのは窓から投げ出されることになります。
要はできないよって言ってますね。
これが辛いかもしれないですね。
もちろんSPAの中でも状態管理とかステートをどうやって持つかっていうのを
一つの大きなシングルドームみたいなグローバルオブジェクトで持っているっていうのもありますし、
それにFluxの概念を入れておいて、データのフローを単一方向にするみたいな請求を入れていることもよくあると思います。
15:02
いわゆるLinux的なものですね。
にしたりもいいですけど、あとは最近の状態であったりとか、
リコイルかみたいな結構小さなかつ軽量なストア管理のライブラリあるじゃないですか。
それでカスタムフックを使ってそこに組み込んでいくみたいな状態管理のものもありますけど。
いずれにせよ、SPAの単純化された開発モデルのようにサービスワーカーで状態とかを管理したりするには、
ぶっちゃけると限界があるよって話をしていますね。
ここも結構サービスワーカーを導入したくないなっていう理由の大きな一つになったりしますね。
現代ではWebアプリケーションでフロントエンドでやるとしたら状態管理するのはほぼ必須だったり、
作ることがやっぱり何らかの大前提だったりすることが多いと思うので、
相性悪いなって感じはありますね。
ラストですね。
私の知る限りではこのようなことを行っているフレームワークがそもそもないよって言ってます。
これも辛いですね。
じゃあ全部自分たちでガリガリ行かなきゃいけないっていうのが正直あるので。
サービスワーカーを使うというか、
PWAを実現するためのライブラリーみたいなのがGoogleから出てたりするんですけど、
サービスワーカーそのもので対してこういうような状態管理したり、
アプリケーションを作るみたいなフレームワークは今のところ存在はしないので、
全部自分で茨の道を歩くしかないっていうところが辛みだって言ってますね。
最後締めてみますけど、
ライブラリのパフォーマンスとシンプルさの長所というのは、
少なくともプロトタイプを作成する価値はあると思いますが、
やはりDXですね。
ディベロッパーエクスペリエンスの方です。
実際に実行可能な程シームレスであるかどうかというのはまだまだ分からないと言ってますけど、
多分読んだ感じ、分かんないというかむしろ疑問に近いところですよ。
だって言ってますね。
オフラインでサービスワーカーを使ってオフラインのMPAを作るっていうのはなかなかきついものがありますね。
SPAをそもそも作るときにサービスワーカーをどこまで使うかっていうのは、
要法要領の話はあると思うんで、それもありますけど、
少なくともMPAよりはSPAのほうが相性がいいんじゃないかという気もしてたりはします。
まあいいや。
ラストですね。
ラストのセクションですけど、
意外と17分いってしまった。
The Virtue of SPAですね。
SPAの長所というところを最後に述べて終わりにしたいところですね。
いきます。
バックフォードキャッシュとかはCore Web Vitalsなど、
SPAについていろいろ説明してきたんですけど、
なぜ2022年になってもSPAを構築したいと思うのでしょうかという問題提起ですね。
多少手垢のついた答えになりますけど、
SPAが良い選択肢であるケースっていうのはたくさんあると思います。
今回はいずつ述べてます。
例えば一度に多くのブラウザのタブが一つだけで、
一度に開くブラウザのタブが一つだけで、すみません。
ページのロード頻度が低く、
コンテンツが非常に静的、
18:01
違うそうです、動的であるだろうですね。
全体系がSPAの適切な使用例に一致するアプリを構築している場合ですと言ってますね。
これそのままですね。
SPAの一番のメリットというか、
よくわかる理由の一つだと思いますね。
いわゆるシームレスで何度も何度もページロードしなくてよくて、
それでもちゃんとユーザー操作によってゴリゴリ動いていくと。
Java Selectでコンテンツを書き換えていくみたいなところですね。
のような必要性があるときには、
SPAがまさにマッチするでしょうというところですね。
ということでした。
一応この中、今の一つの理由の中に、
HoloTypeっていうのがリンク記事に貼られてますね。
これは僕の知らない、
jsconformat.comっていうドメインのアプリケーションホロタイプっていうリンクが貼られてますね。
これも全然よくわからないんですけども、
これですね。もし興味がある方は見てみてください。
今のが一つ目で、
二つ目の理由はCore Web VitalとSEOっていうのは
アプリがログインゲートの後ろにあるなどの理由で
大きな関心事では別にないよって言ったりしてます。
Core Web VitalとSEOは大きな関心事じゃない。
SEOはそんなに小さくもないと思いますけどね。
大きな関心ではあると思いますけど。
SPAって作る中でSEOの話はいつも出てきますが、
GoogleのBotがだいぶ進化してきて
SEOのSEO、SPAでもSEOをちゃんとクローリングっていうか
追ってくれるようになってきたっていう話が出てきているので、
僕はちょっとそれを期待したりしてますけどね。
ただその話自体も結構数年前に出たので、
今どうなんだろうって気はしますけど。
あとCore Web Vitalの話は
SPAというかそもそもパフォーマンス観点の話だったりするので、
SPAだろうがMPAだろうがどちらにしろ必要でしょうみたいなところがあったりします。
なので、SPAを選ぶ理由の一つに
Core Web Vitalを出すのはどうなんだろうって気はしますけど、
ただ一方でCore Web Vitalは昨日読んだ通りですけど、
ちゃんと対応したりとか考えていくんであれば、
やっぱりSPAのほうが相性がいいのは事実だと思います。
柔軟性の観点で変更を聞いたり、
いろんなものをキャッシュ化したりとかそういうことを考えると、
SPAのほうがやりやすいっていうのは僕もそうだなと思いますね。
続いて3つ目ですね。
SPAでしか利用できない必要な機能があると。
例えば前の投稿で述べたように、
どこにでもあるビデオプレイヤーなどですね。
ビデオプレイヤーの埋め込みとかあったりとか、
制御っていうのはSPAでじゃないとできないっていうところがあったりしますね。
4つ目。
お気に入りのフレームワークがサポートをしているため、
チームはすでにSPAを構築して生産的になっていると。
これはビジネス的な観点ですね。
現代のダブルスクリーズの3大フレームワークが、
ちょっと言い過ぎかもしれないですけど、
リアクトだったり、ビューだったり、
スベルトだったり、ソリッドジェイザーだったりとか、
21:00
この辺のやつはなんだかんだSPAを作るところが
前提だなっていうフレームワークだったりするので。
もちろんそれを使ってSPAを作るほうがやっぱり生産的だし、
チームとしても慣れているので、
よりパフォーマンス高くアプリケーションを作れるっていう話は
もちろんあると思います。
ラスト5つ目ですね。
そもそもSPが好きなだけでしょうと。
それはもちろん結構のことで、
私はあなたからSPを取り上げるつもりはもちろんありませんと言ってますね。
それもそれは一つでいいんじゃないですか。
別に開発者が好きだからっていうので、
作るのは別に僕はいいと思います。
ただもちろん誰のためのアプリケーションっていうのを考えると、
もちろんSPじゃないほうがいいときの選択肢はあると思いますし、
技術者ならそこはちゃんと技術的観点から今回SPじゃないっていう
意思決定をすることは必要性はあると思います。
ただ自分が好きなものを選ぶってところで、
その先にどんな問題が起きたりとか大変なことがあるかもしれないですけど、
自分が選んだものなのでその中で戦うっていう意思決定をするのも
一つの選択肢であると思います。
その中でビジネス的な理由とか必要性のところを
実装しなきゃいけないってなっても
自分が好きだというふうに選んだんだから
そこを挑むっていうのはいい態度だと僕は思いますけどね。
以上5つの理由でした。
とはいえ、前回の投稿で私が目指したのは
SPについて人々が抱いているいくつかの前提に
挑戦をするという会話を始めることでした。
いわゆる問題提供するところでしたということです。
技術業界ではしばしば、昔からそうだったからという理由で
物事を行い、以前の決断とか意思決定をした条件が
変わったかどうかを考えることをやめないことがありますと言ってますね。
SPのナビゲーションとは常に速いとかですね。
っていうふうに例えば思っているみたいなところですね。
けど実際にどうなのかっていうところはあったりしますけどね。
SPのナビゲーションの方が速いっていうふうに
言った方がいいかもしれないですね。
前回そのナビゲーションのスピードに関しては別に
NPAでもだいぶ追いついてきたというか
そんなに遜色なくいけるようになったという話もしてましたからね。
ケースバイケースですこれは。
アプリケーションの実装によってもちろん全然ナビゲーションは
SPの速いじゃんっていうのは絶対あると思いますけど。
いわゆるそういう、何でしょうね。
もう過去にそういう経験したりとかそういうことが世界でも騒がれたので
そこから変わらないみたいなところの観点があったりするので
それに対して問題提起をするっていうのが前回の記事のコアコンセプトでしたね。
最後です。
ソフトウェアにおいて唯一普遍だのはやっぱり変化することだというふうに言ってますね。
変化することが普遍だと言ってます。
矛盾してるかもしれないですけど。
ブラウザは何年もかけて大きく変わりましたが
ウェブ開発者としての私たちの習慣というのは多くの場合
新しい現実に適合するように調整されてません。
プロトタイピングや研究というのはまだたくさんありますけど
一つだけ確かなことは10年後の最古のウェブアプリケーションというのは
10年に作られた最古のウェブアプリケーションとは
かなり違って見えるだろうということです。
24:00
ところでこの記事が締められてました。
読み始めたら意外と24分でバンバン時間使いましたね。
これは本当にそうですし、前回の記事の続きなので
この記事自体も根本的には
自分たちの技術の再評価をするべきじゃないのかみたいところの観点から
書かれたものになりますね。
ちなみにこれの次の記事がまたSPAのことを述べられて
この方は結構SPAについて最近バーっと記事を書かれてるらしいですね。
state is hardと、状態は大変だと言ってますね。
なんでSPAはwill persistなんですかと言ってます。
そういう記事もあるんですけど今回は一旦これについては
これを読むかどうか検討したいと思いますので
一旦この記事は終了しようと思います。
残りの時間は5分なんですけど
ちょいとJSAI4ですね。
AZさんがやられているJSAI4、ついに第600回の更新になったということで
いや本当にすごいですね。600回やられたんですねっていうところです。
これの更新をバーっと読んで
本当にRSSをただ僕が音読するみたいな感じになるかもしれないですけど
読んでいこうと思います。
どんな更新があったかっていうところを読んでいきますので
ここからは本当にゆるりと聞いていただければと思います。
JSAI4600回ですけど
一つ目ですね、BANというジグ言語とJavaScriptコアですね。
WebKitのJavaScriptエンジンを持っているジグ言語ですけど
を使って書かれたJavaScriptランタイムが公開されましたというものですね。
BANですね。
昨日なんか誰かが、いくつかの人?失礼ですね。
数名の方がTwitterでツイートしましたね。
BANという言語ですけど
これはAll-in-one JavaScriptランタイムというふうに公式でも書かれているんですけど
TypeScriptとかJSXのTranspiler、Bundler、TaskRunnerとかも同梱していて
NPM互換のパッケージマネージャーやノードAPIですね。
互換の実装とかフェッチなどWebAPIの実装も持っているっていうようなランタイムです。
めちゃめちゃすごいなと思いました。
ざっくりできることと読んでたんですけど
現代で必要性のあるものは大体備えているなというところがあるので
これすごいなと思いました。
立ち位置としては結構Denoと確かに似てるんですよね。
似ている立ち位置のランタイムではあるんですけど
ノード互換のAPIとかパッケージJSの扱いでNPM互換の実装を持つというところで
ノードJSを置き換えて利用できるっていうことを意識されて作られていると思います。
BANというものです。
ここもしかしたらこのBANがどんどん熟成していったときに
ノードJSを置き換えるって話は全然出てくると思います。
なのでこの辺気になりますね。
しかもパッケージJSを扱えるNPM互換の実装を持っているというところもやっぱり大きいですね。
なので今後BANに置き換えたところでNPMに挙げられている
いわゆるサードパーティーのライブラリとかいくつかっていうのをそのまま利用できるっていうことを言っているので
27:04
本当にノードJSから置き換えられる可能性はありますねっていうのが気になりました。
一方で気になるんですけどプロミス問題どうするんだっていうところだけもう1個気になりますけど
そこはまだ僕がこのBANという言語の仕様だったりとかドキュメントを読んでないのでここは気になるんですけど
一応そのBANのロードマップというのもGitHubのリポジトリに一周があるのでそこを見てみてくださいというリンクがあります。
もう1個はどのように作ったかっていうのは動画でインタビューされています。
タイトルがなかなかインパクトあるんですけど
NEXT.js was too slowとNEXTが遅ぇって言っているんですよね。
So he made BANって言ってもらってだから彼はBANを作ったんですかみたいなタイトルのYouTube動画です。
タイトルからかなりパンチがありますね。
続いてBEATですね。
BANTRAのBEATですけど3.0メジャーバージョンがリリースされましたよということですね。
リンク的にはそのBEATの公式ブログとリポジトリのチェンジログのリンクが貼られていますよということです。
今回の更新はデフォルトのビルドターゲットをESMとダイナミックインポートとインポートメタというのをサポートしているブラウザに変更になりましたよと言っています。
結構大きい変更ですね。ビルドターゲットをドカンと変えたっていうの。
あとはオプションの変更したりとか物によってはオプション削除になりましたとか。
あとはデフォルトポート5173に変更になったよという感じですね。
ポート5173の理由はちょっと気になったりしますけど、まあいいや。
あとですね、ミニファインに利用するターサーパッケージへの移動をオプショナルに変更になりました。
あとはインポートメタドットグローブとかの仕様の変更だったり、
WASMファイルのインポート方法の変更なども含まれているってところですね。
割とやっぱりメジャーバージョンアップデートなので大きい変更があったりするなってことでした。
続いて600回目の更新というところで、このJSARinfoというサイトの更新が600回になりましたと。
ありがとうございます。
ちなみに500回からの更新は大体2年くらいかかりましたって言ってますね。
いや、本当にすごい。
数年前にJSARinfoの第何百回記念版の勉強会っていうのがオフラインであったんですけど、
それも参加したんですけど、名だたるフロントエンジンの方しか来てなかったので、
やっぱJASARさんって本当にすごい人だなっていうのを改めて痛感させられたっていうイベントですね。
すみません、完全に余談でした。
じゃあ、まず600回です。
一応JSARinfoの500回目の更新のときにそれ専用の記事も書かれたりするんですけど、
今回600回のときには書かれてないので、もしかしたら書いてくれるかもしれないですけど、
今のところはないようなところですね。
JSARinfoっていうのはスラックワークスペースで色々議論をしたりコミュニケーションを取っているらしいんですね。
気になるものを投稿したりとか更新作業もそこの中でやったりしているということですね。
もちろんJSARinfo自体はGitHubでソースコード管理をしているんですけど、
議論だったり更新作業のコアなどの部分はスラックワークスペースでやっているということですね。
気になるものをメモ、投稿するぐらいの場所として扱うぐらいでいいというふうに思っていますので、
30:01
質問とか何かあったら調べて答える気もしますって言っているので、気分として答えるかもしれないという。
気になる方はスラックワークスペースが次のリンクからのでっていうところです。
あとはGitHubのスポンサーズで支援も引き続き募集してますよっていうことを言ってました。
JSARinfo周りも新しいツールが結構続々と出てきているっていうのがAZさんの印象で、
特に最近はやっぱりCDのエッジを意識したものが多いよっていうふうにおっしゃってますね。
今回公開された版も作者が1週間に80から90時間ぐらいかけて、
しかも1年間それを続けて作っているそうだと言ってますね。
これバケモンですよね。
普通に1日8時間で1週間ですよね。
休日を含めて7日間働いたとしても、8日56時間ですよね。
なんですけどこの人80から90時間ずっと続けたっていうので、
絶対十何時間毎日毎日やってるってことになりますから。
それぐらいの熱量を持って版を作ったっていうところなので、
余計に版ってどんなすごいんやっていうのは気になったりしますよね。
こういう労力を結構かけて作られている。
版だけじゃなくて今最近出ているJavaScriptのライブラリのフレームワークっていうのは、
そういうものが結構多いなっていう印象が多いというふうにAzさんおっしゃってます。
新しいツールが出てもいわゆるウェブ標準の互換性であったりとか、
NodeAPIとかNode.jsとの互換性、CDNとの互換性っていうのが結構強く意識されている感じはありますよっていうふうにしてますね。
最近特にそうかもしれないですね。
やっぱりパフォーマンス周りだろうなっていうところがすごく重要だと思うのと、
やっぱり互換性ってところかなりみんな意識してるんだろうなと思いますね。
逆に言うとその互換性があるからこそ完全に全く新しい知識を必要とするっていうものが意外と少なくなっている。
だからこそみんなが使ってくれたり導入してくれてるなっていうのは結構大きいかもしれないですね。
既存のものに対して何かフラストレーションが出回って、
それを置き換えるために新しいツールとして作りながら、
一方で既存との互換性との意識するという形式が多いような気がしますよと言ってますと。
バウンドの場合はそのフラストレーションがまさに速度というところで、
それを置き換えることを目標にして進化していったようなところでした。
一方でGoogle Chromeが巨大となり、
ウェブ標準のセントラライゼーション問題とか、
あとAppleのiOS、iPadではウェブキット以外のブラウザエンジンを許容しないみたいなことに対する反発の高まりといった問題も起きているので、
その辺もどうなんでしょうなっていうところをお話しされてますね。
いろいろ物事が大きくなっている感覚はなくはないんですけど、
それを小さな視点から見ていきたいっていうのがこのJ5というサイトだというふうにおっしゃってました。
というところですね。
30分を超えたんですけど、
あとひたすらダラダラと更新ががって述べるだけなんで、
もしお時間厳しい方は全然抜けられて大丈夫と思います。
続いてヘッドラインですね。
ヘッドラインは今回かなり少ないですね。
一つ目はさっき見ました、Beatですね。
Beatのメジャーバージョンアップ3.0が出たよというところです。
もう一個はセキュリティリリースですね。
ノードJSのセキュリティリリースが7月7日に出てますね。
33:00
今年の。
ノードJSの14、16、18と言われる安定版と言われている偶数番号のバージョンに対して
セキュリティのリリースが行われたいところなので、
皆さん多分使われていると思うので、
一旦今の使われているメジャーバージョン、
14、16、18どれか分からないですけど、
その中でマイナーリリースされているはずなんで、
そこの更新ですね。
最新版にしておくといいと思います。
続いてアーティクル、記事ですね。
記事はいくつかあるんですけど、
一つ目は応答性を示す新しい指標INPというものです。
ユーザー操作に対するインタラクションにかかった時間を計測するメトリックスであるINP。
Interaction to Next Paintというメトリックスがあるんですけど、
これについて言及されている記事ですよ。
FIDとはちょっと異なって、
ページのロード後に関する値を計測するようなものだと言ってますね。
FIDはロード前、ロードのところまでの観点に対して計測するものなので、
それとは違うというところですね。
あとはCRUXだったり、
Lighthouseのタイムスパーモードだったり、
Web Vitalsですね。
Core Web Vitalsでの計測での取り方についてなど書かれているところです。
これも結構面白そうだなと思いました。
続いてアナウンシングサポート for WASI and Cloudflare Workersですね。
クラウドフレアワーカーズでWASIに対応したWebアセンブリファイルを実行するライブラリーがサポートされたよということですね。
この辺はクラウドフレアワーカーズを使っている方は結構注目してもいいかもしれないです。
続いてアンサーブログですね。
How I Estimate NPM Package Market Shareと言ってますね。
And How Redux Usage Compares to Other Librariesですね。
NPMパッケージのシェアを読み取るかについてリアクトドステート管理ライブラリを例に解説している記事ですよと言ってます。
例えばReduxだったりとかですね。
注目している数字としてはNPMパッケージのダウンロード数とGitHubの依存数ですね。
Dependenciesの数を絶対数として見たときの問題点や総合的に見る方法についてなど結構解説しているよというところでした。
僕はこれ開いてないんですけど。
パッケージシェアについて観点を置いて注目しているのがありますが、
パッケージシェアってダウンロード数に立脚する記事は結構多いんですけど、
しっかりDependenciesの数まで見たときに問題点とか相対的に見たりして、
方法とかを解説したり注目点とかを書いてるってなかなか少ないと思うので、
これはこれでまた面白いなと思いましたね。
なんだかんだは多分プロリケーションを開発するときにどのライブラリ使いますかみたいなのを選定すると思うんですけど、
選定基準としてはダウンロード数だったり依存数だったりとか見ると思いますし、
なんだかんだ僕らの実践の場でも使うんじゃないかなと思ったりはしています。
続いて、Flutter前紙ですね。
ChromeがFlutterになるまでっていうタイトルです。
なんか面白いですね。
これ多分前の記事だから多分日本語かな。
36:01
Flutterの歴史を振り返る動画があって、それについて言及している記事だそうです。
Blynkのフォークから始まりまして、JavaScriptからDartへの切り替えだったり、
DOMからCanvasへの切り替えなどについて言及されたものだそうですね。
なかなかタイトルが面白いですね。
ChromeがFlutterになるまでっていうなかなか面白いタイトルだと思いました。
続いて、NestJs製GraphQLサーバーの起動が遅かったので調査した話という。
もうずっと田舎暮らしっていう。
多分皆さんも知ってるかもしれないブログですけど。
グラフQLのスキーマからTypeScriptのファイルを生成するツールのボトルネックを調べて修正していたよという話でした。
0xを使ったボトルネック分析だったり、
TSMorphのTypeScript、ASTの変換のパフォーマンス問題の修正についてなどなど書かれてますよということでした。
やっぱりASTまで踏み込んだ記事っていうのは結構気になりますよね。
やっぱりそういうところ技術的にコアな話であり、かなり勉強になる気がするので。
最後ですね。記事については最後です。
Executing shell commands from Node.jsですね。
Node.jsのChildProcessっていうモジュールがあるんですけど、
そのモジュールについてのコマンド実行について解説をされた記事でありますよと。
まず、SpawnとかExecの解説。また、SpawnとExecの違い。
あと、ストリームでの出力の読み取りだったり、
AbortControllerを使ったプロセスの終了と動機と非動機についてなど。
この辺結構Node.jsのコアな機能だったり観点だったりするので、
この辺が知れるようになると、
だいぶNode.jsについて詳しくなるなっていう印象があるので、
もしNode.js気になる方は読んでみてくださいってことでした。
あとはサイト、サービス、ドキュメントなどですけど、
ここは今回は2つですね。
1つ目はjcubicさんですかね。
jcubicっていうアカウント名の方ですね。
のWayneっていうようなライブラリですかね。
サービスワーカールーティングライブラリ
for in-browser-http-requestっていうタイトルになってますね。
そういうGitHubのリポジトリのリンクが貼られてます。
タイトルにある通り、サービスワーカー向けの
ルーティングライブラリを作ったりというところですね。
もう1個はTailwind-dxっていうものですけど、
これはTailwind用のChrome拡張っていうのができたっていうことですね。
TailwindのクラスをChrome DevTool上で変更したりすることができるよという話です。
これちょっとTailwind最近使われてる方多いと思うので、
そのChrome拡張を試してみていただければいいんじゃないかなと思ったりしてます。
既に使ってるよって方もいるかもしれないです。
ラストです。
ラストはソフトウェア2ライブラリ関係ですけど、
これは3つですね。大きく3つあります。
だいたいGitHubのリポジトリなんですけど、
1つ目はTypeScript JSONですね。
runtime type checkers and 5xfasterjson.stringifyですね。
json.stringifyっていうメソッドありますけど、
あれの5倍早いruntimeのタイプをチェックするものですね。
すごいことを言ってる。5倍ってすごい。
39:01
TSなどを使ったコード変換とruntimeを合わせたjsonライブラリですね。
TSの型を使ったruntimeでの型チェックだったり、
json.stringifyの相当の処理を提供するものですよって言ってます。
2つ目のライブラリは先ほど出ましたBANですね。
やはりBANです。
一応タイトルはIncredibly Fast JavaScript Runtime,
Bundler, Transpiler, and Package Managerというところですね。
とにかく早いって言ってます。
条件を述べましたけど、もう1回述べると、
JavaScriptコアとジグ言語を使って書かれたJavaScriptのruntimeですよと。
BundlerとかTSのTranspiler, TaskRunnerとかを同行して、
APM互換のパッケージマネージャーやノードAPIの互換の実装を持ってます。
あとはFetchなどのWebAPIの実装も持ってますよというところですね。
まさにこれがノードJSの置き換えになるんじゃないかみたいなところを
ちょっと注目をしたいなと思いました。
ラストですね。
ラストはPGMEMっていうものです。
Uninmemory PostgreSQL DB Instance for Your Unit Testですね。
InmemoryのPostgreエミュレーターのライブラリだと言ってますね。
いわゆるテストで使うための目的。
ユニットテストのために使うための目的に作られたような内容と言ってます。
Postgre使ってる案件があればこの辺使ってみてくださいっていうことでした。
すいません、ちょっと10分もオーバーしましたけどこれで一旦以上にしたいかなと思います。
今回のJSONインフォームはJSONインフォームかなり面白そうな記事たくさんあったので
皆さんのほうでも見てそこからリンクたどっていろいろ記事読んでみていただけたら面白いんじゃないかと思いましたね。
ところでちょっとグダグダりましたけど、
今日も朝食はこちらで一旦以上にしたいと思います。
ご参加いただいた多くの方々ありがとうございました。
明日は何をかちょっと悩んでいるのと、
明日はJavaScript祭りっていう勉強会があるんですけど、
僕それの登壇をするんですけど、今絶賛修行うわって悩んでいるので、
もしかしたらちょっと時間が足りなくてスライド作っていることに注力するかもしれないので、
もしやらなかったらそれはそれでまたツイートします。
今日金曜日ですけども、
週終わり皆さん頑張っていきましょうというところで、
こちらの朝活は締めたいと思います。
ではお疲れ様です。
