以下斜め読んだ内容

pseudo translation of useful posts, book reviews, remarks,etc. twitter: feeddict

Bryan Cantrill「Node.jsに集まりし人々」

斜め読み

The Observation Deck 2010.8.11のエントリ

The node.js demographic

2010.8.10にPalo AltoのSenchaのオフィスで開催されたNode Meetupに参加したときの感想が綴られたエントリ

  • エントリ書いてる人
    • Bryan Cantrill
    • 2010.7末からJoyentにVPとして参加。
    • 前は10年以上Sun（now Oracle)にいて、DTraceのクリエータ
以下斜め読んだ内容
//(fab)ではこんな風にかける
  ( fab )
    ( "/time", function(){ return "the time is " + (new Date).toTimeString() } )
    ( "/date", function(){ return "the date is " + (new Date).toDateString() } )
  ( fab )
  • Isaac Schlueter
  • Tim Caswell
    • How To Nodeでメインで記事書いてる人
    • Senchaにいる。
    • Senchaが開発してるhttpフレームワークConnectつかったアプリ作りのプレゼン
    • （補足）ConnectはNode.jsがマルチコア環境を活かしたNode.jsアプリを作るためのフレームワーク。multi-nodeのライバル
  • Node.jsの実用化フェーズについて界隈でよく言われてることが今回クリアーになった
    • 今後まず最初はソーシャルゲーム関連でNode.jsアプリがデプロイされていく。
      • ソーシャルゲームの開発でNode.jsが強みを持てる。
      • インタラクティブでソーシャルなゲーム開発においてNode.jsがポテンシャルを持ってる
  • ホスティングやっててNode.jsに力入れてるJoyentには好都合な状況
    • オンラインゲームのサービスで必要となるような柔軟性はクラウド屋の得意分野だから
  • 今回のmeetupで一番印象に残ったことはNode.jsに集まってきている人たち
  • node.jsは大流行してるし、jsである点が流行を広範にしてる
  • 流行してるけど、node.jsはアマチュアや素人エンジニア向けという見る人もいるのは確か。
  • 「node.jsはアマチュア向け」という見方が間違いだとはっきり認識させてくれたことがこのmeetupであった
  • このmeetupでPeter Griessと再会した
    • Peterは自分がBrown大のコンピュータサイエンス選考の授業cs169のTAのリーダーだった人
    • （補足）エントリの作者（＝Bryan Cantrill）はBrown大出身でcs169のTAもやってた。cs169はoperating systemがテーマ。
    • 感動の再会とかではなくこのmeetupで集まったエンジニアたちのように技術のことを目一杯話した
  • meetupでは多くのエンジニアがnode.jsを使いまくって経験値あげてること、実用に耐えるシステムをデプロイするという経験を積んでること、その中にはMatt Ranneyのような凄腕のエンジニアもいた。
  • あのMatt Ranneyは「昔作ったアプリ」をnode.jsで作り直していた
    • これは結構重要なこと。これは色々象徴的だから
      • node.jsはお手軽になんかソフトウェアを作れる道具という代物ではないこと
      • 他と比べてはるかに優れた実行環境であること
      • 過去に別の言語／環境で開発したシステムをnode.jsで作り直すだけの価値のある
  • このmeetupが示していることは、node.jsへ浴びせられる意味のない批判への反証になってる
  • 有益な批判もある
    • 一例としてTony Arcieriのmore enlightened criticism読め
    • 有益だが、作法のような本質的じゃないところに矛先が向かってるのが残念
  • node.jsは若いテクノロジーだしtodoリストは沢山あるのは確か
  • meetupで目の当たりにしたnode.jsについてエンジニアの経験値の高さとnode.jsコミュニティの健全でエネルギッシュな雰囲気を見ていれば、node.jsのtodoリストへも楽観的になってる

Thomas Fuchs「javascriptが原因で再フローとレンダリングが発生するケース」

斜め読み

mir.aculo.us 2010.8.17のブログエントリ
When does JavaScript trigger reflows and rendering?

以下斜め読んだ内容
  • ブラウザはシングルスレッドなので飼いならしやすい方
    • chromeはタブごとに別スレッドになるが各タブ内はシングルスレッド
  • おっちょこちょいなjs書いてるとそれが原因で再フローやレンダリングが余計発生する場合があり、それは結構ダメージになる
  • 鉄則
  • ページがカクカク・もっさりしてる？
  • よくある最適化
    • DOMツリーをバッサリ刈り取ってスッキリさせる
    • CSSのスタイルをシンプルにする
  • html/cssにこれといった問題なくてもjsに問題があることがある
  • 再フロー・レンダリングが高くつく処理といわれてもピンと来ない人
    • この動画みろ
      • wikipediaのページが例になってるが、wikipediaという比較的シンプルなレイアウトでもページの表示までに色々なことが起こってることがわかる。

http://video.google.com/videoplay?docid=-5863446593724321515&hl=en

  • js使ってcssスタイルを修正してページの表示を変えるときに起こること
    • 次のいずれかが発生することを待ってからブラウザはスタイル変更を反映させるため「待ち時間」発生
      • １：jsの実行の終了
        • 例えばイベントハンドラにセットされた関数の実行の終了
        • この場合、待ち時間短縮のためにできることはゼロ
      • ２：再フロー発生の引き金となるような処理の（ブラウザへの）リクエスト
        • この場合は最適化可能。うっかり引き金を引いている場合があるから。
  • コード例で説明
//コード例：before
//ページ内のある要素（ex.div#header）への処理
//フォントサイズを14pxに変更してみて、
//この要素の高さが100px以上だったら特定の処理を実行する
someElement.style.fontSize = "14px";
if(someElement.offsetHeight>100){ /* ... */ }//ここで再フロー発生
//この要素の左パディングを20pxに変更してみて、
//この要素の横幅が100px以上だったら特定の処理を実行
someElement.style.paddingLeft = "20px";
if(someElement.offsetWidth>100){ /* ... */ }//ここで再フロー発生
  • offsetHeight/offsetWidthプロパティへのアクセス。これが再フローの引き金になってる
    • offsetHeightへアクセス時に1回、offsetWidthへアクセス時に1回
    • この点を押さえて書き直す
//コード例：after
//先にfont-sizeとpadding-leftを変更してから、
//offsetHeight/offsetWidthプロパティへアクセスするやり方に変更
someElement.style.fontSize = "14px";
someElement.style.paddingLeft = "20px";
if(someElement.offsetHeight>100){ /* ... */ }//ここで再フロー発生
if(someElement.offsetWidth>100){ /* ... */ }//再フロー発生しない
  • 書き直すと、再フロー回数は1回に減る。
    • だいたいだけど速さは2倍になる
  • 再フローが1回に減ったわけ
    • ポイントは「ブラウザのcss変更の反映は一括で実行される」という点
    • 上のafterのコードだと3行目のoffsetHeightプロパティへのアクセスがあるまで再フローは「待ち」状態になる
    • 4行目のoffsetWidthへのアクセス時は、反映させないといけないcssスタイルの変更はゼロなので再フローは起こらない
  • 再フローの引き金はスタイル変更以外にも色々ある。
    • DOMノードの追加／削除も再フローの引き金になる
    • スタイル変更／ノードの追加・削除といった処理を（五月雨式ではなく）まとめて実行されるように、ページ上で実行したいjsのコードの最後の方に置く。
感想
  • js経由でのcss変更はまとめて反映される
    • これがこのエントリのポイントになる情報なんだけど、実際に各ブラウザがこういう動きしてるのかについてのソースをこれから探す