ウェブアプリが依存する技術は少なくしておきたい

ここ数日、Bootstrap-Sass や React-Rails といった、Rails アプリで使える RubyGems を試してみた、その個人的な所感。

Bootstrap と React.js

Bootstrap は、ザックリ言ってしまえば CSS テーマ。これを RubyGems で簡単に導入できるというのが Bootstrap-Sass というモノだ。

ただ、Bootstrap 以外の CSS 関連のパッケージを併用するなら、npm (Bower) で導入し、Gulp なり Webpack なりでガッチャンコしたモノを Rails に適用するのがいいんじゃないかなと感じた。

React.js は、フロントエンドを構築するテンプレートエンジンみたいなもの。React-Rails は、これを Rails アプリに導入しやすくしてくれるモノ。

React 単体で見ると、フロントエンドのデータの受け渡しや仮想 DOM の恩恵は確かに大きい。jQuery を使ってゴリゴリやっていた手続き的な処理と比べたら、どこで何が起きるのか、何がどう制御されているのか、といったものが格段に分かりやすくなると思う。

ただ、こうしたフロントエンド技術を RubyGems で導入して Rails アプリに組み合わせる場合は、Rails が用意するレールに乗らなくなる部分が多くなると思った。

「フロントエンドとバックエンドの分離」のための学習コスト

これは要するに「フロントエンドとバックエンドを分離する」ということなのだけど、それぞれの方面で依存する技術が増え続けることになりそうだなと思っている。

Bootstrap-Sass も、React-Rails も、コレだけを単体で使うならまだいいのかもしれないが、これ以外のフロントエンドパッケージを組み合わせたい場合、どうしても npm が登場することになる。そうすると中途半端に RubyGems で管理するものが混じることになり、扱いにくくなる。

そうすると、

といったことをしてやる必要が出てくる。

正直、あまりにもめんどくさい。

それに、Rails が提供する機能をこんなにも使わなくなってしまって、果たして Rails を使う必要があるのかな、と思ってしまった。

フロントエンドに寄せていた複雑さがバックエンドに寄せられるだけ

React の場合、ここから先色んな画面を構築しようと思うと react-router がルーティングにまで入ってきて、Rails 側が React に合わせにかかってあげるところが多いと思った。

世間のゴミシステムで Struts が生き残っているのって、「結局 Struts だけあれば全部できる」っていう環境の簡潔さ、学習コストの低さがあると思う。ほんで、ユーザ目線で言えば、たとえ Struts 製でも React + Rails 製でもそこは関係なくて、見たいものが見られる、やりたいことができる、ってシステムなら別に良いワケだ。

極端にいえば、MVC でそれぞれがうまく分離できてなくて、中身がちょっとぐちゃぐちゃになっても、どうせ何か変更する時はフロントエンドもバックエンドも手を入れることになる。だったらちょっとゴチャついてるのを受け入れて、1つの技術で完結できてた方がいいんじゃないか、ということだ。

Rails の場合も、Rails が用意するモノをちゃんと覚えれば、これで完結できますよ、というのが基本で、「よくやる機能は RubyGems で入れちゃうと楽になりますよ」って目的で RubyGems が出てくると思うんだ。「レールが用意されている」ことでシンプルになるし、学習コストもまだ低く済むと思う。

それなのに、React を入れるのでビューは Rails の Assets からは逸脱します、ルーティングも React 側でやっちゃいます、ってなると、「じゃあコントローラもそれに合わせてやるか…」ってなって、結局「フロントエンドライブラリのために書いたバックエンド」ができちゃう気がして、何だかなぁと。

これまで「バックエンドの作りのせいで、フロントエンドが仕方なく合わせに行っていた」という面倒で複雑な部分がバックエンド側に寄っただけ、みたいな気がしてしまう。それでいて、覚えることは「Rails 単体」で済んでいたことから、React.js の使い方、それを導入する Node.js と npm、ビルドに使う Gulp や Webpack、と、格段に増えてしまっている。

単なるスキルの問題？

正直、フロントエンド周りはかなりカオスになっていて、全然ついていけない。そして個人的には、それらを頑張って取り入れるメリットをそこまで感じられていない。

開発者としてのスキル、その技術に対する慣れの問題が多いのかもしれないけど、環境や MV* 設計に対して「オレオレ設計」なんてレベルの低いモノを混ぜ込んだら最後、絶対気持ち悪いものにしかならないと思う。

だから、どこに何を置くかとか、どういう名前を付けるとかいうルールは、Rails 様が考えに考えた効率的なレールに乗っておいて、ある種その不自由さ込みでいたい。「フレームワーク」という単語が「骨組み」という意味である以上、「骨が曲がらない方向」を決めることで単純化させることは必要だと思う。

だが、フロントエンドは今のところそれぞれが独自路線で進化中で、「オレのやり方に合わせればみんな自由になれるぜ」という感じがある。今までフロント側が払わされていたツケを、ようやく取り戻そうとしているようだ。でもそれらを個別に追い続けて、自分のところでうまいこと統合してやる、というのがダルくて仕方ない。

ぼくは「何でどう作るか (何の技術をどう組み合わせて作るか)」より「何をどう作るか (どういうシステム・アプリをどんな設計で作るか)」に重点を置きたいのだけどなぁ。

React 使うの止めるかも？

Rails アプリは個人的な趣味で作っているアプリなので、やりたくないことはやらなくていいし、好きに作って良いモノだ。

だから、学習コストが余計にかかる React を取り入れて、そのためのルーティングやフロントエンド資産の管理をしてやるのは、正直面倒臭い。少なくとも、RubyGems で導入するのではなく、npm で導入するようにしておかないと、中途半端に Rails に混ざり込んでる感じが抜けなくてつらい。

こんなことで悩むくらいなら、別にぼくは SPA を作る気でもないし、React を頑なに取り込んでも、得られるメリットが少ないなと思った。

参考にした記事

全体的に、「アプリ作るのにフロントエンドだけでココまで事前準備やらなきゃいけないの？」という感覚を自分は持ってしまった。