前提
- 小さめのプロダクト
- スピード大事
- 対象のチーム
- クライアントサイド専属の人がいない
- JavaScriptに詳しいひとがいない
- JavaScript界隈の流行を過度に追わない判断をした
Railに乗ろう
- Rails公式としては「控えめなJavaScript」を推奨している
- cf. Rails ガイド
- 公式のは控えめすぎるので「クックパッドモデル」を採用する
- ECMAScript6 (ES6, ES2015) のシンタックスを使う
- モジュールの依存解決にCommonJS Modules (もしくはES6 Modules) を使う
- フロントエンドのライブラリ管理にnpmを使う
- クックパッドモデルの最小構成
- cf. hokaccha/browserify-rails-example
- Railsの既存の仕組みを壊さずに babel
- いいかjs、君はあくまで app/assets/javascript な存在なんだ！
Web & Native Apps
- クックパッドモデルはGoogleのクローラにもやさしいのでメディア系のサービスに向いている
- ネイティブアプリ向けにionicを使う場合、うまく CommonJS Module 化すればコードベースの共有ができる
- Basecamp謹製のハイブリットアプリフレームワークが公開されている
テスト
- テストがなくても問題ないくらいJavaScriptは薄しておく
- Non Single Page Application
- ページ遷移しろ
- そもそもフルスタックのjsフレームワークが必要な事態が異常やったんや
- でもテストはかけるようにしておく
- Unitテストを走らせるならNodeで
- 大事なところはPhantomJSから固めにいく
学習コスト
- AltJSやクライアントサイドフレームワークに比べると前提知識が少ない
- ES2015なら完全な後方互換性があるのでES5の知識は生きる
- ES5そんなに知らない人もES2015は未来の標準なので知っておいて損はない
- そのうちプリコンパイラをかませなくてもそのままブラウザで動くようになるんやで
開発ツール
- IDEの恩恵にガンガンあずかっていく
- IntelliJ
- 共通の EditorConfig, lint
所感
- バイバイ CoffeeScript
- 感慨深い
- ES2015に受け継がれてる部分も多いので寂しくなんかないよ
- 雑にテストを書くときには依然重宝するのでこれからもお世話になります
- Turbolinksが扱いやすい
- 正しい指針があるのは説明コストが低くてよい
- もちろん雑に書く人は予期せぬ挙動に悩まされることになる
- ES2015のテンプレートリテラルは薄いjsにも有用
- ES5の変態js文化から開放される
- モジュールある
- クロージャ乱用しなくて済む