今や、画面(UI)の動きを JavaScript で行う事は当たり前になりましたね。
ひと昔前までは画面に表示する要素は、全部サーバー側が html で作成して javascript は「必須項目に値が入っているか？」といった、
単純な入力チェック位しか使われていませんでしたが、今では画面の html（DOM） まで javascript で動的に操作して、
画面のレイアウトを自由に変えられるようにまで変化してきています。
究極的には、SPA(Single Page Applicarion) のように、サーバー側での画面レイアウトは一切不要という考え方にもなっています。
従来のサーバー側でのフレームワークとはいったい何だったのでしょうか？
もともと私は MVC といったフレームワークには懐疑的でしたので、当然の流れかと感じています。
さて、とは言えアプリケーションにおいてはデータの保管や参照といった処理が必要です。
そこで、javascript からサーバーへ依頼や問い合わせを行う手段が必要です。その為に使われるのが Ajax です。
Ajax と言っても、従来の http 通信を行うので、<form>タグの submit やページリンクを押した時の操作が javascript で行えるというだけです。
大きな違いは、サーバーからの応答に画面の html が反映されないので、画面のレイアウトも javascript 側が行わなければならない という事です。
クライアントとサーバーの主従関係がほぼ入れ替わっているのに気が付かれたと思います。
とは言え、サーバー側の処理が全く不要になった訳ではなく、考え方が変わったということです。
今から、「サーバーサイドのフレームワークをどうしよう」と考えているなら、何も使わないのが正解ではないかと思います。
JSP(java) を私は使っていますが、Ajax を使うのであれば、他のどんな言語を使っても大差ないと思います。
むしろ重要なのはサーバー側が何を、どう処理するかを規定した API(WEB API) をちゃんと設計する事だと思います。
簡単と言ってしまいましたが、実は Ajax の処理では注意点があります。それは Ajax の処理が非同期だという事です。
簡単なものではそれほど意識しないのですが、サーバーから応答が返るまで、画面は止まっておらず並行して動いています。
従来なら、応答が返るまで画面は固まっていましたが、Ajax では画面操作や別の処理が継続して動いています。
ユーザーの操作性は良いですが、処理を行う側はそれを考えて作る必要があります。
何が言いたいかと言うと、結局 Javascript の知識が重要になります。
これじゃら先の私の話題では、JSP というよりむしろ Jacascript のほうが多くなります。
時代の流れですね。
| « 前頁 | 次頁 » |