OSCON 2014: How Instagram.com Works; Pete Huntの要点まとめ

Webでやる理由

このアプリ全盛期にあえてWebでサービスを提供しているその理由は、

• パフォーマンスがいいからではなく、
• ぐぐらびりてぃのためでもなく、
• アプリでもモバイルでもPCでも、ユーザーの利用環境を問わず提供できるから

どうつくるか

Webページをユーザーに届ける方法はいくつかって、

• 従来型のサーバーサイドで全部レンダリングして返す
• ページ内をいくつかのパーツ(Pageletって呼んでた)に区切って、それぞれレンダリングしたページを返す
• JavaScriptでAPI叩いてページ組み立てる(いわゆるSinglePageApp)

この中でいわゆるUXが一番良いのは3番目。
なので、SinglePageAppで作ってる。

どう届けるか

全ファイルを1ファイルにするのはもはや悪手。
Instagramでは9.5MB(gzipで2.5MB)にもなるので、モバイルだとやはり酷。

SinglePageAppのPageとは、EntryPointのことであって、サービス全体のことではない。

そのEntryPointごとにファイルを分けるのが良い。
ライブラリなど、共通のファイルは共通のファイルとして固めておく。

モジュール化

ベタで依存関係を考慮しつつ書いていくのはつらいので、なんかしらModuleシステム使おう。
意識すべきは「モジュール化」とその「依存関係」。

CommonJSライクなのがわかりやすくて良いし、
そういうシステムがあれば、依存関係を気にしないで済む。

そして、モジュールは必要な時に非同期で取得。
Cssであっても非同期にrequire()する。
.coffeeも.tsも。

最終的に「ファイル」を読み込ませて利用するという考え方ではなく、
必要な「モジュール」を依存関係に沿って随時ロードするって考え方でやってる。

Instagramではwebpack使ってる。

Css

JavaScriptだけでSinglePageAppは作れなくて、Cssもちゃんとする必要ある。

• タグセレクタとか汎用的なクラス名はダメ
• 読み込み順で上書きされるようなセレクタもダメ

こういうのが蔓延すると、あとでメンテしようとしてもこのクラス使われてんの・・？状態になる。

Instagram流のルールとしては、

• igUserProfileAvatorみたくカッチリ命名
• CSSとはいえカスケードしない！1セレクタ！
• 1要素には3クラスついてたら、その3クラスはそれぞれ別の内容

みんなwebpack使おう

browserifyもrequirejsも、巨大なファイルを提供するだけ。
grunt/gulpも、テストとか動かすには良いけど、そもそもファイルでしかコードを提供できない。

今ある中では、webpackが色々賢くて良い。
Requirejsからwebpackに置き換えたら、ロードパフォーマンス2倍になった。

Howtoつくったよ！

petehunt/webpack-howto

Twitterもやってるよ！

Pete Hunt(floydophone)さん | Twitter