January 16, 2015 Browserify VS Webpack - JS Drama A simple Gist by Substack, the author of Browserify has caused much drama in the javascript community. A lot has been said about modularity vs the kitchen-sink approach. While on the one hand, Substack talks about how bundling features into a single project hurts Semver and hurts competition, Pete Hunt is sick of this ‘modularity shaming’ and point

目次 1. はじめに 2. Promiseの概念を理解する 幕間：行列が嫌いな女の子 2.1 Promiseとは何か？ 幕間：実行順序 2.2 Promiseと並行処理 幕間：式の抽象化 3. Promiseのからくりを理解する 3.1. Promiseで式を順序付けする 3.2. 最小限のPromise実行 4.Promiseとエラー処理 幕間：計算失敗の場合 4.1. エラーをPromiseで処理する 4.2. Promiseの失敗の伝播 5. Promiseの結合 5.1. Promiseを確定的に結合する 5.2. Promiseを非確定的に結合する 6. Promiseの実用的な理解 6.1. ECMAScript Promiseの導入 6.2. .then の分析 7. Promiseとは相性が悪いケースとは？ 8. まとめ 参考文献 追加資料 資料とライブラリ 1. はじめに

多くのシステムは“パワフル”であることを売りにしています。パワフルであることを悪いことだと指摘するのは困難に思えますし、この言葉を使う人々はほとんど全て、良いことと想定して使っているようです。 この記事では、 パワフルではない 言語やシステムが必要なケースも多いということを論じたいと思います。 まずその前に、この記事を書くにあたって、私自身のオリジナルの知見はほんのわずかしかない、ということを述べておきます。ここに述べた一連の考えの背景には、Hofstadterの著作 『Gödel, Escher, Bach: An Eternal Golden Braid』 （訳注：日本語版があります。 『ゲーデル、エッシャー、バッハ – あるいは不思議の環』 ）を読んだことがあります。この本を読んだことで、私自身の経験から得てきた原則について、考えがまとまりました。Philip Wadlerの投稿、

この記事を書き始めたのは、現在使われているCSSの命名規則やスタイルの融合についての見解を Atomic OOBEMITSCSS という題名で風刺的な記事にまとめ、SitePointに投稿した数週間後です。それが8月頃のことだったのですが、この投稿はその後の私の生活に影響を及ぼしました。冗談のつもりで「 Atomic OOBEMITSCSS 」という題名をつけたがために、世間の人々はその題名を取り上げ、話題にしたのです。（正直言って、その内容について直接人々に質問することは、私にとって非常に愉快なことでした）。そして今年のSassConfで @extend の利用について議論したことがきっかけで、この見解を再検討する必要性に気づきました。 Classy CSSについて 上記で紹介した記事（「Atomic OOBEMITSCSS」）では、コンポーネントをマークアップする方法について（Pint