天下一クライアントサイドJS MV*フレームワーク武道会 - connpass に参加してきたのでメモ。

Chaplin - mizchi

  • Chaplin.jsの話 #ten1club // Speaker Deck

  • 仕事で使ってる
  • Chaplin
    • paulmillr作のBackbone拡張系のMVC
    • Rail風の構成
  • Chaplinの設計
    • Rails風のルーター
    • インスタンスの管理するComposer
      • Controllerと強調してインスタンスを管理
      • 差分管理できるので早い
      • 逆にインスタンスを引き継ぐので意識しないと辛い
    • スキャフォールディング
  • Generator
    • MV*だとやたらファイルが増える
    • scaffolt はChaplinとは関係なく使える
  • Brunch
    • ウェブアプリに特化したビルドランナー
    • CommonJS風の展開
    • npmで拡張子に応じたプラグインを使う
    • Gulp/Gruntと競合するので乗っかれない
  • Chaplin.jsの悪い点
    • シングルトンのmediatorがテストしにくい
    • テストがない
  • Backbone.stickit
  • mocha-phantomjsでテスト
  • 学び
    • ディレクトリ構成が規約になる

vue.jsの話 (@kazupon)

  • Vue.js // Speaker Deck

  • Seedという名前で0.6でVue.jsにリネーム
  • Simple
    • mustacheテンプレートとデータバインディング
  • Fast
    • Batcherによる非同期的なバッチ処理
  • Composable
    • ViewModelをコンポーネントとして登録
    • モデルをモジュール化して再利用できる
  • Compact
    • 14KBぐらいで小さい
    • 外部ライブラリに依存してない
  • Powerful
    • テンプレート上で計算したりできる
  • プラグイン
    • Vue.jsを拡張したい人向けのプラグインするAPIがある
    • Vue.use
  • Vue.jsの今後
    • nextブランチで0.11の開発開始

ripple.js(とcomponent関連)の話 (@tajima_ｊ)

  • ripple.js(とcomponent関連)の話 // Speaker Deck

  • reactiveなViewを提供するフレームワーク
  • ripplejs/ripple
  • 今年0.0.1を持ってる
  • Reactと似てる(サンプルコードも同じ)
  • Viewをpluginで拡張出来る
    • eventsプラグインを利用しないとonclickとかもできない
  • rippleはcomponent/componentが基盤
  • compoent
    • Githubを基本のリポジトリのクライアント向けのパッケージ管理
    • 基本的にripple.jsはcomponentと一緒に使う
    • rippleのプラグインとcomponentは相性がいい
  • 現状のripple.jsとこれから
    • 0.5の変更が多い
    • ドキュメントが少ない

knockoutjsの話 (@tenntenn)

  • KnockoutJSとは
    • 双方向バインド
    • View <-> ViewModel どっちが変わっても変わる
    • いろいろなバインディングが用意されてる
    • computed
      • 2つのobsesrverに依存したものを処理するような感じ
  • プロジェクト規模
    • WebViewアプリ
    • コード量 : 数十万行
  • つかいどころ
    • カスタムバインド作って処理を簡潔に
  • KnockoutJSを選んだ理由
    • コールバックが少なくなる
    • 他のフレームワークと一緒に使える
      • 薄めのフレームワーク
    • 独自タグをつかっていない
      • 全部data-bind等の属性
  • KnockoutJSで辛かった点
    • バインディングする量が多いと重たい
    • data-bind属性が大きくなりすぎる
    • ifとifnotバインド等記述が冗長

5分で分かるmarionette.jsの話 (@koba04)

  • 5分でわかるMarionette.jsのいいところ // Speaker Deck

  • 最近2.0になった
  • 何で選んだか
    • SPAを最初Backbone.jsだけで実装
    • ネストしたView構造の管理を書いた
    • marionette.jsと大体似たことやってる
  • ネストViewをサポート
    • RegionとRegionMangerがある
    • 破棄とか自動でやってくれたり、renderも呼ぶ必要ない
  • 各Component毎にViewを作る
    • ロジックレステンプレート
    • Viewが多くなる
  • ソースがキレイ
  • まとめ
    • Backbone.jsからの移行コストは低い

「marionetteからractiveへ、そしてXXXへ」 (@lxyuma)

  • Marionetteからractiveへ - lxyuma BLOG

  • 使用してきたフレームワーク変遷
  • Backbone.js
  • Marionnet.js
    • 色々やることが多い
    • Backboneよりまし
    • だけど大変
  • Ractive.js
    • Viewだけ完全にractive.js使うようになった
    • Backbone.View等がいらなくなった
  • ハマる事が少ない
    • ractive.getはpureなオブジェクトがない
    • 学習ことは少ない
  • マイナー感
  • 今はRactive使ってない
    • バニラJSで書いてる

にわかangulardart(@nyamadandan)

  • にわかのAngularDart - Google スライドb

  • Dart
  • AngularDart
    • AngularJSをDartにポーティング
    • フルスクラッチ
    • WebComponentsを使ってる
  • カスタムタグ
  • KnockoutJSとの比較
    • KnockoutJSみたい関数を実行する必要がない
    • KnockoutJSほど気軽に使えない

AngularJS x designer (@silver_s)

  • angular X designer - デザイナからみたAngularJS #ten1club

  • デザイナにアプリを作ったもらったはなし
  • エンジニアとデザイナの分業フレームワークとして
  • JavaScript触ったこと無いひとにやってもらった
  • AngularJS
    • 設計や実装の自由度が低い
    • それが逆に規約的になる
  • 分厚い - フルスタック
  • HTMLだけでもいい感じに操作もかける
  • ngClick, ngTouch…などもHTML側にかける
    • こういう条件で表示みたいのもデザイナが書ける
  • 自作directive
    • エンジニアが用意
  • 辛い点
    • 内部のロジック -> 暗黒
      • 死ぬのはエンジニア
  • まとめ
    • ViewとController自体はデザイナでもいけた
    • モデルとかはエンジニアが頑張る
    • ngAnimate, ngClassの虜
    • アニメーション増やしすぎる

React + Fluxの話 (@dsuket)

  • React.js + Flux

  • React
  • Just The UI
    • 単なるView
  • Virtual DOM
  • Data Flow
  • ReactiveProgramming
    • データフロー指向プログラミングのパラダイム
    • 値は動的に決定される
  • React + JSX
    • オブジェクトでもDOM作れる
    • JSX使ったほうがDOM構造が分かりやすい
  • Flux(アプリケーションアーキテクチャ)
    • MVC doesn’t scale
    • Viewにreact
    • Dispatcherでイベントの順序を管理
    • フローを1方向にする

Omの話 (@tfukushima)

  • Om

  • swannodette/om
  • Reactと違う点
    • Undoが簡単に書ける
    • ウェブでもUndoが使う機会が増えてる
  • ClojureScript
    • 差分だけの情報が簡単にhookして取れる
    • Clojureが良い
    • ライブラリが良い
    • マクロ良い
    • LinkedList
      • Gitっぽいモデル
      • GET UNDO NOW

パネルセッション

SPA

  • 初期化に時間を取れるかどうかで選択できるか変わる
  • Kintone
    • 部分SPA
    • レガシー部分はページごとに別れてる
    • 最近出来た部分はSPA
  • ゲーム
    • 部分SPA
    • メモリリークがあると辛い
    • 適当なタイミングでメモリ解放したい
  • CodeGrid
    • SPAから普通のに戻ってきてる感じ
    • SEOの問題
    • 最近Google自体がJavaScriptも解釈するようになってきた
    • Google以外にもはてブがタイトル取れないとかの問題もある

Isomorphic

  • Meteorさんが悪い印象を作ってしまった?
  • サーバとクライントで同じロジックを使いたい
  • 夢がある
  • そもそもNode.js自体がビジネスロジックがだるい
  • ロジックは他で、Viewに近い所はNodeに持ってくるとか

差分レンダリング

  • シングルと差分のレンダリングはやり方違う
  • その辺をIsomorphicなものが解決して欲しい

使ってるフレームワークで最悪な所

  • Marionet
    • モジュールとrequireがぶつかる
  • Backbone.js
    • ルーターが微妙
    • ngRouterがよりつらい
  • Chaplin
    • reuseの判定がシビア
    • インスタンスの引き継ぎが大変
    • ジェネレーターをプロジェクトの進行と共に作っていく
  • Closure Library
    • モデルに対するバインディングが最近のMV*の要件
  • AngularJS
    • ngRouteが辛い
    • ServiceやFactoryとか自由すぎて、使い方が難しいngRoute
    • ngRouteのいやなとこ。
    • routeがやること多い。
    • ng-viewと紐付いてるので、まるっと書き換える困ることが出てくる。(スクロール一の記録とかしたいときに困る)

WebComponents

  • http://www.polymer-project.org/tools/designer/ みてどうなってるんだろこれ
  • Polymer - WebComponetsに載ってるライブラリ
  • 銀の弾丸話
    • JavaScriptの問題を解決するコンテキストではない
    • CSSの方についての銀の弾丸
    • CSSのスコープを取れる
    • 今は命名規則(BEMとか)で頑張ってる
    • Polymer ≠ WebComponents polyfill

他のGUI環境と比べて足りない所

  • 永続ストレージが足りない
  • リソース管理が足りない
    • disposeとかその辺
  • window.gc が欲しい
  • 集団になるとルールがない

モジュール

  • AMDはない
  • 現状だとCommonJSが分かりやすい
  • 将来的にはES6 moduleかな
  • Browserify
    • 遅延ロードは明示的に書く
    • ライブラリレベルとかの分離なら遅延ロード出来る
  • CSSとかも一緒にパックしたかどうかで使えるものが別れる
  • 遅延ロードを扱えるかどうか?
    • AMDはモジュールレベルの遅延ロードができる
    • Webpackの遅延ロードも結局は関数で呼ぶ定義を使う

テンプレートエンジン

まとめ

  • AMDはやめておけ
  • 規模とか人に違うよ

その他

懇談会