天下一クライアントサイドJS MV*レームワーク武道会を開催しました。

ぼくの連絡ミスによってUstreamが準備出来てなかったり、直前の台風によって寿司が提供できなかったりと色々と不備がありました。申し訳ありませんでした。

んで、その代わりに完璧なレポートを書こうと思ってたんですが、既にazuさんが完璧なレポートを書いてくれてるので、そちらを見ると雰囲気が分かるかと。僕はそこに対して感想を加える形で書いていきます。

ハイライト

  • 個人的に一番面白かったLTはAngularJS x デザインの話、一番興味惹かれたフレームワークはOm、学びが多かったのはchaplin (marionetteと近くて違いが分かってよかった)
  • IsomorphicなWAFはNode.jsの生きる道であり、夢。
  • WebComponentsはCSSにとっての銀の弾丸、JavaScriptの問題を解決するものではない。
  • AMD (require.js) はオワコン、CommonJSかES6今後使え
  • ぶっちゃけ規模やバックグラウンドによって違うからどのフレームワーク使うかはその状況に応じて使え

はじめに

この天下一MV*フレームワーク武道会は武道会と銘打ってますが、最強を決めるつもりはありません。
結局「こういうケースにはこっちが向くけどこういうケースにはこっちが向く」みたいなケースバイケースになることが多いし、2〜3時間話したところで決まるものでもないので、色んなフレームワークを紹介してもらって、最後に実際にwebゲーム、webアプリ、webサイト作成等、webに関わる色んな分野で活躍している方をパネルで呼んでここ最近のフレームワークの流れとかWebで起きている最新の事を話してもらうことにしました。

なのでこれが一番のフレームワークだ、みたいな話はあんまりするつもり無くて、色んなフレームワークが存在している事を知ってもらい、特徴を掴んだ上で実務や趣味に活かしてもらえるといいなーと思っています。

LT大会

chaplin.jsの話 by @mizchi


mizchiさんが仕事で実際に使っているchaplin.jsの紹介。
僕は仕事でmarionette.jsを使ってるんですが、ViewとかModelとかを作ろうとすると毎回毎回前に作った奴のコピーを使ったり、yeomanでscaffoldを作っているんですが、何か変更がある度にyeomanでscaffold作るのも面倒なので、結局古くなってyeomanが使われなくなっていくっていう事がありました。


今回のchaplin.jsの"scaffolt"のようにフレームワークにgeneratorが強く依存しているのはそういう事が無くなりそうで良いと思いました。非常にRailsを意識した設計だなと。

Vue.jsの話 by @kazupon



読み方がびゅーだったりヴーだったりと発音に困っているVue.jsの紹介。

Simpleで高速、機能は少ないが、バインディング等のやりたい事はできる、興味を持っている人が多いので、次に試そうとしている人も多いはず。今回のLTでは機能概要に加えて今後のロードマップとしてfull scratchで書きなおそうとしているv0.11の話がされてました。割りと作者がVue.jsの利用者に対して意見を求めているらしく、意見があれば積極的に話しかけていきましょう。英語が不安な方は@koba04さん経由で話しかけてもらえれば良いそうです。

ripple.js(とcomponent関連)の話 by @parc_b



Segment.io製フレームワーク、ripple.js。

Reactからjsx成分を引いて、component成分を足した感じ。
Reactiveなview、pluginを持ち、そのpluginがcomponentによって提供される。各コンポーネントを見てみたけど、非常にシンプルでUnix Philosophyっぽい思考を持ったフレームワークだと思った。

比較的新しいため、まだユーザーが少ないのが難点ですね。もっとコントリビュートされて大きくなると面白いと思います。

knockoutjsの話 by @tenntenn

資料見つけられず...

knockoutjsの特徴としては双方向バインディングを持ちつつもシンプルな設計で他のフレームワークと組み合わせて使えるといういい感じの設計ですね。

コード量数十万行のWebViewアプリに導入して使っているとの話で、大規模な開発にも耐えられるという実績があるのが素晴らしい。

5分で分かるMarionette.jsのいいところ by @koba04

わかりやすくMarionetteの良い所、今後のロードマップをまとめてくれた話。

僕も仕事ではMarionetteなんですが、多分Marionette使う人って大体選択基準が似ていて、

1. メモリ管理を簡単にしたい
2. Marionetteのソースコードは中を追うのが楽でやってることが大体分かる

という所が選定基準なんだと思っています。ちょうど同じ時期に弊社でMarionetteを使ったアプリの解説記事が載っているので合わせて読むと参考になると思います。

iOSアプリをHTML5アプリにした時の技術選択と開発ワークフロー〜QuizNow(ブラウザ版)の事例から〜 — Mobage Developers Blog

marionetteからractiveへ、そしてXXXへ by @lxyuma


資料: Marionetteからractiveへ - lxyuma BLOG


Backbone/Marionetteは良いけど、ちょっとしたことを実行するのにもコード量が多くなる、そこでもう少し単純で、学習コストが低い奴を選ぶということでractiveに。でも結局使っている人が少なすぎて最近は何も使わないでvanilla jsで書いてるという話。

最近こういうぶり返しみたいなのがちょっと来ていて、結局色んなWAFを試したけど、結果何も使わないで自分で一から書くという方法をとっている人がちょっとずつ増えているなと感じます。

ractiveはlxyumaさんのエントリがものすごく詳しいので、今後使われる方は参考になると思います。

にわかangulardart by @nyamadandan

angular.jsをdartにportingしたかなり熱いフレームワーク、knockoutjsやpolymerとの比較も載っていてわかりやすかった。
polymer.dartがangular.dartと重なる部分が多いということで今後は両方見ておくと良いのかもしれません。

AngularJS x designer by @silver_s

一番内容は面白かったし、デザイナーから見てもangularのhtmlは直感的で分かりやすいという事がわかってよかった。
中でやろうとしている事を知りたいとか、angularのhtmlから外れた事を表現しようとした時は「エンジニアが死ぬだけだから気にしない！」という過激派な発言が良かったｗ

React + Flux by @dsuket

Facebookが産んだ変わり種のReactさん、よくJSX方面で間違えられること多いんですが、ReactのJSXはJavaScriptに直接XMLを書けるという拡張JavaScriptの事を指します。DOM操作をjavascriptで書かなくても直感的に使えて面白い。

あと、Reactive ProgrammingとVirtual DOM、それにFluxという聞いているだけでも中二心をくすぐられるWAFですね。LTでは割愛されてたけど、Virtual DOMの話もっとしてほしかった >

Om by @tfukushima


ReactをベースにClojure Scriptのインタフェースを取り入れたフレームワーク、一番攻めてたw
Undoを簡単に書けるというデモもわかりやすかった。
実際使うかというと微妙だけど、デモの良さと攻めてる感で言ったらダントツだった。

ぁゃぴさんからのコメントを御覧ください。


パネル

パネル用の質問を応募したところ、かなり多数の質問が寄せられ、全て消化するどころか全体の30%くらいしか消化できませんでした。

まぁそれでも有意義な議論がかなりできました。

Single Page Applicationをしているか

  • 基本的には部分的にSinglePageApplicationだが、Webサイトの領域ではSPAじゃない案件もあるし、最近は普通にページ遷移する案件も多い。ゲームやアプリの領域では部分的にSPAを採用しているのがまだ全盛。

SEOどうしてるか

  • SEOは基本的にGoogleのクローラがJavaScriptを解するようになっているので、それに任せることが多いが、やっぱりSEOを気にするなら基本的にはページ遷移かと。
  • Rendrみたいなhtml要求されたらhtml返して、json要求されたらjson返すフレームワークが出てきてる。

IsomorphicなWAFの夢

  • Node.jsはIsomorphicなWAFをやらないといけないし、唯一できるアーキテクチャ
  • ただvalidatorとかviewをクライアントとサーバサイド両方で実行できてもかなりセンス良い作りじゃないと二重化するの難しい。
  • まぁ夢があるけど決定打がない、今のところは夢だよね、、、

WebComponents/Polymerどうですか?

  • 誤解されてることが多いけど、WebComponentsはJavaScriptの世界の銀の弾丸じゃなくて、CSSの世界での銀の弾丸
  • CSSは基本的にグローバルスコープに存在する
  • 今は命名規則で何とかしてるが、本来はネームスコープがあって然るべき、WebComponents(ShadowDom)はそれを可能にする。

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

  • 永続ストレージが足りない
  • リソース管理が足りない
  • window.gc が欲しい
  • 集団になるとルールがないと開発できない

モジュールロードどうしてますか?

  • AMDはもう有り得ない、現状ではBrowserifyでCommonJSが一番妥当、将来的にはES6 module loadかな

これから学ぶ人へのコメント

  • AMDはやめておけ
  • ぶっちゃけて言うと、規模やバックグラウンドに依ってまちまち、その事を学びつつ、良い物を見極める目を養う事が重要。

あとがき

ものすごく楽しかった。最後にパネルであーだこーだ話すの楽しい。
結構TLを追っていると次回もやって欲しいという声を聞くので、また気が向いたら次回の開催を行います！！