Removing jQuery from GitHub.com frontend

https://gyazo.com/ac307a18402912653fe57f44d7ba9ef6

メモ

共通のDOM操作やAjax周りが無かった

jQueryはそのあたりをラップするのに便利だった

年月が経つにつれてGitHubも大きくなった

JSのサイズや品質を担当するチームもできてきた

技術的負債は返済することがポリシー

この観点でjQueryを見たとき

https://gyazo.com/654587fe2448bc3e9d6eca67f5431c17

Flowを使った

が、jQueryの連鎖構文には不向きだった

Web StandardsのAPIに書き換えた

ファイルサイズは30KB減った

ページロードの速度もアップした

いきなり全部jQueryにするのは大変

回帰テスト問題とか

まずはjQueryの使用率をモニタリングした

https://gyazo.com/3b369656ccd3248775d99e3c7b1504f3

このグラフが上がったらだめということ

ちょっとワロタ

これで既存のコードだということがひと目で分かる

代替案をみんなで考えるため

静的型チェックが非常に役立った

Rails独自のAjaxのLife cycleはフェイクのものを発火

jQueryの削除を進めると同時にカスタムビルドで不要なモジュールを消していった

IE8-9のサポートを切った

使用率をモニタリングし、しきい値を切ったタイミングで

As part of our refined approach to building frontend features on GitHub.com, we focused on getting away with regular HTML foundation as much as we could, and only adding JavaScript behaviors as progressive enhancement. As a result, even those web forms and other UI elements that were enhanced using JS would usually also work with JavaScript disabled in the browser. In some cases, we were able to delete certain legacy behaviors altogether instead of having to rewrite them in vanilla JS.

この英文が分からない…

ライブラリのダウンロードが不要

v0のときはあまり投資しなかった

v1になってから本格的に使い始めた

今後

polyfillはパフォーマンスに影響出るのでプロダクションで使いたくない

本当に必要なときにしか使わない

感想

未来を見据えて＆パフォーマンスやファイルサイズにこだわりまくってブラウザのnative APIしか選択しないのは素晴らしい