00:06
はい、1月18日、水曜日ですね。
時刻は朝9時17分まわりました。
すいません、今日もですね、盛大にWebを押してしまいまして、こんな時間になりました。
はい、おはようございます。夢見のkeethと桑原です。
では、本日も朝から始めていきたいと思います。
本日はですね、昨日の配信でも言った通りですけど、タイトルも
「The Developer Experience Bait-and-Switch」という記事を読んでいこうと思います。
はい、あんまほかならぬ水辻さんが書かれた、前に書かれた記事の中で引用されていて、
僕はそこで初めて知ったんですけど、とても素晴らしい記事だということなので、
以前別のところで実は読んでいるんですけど、改めてもう1回ここでも読み直して復習したいなと思ったので、
それを読んでいこうと思っております。
じゃあ、いきたいと思います。
まず、TLDRですね。
私たちは、現在のように多くのJavaScriptを使い続けることはできませんし、
ウェブが反映することも期待できません。
同時にほとんどの開発者というのはJSの仕様に何の制約も感じていません。
手遅れになるまではということですね。
で、軽量で効果的なツールはここにあるのに、私たちはレトリックなマンネリ化から抜け出せないでいます。
開発者の経験についての会話をリセットし、JSの非対照的なコストを考慮する必要というのがありますよと。
で、JavaScriptはウェブのCO2だと言っています。
なるほどね。
必要ではあるけど、多すぎると人が死ぬというところですよね。
私たちはその一部を必要としていますが、多すぎるとエコシステム全体が危険にさらされています。
で、最も多く排出する人は生態系が崩壊するまでその影響を受けることから最も実は遠いところにいます。
排出する側の人は崩壊するまで実は影響を受けないというところにいますね。
JSの排出をコントロールしない限りコンピューティングが向かう市場やフォームファクターでウェブが成功することはないでしょうと言っています。
うーん、なかなか鋭いことをおっしゃられているような気がしますね。
確かに。
生み出す側の人って影響を完全に受けないわけではないですけど、そこから遠い方にいますよね。
影響を与える側に回っているわけですからね。
このような厳しい状況の中、JS志向の開発コストに関する会話には、開発者の価値をユーザーの価値に置き換えるという修理的な表現が見られます。
最近のいくつかの会話から、わら人形を構成したものを紹介しましょうと。
最近出てますけど、この記事は2018年の9月11日に公開された記事になりますね。
紹介の内容ですけど、これらのツールのおかげで、より早く開発できるようになりました。
これらのツールのおかげで、より早く開発することができ、より良い体験を提供することができます。
もしパフォーマンスが問題なら、サーバーサイドレンダリングでプログレッシブエンハンスメントを行うことができますよと。
プログレッシブだけど、サーバーサイドレンダリングにはそれでいろんな制約だったり、別の課題が出てきたりしますけどね。
03:08
この議論というのは、善意や開発者の価値、より早く動く、より複雑でないというものを価値だと言っている人たちの
ユーザーの生活体験に関する疑問とすり替えるものでございますよと。
また、根拠もなくそうする傾向もあります。
私たちは善意の人々だけが結果の軌跡について質問されることがなければ、全てがうまくいくと信じるようにと言われていますよと。
最も残念なことに、この代替案というのは、その影響に対処する余裕が最もない人々を犠牲にして、利益を得る立場にある人々の好みを保護するために頻繁に提示されます。
汚染者は排出のコストに焦点を当てない会話を非常に好みますと。
まあまあまあ、なんていうか結構ビジネス観点ではあるんですけどても言うて、余裕がないからこそそこにつけ込まれるみたいなところも正直ありますよね。
難しい話ではあるが。
皮肉じゃないですけど、これ結構鋭い指摘なんだろうなと思います。
とはいえ、まあとはいえな話も実際あったりはしますけどね。
では、この議論の背景には名目上共有されている一連の価値観に人々が異なる重みを与えているということがありますよと。
その重みというのが主に3つです。
1つ目は普遍性とアクセシビリティ。2つ目に忠実性と豊かさ。3つ目に競争力のあるあるいは優れた政策コストですと。
開発者エキスペアレンスという囮商法ですね。バイトイン&スイッチ囮商法というのは、
開発者や管理職というリスナーの偏狭な関心に訴えあるカテゴリーでの優位性を主張することで、他のカテゴリーを会話から排除することで機能しますと。
このすり替えは開発者のために物事を良くすることで、最終的にユーザーも同等の利益を得られるとほのめかすことで実行されます。
開発者はエンドユーザーやマネージャーと同じ共同で同じ目線を共有しているというのが暗黙の了解になっていますと。
これは真実じゃないよねという感じがします。
真実のユーザー体験からチームレベルの利点に話を移すと、エンドユーザーやビジネスではなく開発者に焦点と注意が向けられるという文化が生まれますと。
ん?実際のユーザー体験からチームレベルの利点に話を移すと、エンドユーザーやビジネスではなく開発者に焦点と注意が向ける。
はいはいわかりました。
当然ながらそうなるとチームはツールを目標に置き換えることになります。
まあ確かにそれはそうなんですよね。
でも目的はツールじゃないんですよね。
ツールはあくまでツール道具であって、やりたいこと実現したいことの手段でしかないんですよね本当はね。
特に開発者がコンピューターに関する高価な知識を持つという特権的な立場からコストを外部化することが許される場合、これは予想された結果であります。
そしてそうなってしまうんですよと。
私が出会ったチームの中でユーザーの実際の体験に関連する実用的な指標を持っているチームはほとんどありませんでした。
06:04
Google製品を含め遅延のリグレッションのためにローンチューをブロックできるような目標を持っているチームの数は片手で数えられるほどです。
最近のフロントエンドのショップではほぼ全ての開発者が手遅れになるまでパフォーマンスの制約を経験しません。
これはですね、ある種フレームワークとかツールだったりとかライブラリとかの技術の進化が伴ってきて、
そもそも普通に作るだけでもそんなにパフォーマンス悪化しないみたいなことはよくあると思いますね。
悪化する場合って基本的に多分画面上の情報設計だったりデータの量ですね、
保持しなきゃいけない、フロント側で保持しなきゃいけないデータの量が多すぎたりとか、
ドムの要素が多すぎたりとかですね、っていうところになってきたりするので、
ちゃんと作ってたり、ちゃんとデータの制限したりとか情報設計してるんであれば、
そもそもそんなパフォーマンスがやばいみたいな話になることがそんなないんじゃないかなと思いますね。
とはいえ、そもそも作りながら途中でパフォーマンスを常に見ながら実装してる人もどれだけいるのかっていうと、
それは結構疑問で、みんな作ってある程度の機能であったり、画面単位ぐらいまでできて、
じゃあパフォーマンス測りましょうみたいな感じになると思うんですよね。
つまり後からパフォーマンスの制約だったりっていうか、
劣化、悪化みたいなところは意識しないっていうのはよくある話だと思います。
すみません、余談でした。
そんな感じでパフォーマンスが悪くてビジネスに支障が来たすまでは基本的にはブレーキはかからないんですよねってところです。
まあそういうもんだよねって感じですけど。
もしウェブを既存の裕福なウェブユーザーという固定市場に対応するための方法と考えるんであれば、
リッチで低い制作コストに偏るっていうのは合理的ですと。
一方我々の主要な課題っていうのがコンピューティング全体の成長とともに、
ウェブを成長させることであるならば、コンテンツに合理的にアクセスする能力の優先順位というのが上がります。
もしあなたがほとんどのユーザーにとってほとんどのウェブ体験が使い物にならないために、
ウェブの未来が危機に瀕していると考えているのであれば、
阻害されたユーザーにとって明白な利益と結びつかない開発者の快適さの議論っていうのは、
せいぜい検討次第なものでしかないでしょうと。
まあそうだよね。
大々にしてこれはよくある話なんですけど。
ちょっとグラフが一枚パッと画像が貼られてますね。
これらの勢力間の競争っていうのは、イメージマップとテーブルのレイアウトに関する議論と同じぐらい古いものですよ。
新しいもののJavaScriptは、つまり私たちが問題解決するために適用している量ですと言ってます。
一つ貼られているグラフはですね、横軸に年代が貼られてますね。
2011年から2018年、ちょっと過ぎ前みたいなところですけど。
縦軸にJavaScriptバイティーズなので、しかも括弧キロバイトですね。
ということは縦軸にJavaScriptの容量と言ってますね。
今言ったやつですけども。
ちょっと途中までパフォーマンスの話をしてたから、データの容量が大きければ大きいほどパフォーマンスは下がるけど、
09:01
そのパフォーマンスを気にしないまま無邪気にどんどんJavaScriptを追加していった結果みたいな話をしてるような気がしてますね。
では戻りまして。
お、NEVさんですね。おはようございます。ご参加いただきありがとうございます。
というかご無沙汰してますね。
今日もダラダラと記事を読んでます。
続けていきますね。
以前ですね、JavaScriptがブラウザで何かを達成するために最も効果の方法であるという理由を説明しましたけど、
これはコンピューティングに関する進化した事実。
全てがモバイル化し、そのほとんどがAndroidで、ハイエンドデバイスではないと。
日本ではまだiPhoneが若干多かった気がしますけど、世界はAndroidですよね。
そういう事実に寄り添う試みと結びついたものになります。
私が望むのは、これらのアイディアを結びつけてくれる人なら、
誰でも私たちにはこれまで通り続ける余裕がないということを理解してくれるだろうと言ってます。
予算を組む必要もありますよと。
キャップ&トレード方式でJSを導入しなければなりません。
私たちがスクリプトで壊してしまったものを直すにはそれ以外の方法はないと。
スクリプトで壊したものはスクリプトで直すしかないと言ってますね。
それは結構ありがちな話だと思うし。
それがいいんじゃないかなと、なんとなく思います。
このメッセージが特定の方面で根付いたという肯定的な兆候というのはありましたが、
一般的にダイナミックを変えるには至っていません。
ポリマーだったり、リアクト、スベルト、アイオニック、ビューみたいな、
より少ないJSをデフォルトで送信するために必要な構造を提供するコンパニオン、
いわゆるスターターキットみたいなものですね。
またはCLIツールを作成するという、
英雄的努力にもかかわらず、例年と同じくらい多くのまたはそれ以上のJSヘビーパフォーマンス災害が
平均月に私の机を横切っていきますと。
この記事2018年なんですけど、その時にすでにスベルトとかビューみたいな話はずっとされてたというのは結構いい話ですね。
2018年のビューってかなりバージョンまだまだ新しい方で、古い方か。
そんなにまだ熟成してない頃なんですけど、その時にすでにこの方海外の方ですけど、
そういう最新ツールをしっかりキャッチアップしてたというところは、
そこはしっかり学んでいかなきゃいけないというか見習わなきゃいけないなと思いましたね。
2018年にビューとスベルトされてたというのは結構びっくりですね。
余談ですけど。
この人はいろんな努力をしているにもかかわらず、結局JSのヘビーパフォーマンス災害というのが
毎月毎月自分のところに降ってくるみたいな話をしてますね。
これは本当によくある話です。
そしてフレームワークのマーケティングというのは未だに修正されることなく続いていきます。
人気のあるツールのランディングページでは脈々なくスピードについて語られています。
これもよくある話ですよね。
何のためにスピードとかパフォーマンス改善するのというところですけど、
実は問題じゃなかったりする時もあったりしますからね。
WPTの痕跡とかを議論に持ち込む人は比較的少ない。
開発者エクスペリエンスを脈々なくアピールします。
私たちはどのようなユーザーにサービスを提供するつもりなのだろうか。
全ての人でしょうか。
それとも少数の裕福な人たちに提供するのでしょうか。
12:03
トレースの収集と公開がかつてないほど容易になった2018年のJavaScriptコミュニティで、
グローバルなベースラインに対するトレースだったり、
そのベースラインがなぜ不適切なのかの説明なしにパフォーマンスに関する議論を行うことは明らかに可能ではあります。
おとり商法はまだまだ有効であり、それはとんでもない問題になります。
おとり商法はビジネス側にやりやすいですからね。
そしてJavaScriptは結構ビジネス側に近いところで仕事をするから、
余計に影響を受けるんじゃないかという感覚はありますね。
おそらく私がサイトーナーの同意なしに分析結果を掲載しないという方針を取っているため、
私の主張は効果的ではなかったのでしょう。
このため私はデータなしの対談者と同様にキッチンの紙剃りによる批判を受ける可能性があります。
その証拠に今までにないほど簡単に収集することができ、
その集計結果というのは冷ややかな絵を描いています。
しかし集合体は具体的で引用可能な事件ではないですよ。
ロードの遅い1ページのビデオというのは直感的に理解できますが、
抽象的なグラフはそうではないよということですね。
まあそうだよね。
グラフで見たからといってそこが伝わるかというとそれはまだ難しい話なんですけど。
その多くというのはビジネスに重大かつマイナスの影響を及ぼしています。
まともなヘッジファンドの戦略というのはプライベートなWPTインスタンスを走らせ、
商業目的のサイトのJSの被害家とTTIを追跡して、
唯一の真のフレームワークで全てを書き直したために逆行する企業を空売りすることになるでしょう。
その証拠を目の当たりにすると恐怖を覚えますけど、
チームと一緒に舞台裏で仕事をしながら展開される惨状を大まかに描く以上のことはできません。
一つだけ例外があります。それは公共部門ですよと言って、
特に私が税金を納めている国の公共部門、現在ではアメリカとイギリスがその対象になりますけど、
もっと包括的な例外を認めるよう説得することも可能でしょう。
しかしその目的は低賃金で懸命に働いている立派な人々をバカにしたり恥ずかしめたりすることではない。
むしろモダンなフロントエンドがウェブのアクセシビリティに何をもたらしているかというのを実証することです。
従来のアクセシビリティの意味ではなく、このサイトに行くことは想定されるユーザーにとって妥当なのかという意味の方のアクセシビリティだと言っています。
いわゆるA11倍の方ではないですよということですね。
つまり私が共有できないデータの代用品としてこの話をすることになります。
幸運なことにアメリカ政府調達省というところがあるんですけど、そことイギリス政府のデジタルサービスの優秀な人々が
政府調達の暴走の最悪の例の多くを一掃してくれましたと。
へー、それは良い話じゃん。
私の目的はこの波外れた業績から何かを損ねることではありませんと。
その代わりに私が望むのは具体的な結果とその圧倒的な量を示すことで何が間違っているのか
データを使ってそして広く引用してより具体的に話すことができるようになることです。
15:03
全ての人にサービスを提供しようとするときに上手く構築することが何を意味するかを語ることで
企業がいかに的外れなことをしているか、JS中心の開発における共通の根本原因がなぜ有害であるかというのを示すことができればという風に願っています。
そしてその分析が公共部門のサービスを浄化するのに役立つのであればまあまあなおさるですよという話ですね。
これっていうのはプランAではないんですが、16年のCDSの話でもみんなをあんなに怒らせたものではありません。
コミュニティとしてプラットフォームとしてこのような状態になっていることが嫌なんですよね。
このままJSのコミュニティから添えになるのもまあ嫌です。それはそうだよね。
私たちにはツールが必要です。フレームワークももちろん必要です。
しかしユーザーエクスペリエンスを根本的に損なうことなく、より良い開発者体験を提供するかどうかで判断する必要もあります。
私たちはJSニュートラル、あるいは私の好みではTime to Interactive Neutral or Negativeなツールを手に入れなければならないという風に言っています。
フレームワークやツールというのは小さな言語で、再現性のある説明でどのように低予算の体験を提供するか、
予算コストの後にどれだけの余地があるか、どのデバイスやネットワークでそのツールが適切か明確に説明する必要がありますよと。
これは多くの一般的なツールがプロトタイピングに追いやられてしまうことを意味していますが、それはそれで別にいいんだよと言っていますね。
プロトタイピングがちゃんとできるのであればそれはいいと思いますけど、追いやられるというところが悲しい現実ではありますね。
ただ、この人は一旦それはそれでいいという風に言っているんですね。
これはまさにプランDもしくはあるいはEであると、そこまでプランニングしていることはそうそうない気がしますけど、公共部門ならあるかもしれないですね。
しかし機器は現実であり避けられないものではないと。
外製的でもないし、私たちはそれを作り出して解決することもできます。
結構そうやってちゃんと団結してくれるなら安心ではありますよね。
この機器を解決するには開発者エクスペリエンスという囮情報に立ち向かう必要があります。
この記事のタイトルに根本的に向き合う必要があります。
最も貧しいユーザーが幸福な開発者に支払う費用を負担するようなツールはもちろんデタラメですよ。
より良いものにするために私たちは会話に証拠に基づく足場を作る必要がありますよ。
私の立場に対して人々が行う議論というのがデータに基づいたものであればよかったんですけど、
現実はなかなかそうじゃない。いくらでも口はあるのですから。
ある会社が市場分析をしていて年少10万ドル以上のユーザーや企業内のユーザーにリサーチすることだけを考えているのかもしれません。
もしかしたら研究によってインタラクティブ性は画面上のビットの取得ほどに価値がないことが証明されるかもしれません。
いわゆる通常のSSRの議論ですね。
あるいはより可能性が高いのは認知ですね。
画面上のビットというものの認知がおそらくスキャンによる予想以上の量の近くの水増しを買っているということですね。
おそらくグローバルなネットワークの状況が劇的に変化しているためクライアントサイトのJS実行時間の予算というのが増加しているんでしょう。
18:05
CPUの中央値の向上が実現するのは早くても2021年頃と思われますが、それよりもずっと早い時期に実現するかもしれません。
2023年現在はどこまでこれが実現したかわからないですけど、少なくとも昔よりはだいぶ早くなったと思いますし、向上したと思いますね。
そういうのもあって開発者としてはなかなか開発中にパフォーマンスの話とかも意識することは結構なくなったと思いますが、
現実の皆さんの端末がどこまで早くなったかというのはまた議論の余地がありますね。
特にこの国は一度使ったというより一度購入したものをなかなか買い換えるってそうそうないですからね。
もっと言うと政府官公庁とかそういうことはほとんどしないので、なかなか課題は大きいと思いますが。
まあでもハードウェアレベルの方とかCPUの改善でもいろんなものは解決してくるのでね。
しかし私たちはまだそのような会話をしていません。
そして私たちが開発者エクスプライデンスという劣る情報を特定し罵倒し終わらせるまではそのような会話をするつもりはないんですよと。
というところでこの記事は締められておりました。
中小的なものだったりビジネス観点だったりとかですね。
いろんな要素を取り込んだ記事であったので、
資産に富んだものではあるんですけどちょっと僕の今のレベルだと難しいなと思っちゃいました。
とはいえでもすごく共感するものはあるし、このお話っていうのは今もやっぱりまだまだ続いてるなっていうのはある。
今もっていうか今後も続くんだろうなっていう話はあるので、
やっぱり市開発者としてどういう観点で成長していくかっていうところの一つの観点にこれを持ってくるのがいい話かなというふうには感じましたね。
というところでちょっと30分オーバーしてしまいましたけど、
今日の朝勝はこちらで以上にしたいと思います。
今年もですね僕のまだ年の目標だったり方針だったりやりたいことっていうのをまだ決めてないんですけど、
その辺決め次第ちょっと今年の朝勝で読む記事っていうのはまたちょっと経路を変えるかもしれないなと思いました。
それでも興味ある方は来ていただければ幸いです。
基本的にはフロントエンドの周りの勉強になることはあまり変わらないんですけど、
先にざっくり言うと今年やりたい技術っていうのが大きく2つあって、
ウェブパフォーマンスの改善の話と、
非機能用件周りで若干セキュリティーの話と、
あとはやっぱりウェブ3が来ることはもう間違いないし、
ジェネレティブAIですね。
チャットGBTだったり画像生成のミッドナイトでしたっけ、
みたいなものが発生するので、
その裏の根本的に使われているツールとかの技術は何なのかっていうところがちょっと気になっているので、
その辺を読もうかなと思ったりしています。
どこまでいけるかわかんないですけどね。
まあいいやっていうところで今日は水曜日ですね。
1週間中日ですけど、また今日も一日頑張っていけたらなと思います。
それでは朝勝終了したいと思います。
お疲れ様でした。
