この記事ね。ちょいと炎上してるけど、言ってることはわかるんですね。
今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」
タイトルが誤解を生んだので妙な方向になってるようですが、要するにRailsやCakeを使うための学習コストを払おうとして悶々としてるくらいなら、普通のHTMLやSQLを使ってPHPなどを書けるようになってから、フレームワーク勉強したほうがいいんじゃね？ということだと思います。
ノーフレームワークのPHPって、ある意味、学びの材料としての粒度として最適なのかなって最近思ったりしています。
例えば個人的にフレームワークで過剰かもなって思うものに「オートリンク作成」「オートフォーム作成」の２つの機能があります。
オートフォーム作成は、それこそSmartyの頃からありますけど使ったことがなくて、何故にHTML生成を特殊な関数に置き換える必要があるのだろうか？と思ってました。例えば、コーダーが書いてくれたHTMLをわざわざ、フォーム作成コマンドに置き換えることに価値があるのか？！
もしくは、こういった特殊なメソッドは、少しHTMLがわかりにくくなるトレードオフに対し、何か生産性に返ってくるのだろうか、と考えることがあります。一番最悪なのは、自由度が下がり、やりたいことができなくなるというケースで、それを回避するのに、本当は、目の前に答えが見えている、ただのHTMLを書きたいだけなのに、いろんな技を使って時間をかけてしまうということに本末転倒感を感じるのは、割とよくあることです。
一般的にフレームワークというコードを通すからには、何もないPHPコードに比べて実行速度は確実に遅くなります。キャッシュを挟んでいるのは、その処理コストをどうにか誤魔化すからということがよくあります。そのために今どきのフレームワークは高度なキャッシュ管理機能になっていくわけですが、それらのコストを支払う正当な理由があるからこそ、フレームワークは支持されているのだと思います。
その理由は、
１．セキュリティ・ホールの作りこみをフレームワーク側で抑止したい（SQLインジェクション、その他）
２．ViewのコードをできるだけピュアなHTMLに近い状態にしておきたい。
３．プラグインで、他人が作った高度な機能を簡単に使えるようになる。
などがあげられると思います。特に実装が面倒くさいものがプラグインで提供されていると、本当にありがたく実装させてもらっています。
ただ、効率的なプロダクト管理ができることや、素敵なプラグインで楽ができるという可能性の面と、技術を学ぶことや良いサービスを作ることは、必ずしも一致しない話でありまして、特にプロトタイプに近い状態のサービスが、必ずしもrailsやcakeである必要はないのかもしれません。
意外と世の中、実情を聞いてみると、フレームワークを使わずピュアなPHPで作られたサービスが世間をあっと言わせているケースがありまして、「信用できるプログラマーが書く場合、ピュアなPHPが一番良い」というのもまた真なり、ということなのだと思います。
と書くと、そんなのアセンブラやC言語でも同じじゃないかと思われるかもしれませんが、フレームワークを使わないという選択が、そこまでの話ではないと思ってるし、Webプログラマーとして知っておいて欲しいミニマムな部分を学ぶ方法が、フレームワークを使わないことで得られるのであれば、本来は、一度、そこで勉強するのが一番ベターなハズです。
それが冒頭の記事は賛成だと思った理由です。ただフレームワークが持つ高機能な部分を否定するのはいささか難しかったと思います。そこは、まぁフレームワークを学んで活用している人が得られる特権ということで良いのではないでしょうか？！
で、こういう話を書くと、はてブのコメントが炎上してネガティブな反応が面倒くさいのですが、フレームワーク使うの当たり前じゃん、という観念から一回解き放たれてみると、フレームワークを使って良いことはあるけど、使わないことでのデメリットもそんなに多くない、というのがどうもあるように思えて仕方ありません。
アップルのWebフレームワークで、WebObjectsってのがあるんですが、XCodeのような開発手法でWebを開発できるという素晴らしいフレームワークと開発ツールのセットでした。しかし、ピュアなHTMLからいじりたい人には、どうにも使いづらい。開発ツールが今のXCodeぐらい完成されていればよかったのかな。ただし、スマホアプリみたいなプログラミングになるので、Webプログラミングしてる感はなさそう。またColdFusionっていう今Adobeが権利を保有してるXML記述のフレームワーク言語がありまして、昔のCookpadさんがそれを使っていたのですが、これもある意味高度すぎたように思えます。その後、CoodpadさんがRailsに乗り換えてから、人材採用においても輝かしい成功を収めたのは御存知の通り。
フレームワークが高度になっていくと、どこかで「行き過ぎる」部分が出てくることがあるようです。何故行き過ぎるかというと、HTMLがものすごく柔軟にテキスト処理とDOMが結合したパラダイムであり、オブジェクト志向やヘルパーメソッドで標準テンプレート化（カプセル化）することと相反するシーンが多いからだと考えます。
そのたMVCのデザインパターンやXMLからYAMLなどのトレンド変化も含めて、葛藤が増えていくたびに新しい技術にスピーディに適応した、軽量シンプルなフレームワークが出てきて時代が循環していくのだと思いますが、そういう変遷の中でも、少し危うく、比較的プリミティブで、かつ一番柔軟なものがピュアPHPの粒度なのかなぁなんてイメージしています。Perlはわかるけど、Rubyはどうなんだろう。RubyでRailsを採用しないという選択肢は現実的なのだろうか。
今後は、リアルタイムWebに対応した高速かつスケーラブルな方向で末永く使える職人型フレームワークと、よくある構造のWebを低コストで作るためのフルスタック方面に分かれてほしいと思いますね。Twitterがrailsを捨てたのが記憶にありますが、予測ができないアーキテクチャに対応するシンプルで絶妙なものってのは常に需要があると思います。例えば一切、RDBを使わないサービス、とかね。
個人としてどうするんよ？！という部分は、もちろん就職する先が特定のフレームワークに依存してしまっている場合は、その知識があることが望ましいという話になりますし、MVCフレームワークを全く知らない＝今どきのWeb技術に無頓着だ、と判断されてしまうこともあるので、ノーフレームワークで貫くのがベストだとは言いません。その辺はトレンドと連動した話なんだろうなと思います。
また、人材募集をする側にとっても、現状フレームワークなんていらないと思ってるのに、募集ウケの問題でフレームワークを使わなくちゃとか、PHPで作られてるサービスをRubyに切り替えなきゃいかんのかと思ったりもするという本末転倒なことを思うケースもあったりして、それはプログラマーのキャリアパスの一助になるためなの？そもそも、そういう人が欲しかったんだっけ？！と悶々とすることもあり、世の中、難しいよなぁとは思ったりもするわけです。
結論としては、そういうことを考えながらも軽量フレームワークを探そうかなと思ってるわけです。M+V+Cが緩やかに存在していて、ちょっとしたヘルパーメソッドがあればそれで十分で、オートリンクとかオートフォーム生成に依存しない感じで、HTMLを組み込むのが簡単な今どきのPHPで問題なく動くフレームワークを探しています。
【PR】ご意見、感想などは是非、mstdn.fmのローカルタイムラインでお聞かせください