September 11, 2005

Web Frameworks explored

O'Reilly Network に掲載されてる DHH のインタビュー や LLDN でさらに最近話題になっているなあと感じる Ruby On Rails なわけですが、Rails の数ある特徴の中でも、以下の部分が一番大きなポイントなのかなと。

O'Reilly Network: Ruby on Rails: An Interview with David Heinemeier Hansson

ED: What's your favourite Rails feature?
DHH: In general, all the things it doesn't do. All the features we said no to. All the ornaments we turned down. All the 20% solutions that solve 80% of the problem.

Rails は何でもできるフレームワークでは決してなく、柔軟性を犠牲にすることで Less-Configuration を実現している、という部分。以前から Sledge のデザイン・開発をしていた経験からこの部分はよく理解できます。

Sledge の場合は Rails とはこの部分では逆で、 MVC の Model 部分は何でも使うことができて、それゆえにフレームワークを使い始めるまでの敷居が若干高い。が、いったん慣れてしまえばかなりの柔軟性と拡張性を手にすることができる、という具合です。ただ実際には Class::DBI をつかって CRUD するアプリケーションをつくるのが普通で、Livedoor の社内では Class::DBI でテーブルを指定すると SELECT / INSERT / UPDATE / DELETE する UI を生成するプラグインなどが転がってました。

また Rails に対抗して Perl 界隈で話題にあがるのは Catalyst なわけですが、ちょっと使ってみた印象では、Catalyst はそういう意味では Sledge とも Rails とも違うレイヤーにあるなという印象。

Stupidfool.org: Rails developers kill kittens!

Let's get this out of the way up front: I actually really like Catalyst. And I also really like Rails [1].

Ben のエントリにもあるように Rails と Catalyst にはマーケティングのよしあしという決定的な違いがあるにせよ、Catalyst は「CPAN にあるモジュールを徹底的に使いこなして、それをコンテナ的につなげる触媒(Catalyst) 的な動きをする」というのが一番のメリットだなあという風に僕は理解しています。ただ実際には、コンポーネントに実装すべきインタフェースの規定などがほとんどない (process というメソッドがデフォルトで呼ばれるぐらいか)ので、いちいちコンポーネントをつなげるのに自前で規定を決めないといけなくて、あまりサクサク気持ちよくは使えないのもまた事実。

TheRoadmap - Maypole

The primary focus of development at the moment is stabilising Maypole 2 by improving documentation and tests. The intention is to try and ensure backward compatibility.

Catalyst が生まれるもととなったフレームワーク Maypole もまだまだ開発は続いていて、実際にみてみると、こちらのほうが Rails + ActiveRecord に雰囲気が近いかもという印象。テンプレートもデフォルトでは TT しか使えなかったり、規約を増やすことでフレームワーク側で面倒を見る部分が増やせる部分もありますね。

まとめ

あまりまとまってませんが、Catalyst は企業やプロジェクト単位でのフレームワークをつくるベースになるメタフレームワークとして活用するのがとてもエレガントなんじゃないかなぁと思うしだい。実際に Handel というコマース系のフレームワークが Catalyst をベースにして出てきたりしているのを見ると、そういう見方もありなのかなぁと。また Rails のように規約がカッチリしたフレームワークはプラグインがつくりやすかったり (acts_as_taggable でモデルに Tagging を追加 なんてカッコイイですね)して、小さなプロジェクトなどでは学習曲線もなめらかというメリットもありそうですが、フレームワークの限界(残りの20%)に達したときにどう対処するのかもリスク要因にはなるのかなぁなどと考えてみたりしました。

Posted by miyagawa at September 11, 2005 01:54 PM | Permalink | Comments (0) | TrackBack(0)
Comments
Trackbacks
TrackBack URL for this entry: http://blog.bulknews.net/mt3/mt-tb.cgi/1807
Post a comment