Display Locking によるレンダリングの最適化と Async DOM | blog.jxck.io
Intro React や lit-html などにより、DOM 操作の抽象化に加えて最適化が提供されることが一般的となった。 見方を変えれば、本来ブラウザがやるような最適化を、ライブラリが肩代わりしていると捉えることもできる。 これは、現在の標準 API には、規模が大きく処理が複雑なアプリケーションを開発する際に、足りてないものがあると考えることが可能だ。 課題の 1 つとして「DOM 操作が同期処理である」という点に着目し、Async DOM という文脈でいくつかの提案が行われた。 今回は、その提案の 1 つであり Chrome で実装が進んでいる Display Locking について現状を解説する。 現状の DOM 操作の課題 まず、以下のような処理を考える。 body.appendChild($div) この処理が JS の途中で出現すれば、その瞬間 Window にある D
自作フレームワークをつくって学ぶ 仮想DOM実践入門
昨今の代表的なJavaScriptフレームワーク（React、Vue.jsなど）には「仮想DOM（Virtual DOM）」という概念が採用されているので、フロントエンド界隈の人は一度は耳にしたことがあるだろう。ただ、仮想DOMについて学ぼうと検索してもヒットするのは「フレームワークの使い方」ばかり。踏み込んでいても概念の説明どまりで、仮想DOMがどのように実装されているか解説した記事はすくない。 ということで、当記事では理解を深めるために仮想DOMを使ったフレームワークを自作し、仮想DOMに入門する！ そして、ReactやVue.jsを単なるブラックボックスのフレームワークではなく、中身を理解して使えるようになることを、当記事の目標とする。 フレームワークが完成すると以下のようなWebアプリケーションがつくれるようになる。 TOC 記事が長くなりそうなのでも目次 そもそもDOMとは？ D
第6回 DOM-based XSS その1：JavaScriptセキュリティの基礎知識｜gihyo.jp … 技術評論社
JavaScriptによるブラウザ上での処理量およびコード量の増加に伴い、JavaScript上のバグが原因で発生する脆弱性も増加しています。そのような脆弱性の最も代表的なものが、DOM-based XSSです。今回から数回に分けて、DOM-based XSSについて説明していきます。 DOM-based XSSとは 本連載第2回で説明したような一般的な反射型および蓄積型のXSSのほとんどは、Webアプリケーションがサーバ上でHTMLを生成する際に、攻撃者が指定した文字列のエスケープが漏れていることが原因で発生します。一方、DOM-based XSSは、サーバ上でのHTMLの生成時には問題はなく、ブラウザ上で動作するJavaScript上のコードに問題があるために発生します。 たとえば、以下のようなJavaScriptコードがあったとします。 // bad code div = docum
Shadow DOM v1でHTMLの内容と構造を分離する
近年ではウェブに対する要求が肥大化しており、それに対応してHTMLも複雑化してきています。しかし、もともとHTMLはウェブアプリを記述するための言語ではありません。大規模なウェブアプリを作成するとなると、様々な点で不都合が出てきてしまいます。特に、まとまった部品をコンポーネント化して扱う機能に欠けていました。このことが私たちを悩ませ、今まで多くの苦労を引き起こしていました。 でも、もう悩まなくてもよくなるかもしれません。HTMLをコンポーネント化する規格が生まれました。それがWeb Componentsです。 Web ComponentsとShadow DOM Web Componentsは次の4つの部分からなる規格です。 Templates Shadow DOM Custom Elements HTML Imports 今回は、このうちのShadow DOMに焦点を当てていきたいと思いま
Observableってなんなんね？ - パステル色な日々
ついにRCのリリースも間近となったAngular2ですが、私はこの間のハンズオン以来全然触れてません。 少しづつ触っていきたいものですが、ここ最近の勉強会の経験からAngular2を学ぶならWebの最新技術を学ぶことが大切なのだとわかったので、まずは、Observableを調べてみようと思います。 学習教材を探す Observableについて学ぶぞ！と意気込んでみたもののどうやって学べばいいのでしょう。 どこかにObservableの正体について書かれた資料はないでしょうか。 github.com ここにObservableがリストアップされています。 TC39、ECMAScriptを策定してる組織です。ECMAScriptはJavaScriptの仕様だと前に教えてもらったことがあります。 どういう人達なのか 何が目的なのか そのために何をしているのか 思うことはいろいろありますが、とりあ
You Don't Need jQuery - Qiita
注意とお願い この記事の内容はもはや古いです。ここに書いている方法では動かないものをいくつか見つけました。参考にする際は動作をよく確認してから使ってください。 ひとつお願いがあります。「あれ、動かないぞ」というコードを見つけたら是非コメントか編集リクエストで教えてください。解決方法までなくても結構です。「これはもう動かないよ」という印をつけたいのです。 この記事はYou Don't Need jQueryの日本語訳と同じ内容です。 先日ひょんなことからYou Don't Need jQueryの日本語訳をさせていただきました。著者のCam Songさんからも快諾をいただけたので1、Qiitaでも公開させていただきます。 なお、本家の英語の説明は継続的にメンテされているので、この記事の情報は古くなっている可能性があります。 追記 この記事は当初は「もうjQueryは必要ない」というタイトルで
フロントエンドで知っておきたい要素指定の考え方 - pixiv inside [archive]
みなさんはじめまして、ピクシブのフロントエンドエンジニア id:koharusugiura です。 JavaScript を用いた開発を行う際に jQuery や React、vue.js といったライブラリーを使う方は多いでしょう。これらのライブラリーは共通して DOM を扱うライブラリーとなります。 DOM についての説明は長くなるのでここでは省きますが、簡単に説明すると HTML や XML の構造を表現するための仕様です。DOM は JavaScript のためだけにある仕様ではなく、 Java や Python など、多くの言語に対応する仕様です。 前述した各ライブラリーは多くのウェブブラウザー間の差異を吸収してくれるため、非常に便利なものです。しかし、その機能の豊富さからライブラリー自体のサイズは大きく、ウェブブラウザーで読み込むファイルの数や合計の容量が増えてしまいます。状況
![フロントエンドで知っておきたい要素指定の考え方 - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/7d644981ad849880f091ef36cfae5c3847f8753a/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F24a8302cb73d8136c53004da7819311a96b0b746%2Fbackend%3Dimagemagick%3Bversion%3D1%3Bwidth%3D1300%2Fhttp%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fk%252Fkoharusugiura%252F20151222%252F20151222103513.png)
Reflowを制するものはDOMを制す - Qiita
すごい記事が1日目2日目で来ている中で恐縮ではありますが、フロントエンドJavaScriptでパフォーマンス点から気にしたほうがいい部分について書いてみることにします。 DOM律速になるケースもある よく「JavaScriptが遅い」ということも多いのですが、具体的にはどのあたりが遅くなってくるのでしょうか. 純粋にJavaScriptのスクリプト処理が遅い…最近はブラウザ自体も高速化しては来ましたが、それを追いかけるようにJavaScriptの巨大化も進んでいます。ただし、純粋にプログラム言語的な処理なら、Web Workerに振ることで並列化が可能です。 Ajaxや画像読み込みなどの通信が遅い…サーバ側で高速化する手もありますが、状況によってはJavaScriptで先読みを始めておいて、体感時間を短くすることも可能かもしれません。 DOM操作・表示が遅い…これについて今回考えてみます。
JavaScriptでのDOM操作は重いのかという話とForced Synchronous Layoutについて - id:anatooのブログ
2015年にもなるのにJavaScriptでのDOM操作のパフォーマンスについて書く。ウェブページにインタラクションを持たせたい時に、JavaScriptでDOM操作を行うことがよくある。このDOM操作のパフォーマンスについて、よく聞く意見を大別すると次の2つがある。 JavaScriptによるDOM操作は重たい レンダリングが重いだけで、DOM操作そのものはそれほど重たくない JavaScriptでオブジェクトのプロパティを操作したりする単体の処理は通常1ミリ秒もかからないが、DOM操作をするとレンダリングが完了するまでに数十ミリ秒程度かかったりする場合がある。1番目のDOM操作が重たいと言っている人は経験則的にそう言っていることが多い。 レンダリングの仕組みを知っている人は2番目の意見を言うが、重箱の隅をつつくような話をするとこれも必ずしも正しいわけではない。DOM操作するコードによっ
Vue.js が辛くなってきた | status code 51
Vue.js が辛くなってきた。 ひとまず現状の辛さをダンプ 今日チームで改めて話し合って辛さがハッキリしてきたので、それをつらつらと書いてく。 (今のチームは僕を含めて Rails プログラマが多くて、フロントエンドを専門にやってる人はいない。) グローバル変数大量問題(もしくはイベント地獄問題) たくさんの状態(変数)が必要 && 複数 DOM にまたがるレンダリングがしたい。 今は、左ペインで選択して右ペインに出す、みたいな事をしている。 左ペインはタブで様々な種類の項目を選べて、選択したものを右側でリスト化して表示している。 これをやろうとするにあたって、方向性が２つあると思っていて 左ペインと右ペインでコンポーネントを分けて、親玉 ViewModel に変更を通知して親玉がレンダリング制御する -> イベント地獄 左ペインと右ペインの上位の親玉 ViewModel をつくって全て
関数型UIプログラミング - 標高+1m
Pasta(deprecated)とかkakahiakaとかcastorocaudaっていうのを2012年くらいからぽつぽつ作ってて、その時に考えていたこと。多分Fluxも同じことを考えてて思いついたんだと思ってる。あと継続ベースのWAF( Seasideとかkahuaとか )とも通じる部分がある。*1 狭義の関数型プログラミングには値と関数しかない*2ので状態が持てない。つまり入力から一意に出力が決まるプログラムしか書けない。つまりアプリケーション自体が一つの関数である必要が有る。 こういうアプリケーションの典型例としては、対話式でない単純なシェルスクリプトがある。完全にステートレスな(裏にDBがあったりしない)Webサーバの各エンドポイントとかも当てはまる。 $ echo hello hello このパラダイムで対話的UI(例えばWebフロントエンド)を作るには、シェルの役割を果たすフ
JavaScript で DOM 要素の絶対座標を取得する方法 - tmlife
備忘録. スペニット的に使ってもらえれば幸いです. DOM 要素の絶値座標を取得する element.scrollTop とかだと親からの相対値になっちゃいます. getBoundingClientRect() を使えば絶対座標を取得できます. window.onload = function() { var element = document.getElementById('hoge'); // hoge というIDがついたやつを取得する var rect = element.getBoundingClientRect(); console.log(rect.left); // x座標(絶対座標) console.log(rect.top); // y座標(絶対座標) console.log(rect.width); // 幅 console.log(rect.height);
[JS] 慣性を使ったコンテンツ - Qiita
iOSやAndroidなどのスマホの画面は基本的に慣性が効くようになっています。 （スワイプして指を離すとすべるように画面が移動するアレ） そのため、逆に慣性をオフにした場合にとても違和感があり、また慣性の効き方がおかしいとクオリティがとても下がったように感じます。 Webサイトでiframeを使ったりしていると慣性が効かない部分がたまにあることに気づく人もいるでしょう。 また、スマホゲームなどではUI部分は独自実装（やUnityなどのフレームワークが準備してくれたUI）されているものが多く、OSの動きと比べると違和感を覚えることも少なくありません。 過去に、iOSのスクロールを真似たカスタムスクロールのビューを作ってみたことがありますが、やはり違和感を消すことはできませんでした。 普段ユーザーが当たり前に使う部分だけに、慣性を活かしたコンテンツを作りたいものです。 と、前置きが長くなりま
![[JS] 慣性を使ったコンテンツ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/59f981d7748ddb4f2199ce3f13123c70c2f79e7f/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFwLW5vcnRoZWFzdC0xLmFtYXpvbmF3cy5jb20lMkYwJTJGNTYxNiUyRnByb2ZpbGUtaW1hZ2VzJTJGMTYwMDMwMzY2Mz9peGxpYj1yYi00LjAuMCZhcj0xJTNBMSZmaXQ9Y3JvcCZtYXNrPWVsbGlwc2UmZm09cG5nMzImcz00YWVlZmJkNWZiMmZkYWUyOWM0Yzk5ZDJmOTJiMjZlYQ%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253D39d93af82d0822915255df0c881cf200%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCSlMlNUQlMjAlRTYlODUlQTMlRTYlODAlQTclRTMlODIlOTIlRTQlQkQlQkYlRTMlODElQTMlRTMlODElOUYlRTMlODIlQjMlRTMlODMlQjMlRTMlODMlODYlRTMlODMlQjMlRTMlODMlODQmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtcGFkPTAmcz1hNmYyNTg1ZmI0NmU2NzYzMWVlY2M3MDRkYzBiZWRlOQ%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBlZG9fbTE4JnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LXBhZD0wJnM9ODM0NTU3N2U0MjQ2ZTA3MjZjZmFhMTNjYjIwODJkMWE%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3D8f2bf8e8a68850d6d0541eeb4c9d60aa)
SCRIPTY #02 に行った - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? SCRIPTY#2 〜フロントエンド紳士・淑女のための勉強会〜 http://scripty.connpass.com/event/10345/ セッション JSコードの品質 - platoの紹介 by @mwakkiy JavaScriptでトゥイーンアニメーション入門 by @wemra Flux + React.js入門 by @pirosikick Dockerを使ったWordPressテーマ開発、Selenium Serverについて by @moongift Meteorフレームワークについて @rukiadia ライブコー
リアルな DOM はなぜ遅いのか - steps to phantasien
これは VirtualDOM Advent Calendar 2014 に勝手に参加する記事です。 あたたかい春の昼下がりのこと、あるブラウザベンダの社内を不穏な噂が駆け巡った。 「React.js なるライブラリ、どうも仮想 DOM というやつのせいで速いらしいぞ」 もうリアルな DOM はお役御免、ブラウザも商売上がったりか・・・。雇用に不安を覚える人(私)がいる一方、 そのアイデアをとりこんでブラウザの DOM を速く出来ないかと考える人たちもいた。 仮想 DOM はなぜ速いのか。誰かのつてを辿って React.js チームにおいでいただき、速さの秘密をテックトークしてもらう。 イミュータブルなデータ構造による単純化、非同期適用による処理のバッチ化、差分アルゴリズムによる副作用の最小化… いくつかのアイデアはブラウザからはどうにもならないが、たとえば非同期化なんかは形は違えどブラウザ
Virtual DOMを持つMV*ライブラリのmercuryについて
最近node-webkitアプリを書く時、何かしらのMV*やデータバインディングライブラリと言われるものを試しているのですが、floating-memo.appではRaynos/mercuryを使いました。 mercury は小さなモジュールを組み合わせたライブラリとも言えますが色々特徴的です。 完全にモジューラーな実装 Virtual DOM FRP ファイルサイズが小さめ モジューラーな実装とは何かというとmercuryのindex.jsを見ると面白い事が書かれています。 /* Pro tip: Don't require `mercury` itself. require and depend on all these modules directly! */ require("mercury") しないで、直接それぞれのモジュールを読み込んで使えるという事が書かれています。 (これ
今からVirtual DOMを勉強します！ - Qiita
VirtualDOM Advent Calendar 2014 - Qiitaの10日目です。 はじめに この記事は、これからVirtual DOMを始める人やVirtual DOMに興味があるけれど触ったことがない人のための記事です。まず、Virtual DOMとは何なのかについて述べて、なぜVirtual DOMが必要なのかについて考察してみます。そして、少しだけReactに触ってみましょう。 私はVirtual DOMについて詳しくありません。もしかすると間違ったことを記事に書いてしまうかもしれません。もし誤りに気付きましたら、指摘していただけれると助かります。また、コメントも励みになります。気軽にコメントしていただければと思います。 Virtual DOMとは？ まずはどういうものなのか知りたいですよね？公式な定義ではありませんが、Virtual DOMとは__DOMを作るために必
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
jQueryは必要ない（You Don't Need jQuery）
Incremental DOM ざっと見たやつ。追記: 初期バージョンのコードなので最新では異なる場合があります。
【個人メモ】React.jsを使ってserver-sideレンダリングを試す - Qiita
