フルスタックフレームワークは大規模サイトに向いているのか？

シンフレームワーク（薄いフレームワーク）とフルスタックフレームワーク（重厚なフレームワーク）はどちらが良いのか。
もう少し言えば、どちらがどういうものに向いているのか。最近の私の考えを書きたい。

ザックリとしたイメージ

まず前提として、開発言語におけるフレームワークに、デファクトスタンダードが無いことがあると思います。
例えば、rubyにおいてはほとんどrails一強で、マイクロフレームワークとしてのsinatraなどはあるものの、railsの普及度には一歩劣るところでしょう。
その言語での事実上の標準が決まっているほどにシェアを持っているものがあるのなら、コミュニティのノウハウの集約度的にそれを使うのが良いと思います。枯れているという意味で。

大規模開発に向いているのは

フルスタックフレームワークとシンフレームワークの比較だと、前者は大規模開発に向き、後者は小規模なアプリケーションに向いているという説明が多いように私には見受けられます。
まぁどれぐらいからが大規模というのか、という問題は人や会社によって異なるので、別に定義をしようとは思いません。
しかし、基本的にこれは逆のことが多いのではないか？と最近常々思っています。

つまり、シンフレームワークは大規模開発に向いていて、フルスタックフレームワークは小規模なアプリケーションに向いているということです。

理由としては簡単で、プログラム全体のサイズが大きくなればなるほど、フレームワークの占める割合は小さくなります。つまり相対的に自作した時との差が出ない。
ならば、限定された機能群を持つ薄いフレームワークを採用し、必要な部分を自作していくというのは、システムの柔軟性において大きな価値になります。
railsでもよく言われることですが、railを踏み外す（フレームワークの流儀に沿わない設計を行う）と苦労が大きい。ならば最初からrailが引かれていないフレームワークは有利。

オレオレフレームワークが一般的に嫌われがちなのは、メンテが滞りがちになってしまうことや、低品質なフレームワークになってしまうことを嫌うからだと思います。あとはドキュメントが整備されていないことによるメンバーの学習コスト。

とは言え、じゃあフレームワークのメンテが滞りがちになってしまうような開発体制の会社で、キチンと社外製のフレームワークのアップデートに追随できるのかとか、開発やサポートが止まっても自分でパッチ当てれるのかは甚だ疑問です。
まぁそういう開発体制のチームだと、低品質なフレームワークになるのは、むべなるかな。
ドキュメントに関しては、懸念点は正しいと思います。なにせドキュメントを作るコストというのはそれなりに重く、ある程度知名度のあるフレームワーク級に纏まっているドキュメントはジョインしたてのメンバーにとって価値あるものです。

なのでまぁ薄いフレームワークに、業務やプロジェクトに合わせた内製ライブラリて組み合わせが、大きな開発だといいじゃないかなーと。
アプリケーションの仕様をフレームワークの仕様に寄せる権限があったり、フレームワークの流儀に乗って、作りきれるならフルスタックフレームワークOKかと。後プロトタイプとか。

rails1.6～2.0ぐらいの頃にこういうこと言うと、railsでも大規模サイトできるよ！twitterとかそうだよ！みたいな話が絶対出てましたけど、当時のtwitterのサイズでもrailsの恩恵をどの程度受けていたかは疑問です。プロトタイピングの段階はともかくとして、当時のサイズでもまぁActiveRecordにおんぶ抱っことか絶対無理だし、確実にコア部分にも手を入れまくっていたでしょう。

まぁそういうことが読めるんだったら、逆に大変ってのも読めるよねー。みたいな話です。