いわゆる SPA + サーバーサイドレンダリングがダルい 唐突ですがおさらいです。 なぜサーバーサイドレンダリング（SSR）が嬉しいかと言えば 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰にやさしい（） 古いブラウザ・低性能マシンにやさしい yahoo/fluxible による SPA + Server Rendering の概観 ::ハブろぐ であり、特に SPA + SSR の文脈においては Universal Architecture による SPA + SSR は、技術的には過渡期の歪なキメラっぽさが拭いきれませんが、昨今の Web フロントエンドにしては珍しくビジネス的な説得力があります。 SSR なのでSNSや検索からの流入による初期表示が速い SPA なので回遊時のページ遷移も速い SSR なので古いブラウザでも CSS

Reactive Programming in JavaScript ( 今回のスライド: HTML版 ) このスライド自体が Bacon.js で書かれた ahomu/Talkie で作られています。Rx系のライブラリに興味を持たれた方は、ぜひコードのほうもご覧いただければ。 アジェンダ What is Reactive Programming ? Reactive in Frontend JavaScript FRP with Reactive Extensions Reactive Programming について紹介しました。今回も懲りずに新ネタでしゃべった次第。Reactive も Functional も若干こわいひとたちが生息しているイメージ（個人の感想です）があるので、遅延評価で飛んでくる斧だけがこわい :P ノイズ避け 率直な感想として、RP/FRP を学ぼうとすると情報

何かと不透明なあたり 気がつけば一ヶ月ほどブログを更新していませんでした。リハビリ記事です。 今回は、GPUを効かせる == それに関連するプロパティ（ただしOSやバージョンによって何がトリガかは厳密に異なる）を適用したら挙動が改善した、というようなノリの体験TIPSをゆるくまとめました。 このあたりの振る舞いについては、描画パフォーマンスの問題として、それなりに明らかになってきているように思います。WebKitのレンダリングプロセスにはじまり、GPU命令のサポートが受けられるのはどんな操作だとか、GPUへ処理が預けられるレイヤーの生成がどーとか、最近よく見聞きします。 自分が業務で扱っているスマートフォン向けのWebサービスでは、このような描画パフォーマンスの問題は、スクロールパフォーマンスと合わせて非常にクリティカルです。この辺りについてのロジカルなまとめは、某氏が近日中にまとめるらし