銀の弾丸は川から流れて来ない - saneyuki_s log
The Evolution of Flux Frameworks — Mediumを読んだ。自分がここ3ヶ月～半年くらい考えてたことと殆ど一緒で、若干の安心感を得たり。実装論の話も概ね同意ではあるのだけれど、自分は必ずしも同意しかねる面がある。 今のメモリマネージド言語のトレンド、特にクライアントアプリケーションの存在を想定したアーキテクチャは、C#が筋道を立てた実践理論に追随してる面があるので、過程はどうあれ、彼らの先端スタイルに近づいていくことになると思うのよね。 Fluxパターンの話をすると、あれが偉かったのは「疎結合すると色々楽になるから、オブザーバーパターンにして、コマンドパターン使って、コマンドは単方向にすると破綻しにくい割に弄りやすいよ」ってのを、フレームワーク症候群に陥っていた凡百なWebクライアントサイドに、一発、投げつけた辺り（というのは半年くらい前に書いたな……）。
Fluxとはなんだったのか + misc at 2014 - saneyuki_s log
はじめに VirtualDom - なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita を読んでいる前提で話を進めます。 結局”Flux”なんだったのよ 詳細については過去に自分が覚え書きを書いたのでそっちを読んでいただけると良いと思うけど、あれは 「MVCの変形亜種に、オブザーバーパターンを乗せ、データを単一方向に流すことを規定した」ものに、Facebookが命名したものでしかない。極端に目新しいものでもない。その最大の功績はアーキテクチャそのものではなく、「試行錯誤を踏む中で誰もが一度はやっていたであろう似たようなことを上手く実践法則としてまとめた上で、共通認識としての名前をつけた」こと。概念に名前をつけて共有することで、事前説明が簡略化され、本質的な問題に取り組む時間が増える。これをFacebookのブランド力でねじ伏せるように広めたことこそが重要かつ評価すべきポイン
CSSのcanvasとviewportとposition:fixedとpinch zoom - saneyuki_s log
specを元にした概念の整理 間違いあったら教えて欲しい CSS 2.1におけるviewport CSS 2.1におけるviewportを説明するにあたり、以下のterminologyが必要となる canvas For instance, user agents rendering to a screen generally impose a minimum width and choose an initial width based on the dimensions of the viewport. viewport User agents for continuous media generally offer users a viewport (a window or other viewing area on the screen) through which users co
Virtual DOMのアルゴリズムが知りたくてvirtual-domのコードを読んだ話 - saneyuki_s log
Reactの登場以来気になっていた、Virtual DOMアプローチの具体的な差分抽出手法について、virtual-domを読んで確認してみた。 Reactをいきなり読むのは面倒くさかった・ミニマムな実装から読みたかったというのが、こっちを選択した理由。Reactのアルゴリズムが参考にされているものの、Reactには存在する特定の最適化が入ってないかもしれないので、あくまでもReact系のVirtual DOMを実装するには最低限何が必要かを知る程度のものと判断してほしい。 virtual-domについて ReactのVirtual DOM部分だけを切り出して再利用可能な形で再実装したライブラリ。elm-htmlとかMercuryといった箇所でvDOMインフラとして既に使われているので、まったくの趣味プロダクトという訳でもなくなっている。 README.md中での触れられている通り、Vir
JS界隈にIDLもしくはd.tsを併記・同梱する文化が根付いてほしい - saneyuki_s log
前置き 最近、ウェッブフロントエンドエンジニアらしく各種JavaScriptのライブラリを眺めて、調査・選定しているのだけれども、その過程を通じたこととして、多くのライブラリが、ドキュメントのAPIの説明が貧弱すぎる。 jQueryのドキュメントが腐っているというのは既に広く知られた事実であると思うし、そうでないならば積極的に既知の事実として腐っている事を広めて行くべきであると強く思うが、jQueryに限らずとも、ドキュメントが満足な形で整理されていないのをひしひしと感じる。 この手のものでよくドキュメント化されている部類だと感じるBackbone.jsですら、仮引数の名称と定義のみしか書かれておらず、肝心の引数が備えるべきメンバや、引数の型情報が明示的に記述されていない。そのため、APIを俯瞰し、自分の欲しい情報がどこに詰まっているのか・どのように取得できるのか・DOM標準もしくはECM
ES6の前にES5のベストプラクティスを改めて考えたい - saneyuki_s log
歴史認識 だいたい以下のような流れだと認識している。 IE8以前を含むECMAScript 3暗黒時代があった この時代をベースにベストプラクティスが構築 + HTML5ブームが発生した 暗黒時代なんで結構つらいし、IE9じゃないとECMAScript 5使えないし、結局辛い CoffeeScriptを筆頭としたaltJS一派に救いを求めた（結局Coffeeは一過性のカフェインだったわけだけど） 気がついたらECMAScript 6が来そうになっていた ES6でのsyntaxの拡張・標準ライブラリの増強はカッコいい 気がついたらES5当たり前、ES6も使えそうな世界が来そうになっていた（希望的観測が多分に含まれているのは暗黙の了解と化している） ES6、altJSの次のナウい世界として注目を集める だいたいこんな感じで、ECMAScript 5を用いたベストプラクティス的な物が存在しない、
Web ブラウザは Web に対する GUI シェルである - saneyuki_s log
2年くらい前から個人的に色んな場で話しているんだけど、現状のWebブラウザには「HTML5 で導入された API 群に対して、ブラウザ側が適切なUIを提供できていない」という問題点がある。 これについて分かりやすい例を挙げると、cookieの管理ビューはあるのにDOM storage の管理ビューが無いこととか（この2年間でChromium先生は実装したけど）。 よくよく考えてみれば、だいたいのブラウザには現在保存している cookie をユーザーが閲覧するための機能があるのに、DOM storage や IndexedDB に何が保存されているのか、そもそもどこのドメインによって保存されているのかすらわからないというのは奇妙な話なんだ。何故なら、どれもユーザーのプライバシーに関連する情報の保存用途に使われるからだ。最近はトラッキングに関連する話題としてトラッキング cookie がやり玉
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
