フレームワークとは
フレームワークとは以下のように定義されています↓(Wikipediaより)
プログラミングにおいて、アプリケーションソフトウェアの標準構造を実装するのに使われるライブラリ（サブルーチンやクラスなど）の集まりである。
フレームワークは「枠組み」と言う意味を持っており、その名の通りアプリケーションをプログラミングするための枠組みがフレームワークと呼ばれています。
(ex.この処理したいときはこうしてね、など予め決められている)
一通り汎用性の高いライブラリや機能を標準で用意しているのが主な特徴ですかね。
何がいいのか
こちらは言及するまでもない気がしますが、自己満のためつらつらと書いていきます。
まずは、と言うかこれしかないと思いますが、爆速で開発を進められるということです。
フレームワークなしで開発する場合、処理の書き方やファイルの置き場までも自分で決めなければなりません。
が、フレームワークはあらかじめ、そう言ったものを用意してくれています。「その処理はここに書いてねー」だとか「それはここに置いておいて！」とか。それを明示的に示してくれている場合が多いので、開発者はそこをあまり意識せず、開発を進めることができるようになるんですよね。
これだけだと、「いや、そんなことはせずに1からじっくりと自分の形で開発したい」と思う方もいると思います。個人開発ならそれもいいと思います、そう個人開発なら。
ただ、こんな便利なフレームワークにも注意点があります。
便利さ故の落とし穴
前項ではフレームワークの便利さについてちょこっと言及しましたが、今度はその反対を語っていこうと思います。(いや、便利ではあるんですけどね)ここからは実際の現場目線も入ってきます。
実はフレームワークが光るには条件が実はありまして、、、
1. 対象のフレームワークに対して知見がある
2. 実装したいプログラムが比較的汎用な処理しか行わない
この2点が揃ったときに比較的フレームワークは光るんですよね...
1に関しては完全に現場目線のものです。(個人開発では時間が有り余っている場合が多いので除外。現場では常に時間との戦いが起きています。)
例として、とある開発でフレームワークを使うことになったとしましょう。
A「今回の開発でこんなフレームワーク使うみたいだけど知ってる？」
B「いや、使ったことないな」
A「え、じゃあ勉強しながらの開発になるってことじゃん」
B「いやいや、それは時間が...
だったらその言語なら知ってるし、1から作った方が早いと思う」
みたいなことが起きないとも限りません。(言語知ってりゃフレームワーク知ってるだろ、とかはなしで)
2に関してはプログラミングの深みを知るに連れて、フレームワークの存在意義を問い始める原因です(知りませんが)。
そもそも、フレームワークが存在してる意味が「汎用的なプログラムをまとめ、開発を楽にする」と言う所にあります。これはある意味、裏を返すと簡単な処理しかしませんよ(例外はあり)と言うことであり、応用的な処理を実現しようとしたときに、フレームワークの制限か何かで実現できない可能性がある、と言うことです。
とは言いつつも、フレームワークにいちゃもんをつけられるレベルになると相当に技術持ってるだなとも思ってしまいますが...
まとめ
個人開発はとりあえずおいといて、
・フレームワークは特定の条件下で光る
・慣れちゃえばめちゃくちゃ強い武器になる
・応用はあまり効かないことが多い
と言うことですね