DIV ⇒ SVG 移行して気付いたこと - ジンジャー研究室
マップ閲覧・編集システムで画面上に DIV で描いていた図形を SVG に移行した。内部に数百のオブジェクトを含む要素の動作が重く、ドラッグしたときにカクカクになる問題を解決したかった。ちなみに Virtual DOM は使っているがすでに最適化は済んでおり、毎回描画されるような事態はあらかじめ避けている。代替案として Canvas と迷ったが CreateJS のようなライブラリを使わないとイベントハンドリングがきついので、 SVG で行けるならそれが一番。以下、移行した結果と移行中に気付いたことのまとめ。 描画パフォーマンスが上がった（Firefox: 20fps ⇒ 60fps、Chrome: 50fps ⇒ 60fps）。 Chrome の DevTools で見ると、DIV 版は UpdateLayout と Paint に時間がかかっているが、 SVG は Layout に時間
スケーラブルなプログラミングのために何が必要か - ジンジャー研究室
Fluxに関する独自解釈と妄想を、何かの翻訳っぽく書いた。 スケールするアーキテクチャ フレームワークを作る時、我々は「簡単に記述する」ことを第一に考えがちだ。 そして、簡単にするための仕組みはウケる。 逆に記述量が増えるとウケない。 しかし例外があって、多く書くことによるメリットが受け入れられたときは別だ。 例えば、Backbone.jsを使うと記述量が増える事は誰もが認めるところだが、MVCの実現というメリットのために広く受け入れられた。 要するにトレードオフなのだ。 ここのところFluxアーキテクチャが注目を浴びているが、書いてみると記述量は相当増える。 そもそも登場人物が多すぎる。 Action、Dispatcher、Store、View、それからそれらの間に挟まって仕事をする者達。 一体彼らは何をしたいのか。 最近になって分かってきた。 これはアプリケーションそのものを抽象化した
React.js+Fluxをやるなら今すぐElmを使うべき理由 - ジンジャー研究室
皆さん、そろそろElmやりましょう。 Elmって何なの？ Webブラウザで動くFRP(Functional Reactive Programming)言語です。 コンパイルするとHTMLやJavaScriptを吐き出します。 Elm 公式サイトに動くサンプルが大量にあるので見てみると面白いです。 どうして今やるの？ これまでElmと言えば、良くも悪くも理想を追求した言語で、一般的なWebの部品(HTML/CSS/JavaScript)と相性が悪く、「まぁちょっとCanvas使っておもちゃアプリでも作るかー」くらいが関の山だったのですが、最近になってその状況は一変しました。 HTMLライブラリのサポート Ajaxなど非同期タスクのサポート JavaScriptとAPIを通じて相互接続可能 エコシステムの登場 順序はちょっと忘れましたが、0.14とか0.15で色々出来るようになりました。 im
HTTP/2のサーバープッシュを自動化するNode.jsライブラリを作った - ジンジャー研究室
そろそろRFCとして公表されるHTTP/2ですが、GoogleがHTTP/2を使ったRPCフレームワークを出してみたりとか、その界隈は大盛り上がりですね！ HTTP/2の目玉機能と言ったら、やっぱりPUSH_PROMISE！ PUSH_PROMISEと言えば、「index.htmlが必要だったらapp.jsとかstyle.cssも要るよね！」とサーバ側で勝手に判断して送りつける、というのが良くある説明なのだが、それを自動でやってくれるわけではないので、Node.jsサーバ用にライブラリを作ってみた。 jinjor/auto-push · GitHub npmにもpublishしたので、npm install auto-push可能。 やっていることは、レスポンスの直前にHTMLをパースして、必要そうなJavaScriptなりCSSなり画像なりをプッシュする。それだけ。 HTML Impor
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
