■

id:koichikさんの日記（これ）に反応。

単純なフレームワークは理解するのは簡単かもしれない．

しかし，手間が少ないという意味の簡単さはもたらしてくれないかもしれない．

なんてことを，Click のサンプルを見て思ったり (人によっては「コード書いてる感」が味わえて楽しいそうですが)．

フレームワーク側でアプリケーションの手間を減らせるものなら減らしてあげたい．

それによってフレームワークは複雑になるかもしれない．

それはトレードオフかもしれない．

もしトレードオフだったらどこでバランスを取るか？

これは確かにトレードオフだと思います。
ユーザの利便性を追及していくと、どうしてもフレームワーク側で対処しなくちゃいけない事が増えます。
しかし、それがフレームワーク自体の内部構造を複雑にしてしまうことは事実でしょう。
これってその作る人・使う人の立ち位置によっても見え方が変わると思います。
例えば、シンプルなフレームワークは一般的にフレームワーク開発者には喜ばれそうです。
何故かと言うと組み込みやすいから。
機能足りなくても、足せばいいじゃん。組み込んじゃえばいいじゃんで済むので。

ただ世の中そういう意見の人ばかりではありません。
何かの記事で読んだのですが、Railsは内部構造が多少汚くなっても出来る限り
フレームワーク側で処理してユーザの手数を減らして効率的にしてユーザの手数を減らすことを
目的としているようです。Railsは既にフルスタックで一通り揃っているのでそのままユーザが
使って開発できることを目指しているのでしょう。間違ってたら教えてください＞Railsな人

このようにどこに軸足を置いているかでずいぶんその使い方も変わります。
これは各フレームワークのポリシーなので、それぞれのあり方があっていいんじゃないかと思います。
自分はポリシーが見えるフレームワークは好きですね。使うかどうかはともかくとして。
こういうポリシーがあるフレームワークはopinionated-frameworkとか呼ぶそうです。
自分は確かTapestryでこの言葉を知りました。例えばTapestryもHLSさんがかなりのツワモノなので、
強いポリシーのもとガッチリ作られています。

ただ実際の現場では、このポリシーの違いを意識できていないと思わぬところで
足止めを食ったりします。優秀なフレームワーク開発者があれとこれとそれで、ポリシーの違いを
吸収できる層をもうけてささっと作れればそれはよいことですが、普通のエンジニアでも
人手不足の時代にいつもそうできるとは限らないわけです。
というわけで、フルスタックなフレームワーク、つまりポリシーに一貫性があるフレームワークは
、経済性・効率性・利便性の面でも最近の世の中の流れだというのも納得できます。

手前味噌なTeedaではどうかというと、フレームワーク側でなるべく対処のポリシーですね。
これはChuraとしてそうなので、Teedaだけの話ではないですけど。
JSFとしてもどちらかというと、そういう匂いをかなり感じます。
もともとコンポーネントのカスタマイズの敷居はそれなりに高いので、誰にでも門戸が開かれているような作りにはなってません。
がしがし書けばそりゃあ出来るけどねえって感じ。
JSFの拡張性に関してはそれなりに思うところはあります、正直。
（もしかしてこの辺はTeedaでは対処できる余地があるのかなあとも思う）
例えばMyFacesも、かなりリッチに色んなコンポーネントが存在します。
正直よくこんなに作ったなあーって関心するくらいある。

フレームワーク側でなるべく対処となると、やるべきことが爆発的に増えます。
本当に山のようにあるしｗ
色んなユーザビリティの部分でも、もっとやれることはあるのです。