Laravel3 vs Laravel4
（追記：Laravel4正式版がリリースされました。多少、インストールが面倒ですが、Laravel4を採用することを現時点ではおすすめします。全体的な仕組みさえ理解してしまえば、3も4も、難易度はさほど変わらないものに仕上がりました。この先の、ライフサイクルを考えると、4のほうが断然有利です。）
Laravel4はベータリリースですが、今の時点で両方の使い所を考えてみましょう。
誰がLaravelを使っているのか？
Laravelがブレークするきっかけとなったのは、あるブログ記事で、「Laravelだけは、私を馬鹿にしなかった」と書かれたものです。
私の推測ですが、フレームワーク利用者は、大雑把に２つに分かれます。一つは主に個人で開発を行なっている人々で、スクラッチから（最初から）Webアプリを組み上げていく人達です。もう一方の人々は、大きめのアプリを複数人の開発者が集まるプロジェクトとして開発していく人達です。
フォーラムの書き込みや、フレームワークの機能から見て、ほとんどのユーザーが、小さなアプリを個人で開発している人々です。特に初学者が多いようです。
明らかに個人の開発者とグループでの開発者ではフレームワークに求めているものは異なっています。個人の開発者は、作りやすさ、開発の容易さを評価します。
一方、ある程度の大きさのプロジェクト単位で開発をしていく人にとっては、作りやすさや、開発の容易さだけを指針とするわけにはいきません。よりシビアな品質管理が必要とされるため、テストがやりやすいかというポイントも含まれます。
Laravel3
Laravel3が人気を得ているのは、学習の容易さが第一です。フレームワークの設計者が忘れがちなのは、何もかも詰め込めば便利なものになるのではなく、それぞれの構成要素を矛盾なくスムーズに結び付けなければ、使用者は理解に苦しむことになる点です。
その点、Laravelが幸運だったのは、開発者が一人で始めたプロジェクトであり、読み書きしやすい、車輪の再発明はしないことを初めからコンセプトに含んでいました。そのコンセプトに同意した人々がその後開発に参加したことで、統一性に関しては参加者の同意が得られやすいのです。
新しいフレームワーク学習時は、過去に使用したフレームワークの知識を持っていれば、それだけ容易ですが、他のフレームワークの経験が無いと理解できないものも多いのも事実です。そのため、初学者にはフレームワークを使い始める大きな壁が存在しています。
その点、Laravelはフレームワークを初めて使用する人が超えなくてはならない、壁が比較的低く、最初の壁を超えてしまえば、後はその統一性により、スムーズに学習が進められます。
そして、学習のしやすさを助けているのが、ドキュメントが読みやすいことです。この読みやすさが、壁を超えるのを助けてくれます。ただし、これは逆にある程度の知識がある人にとって「分かりやすい」ものではありません。いささか情報が分散しており、APIとサンプルを使ってまとめたほうが、ある程度のレベル以上の開発者にとっては、情報収集がしやすいと思われます。これは今後の改良点でしょう。
Laravel3は間違いなく、個人の使用者が中心です。メインの使用者は機能をや振る舞いを決め、設計し、ユニットテストを積み上げ、品質を確保しながら、じっくりとアプリケーションを作成する人々ではありません。手っ取り早く、自分の頭の中にあるアイデアをそのまま軽量なエディターを叩いて実現したい人々です。
LaravelはPHPに存在するものをわざわざ自前のクラスで用意しない方針です。そのため、PHPに存在する関数よりちょっとだけ便利なクラスをわざわざ用意しません。これにより、使用者は覚えることが減ります。
高速スクラッチ開発にはお誂え向きです。分かりやすいORMであるEloquentがそれを支援します。
ただ、どのORMでも同様でしょうが、ORMの機能であるリレーションを使用し、直接ORMクラスをあちこちのコードに入れ込んでしまうと、ユニットテストが難しくなります。特にLaravelは関係をテーブルのJOINで実現するのではなく、関連先のモデルのインスタンスを関連元のインスタンスに付属させる方法を取っているため、テストスタブの作成が難しくなります。
ですから、「高速開発」を目的とする場合は、ORMをどんどん使用し、単体テストはしないくらいのスタンスで行えば、とても使いやすいのです。実際、拡張機能のバンドルなどを提供する目的ではなく、個人でアプリを作成する多くの開発者は、このスタイルでしょう。
逆に、「品質重視」の大型案件であれば、ORMを使用するより、クエリービルダーを使用するにとどめ、テーブルアクセスを直接ビジネスロジックに入れ込まないで、別のクラスで仕立てることでてスタビリティーは上がります。（まあ、当たり前のことですいません。）
Laravel4
高速スクラッチャーにとって利点となるのは、Composer上に乗っかったことで、ある程度方針が決まっていれば、環境を整えることが容易になることでしょう。
逆に方針を決めるまでには、色々と迷うことが増えています。例えば、Laravel3に存在したHTMLクラスとFormクラスは無くなりました。理由はComposer上には、その役目をするパッケージが多く存在しているからです。さらに、Laravel3と同機能のパッケージをComposer上で提供している開発者もいます。
つまり、どの様にビューを実現するかについて、スタンダードな方法はなくなり、各個人が選択する必要がおきます。これは自由度を増しますが、経験が物を言う部分でありますので、Composerで何ができるのか、どの様なコンポーネントが用意されているのかという知識がなければ判断できません。そのため、ビュー周りの方針を決めるため、自分の頭で考える必要があります。（今までのように、気軽にフォーラムで質問しても、書く個人の使用しているパッケージがバラけるため、答えが得られる可能性が低くなります。多分、結局は長いものに巻かれることになり、一番使われているだろうパッケージに人気が集中するでしょう。）
高速スクラッチャーにとって、ORMが多少強化されたことと、Artisanコマンドによる生成機能が向上したことは利点ですが、今のところ結構バグがありますし、全体的な手間を考えると、Laravel3のほうが向いているのではないかと思えます。
Laravel4における重要な強化点はIoCコンテナがコアで一層活用され、またSymhonyのコンポーネントを更に取り込むことでテストアビリティーが向上したことです。これによる利点は大きなプロジェクトになるほど生きてきます。
しかしながら、テストアビリティーに関する部分がフレームワーク選択の重要点であるならば、Symfony2などのビッグフレームワークを使用したほうが、利点が大きいと思われます。
実際、ユニットテストの強化に関してはSymfony2をライブラリーとして活用しています。ただ取り込んでいるだけでなく、上手くまとめています。慣れてしまえば、そう違和感を覚えないと思いますが、詳細を確認する場合は、Symfony2のドキュメント参照しなければなりません。
そのため、大きな案件をLaravelに持ってくるというのは、やや難しいかなと思います。フレームワーク経験が少ないPHP開発者が集まり、初めから学習する必要があるのであれば、学びやすさという利点を生かせますが、ある程度の経験者を集められる場合であれば、やはりビックフレームワークのほうが有利でしょう。
そう考えると、いささか中途半端な感じがします。今の人気を分析し、考えるのであれば、もっと高速スクラッチャー向きの機能を強化したほうが、良かったのではないかと思えます。
今はまだ、ベータ版ですから、完全に結論を出すには早いでしょう。ある程度開発に使用されるパッケージがかたまり、それらに対する記事が増えた時点で、Laravel4は本格的に人気が出るでしょう。もし、デフェクトスタンダードとなるバッケージなどが決まらず、多くの人によりバラバラのパッケージが支持されると、情報も分散し、Laravelの人気は危うくなるでしょう。