November 16, 2005

妙なカスタムタグよりも先にHTMLやJavaScriptを書きたくなる人には、Webフレームワークは厳しい？

ASP.NET Webアプリ開発の裏事情 > エピソード9：「モバイル対応」と闘う

ある意味、問題点はこのリンクに集約されているかな。Strutsを使ってて感じるのは、

・今まで当たり前のようにできていたことが、できにくくなった。
　（正確に言うと、統一感を得る代わりに、ユーザビリティ主体にできていた個別のメッセージハンドリングやリンク制御とかが、Strutsのアーキテクチャに従った結果、自在に制御するのが「面倒くさい」。設計の問題なのは重々承知で、あえて書くが。）
・タグが覚えられない。HTMLを書いたほうが速いので、もどかしい。
　（Strutsのattribute規則は直感的でないと思う。スキーマに機能を無理やりあわせこんだ感じがプンプンする。）
・同様にJavaScriptとHTMLの結びつきが遠くなり、サーバサイドとHTMLが近くなって、たまに何やってるんだろ・・とか思う。
・カスタムタグは、デザイン（HTML）とデータの分離ができなくなる。
・forループが入ったタグは、カスタムタグにしようがスクリプトレットにしようが、ASP,PHPにしようが、どんな記述法を使っても同じで、扱いにくさは全く改善されない。（つまり今の発想では諦めろってこと。）JSPとの違いはあるけどね。ぬるぽから解放される。要は身内の改善。

Webフレームワークとしては、２極化が進んで欲しいと思っている。
それは、Webデザイン（HTML）ドリブンか、エンタープライズドリブンかのどちらかである。

「Webデザイン（HTML）ドリブン」は、HTMLやJavaScriptを直接いじったほうが速い人たち向けのフレームワーク。
「エンタープライズドリブン」は、そういうのが全然ダメな人向けの主に企業システム向けフレームワーク

前者は、HTMLやJavaScript,Ajaxとサーバサイドの結びつきは薄い。オブジェクトデータのやりとりを如何に簡単にするか？が重要で、HTMLを壊さず、自由度を損ねないようにする。その代わり、デザイン融通性やデザイン変更のメンテナンス性を最優先にできるため、デザイナー、コーディング工程の成果物を如何にそのまま反映できるか？を追求。

AjaxもJavaScriptライブラリをそのままカスタマイズするようなノリで開発する。
開発に必要な知識は、基本的にJavaScriptやHTML、そしてWeb技術そのものである。学習のアプローチそのものがハックに近い。

（例：フレームワークとして良いのはまだない？PerlやPHP系のライトなテンプレートエンジンがあえて言うならここか？Ruby on Railsもこっちだよね？）

適度なバランス間が重要。フレームワークが肥大化していくことが寿命を迎える第一歩。ビジネスにはなりにくい。

後者は、ガチガチのライブラリで固める。HTML（Flash）のUIコードなんか書く必要がないぐらいが理想。その代わりデザイン自由度も低いというか、反映するのが結構大変。VBライクであることとサーバで何でもやりたいという発想が原点で、何よりクライアントコードをいじるのがリスクと感じる人向け。
（例：ASP.NET,Struts,JSF,Flex、最近出たAjaxをサーバ側のRPCでどうのこうのとか言う奴もこっちかと。）

開発に必要な知識は、何よりフレームワークの知識であり、そこから生成されるコードは二の次で良い。まずはフレームワークの範囲に収まる努力をが求められる。

将来的にはVisual Basicのようにウインドウアプリが、さくさく作れてしまうのがゴールと思われる。プロダクトビジネスとしてはこっちが本命。

当然、僕は前者派なのであります。