![http://rrlrlrll.org/dom/](https://cdn-ak-scissors.b.st-hatena.com/image/square/f9ae561dc26058c5681d9fc28a6738b774bca8ab/height=288;version=1;width=512/http%3A%2F%2Frrlrlrll.org%2Fwordpress%2Fwp-content%2Fplugins%2Fwp-ogp%2Fdefault.jpg)
2015年にもなるのにJavaScriptでのDOM操作のパフォーマンスについて書く。ウェブページにインタラクションを持たせたい時に、JavaScriptでDOM操作を行うことがよくある。このDOM操作のパフォーマンスについて、よく聞く意見を大別すると次の2つがある。 JavaScriptによるDOM操作は重たい レンダリングが重いだけで、DOM操作そのものはそれほど重たくない JavaScriptでオブジェクトのプロパティを操作したりする単体の処理は通常1ミリ秒もかからないが、DOM操作をするとレンダリングが完了するまでに数十ミリ秒程度かかったりする場合がある。1番目のDOM操作が重たいと言っている人は経験則的にそう言っていることが多い。 レンダリングの仕組みを知っている人は2番目の意見を言うが、重箱の隅をつつくような話をするとこれも必ずしも正しいわけではない。DOM操作するコードによっ
I have to be honest with you: I feel like a fraud writing about JavaScript for HTML5 Doctor. I would feel like a fraud writing about JavaScript for a click-driven ad-splattered content farm, never mind HTML5 Doctor. The thing is though, I’m writing about the classList API, and it’s super easy. If your JavaScript-fu isn’t great and you’re wary of HTML5 APIs, this one is at the perfect temperature f
これは VirtualDOM Advent Calendar 2014 に勝手に参加する記事です。 あたたかい春の昼下がりのこと、あるブラウザベンダの社内を不穏な噂が駆け巡った。 「React.js なるライブラリ、どうも仮想 DOM というやつのせいで速いらしいぞ」 もうリアルな DOM はお役御免、ブラウザも商売上がったりか・・・。雇用に不安を覚える人(私)がいる一方、 そのアイデアをとりこんでブラウザの DOM を速く出来ないかと考える人たちもいた。 仮想 DOM はなぜ速いのか。誰かのつてを辿って React.js チームにおいでいただき、速さの秘密をテックトークしてもらう。 イミュータブルなデータ構造による単純化、非同期適用による処理のバッチ化、差分アルゴリズムによる副作用の最小化… いくつかのアイデアはブラウザからはどうにもならないが、たとえば非同期化なんかは形は違えどブラウザ
virtual-domという、(その名の通り)仮想DOMの生成とdiffを行うシンプルなJavaScriptのライブラリがあります。 GitHubのexampleを見るとわかるのですが、このライブラリのみでも、シンプルな形で動的なビューを実現することができます。 このシンプルさがとても魅力的で、実際に使ってみたのですが、 分かったことをまとめたいと思います。 仮想DOMって? Reactなどで以前から採用されていて、最近流行している感じの 仮想DOM ですが、 重い本物のDOMとは別に、仮想のDOM(ただのJSオブジェクトなので軽い)のツリーを構築する 仮想DOMの構築を状態が変更されるたびに行って、前回の仮想DOMとのdiffをとって実DOMに適用する という形で動的なビューの実現に利用されます。 仮想であるので、ブラウザ上だけではなくサーバーサイドのHTMLレンダリングにも使えます。
DigitalOcean provides cloud products for every stage of your journey. Get started with $200 in free credit! A reader recently wrote in asking me what the DOM was. They said they’ve heard it mentioned and alluded to, but aren’t sure they really understand it. We can fix that. But the HTML you write is parsed by the browser and turned into the DOM. View Source just shows you the HTML that makes up t
DOM操作の最適化によるJavaScriptチューニング(前編) | HTML5Experts.jp はてなブックマーク - DOM操作の最適化によるJavaScriptチューニング(前編) | HTML5Experts.jp はてなブックマークで『後でツッコミする』と書いたとおり、ちょっとツッコミたいと思う。 ツッコミ記事のつもりが、自分がツッコミされることとなり、ダメダメな記事です。それでも良ければお読み下さいw // サンプル1: パフォーマンスが悪い var ul = document.querySelector('#output'); for ( var i = 0; i < data.length; i++ ) { ul.innerHTML += ‘<li>’ + data[i] + ‘</li>’; } 上記コードはダメなコードであり、理由は、 li要素をループが回るたびに追
<body onclick="alert ('BODY');"> <div onclick="alert ('DIV');"> <p onclick="alert ('P');">バブルスライムはにげだした!</p> </div> </body> 「バブルスライムはにげだした!」をクリックすると、それは p 要素をクリックしたことになりますから「p」がアラートされます。さらに、このクリックは div 要素内で生じたものでもあるので「div」がアラートされます。さらにさらに、そのクリックは body 要素内で生じたものでもありますから「body」がアラートされます。結局、1 回のクリックで 3 個もの onclick 属性が呼び出されることになります。では、onclick 属性を呼び出す順番はどうなっているでしょうか。これは明確に決まっています。階層的に最も深い p 要素の onclick
身近なところで話題になったので。 過去にも、「empty() とか remove() するより、DOMオブジェクトにアクセスして innerHTML = ”” した方が速いよ!」というブログエントリを投下する方が多かったのですが、「必ずAPIを使う」こと。 理由は、「メモリリークの温床だから」 GitHub で manipulation.js のソース読めば判るとおり、結構頻繁に jQuery.cleanData() が実行されてます。― jQuery.cleanData() メソッドは、data() API として独自に実装された「各要素と紐づけられるキー・バリューストア(メモリストア)」に対する処理なので、innerHTML を使う場合でも、jQuery.cleanData() を使うなら、まぁ問題無いです。 要するに、jQuery (Zeptoみたいな類似ライブラリもそう)は、常にH
(タイトル修正 DOMを高速に操作 => DOMの値を高速に更新 at Sat Mar 09 2013 15:30:09 GMT+0900 (JST)) (Skin#inject実装したのでタイトル元に戻した at Mar 09 2013 18:10:04 GMT+0900 (JST)) 若手の会で、JavaScript Hell on Earth というテーマで話してきました。 js_hell_on_earth http://www.rvl.io/mizchi/js_hell_on_earth というわけでDOM抽象ラッパーつくりました。 mizchi/skin.js · GitHub https://github.com/mizchi/skin.js 目的 クライアントサイドJSでは一回書いたら終わり、ではありません。ゲームなどのリッチなユーザー体験を提供する際、高頻度でDOMを書き換
DOM入門に仕様書を推奨する記事。 W3Cの勧告原文や和訳をあたってみれば間違いが無かろうと思いはしたものの、どうにも敷居が高くて挫折した。 適宜覚書: DOMツツキ より 私も挫折……というか、最初は仕様書を読んでも今一ピンときませんでした。使用例が載っていないからです。でも、それなら自分で「使用例」を作ってみれば良いのではないでしょうか。interface Documentなんてのが出てきたら、それを実際に参照してみたり作成してみたりするわけです。更にその「attributes」や「methods」も同様に。 何と言っても「勧告原文」をきちんと読めるようになるのが最良だと私は考えます。辛いかも知れませんが、その辛さを超えれば応用の幅が、他のアプローチによる理解に比べて比較になりません。次々新しい勧告が公開されるわけですから。 あるDOMのインターフェイスを理解しようとする際に私が必ずチ
ある種類のオブジェクトが、どんなメンバ(メソッドやプロパティ)を持つかを定義する仕組みをインタフェースと呼びます。インタフェースは Web IDL で次のように定義されます。 このインタフェース A を持つオブジェクトは、次のようなメンバを持ちます。文字列値であるプロパティ x。文字列値であるプロパティ y。文字列値を返すメソッド f(引数なし)。文字列値を返すメソッド g(引数なし)。すなわち、attribute から始まる部分はプロパティの定義、それがなければメソッドの定義です。次に、プロパティなら値の種類、メソッドなら戻り値の種類を書き、その後にそれぞれの名前を書きます。最後に、メソッドの定義の場合は括弧の中に引数定義を書きます(引数定義については後述します)。各部分はセミコロン ";" で終わります。その間に空白文字や改行文字がいくつあっても構いません。このオブジェクトを ECMA
DOM 仕様書を読む前のガイドとして、DOM のおおまかな内容と ECMAScript(JavaScript)によるごく簡単な例文を提供します。DOM Level 1 から Level 3 まで。DOM Core 入門 (1)DOM Core 入門 (2)DOM Events 入門DOM Traversal 入門DOM Range 入門DOM Load and Save 入門DOM Validation 入門DOM HTML 関連。DOM HTML 入門 (1)DOM HTML 入門 (2)DOM Views、DOM Style Sheets、DOM CSS 関連。CSSOM 入門 (1)CSSOM 入門 (2)CSSOM View 入門未勧告のもの。DOM XPath 入門DOM Abstract Schemas 入門DOM Views and Formatting 入門その他、ウェブプ
This specification contains leftover shadow DOM-related definitions which are not yet given a more permanent home in other specifications. Not an active specification Most of the Shadow DOM specification has been upstreamed to DOM [[DOM]], HTML [[HTML]], CSS Scoping [[css-scoping-1]], UI Events [[uievents]], and other relevant specifications. What remains here is stuff which has not yet been prope
If you build Web sites, you probably use Javascript libraries. If so, you are probably grateful to the nameless heroes who make these libraries not suck. One common problem these brave soldiers of the Web have to face is encapsulation. You know, one of them turtles on which the Object-Oriented Programming foundation sits, upon which stands most of the modern software engineering. How do you create
かん吉さんの記事 「遅いブログパーツを高速表示する方法」、すばらしいですネ。アフィリエイトをやっている人にとっては、とても興味を引く記事だと思います。ですが、紹介されているスクリプトは、中級以上の方が対象 とあるように、私のような初級者が知っておくべきことがあるはずです。 そこでまず私自身が中級者以上となるために、過去3回に渡り自分なりにブラウザの動作を勉強してきました。 ブラウザ動作の理解-レンダリングツリーの構築と描画のタイミング ブラウザ動作の理解-リフローとリペイント及びその最適化 ブラウザ動作の理解-レンダリングの負荷を測る そこから見えてきたのが、レンダリング・ツリー の役割りです。ブラウザの本質は、ドキュメントとその見た目 (ビュー) の管理です。前者は、文書自体やその構成の管理に責任を負い、後者は、描画について責任を負う。そして、両者のコラボレーションによりユーザーに情報を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く