Rx.js, Immutable.js について - mizchi's blog
自分はImmutable.jsとRxをなぜ採用しなかったか、自分の考えを整理するために書き出してみる。 僕の理解が及んでいない無知のゆえのアレもあると思うので間違っていたら罵倒ブコメお願いします。 Immutalbe(.js) 扱う対象をイミュータブルにするのはたぶん間違いなく正しい。正しいが、現時点のエコシステムにおいてその必要性を示せてない。具体的に言うと、Immutable.jsの110kbのオーバーヘッドの配信負荷、読み込み負荷、開発者の学習コストを支払ったとき、それに見合う価値を提示できているのか？にまだ疑問が残る。 PureなJSでも、ただ単に目的のデータを作るだけなら、ほとんどのケースで組み込みのarray.mapとObject.assign(またはそのポリフィル)で代用できる。(勿論生成したオブジェクトに副作用を加えないことが前提になるが) あと型がない環境でImmutab
なぜ僕は(2015年のフロントエンドで、makeではなく)gulpを選ぶのか - mizchi's blog
http://d.hatena.ne.jp/m-hiyama/20150511/1431306678 の件 最初に 僕もgulpが今後生き残るかというと、かなり懐疑的です。開発パラダイムに合わせて変わっていくで、来年の段階で自分はgulp使えないなといっている可能性は十二分にあります。そのタイミングの一つはES6 import がHTTP2で並列ロードのオーバーヘッド無しで解決されるようになるタイミングでしょう。 根本的な問題として、Web周りは標準化の関係で動きが遅いです。最新の仕様ではままならず、ブラウザ間の実装がまちまちで、また開発上の要求が多様なのでプリプロセッサで解決する文化が根付きました。プリプロセッサがいらなくなるぐらい個々の標準が洗練されればプリプロセッサも不要になりますが、そのような未来は、今の動きをみるに、あと15年は来ないように思えます。 とはいえ、ただひとつ言えるの
あなたがReactを使うべき理由 - mizchi's blog
最近フロントエンドでfacebook/reactをずっと使っている。世界的には一部のエンジニアの間で流行っているのだが、国内だとqiitaのタグ等を見てもどうも少ない。みんなもっと使うべきだと思うので、宣伝かねて意見をまとめてみる。 複雑化するデータバインドに対する懸念 MVWのVに対して思いを馳せると、だいたい次のことに行き着く。すなわち、「ある構造体の入力に対して、必ず一意なビューを生成したい」 {items: [1, 2, 3]} を入力とすると、 1, 2, 3のli要素になってほしい。これは単純な例だから問題に成り得ないように見えるが、アプリケーション全体の状態を一つのjsonとして定義し、 そこから常に0から組み立てればアプリケーションの健全性が確保できると考えたことはないだろうか？ 現実の問題 UIのだいたいの状態は遷移で表現される。遷移の差分をプログラマが記述する。jQue
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
