意図的かつ構造的にフレキシブルではない。「フレキシブルが好みな人は、Emberを使うべきでない。Reactフレームワークではなくて、viewレイヤであるが、話題になっているので追加。FacebookのFluxアプリアーキテクチャになると、フレームワーク的になる。prosバーチャルに都度、再レンダリングし、実際のDOMとの差分を確認のうえ、変更箇所だけをうまく反映してくれる。バーチャルDOMによる抽象化が、うまくコンプライアンス的に働き、どのブラウザでも整合性のとれたイベントモデルを実現してくれる。フレームワークではなく、viewモデルなので、柔軟にアプリを構成できる。Backbone.jsとの連携も可能。つくり方に違和感あり。JavaScriptのエンジニアにとっては、引用しないHTMLをJavaScriptに組みような感じ。DOMに何がどう適用されるか完全にコントロールしたい人にとっては不向き。複雑なアプリが自動的に再レンダリングされると相当なdiffがでるので、把握できなくなることを恐れ、理解できているコンポーネントだけをアップデートするエンジニアの話を聞いたことがある。Polymerprosブラウザから独立したかたちで、入力フォームのカスタマイズなどができるのは素晴らしい。Polymerはポリフィルとしてブラウザ機能を拡張できるので、今から即利用可能なテクノロジー。webにとって長年の課題であった、ウィジェットをつくる際の適切なスタイルの分離を、ブラウザレベルで問題を解決してくれている。consweb開発の万能薬的なポジショントークにはちょっと違和感を抱く。シングルページアプリづくりは、素敵なカスタマイズした要素に置き換えるだけではダメで、全体の要素の生成/終了を管理する仕組みが別途必要。Googleにとっては、JavaScriptを把握してなくても、Googleのサービスを理解できるようにさせるという戦略ではないか。マーケティング的に盛り上りをつくり、技術標準化しようとしている意図を感じてしまう。Google内で採用されているのが、Polymerのサイトだけというのも危険信号。Importは、CSS@import問題の再来ではないか。コンポーネント化されたアプリをつくると、大量のネットワークリクエストが行ったり来たりすることになる。vulcanizerでまとめるというソリューションもあるようだが、それをインラインするオプションはないと思う。詳細はこちらのブログ参照されたし。routerは、十分テストされていて、フレキシブルに使える。基本的な問題をしっかり解決してくれている。スコープが限定されているので、理解しやすい。新しく採用したフロントエンドエンジニアへの最初のタスクとして、Backbone.jsのドキュメントを読ませるようにしている。何とか」というフレームワークになる。要素内で一連のviewをレンダーする方法subviewやネスト構造をきれいにつくる方法Backboneはミニマム主義であるものの、各ピースが密に連携しすぎている。collection内では他の型のmodelは使えない。Backbone以外のアプリがアクセスするデータを保持するmodelをつくるときなどは困る。モンキーパッチするか、Backbone全体をincludeするか。フレームワークに頼らないpros究極なフレキシブルさ。アプリに本当に必要なコードだけを残せる。Florence曰く、「パブリックなフレームワークを使わないという選択をした場合、最終的にはフレームワークを利用することになる。自分独自のというフレームワークを。誰かがつくってくれているはずのソリューションを自分でつくることになる。正しいmoduleの選択は難易度が高い。後から新しいエンジニアが参加しても、ドキュメントは不十分で、頼るべき慣習がわからない。次のプロジェクトにコードを再利用するのは本当に難しい。他人のコードで恩恵を受けるのではなく、結局は自分の失敗から学ぶという機会になる。&yet社のメンバです。原文をかなり省略してますので、詳細はサイトを確認ください。prosフレキシブルだが適度な結合度スタートにあたって、構文は明示すべきだが、強制するのはよくないと考えている。そこでCLIを用意し、これから開発にトライしたい人も、参照するだけという需要にも応えられるようにしている。試しにつくるというのではなく、本格的なアプリづくりの道具にしたいので、Backbone.jsを利用して構築している。JavaScriptという本(オンライン購読無料)にまとめた。npmを利用し、モジュール検索機能も提供。consコードが未成熟なところがあり、ツール群の充実はこれから。コミュニティも立ち上げ中。古いブラウザのサポートは不十分。