Web開発でクライアント側に急ぎます

過去数か月の間に、私はWeb開発におけるクライアントサイドスクリプトについて大きな興奮を感じました。しかし、サーバー側の技術は成熟しており、安定していて、バックエンド開発者に受け入れられていますが、クライアント側の技術は未成熟であり（つまり、大きなサーバー側のフレームワークに比べて）、多くの老舗の開発者には嫌われています。それにもかかわらず、最近では誰もがクライアント側の開発を行っています。個人的には、これらの大きなサーバー側フレームワークが2〜5年で消滅し、現在の傾向を見ると期待しています。

どうしてこんなことに？HTML5 / JSで開発された新しい「びまん性」のクライアント側の開発は、大きくてよく考えられたサーバー側のソリューションよりも優れているのでしょうか。

これは本当です：

Web開発でクライアント側に急ぎます

しかし、それはクライアント側に限定されず、完全なスタックの動きです。

これは驚くべきことかもしれません。聞いてください。

どうしてこんなことに？HTML5 / JSで開発された新しい「びまん性」のクライアント側の開発は、大きくてよく考えられたサーバー側のソリューションよりも優れているのでしょうか。

まず、両方ともよく考えられています。

第二に、それが良いからです。

良い質問。

しかし、「より良い」とは主観的なので、あなたの質問に対する答えは、具体的には何がより良いのでしょうか。

質問に再度アクセスしてください：

HTML5 / JSでの「拡散」クライアント側の開発は、大きなサーバー側のソリューションよりどのように優れているのでしょうか。

Because small is nimble.
And big is clunky.

柔軟性です。

大したことではないようです。そうですか？柔軟性。

ただし、柔軟性がすべての根底にあります。柔軟性の1つの改善-すべてを改善します。

保守性。拡張性。スケーラビリティ。モジュール性。使いやすさ。UX。

そして、それは実装するのが速いです。これが現実です。より速く、より良い。

This is why Windows 8 made JS a first-class citizen.

HTML5-JSは流行ではなく、なくなることはありません。タブレットにコンピューティングコンテンツとインタラクション動作を提供するために成長するテクノロジーの種を見ているだけです。タブレット。

スマートフォンは、1950年代のテレビ以来、最速のマスメディア採用でした。今、私たちはスマートフォンを持っているだけでなく、タブレットも持っています。

MozillaおよびWindowsですでに開発が進んでおり、市場の将来のデバイスで動作するOS-> HTML / JS。

多くのソリューションとイノベーションが残っています。

柔軟性に基づいて、JSの完全なスタックが出現しています。

お役に立てば幸いです。

この物語には、常に2つの側面があります。サーバー側とクライアント側のコードには、それぞれ長所と短所があります。

クライアント側のスクリプトの利点は次のとおりです。

• サーバーのラウンドトリップなしで、応答性を高めることができ、広範な変更が可能です。
• コードはクライアント上で実行され、サーバー上のリソース使用量を減らします。
• ロジックとプレゼンテーションの分離は物理的になります。
• 特に要求ごとの認証が使用されている場合は、負荷分散が容易になる場合があります。

ただし、サーバーサイドスクリプトには多くの利点もあります。

• コードを実行するマシンを制御します。
• ほぼすべてのことが可能です。サーバーで実行できる場合は、スクリプトでも実行できます。
• ユーザーはスクリプトを実行する前に変更することはできません。
• ユーザーはスクリプトブロッカーを使用してスクリプトが実行されないようにすることはできません。
• ユーザーはスクリプトの動作を見ることができず、出力を観察することしかできません。
• このコードは、スクリーンリーダー、テキスト形式のWebブラウザー、検索エンジンスパイダー、スクレイパー、アキュムレーター、IRCボット、超低価格のマシン、スクリプトブロックされたブラウザーなど、想像できるすべてのクライアントで確実に機能します。
• ユーザープラグインが壊れる可能性は低くなります。

非常に動的なWebアプリケーションの場合、クライアント中心のアプローチが常に人気のある選択肢でした。これは、適切なレスポンシブデスクトップのようなユーザーエクスペリエンスを提供する唯一の方法であるためです。クライアント側のスクリプトなしでは、ユーザーのすべてのアクションにラウンドが必要です。トリップ、つまり少なくとも0.5秒の遅延、通常はそれ以上の遅延。しかし、基本的にはデータベース（Wikipediaなど）から提供される一連の静的ページである情報サイトの場合、利点はわずかですが、サーバー側スクリプトの利点は依然として圧倒的です。

観察された誇大広告は、最近の2つの進展の組み合わせから来ています。

1. HTML5とその関連技術のコロナ。時間がかかりすぎましたが、ハックを積み上げることなく動的なデスクトップのようなWebアプリケーションを作成するために必要なすべてを含む標準と、それらを適切に実装する主流のブラウザーがついに完成しました。
2. 利用可能な処理能力。今日の一般的なデスクトップPCはエントリーレベルのWebサーバーと同じくらい強力で、顧客グレードの携帯電話は事実上2005年のデスクトップコンピューターであり、最新のJavaScript実装はパフォーマンスバランスを調整するのに十分効率的です。今では、クライアント側のリソースはサーバーよりも安価です。リソース。

実際、サーバー中心のアプローチとクライアント中心のアプローチのどちらが優れているかという点では何も変わっていません。変更された点は、クライアント中心の方法がより簡単で安価になり、数年前よりもパフォーマンスが向上し、以前よりもはるかに多くのアプリケーションで実行可能な選択肢になることです。

サーバー側は常にあります。あなたはすべてのためにクライアント側に座ることはできません。たとえば、製造現場の天井クレーンからリアルタイムでパラメーターを送信するマイクロコントローラーにBackbone.js MVC設計を使用したくない場合があります。

誇大広告を信じてはいけない。

2009年に、サーバー側のPHPフレームワークからサーバー側のWebサービスに関連付けられたクライアント側のExtJSソリューションに切り替えました。

私にとっての移行の理由は次のとおりです。

1. サーバー上のエンドポイントとコードの量を減らすことにより、セキュリティを向上させます。
   Webサービスに移行することで、Webサービスの境界で入力を検証し、サーバーのI / Oをより正確に制御できます。セキュリティアーキテクチャを混乱させるサーバー側のUIレイヤーはありません。
2. サーバーラウンドトリップ
   の減少によるパフォーマンスの向上アーキテクチャが変更され、データフェッチの頻度が減り、データをローカルにキャッシュできるようになり、UIレンダリングでラウンドトリップをまったく必要としません。往復は、Webアプリのパフォーマンスを低下させるものです。
3. UI
   のキャッシュ機能によるパフォーマンスの向上UIレイヤーはCDNで完全にホストできます。UIコードをHTML5アプリキャッシュに押し込むことで、オフラインのウェブアプリも構築しました。
4. UIの忠実度が高い（クライアント側の豊富なコントロール）
5. サードパーティの開発者は、自分のフロントエンドが使用しているのと同じAPIを使用できます。また、機能を共有している場合、モジュール間でAPIを簡単に再利用できます。
   これは、開発、QA、ドキュメントなどが少ないことを意味します...
6. PHP、Python、JavaよりもJavaScriptでのプログラミングが好き

しかし、間違いなく、今起こっていることは誇大広告です。それは吹き飛ばされ、多くのウェブアプリは再びサーバー側のUIアーキテクチャを使用します。

クライアント側のソリューションに対する熱意を駆り立てているもう1つの要因は、モバイルアプリの成長です。クライアント側のJavaScriptとAJAXに基づいてWebサイトを作成し、ネイティブのiOSアプリとAndroidアプリも構築する場合、3つすべてが同じRESTサービスを使用して、データのすべてを実行することができます。 。

まず第一に、ユーザーはサーバーではないものを認識しません（場合によっては気にしません）。サーバー側のコードがどれほど上手く記述されていても、クライアントの部分がうまく機能していなければ、ユーザーはアプリケーションに感謝しません。場合によっては、機能よりも素敵なUIの方が重要なことがあります。

大きくて強力なサーバーホスティングは非常に高価です。一部のロジック（検証を除く）をクライアント側に実装する方がはるかに安価です。したがって、それほどロードされないため、より小さな（したがって、より安価な）サーバーホスティングを使用できます。

これらは、不安定性にもかかわらず、クライアント側のテクノロジーの人気が高まっている理由です。さらに、JSとHTML / CSSは（ほとんど）すべての最新のブラウザーでサポートされています。

アプリケーションのこれら2つの部分は、別々に存在することはできません。そして、インターネットは近い将来どこにも去っていかないようです。
それもなくなるとは思いませんbig server-side frameworks。それらを買う余裕があり、その重要な利点を利用する企業は常に存在します。

クライアント側のWeb開発は、Webブラウザーと時間の経過とともに変化するWebブラウザーと強く結びついています。現在提供しているソリューションは、Webブラウザーのページレンダリングエンジンの大幅な変更により、数か月で機能しない場合があります。一部のブラウザは標準と互換性がないか、互換性がなかったため、期待される結果を得るためだけに開発者からさらに多くの労力を要求されました。

この問題を修正しようとするいくつかの解決策があります。たとえば、jqueryを使用すると、スクリプトはこの特定のjqueryライブラリでサポートされているブラウザで動作することが保証されます。しかし、一部/ほとんど/すべてのブラウザとの互換性を提供するのは、作成者次第です。問題は、どのチームがあなたをより良くサポートするかです。motoolsチーム、jqueryチーム、その他のチームですか？特定のWebブラウザーをサポートしていない場合、プロジェクトはそのブラウザーで機能しない可能性があります。

あなたが持っていると思われる興奮は長い間あります。Shockwaveとその後継のFlashが導入されたときに私はそれを見ました。最初にmotoolsで、次にjqueryで複雑なjsライブラリが出荷されると、豊富なユーザーインターフェイスの「大きな復活」がありました（この順に使用し始めました）。FlexとJavaFXがありました。しかし、市場で大きなシェアを獲得することはできません。プラグインを必要とするプラグインもあれば、エンドユーザーをセキュリティの脆弱性にさらす場合もあれば、カスタム設定が原因でクライアント側で機能しないものもあります（クライアントのブラウザでJavaScriptが無効になっているなど）。

一方、サーバー側のソリューションは通常、1回だけ記述されます。すべてが失敗することを心配する必要はありません。新しいFirefox / Chrome / IE / Operaが出荷されたら、書き換える必要があります。クライアントがアプリを改ざんしたり、データを破損したりすることを心配する必要もありません。

あなたの感情に絶対に同意してください。私はまた、あなたが言っている以上に、RESTの劇的な低下と、サイトがサーバーと通信する主な方法のためのWebソケットの大幅な増加を見ることになると信じています。Vert.x、Node.jsなど。サーバー側だけでなくクライアント側も、イベント駆動型プログラミングに移行しています。Java EE、PHP、Railsなど。すべて適応する必要があります。そうしないと、すぐに失われます。