フロントエンドエンジニアのための「俺の最近のRailsのJS開発環境」を考察する - Qiita
「俺の最近のRailsのJS開発環境」 for フロントエンドエンジニア TL;DR 「片手間のJS」ならhogehoge-railsで大丈夫（e.g. browserify-rails, sass-rails, etc.） 「本気でJS書く」ならsprocketsから切り離す（e.g. SPA, etc.） 迷えるフロントエンドエンジニアに愛の手を ※ 個人の見解です はじめに 本記事の内容は個人の見解であり、所属する組織の公式見解ではありません． 本職は学生，片手間にRailsエンジニア，そのさらに片手間に過激派フロントエンドエンジニアやってる人間の戯言です． 『俺の最近のRailsのJS開発環境を教えてやる』を受けて，フロントエンドエンジニアの視点から見たRailsのJS環境を考察してみた記事になります． 元記事をdisっているわけではなく，むしろリスペクトしたうえで視点を変えてみた
俺の最近のRailsのJS開発環境を教えてやる - Qiita
こうやってるだけでも出力されたhtmlにはscriptタグが30個ぐらいならんでて、ページの読み込みに10sec以上かかる。 だけど、単にapp/assets/javascriptsをgulp watchとかはしたくない。 なぜならビルドはブラウザのリロード時に変更がある場合だけして欲しかった。 あとwindow.AppNamespace以下にモジュール追加していくのも辛い。 モジュール同士の依存関係もよくわかんないし、何よりwindow.AppNamespace.Modules.UserList.ItemViewとか長すぎ！ browserify-railsってやつ使ってみた browserifyがrailsの仕組みの中で動くようになる。 browserify-rails/browserify-rails https://github.com/browserify-rails/brows
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
