#Rubyhiroba で発表してきた

これ。もう一ヶ月前のことになる。 http://rubyhiroba.org/2014/presentation.html

「Rails3で作り始めたアプリケーションをちょっとずつ改善してゆく道のり」を発表してきた。

この発表、Denkinovelの紹介部分は情報科学若手の会で話した部分をそのまま流用している。当初、若手の会でもRailsでの実装部分を説明しようと思っていたのだが、発表時間も短かったうえ、若手の会にはRailsやってない人が多そうなので断念した。上記のRubyhirobaの発表はその削った部分も大幅に投入したものだ。

Denkinovelの実装についてちゃんと公開したのはRubyhirobaが初めてで、ノベル作成からJSON変換までをどう表現すればわかりやすいかなど悩んだ。

BackboneとかAngularとか、JSのフレームワークはSPAの文脈で説明されることが多いけど、アプリケーション全体のSPAではなく単に遷移なしでのリッチな表現のために使う機会のほうが多いと思う。

Denkinovelの知見が他のWebアプリ開発に役だってくれればありがたい。

興味を抱いたこと

id:joker1007 さんの、RailsからSprocketsを投げ捨てる話が興味深かった。

これ。

僕自身、Railsアプリを開発してるとフロントエンドをすべてSprocketsで管理するのが煩わしく感じてきている。

joker1007さんの意見、RailsのSprocketsを捨てるべき、という意見、かなりうなずける。

なぜこの意見に僕が賛成しているのか、まとめてみた。

なぜSprocketsを捨てるべきなのか

npm, Bower, WebPack, grunt, gulpなど、最近のWeb開発ツールはだいたいNodeで動く。Web開発の環境を整えたり、フロントエンドの管理をするのはNodeにやらせるのがこの数年の主流だ。

フロントエンドはJSの領域で、RubyもPythonも手出しできない。だから、JSファイルを結合させたり、依存関係を整理したりするのはサーバサイドJSであるNodeにやらせるのがよいと思っている。

RackのライブラリでしかないSprocketsと、Webアプリケーションには必須の言語であるJavaScriptで作られたgulp, gruntでは、利用される頻度が違う。JavaScript製のツールは、Webデザイナーも、非Rubyプログラマも使うのだ。

そして、こっちがより大きな理由なのだが、sprockets、わけわからんことを勝手にやってくれて、それを理解していないせいで不具合を解決できなかったりする。

わけわからんお節介のせいでSprocketsの挙動を調べるのがイヤだから、Sprocketsを捨てたい。なんで挙動を調べたくないかというと、Sprockets、静的ファイルの名前にハッシュ値を与えたり、JSの依存関係をもとに合体させたり、役割が複数あって無駄に大きい。

その点、複数の小さな部品を組み合わせて作っているgruntとかのほうが理解しやすい。UNIX哲学は偉大だ。

ということで、そろそろフロントエンドはRailsの手から放してやるべきなのだと思う。

turbolinksとか誰も使ってへんやろ？