jQueryとサーバレンダリング
jQueryとサーバレンダリング:
今の職場でもそんな意見はよく耳にする。世の中は、AngularとかTypeScriptとかWeb開発技術は10年前とは大きく変わっていることはもちろん、そんな技術を使って開発したいと常々思っている。
でもね、世の中にはまだあるんですよ。
予算や人的リソースの関係で過去の遺産やノウハウを使い回しでやりくりしないといけないプロジェクトや、「ローカルネットワークでしか動作しないから」という理由で、いまどきStruts1とか使って動いてるシステムが。
そんな滅びの呪文を唱えたい化石システムであっても、仕事となればメンテナンスしていかなくてはならない。
でも、だからこそ、そんな10年前の技術をバリバリ活用するプロジェクトではjQueryって本当に重宝する。
これからJavaScriptを勉強し始めるビギナーにとっては、廃れ始めたjQueryよりVue.jsみたいなモダンなフレームワークを学んだほうが有益かもしれないが、食わず嫌いはよくないよね。
あと、Struts1に比べたらjQueryはサポートも続いているし、何よりもその手軽さ、シンプルさは今でも変わらない魅力があるので、個人的には生き残ってほしいと思っている。
そんな、古臭い技術を使う現場で働く人間にとって、なくてはならないjQueryを改めて勉強し直して感じた感想を記事にまとめてみる。
個人的には以下じゃないかと思う。
ちなみに、モダンなフレームワークだとDOM操作は嫌われていて、避けるべきとされているけど、その理由は画面上の見た目と管理したいデータがごちゃごちゃになるのを避けたいからというのが理由の一つだと思っている。
でもこれは設計次第で軽減できることなので、jQueryを嫌う理由とは違うのではないだろうか。
ひとことで言うと 昔のやり方で開発するなら超便利ってこと。
昔はJavaScriptでオブジェクト指向やMVCな設計をしようとすると、かなりトリッキーな方法で実装しないといけないのが普通だった。だからこそjQueryが重宝して、jQueryがあれば古いブラウザでも簡単に実装できた。今保守しているシステムも、Windows7のIE9とか、VistaのIE7だったりするので、そんな環境ならjQueryは超便利。
あと、jQueryが得意とするDOM操作だが、画面がSinglePageでなく、Struts1みたいなサーバレンダリング方式ならむしろ積極的に使わなければならない。サーバレンダリングだとページ遷移で毎回メモリ解放されるから、管理したいデータは毎回消えてしまうし、ページ遷移後も同じデータを持ちたいならレンダリングされた画面から取り直さなければいけない。これは画面遷移後にDOM操作が必須になることを意味するので、jQueryの得意とする分野になる。
また、メモリ解放が画面遷移の都度行われることは、以下のメリットもある。
今はかろうじて動いているstruts1なシステムも、いつかはリプレースするときが来る(と信じている)。jQueryを使った現役コードは、その時に別のフレームワークに置き換えられるかもしれない。注意すべきは、そんなときのことを考えてコーディングすることだと思う。
流行りのモダンなフレームワークの使い方や設計思想を理解した上でjQueryと向き合っていくことは忘れてはいけないことだろう。
世間一般はSinglePage、サーバレンダリングはもう古い
今の職場でもそんな意見はよく耳にする。世の中は、AngularとかTypeScriptとかWeb開発技術は10年前とは大きく変わっていることはもちろん、そんな技術を使って開発したいと常々思っている。でもね、世の中にはまだあるんですよ。
予算や人的リソースの関係で過去の遺産やノウハウを使い回しでやりくりしないといけないプロジェクトや、「ローカルネットワークでしか動作しないから」という理由で、いまどきStruts1とか使って動いてるシステムが。
そんな滅びの呪文を唱えたい化石システムであっても、仕事となればメンテナンスしていかなくてはならない。
でも、だからこそ、そんな10年前の技術をバリバリ活用するプロジェクトではjQueryって本当に重宝する。
これからJavaScriptを勉強し始めるビギナーにとっては、廃れ始めたjQueryよりVue.jsみたいなモダンなフレームワークを学んだほうが有益かもしれないが、食わず嫌いはよくないよね。
あと、Struts1に比べたらjQueryはサポートも続いているし、何よりもその手軽さ、シンプルさは今でも変わらない魅力があるので、個人的には生き残ってほしいと思っている。
そんな、古臭い技術を使う現場で働く人間にとって、なくてはならないjQueryを改めて勉強し直して感じた感想を記事にまとめてみる。
jQueryが嫌われ始めた理由
個人的には以下じゃないかと思う。- ブラウザが進歩して標準サポートする機能が多くなった
- 昔はjQueryで機能を補ってた
- ブラウザごとの機能差異がなくなってきた(統一されてきた)
- それまではjQueryが差異を吸収してくれてた
- JavaScriptという言語自体(ECMAScript)が成長した
- MVCの概念を実現しやすくなり、MVCなフレームワークが注目を浴び始めた
- クラスやモジュールの概念が強くなってグローバル領域に作られるjQuery(
$
)が嫌われる理由になってしまった
ちなみに、モダンなフレームワークだとDOM操作は嫌われていて、避けるべきとされているけど、その理由は画面上の見た目と管理したいデータがごちゃごちゃになるのを避けたいからというのが理由の一つだと思っている。
でもこれは設計次第で軽減できることなので、jQueryを嫌う理由とは違うのではないだろうか。
jQueryの強み
ひとことで言うと 昔のやり方で開発するなら超便利ってこと。昔はJavaScriptでオブジェクト指向やMVCな設計をしようとすると、かなりトリッキーな方法で実装しないといけないのが普通だった。だからこそjQueryが重宝して、jQueryがあれば古いブラウザでも簡単に実装できた。今保守しているシステムも、Windows7のIE9とか、VistaのIE7だったりするので、そんな環境ならjQueryは超便利。
あと、jQueryが得意とするDOM操作だが、画面がSinglePageでなく、Struts1みたいなサーバレンダリング方式ならむしろ積極的に使わなければならない。サーバレンダリングだとページ遷移で毎回メモリ解放されるから、管理したいデータは毎回消えてしまうし、ページ遷移後も同じデータを持ちたいならレンダリングされた画面から取り直さなければいけない。これは画面遷移後にDOM操作が必須になることを意味するので、jQueryの得意とする分野になる。
また、メモリ解放が画面遷移の都度行われることは、以下のメリットもある。
- DOMに登録したイベントも定期的に消える
- 「イベント管理地獄」に陥りにくい
- グローバル変数も定期的に消える。
- そのページ内だけだから管理できる範囲に収まる
注意すべきは移行するとき
今はかろうじて動いているstruts1なシステムも、いつかはリプレースするときが来る(と信じている)。jQueryを使った現役コードは、その時に別のフレームワークに置き換えられるかもしれない。注意すべきは、そんなときのことを考えてコーディングすることだと思う。流行りのモダンなフレームワークの使い方や設計思想を理解した上でjQueryと向き合っていくことは忘れてはいけないことだろう。
コメント
コメントを投稿