あらためてアプリケーションフレームワークのことを考えている。フレームワークってふんわりした言葉で、まあでもだいたいあれとかそれとかのことをフレームワークって呼ぶ。
ぼくがはじめてフレームワークをがっつり触ったのは携帯電話の組み込みアプリケーションを開発する仕事をしていた時期で、携帯電話の組み込みアプリケーション用の UI フレームワークを使ったりしていた。Symbian OS という携帯電話向けの OS だったので OS 提供のフレームワークだったわけなんだけど、これはどこまでが OS 提供の機構でどこからがアプリケーションフレームワークなのか曖昧だった。
たとえば VC++ でも MFC はフレームワークだけどクラスライブラリでもあり、文字列や可変長配列みたいな基本的なデータ構造のためのクラスも MFC が提供する。.NET Framework は名前からしてフレームワークという名前だけど、これだって C# のVM 込みのもので、じゃあフレームワークってなんやねん、となる。
Ruby on Rails はウェブアプリケーションフレームワークの代表だけど、その内訳はけっこう込み入っている。
Rails 以降ウェブアプリケーションフレームワークっていう言葉が Rails みたいなものみたいな感じになってしまったけど、Rails を触っていると Symbian OS のどこからが OS 提供の機構でどこからがアプリケーションフレームワークなのかわからない、というのを思い出す。
Active Support は Ruby のコア機能を拡張するので Rails から入った Ruby プログラマはある機能が Active Support 提供なのか Ruby の標準添付ライブラリのものなのか判然としないという話も聞く。
別にウェブアプリケーションフレームワークは ORM を備えていなくてもいいし、テンプレート機構を備えていなくてもいいし、ルーティング機構を備えていなくてもいいし、HTTP サーバ機能を備えていなくてもいいし、クラスライブラリを備えていなくてもいい。それらはそれぞれ別の互いに独立したライブラリをプログラマが自由に組み合わせて実現してもかまわなく、実際ウェブフロントエンドではそうなっている。React と Next.js のようにあるフレームワークをラップして別の機能と結合したフレームワークというのも存在するが、だからといって React はフレームワークとしては不足しているということにはならないし、 Next.js がフレームワークとしてのあるべき姿ということにもならない。
現実の問題において、完全に同一な対処が可能なものは存在しないと思っている。現実の問題を細分化してみるとよくあるケースとして分類できるようになるのであって、現実の問題それ自体はよくあるケースの集合体であって、その集合が同一の問題というのは存在しない、ということである。
だからよくあるケースを広くカバーするフルスタックフレームワークというのが求められるのはそうだし、実際それでカバーできてきたわけだけど、だんだんとそれも無理になってきたんじゃないの、と思っている。
よくあるケースをフレームワークがカバーしてくれるので一番解決したい本質的な問題に注力できてうれしい。本当にそうなっていますか？
よくあるケースをカバーするためにフレームワークが無理している部分に忖度して、やり方を捻じ曲げないと解決したい事象に向き合えないことが実際には起こっていて、いっそもうフレームワーク捨てたほうがいいんじゃない？みたいなことを考えて正気に戻るということを繰り返す。自分の足を撃ちたいとか言い出してしまう。
現実の問題のよくあるケース単位でマイクロサービスで解決してプログラマがそれを組み立てる、というやり方なら、その組み立てのコストはかかるけど、そのかわりにやりたいことのために鋳型から直さないといけないみたいなことは回避できる。
解決すべき現実の問題は年々多様化しているので、単一のすごいフレームワークがそれを解決してくれるようになることはおそらくもうないんじゃないかな、と思うし、Protocol Buffers だったり Web Component だったりが普及した未来においては、フレームワークがそれらを肩代わりするために独自のライブラリを使わなくなって、標準化された技術の集合になっていったりするかもしれない、と思っているし、ウェブフロントエンドでは、わりとそうなりつつあるんじゃないかと思っている。だって、ある言語の処理系自体のサポートが手厚かったら、究極、クラスライブラリなんていらんもんね。
