1. まとめトップ

dev.to 、ServiceWorker抜き(Safari)でみても速いってことはSWは本質的ではないな。

いや真面目に、dev.to をさんざん触ったとに、dev.toに行こうと別サイトとかに貼られたリンククリックしたら、リンクのリダイレクトの遷移時間が大きすぎてバグったのかなという体験になる。 どんな何かよりもまずはスピードis神という基本原則を思い出させてくれるね。

dev.to みたいに autopagerize (死語?) するページ、一番下の会社概要読めないのでなんとかして欲しい。

dev.to は fastly と ServiceWorker のオフラインキャッシュと先読みの合せ技ですね

dev.to を見たCTOが「やっぱり時代はホームページビルダーなんですよー」を連呼していて心配になってきた

dev.to マジでヤバイ。日経もやばいけど比じゃない

フロントエンド開発、作りはじめの最初は dev.to ぐらい速くて、どんどん機能要件が足されて理想から遠くなっていくんだけど、あくまで速度が第一でそれ以外は数値出して言え、みたいな感じが通れば dev.to みたいなウェブサイトを作ることは可能だが、皆それなりに苦労する

dev.to リンクにホバーした時点でページを読みに行ってる。相当アグレッシブな先読み。

dev.to から外部サイトに遷移するとうわおっそ!!! 帯域制限かな!?!?!? ってなるけれど当然そんなわけはなくむしろこれが従来の WEB 体験であって、

dev.to、閲覧体験における「気持ちよさ」が不足しているので皆さん高速化ブームがピークまできたら次はそれですよ

dev.to あまりにも速すぎて全てのサイトが過去になってる

dev.to マウスカーソル合わせると裏でService Workerでfetch走るの光の速度の向こう側を俺らに見せようとしてくれて最高にかっこいい。

dev.to確かにTwitterではほぼみんな速いしか言ってなくて内容に言及してる人少なめに見えるが、速いしか言わせないほど速いのやばいな

dev.to のおかげで、 サービスワーカーを導入するとこんなに早くできますっていうアプローチができるようになった。

dev.toを見てわかるのは速さの大切さももちろんだけど、以前から言ってるインタラクションの重要さも実感できると思ってて、今まではロードのプログレスバーが遷移を明確化してたけどちゃんとアニメーションなりを入れてやらないと速いだけだとただ不恰好になるというのも理解して欲しい

dev.to は、やるべきことを全部やったらweb browsingがどんだけ快適になるか、という事実を見せるという1点ですばらしい価値があるなという気がする

1