JavaScriptでのDOM操作は重いのかという話とForced Synchronous Layoutについて - id:anatooのブログ
2015年にもなるのにJavaScriptでのDOM操作のパフォーマンスについて書く。ウェブページにインタラクションを持たせたい時に、JavaScriptでDOM操作を行うことがよくある。このDOM操作のパフォーマンスについて、よく聞く意見を大別すると次の2つがある。 JavaScriptによるDOM操作は重たい レンダリングが重いだけで、DOM操作そのものはそれほど重たくない JavaScriptでオブジェクトのプロパティを操作したりする単体の処理は通常1ミリ秒もかからないが、DOM操作をするとレンダリングが完了するまでに数十ミリ秒程度かかったりする場合がある。1番目のDOM操作が重たいと言っている人は経験則的にそう言っていることが多い。 レンダリングの仕組みを知っている人は2番目の意見を言うが、重箱の隅をつつくような話をするとこれも必ずしも正しいわけではない。DOM操作するコードによっ
JavaScriptをプロトタイプベースのオブジェクト指向言語と言うべきではない - id:anatooのブログ
勘違いしている方も結構多いと思ったので、これの解説。 JSをプロトタイプベースのオブジェクト指向言語って言うの誤解しか産まない気がしてきた— anatoo (@anatoo) 2015, 5月 3 ウェブ上の記事を眺めていると、JavaScriptをプロトタイプベースのオブジェクト指向言語(以下OOPと書く)と説明している例がよく散見される。この書き方は間違ってはいないかもしれないが、もはや誤解を生むだけである。 そう言う理由には、ES6からはclass構文があるため、通常のクラスベースのOOPと一切何も変わらなくなっているからというのがある。だが最も大きな理由は、JavaScriptはプロトタイプベースのOOPの中でも異端であり、本来のプロトタイプベースのOOPとはあまり似ていないからである。 JavaScriptでは、new演算子を使ってオブジェクトを生成したり、prototypeオブ
github社製ボットフレームワーク、hubotをIRCボットとして導入した話
修正: 2/10 node-cronを使ったコードの例が間違っていたので修正。 github社製のボットフレームワーク、hubotをIRCボットとして導入する話。 インストール hubotはnode.jsとcoffescriptで書かれたgithub社製のボットフレームワーク。IRCに限らず、campfireやtwitterなどいくつかのアダプタに対応しているが、ここではIRCで利用するための導入手順を記す。 あらかじめnode.jsとnpmをインストールしておいて、hubotをインストールする。 $ git clone git://github.com/github/hubot.git $ cd hubot $ npm installhubotは、ボットが扱うデータを永続化するためにredisというKVSを利用する。redisが入っていない時はエラーになるので動かす前にインストールする。
Node.jsがどうして注目されているのか、もしくはどうして他のサーバサイドJavaScriptはスルーされているのか - id:anatooのブログ
サーバサイドJavaScriptにはNode.js以前にもいくつかの実装がある。ちょっと前に注目されかけたものだと、現在はAppcelerater社に買収されたAptana社が出していたJaxerなどがあるが、きちんと調べるとRingoJsやnarwhalやv8cgiなど選択肢の一つとして数えられるサーバサイドJavaScript実装がいくつかある。ただ、これらはNode.jsのように注目を浴びているわけではない。 Node.jsとこれらの既存のサーバサイドJavaScriptの違いは、他のサーバサイドJSの動作モデルが既存のサーバサイドのものと変わらないのに対して、Node.jsの場合はそうではないから。具体的には、HTTPコネクションのハンドリング戦略が違っていて、既存の動作モデルが1コネクションに対して1プロセス/スレッド消費するのに対して、Node.jsの場合は非同期I/Oを用いて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
