WEB開発モデルの簡単な分析_html/css_WEB-ITnose

WEB テクノロジーはインターネットの台頭とともに出現し、モバイル インターネットの発展とともにさらに多様化しました。

暗黒時代: 2005 年頃までは、いわゆる WEB 開発は主にアーティストの仕事であり、HTML/CSS はページ デザインの三剣士の 1 つとして、ほとんどの WEB プログラマーにとって必須のツールとなりました。 Javascript を使用できない場合は、できるだけ使用しないでください。ブラウザは IE のみを考慮します。当時、Javascript は、プロトタイプの継承、柔軟な構文、デバッグの難しさなど、非常に異質なものに見えました (IE での Javascript のデバッグでの苦痛な経験を覚えていますか?)。ほとんどのプログラマーは、フロントエンドの作業をやりたがりませんでした。最後に、Bindows が作成され、多くのプログラマーから成果物として賞賛されました。しかし、少し試してみたところ、カタツムリのように遅く、問題が絶えず、まったく実用的ではないことがわかりました。当時のブラウザは Javascript エンジンの最適化を重視していなかったことがわかります。それらは Web 開発の暗黒時代でした。 ルネッサンス: 2005 年頃、徐々に誰もがユーザー エクスペリエンスに注目し始め、AJAX テクノロジがますます普及し、WEB2.0 についての言及が非常に一般的になりました。こんにちは。当時、Java コミュニティは Struts/Spring/Hibernate のリーダーシップのもと、非常に活発で繁栄していました。ここでRuby On Railsの登場です！ 「コントラクトファースト」という概念により、SSH モードでの複雑な XML 設定方法が面倒になるだけです。新しい技術や新しいアイデアが次々と生まれる中、2006年にjQueryが誕生しました。 jQueryの登場により、WEB開発の暗黒時代は完全に終わりを告げ、WEB分野に「ルネッサンス」が到来しました。 Ajax テクノロジーの普及、WEB 標準化の徐々に進んだこと、ブラウザ市場の緩やかな変化などはすべて、この「復活」の証拠です。 何百もの花が咲く: Apple が 2007 年に最初の iPhone を発売してから今日で 6 年以上が経過しました。この年は、モバイル インターネットがその始まりから急速に発展した年です。ユーザーエクスペリエンスの究極の追求は、WEBテクノロジーにさらに大きな変化をもたらしました。 Javascript のサーバーへの移行により、node.js が可能になりましたが、ビジネス上および技術的な理由により、Flush テクノロジーは徐々に衰退しているようです。流体レイアウト、レスポンシブ レイアウト、アダプティブ、スキューモーフィック デザインなど、JavaScript に基づくさまざまな MVC フレームワークが際限なく登場しています。 、フラットデザインなどの概念が次々と生まれ、WEB分野では百花繚乱の時代です。

WEB 開発は、Java サーバー開発を行うのと同じです。多くの基本ライブラリと開発フレームワークの中から適切な選択をする必要があります。

jQuery: シンプルなチェーン操作で有名で、基礎となるブラウザ API をカプセル化し、ブラウザの違いを保護します。実装は現在最も人気のある基本ライブラリですが、HTML5 標準が主要なブラウザ メーカーに徐々に受け入れられるにつれて、jQuery の役割も大幅に縮小され、その配布パッケージのサイズが人々から批判されることがよくあります。 mootools: 当時 jQuery と競合していたフレームワークは、prototype.js と mootools でした。当時、プロトタイプは Ruby コミュニティから強い支持を受け、一時は jQuery に匹敵するほどでした。 Mootools は Java 陣営によってサポートされていますが、最初の 2 つほど優れたものではありませんが、その API 設計は Java プログラマーの習慣により沿っているため、急速に発展しています。少し前に、プロトタイプの作成者がプロトタイプの失敗を認めた記事を書いているのを目にしました。現在でも、基礎となるライブラリの選択の中で jQuery が唯一のものです。Dojo は、Java Swing に似た完全なフレームワークであり、基本的なものと、両方の機能が含まれています。ライブラリと多数の UI コンポーネント。 dojo は struts2 から強力なサポートを受けていますが、依然として世界的な地位を逆転させることはできません。extjs: 当時の Bindows と同様に、WEB 上のデスクトップ プログラムと同様の効果を実現します。当時、ビンドウズは性能の問題で戦場で悲劇的な死を遂げたが、それは間違った時代に生まれたとしか言いようがない。しかし、extjs の現在の運命も憂慮すべきものです。変化しないインターフェイス スタイルと操作モードは、Web の常に変化する本質的な特性、つまり jQuery に基づく宣言型 UI コンポーネント ライブラリに反しています。いわゆる宣言型コンポーネントとは、従来のデスクトップ プログラムのようにコードを記述してコンポーネントを作成および設定する必要がなく、最もオリジナルの HTML 宣言型の概念に従い、元の HTML タグに属性を設定するだけで目的の効果が得られることを意味します。 easyui に似た国産フレームワーク DWZ も同様のアイデアを持っており、Javascript に基づいた MVC フレームワーク、つまりブラウザーでの MVC コンセプトの完全な実装です。ご想像のとおり、このタイプのフレームワークには、クライアントでのマルチビュー データの同期の処理に大きな利点があり、クライアントの表示および対話ロジックの開発プロセスを大幅に簡素化できます。

上記の基本ライブラリまたは開発フレームワークの 1 つまたは複数を選択します。 , それは開発モデルを選択することを意味します。開発モデルの観点から簡単に要約できます:

従来の HTML+CSS+JS モード: このモードでは、開発者は大量の HTML コードを作成してページの表示ロジックを実装し、JS コードを作成して対話ロジックを実装する必要があります。これは最も伝統的な開発方法であり、エンタープライズ レベルの管理システム、電子商取引 Web サイト、モバイル WEB アプリケーションのいずれであっても、この方法で実装できます。この方法の欠点は、アプリケーションや複雑な対話型アプリケーションを使用する場合、JS コードの量が比較的多くなる点です。EXTJS などの開発者は、基本的にすべてのページを JS を使用して実装しません。 HTML コードを記述する必要があり、大量の表示ロジックと対話ロジックは JS コードを使用して完成します。この方法は単一ページのアプリケーションを実装するのに非常に便利ですが、開発者は JS と開発フレームワークのコンポーネント ライブラリを深く理解する必要があり、思考モードをコンポーネントベースの宣言型 UI に適合させる必要があります。開発モデル: easyui や国内の DWZ など、ページの表示ロジックは最初のモードと同様に HTML で実装されますが、最初のモードと比較して、このモードは表示ロジックの一部やさらには抽象化の点で優れています。従来のモードで JS に実装された対話型ロジックも、宣言型アプローチを使用して実現できます。これは、最初のモードの拡張であると言えます。クライアント側 MVC 開発モード: バックボーンなど、このモードは、ページの表示および対話ロジックが大量の JS を通じて実装されます。コードではありますが、データ モデルとそのステータスはクライアント側で維持され、ビューとモデルのバインド メカニズムを使用することで、JS コードの量を大幅に削減できます。

最初のモードは 3 番目のモードと似ています。どちらも HTML コードを使用して表示ロジックを実現し、JS コードを使用して対話ロジックを実現しますが、3 番目のモードはより抽象的なコンポーネントを使用し、HTML を使用して可能な限り多くの表示ロジックと対話ロジックを実現しようとします。このモードは、表示ロジックと対話ロジックを実現するために可能な限り JS を使用し、ページ レイアウトまたはページ コンテナーとして HTML のみを使用することに重点を置いているという点で 4 番目のモードと似ています。相対的に言えば、2 番目のモードは JS を使用してインターフェイス ビューのアセンブリを実現することに重点を置いており、4 番目のモードは JS を使用して完全な MVC メカニズムを実現することに重点を置いており、通常、ビューは HTML コード スニペットに基づいたテンプレートを使用して実装されます。

3 番目のモードは 1 番目のモードを拡張したものであるため、実際のプロジェクトで 3 番目の開発モードを選択してみることができます。1 番目と 3 番目のモードと比較して、2 番目のモードは主に開発方法に焦点を当てている点です。後者の 2 つは JS に焦点を当てており、後の 2 つは HTML に焦点を当てています。また、この 2 つのアプリケーション シナリオと適用範囲は非常に似ています。

4 番目のモードも 2 番目のモードと同様に、JS を使用してページ ロジックを実装することに重点を置いていますが、強力な MVC メカニズムにより 2 番目のモードとは本質的に異なります。 Gmail のようなアプリケーションの場合を想像してみてください。クライアントが最下位層で一連の電子メール データ モデルを維持していない場合、前述の 3 つの方法を単純に使用して現在の Gmail ページのインタラクション効果を実現することは非常に困難になります。

つまり、WEB 開発モードの選択に関して、現段階では、個人的には 3 番目のモードを優先することをお勧めします。アプリケーションの対話が非常に複雑である場合、またはより優れた対話エクスペリエンス (ローカル ストレージ、元に戻す、やり直しなどのサポートなど) を実現する必要があり、結果として大量の JS コードが必要になる場合は、4 番目のモードの使用を検討できます。