なぜ dev.to がこんなにも速く、こんなにも自分にとって感動的なのか

最初にいっておく。これは負け惜しみだ。

SPAとPWAの現状

自分は日本でReactの勝手エヴァンジェリストみたいなことをやっていて、SPAの重めのコンテンツをよく作ってるからか、「お前らフロントエンドを物事をややこしくして、重いページを量産してウェブを劣化させてるじゃないか！」みたいな批判を、名指しでよく受ける。なんで僕にいうかわからないけど、React = SPA みたいなイメージでスケープゴートにされてるんだろう。それはまあいい。

自分の仕事でSPA技術を使うところは、ちゃんと必要性もあるし理由も説明できる。ただ、やはり近年の複雑化/重量化について思うところはあるので、逆に振って AMP/PWA という選択肢を持っておきたくて、正直言うと依頼されたR&Dの仕事でもあったんだけど、一通り覚えた。なんだけど、今のところ仕事で使うタイミングがない。

PWA技術を仕事で使えなかった理由として、やはり新しい技術だから枯れてないのは勿論、既存のものと同時に運用するのが難しいって点が大きい。AMPは技術制約の極地として、PWAをフルに活用するにはHTTP/2 や ServiceWorker の導入などをしつつ、ユーザートラッキングを作り直し、セッション管理をやり直し、レガシーな技術を切り捨てないと恩恵に預かることが難しい。正直のところ既存のものからアップデートは厳しく、スクラッチしかない。結局話題になってた日経新聞の https://r.nikkei.com もスクラッチだ。

もう一つ、PWA技術は結局、回線が細くメモリも弱い Android Chrome の体験を最大化する手法でしかなく、日本のマーケットにそぐわないのではないか、という懸念があった。Google がなんと言おうとそうだと思っていた。しかし、これは dev.to の体験によって思い込みを破壊された。

なぜ dev.to かすごいか

dev.to は速い。PRPLパターンの導入ってのは新しいが、それ以外はオンマウスの先読み含め既知の技術で単にやることやった上で、コンテンツ遅くさせる要素を一切入れない判断をしているのが良い。速さを第一に設計したからこそあれがある。たぶん他のあらゆるものを切り捨てて、パフォーマンスを最重要KPIにしないと実現できない世界だ。

たとえばソーシャルウィジェットが一切ない。Facebook や Twitter への投稿ボタンがない。導入したことがある人はわかると思うけど、あいつらとにかく不安定で読み込みが遅くて、こっちの最適化への努力を無駄にすることにかけては天才的だ。また、その需要の多さも我々を悩ませる。

フロントエンドエンジニアとして、dev.to ぐらいの速さは日頃自分の手元で体験してはいる。開発時は爆速だったウェブサイトが、ソーシャルウィジェットと営業が持ってきた謎のアドとユーザーサポートのための謎SDKで驚きの重さに！ってのが日常の風景で、いつも諦めてるけど諦めなかった先にこれがあると思うと、説得を頑張ろうと思う気持ちが多少出てくる。

そう、 dev.to の何が一番いいかって、画面領域を占めるサイズとその遷移が派手なんだ。派手だから説得材料になる。速さは最高のUXの土台で、フロントエンドに求められるものはそれだ。だからこれを目指すべきだ。これが当然のレベルで求められるようになって初めて、フロントエンドエンジニアが今まで培った技術の本領を発揮する土俵が整う。

今までのウェブは偽物だった。そう言える時代がもうすぐ来る。

…dev.toはユーザーが混乱するほどに速いので、遷移アニメーションなりを挟んでアフォーダンスを確保すべきだが。

dev.to を自分で作る

dev.to はそもそも特殊技術な技術ではない、ということを示すデモを作った。

https://mizchi-playground.firebaseapp.com/

SSR+ServiceWorker onfetch 割り込みでhtmlのキャッシュ送信で画面遷移。

lighthouse での点数、100点。

まあ、なにもないので無は100点という言い方も出来るかもしれないが、どんなウェブサイトも、生まれたときは速かった。あとはこれを維持するだけだ。そしてそれがどんなに難しいことか！

やったことは、軽量reactであるところの preact のツール、 preact-cli が PRPL をサポートを謳っていたので、これを firebase hosting に投げただけだ。フロントエンドの土台としては SSR+PRPL+Fastlyのdev.to とほとんど変わらない。明言されていないが、firebase hosting のアセット配信のヘッダが fastly なのは有名な話である。Google なのに。

$ npm install -g preact-cli
$ npm install -g firebase-tools
$ preact create default myprpl
$ cd myprpl
$ preact build -p
$ firebase init # firebase hosting で build ディレクトリを指定
$ firebase deploy

発行したコマンドととしてもほぼこれだけである。react はやはりこの用途だと重いので、preact を使うのがいいと思う。生成されるコードはなかなか興味深いので読んでみるといい。

PWAに投資すべきか

PWA技術は、既存の複雑さは排しつつ、別の複雑さを持ち込んでいる点は否めない。そして現在はGoogle主導すぎて、Apple(Safari)の出方が不明で、また ここで土台となるべき WebComponents方面では Google と Mozilla の仕様を巡る対立がある。そこの政治的な駆け引きに左右されるだろう。

とはいえ、自分の定点観測だと、webkit に ServiceWorker の fetch が実装されたのは確認済みなので、来年の11月のSafariのメジャーリリースには乗るんじゃないだろうか、という見通しをしている。

https://github.com/WebKit/webkit/commit/c7c21c947e6071cd6746fa15cbf8cb228eeb2897#diff-86bd2c027490094de3f06c3f27f9a923

あと自明のことだが、toBはともかく、toCではデスクトップウェブは死につつあり、モバイルが全てという世界は割と近い。プログラマとしては悲しいことだが、IEのことを忘れられると思うと、悲観するばかりでもない。

Node.js が一発当たる時代

最後に、この記事であえて避けてきた話をする。「ウェブサイトの支配的なチューニングってクエリチューニングじゃん」みたいな話である。それはそうだ。あくまでこの記事はSPA技術でブラウザのタブのリフレッシュを避けながら、通信速度が常に1s未満だと仮定すれば、この体験が実現できる。

正直、1s未満ってのはクエリがどうこうという世界ではなく、ラストワンマイルのことも考えるとRedisなどのインメモリキャッシュをどう扱うかって世界になる。クラサバでロジックを持ってキャッシュコントロールしつつ複雑なロジックを持ったHTML/JSONを生成するのにはサーバーでクライアントをエミュレーションをする isomorphism が必要で、それが可能なのは今のところ Node.js だけだ。この前SSRのキャッシュミドルウェアを作る仕事をしたが、結局 Redux の store を組み立てて redis にキャッシュしていた。そんな話。

とはいえBFFとしてNodeを置いたとしても、SQLを触るのは結局別の言語の方がいいと思うし(やっぱりNodeはデータモデリングやビジネスロジックをうまく記述できる言語ではない)、graphql などのプロトコルでマイクロサービスに分解した方がいいだろう。

Node.jsエンジニアに言いたいのは、せめてこの分野でシェアを取らないと今後一生Railsに勝てないからな！

まとめ

• dev.to は猛烈に速いが再現可能な技術である
• いかに速くするか、ではなく、いかに遅いものを排するか、が決め手になる
• PWAに投資する価値はある。間違いなく。 dev.to はその説得材料に使える。
• node.js 勢はここで一発ツールチェイン当てる努力をするぞ！

参考

• https://github.com/developit/preact-cli
• https://developers.google.com/web/fundamentals/performance/prpl-pattern/?hl=ja