Spring MVCフロントエンド開発向けのクライアント側レンダリングとJSPの比較
最初に、これから説明するアプリに関するメモ：これは非常に大きく、Airbnbのようなサービスアプリとほぼ同じ大きさです。つまり、静的なWebページではなく、完全なWebアプリケーションです。開発の初期段階です。
ここに質問があります：
私はフロントエンドの開発に厳密な飛び込みを始めようとしていて、正しい方向に進んでいることを確認したいと思います。バックエンドはSpring MVC設計で構築されており、これまでに行った限られたフロントエンド作業では、JSPおよびいくつかの単純なJavaScriptでTwitter Bootstrapを使用しています。問題は発生していません。それ自体はそのスタックで使用できますが、次の懸念事項があります。
開発の容易さおよび/または標準化
JSPを介して高度にインタラクティブなページを作成するために必要なJSTL構文は、非常に扱いにくくなっています。プロジェクトを拡張してエンジニアを増やすと、初期の学習曲線が急になり、その後にJSTLの冗長性が原因で、開発プロセスの持続的なスローダウンが発生するのではないかと心配しています。
JSPの使用は、人気のあるJSフレームワークの数に照らして、フロントエンド開発への現代的ではないアプローチのようにも見えます。 JSPを使用して構築する場合、フロントエンドまたはフルスタックのエンジニアのチームを編成するのは難しいと思います。
これらの問題についてそれほど心配する必要はありませんか？開発者の懸念を上回る、JSPを使用したサーバー側レンダリングの長所はありますか？ JSP devが広く知られていることを感じていただけますか。
パフォーマンス
これまでのところ、サーバー側のレンダリングは私のテストにとって素晴らしいものでした-しかし、私たちのアプリが大規模で歴史的な世界的な成功と実に現象である場合はどうなりますか？ JSPで行われた場合、サーバーはすべてのレンダリングで行き詰まりますか？または、サーバーへのロードバランシング要求とサーバー側のレンダリングをそのままにしておくことで、トラフィックの問題により適切に対処できますか？
クラウドでホストされたサーバーからのサーバー側レンダリングのメンテナンスコスト
上記のパフォーマンスの懸念事項に沿って、アプリが大量のトラフィックを取得し、サーバー側でビューをレンダリングしている場合、帯域幅の使用量は増えませんか？私たちはAWSにデプロイしますが、これは私にとってはなじみのない領域ですが、消費する帯域幅に応じて支払うことになると思います。クライアントのブラウザーにビューのレンダリングの義務をプッシュすることは、私たちのようなクラウドでホストされるアプリにとって費用効果の高い戦略のようです。私はその考えを誤解していますか？
ブラウザ間の互換性
私たちのアプリは、技術に不慣れなクライアントに販売されます。私は、そのようなクライアントが時代遅れのブラウザを持っている可能性が高いと想定するのは理にかなっていると思います。古いブラウザには、JavaScriptレンダリングとの互換性の問題があり、最新のJSフレームワークではさらに悪い問題がある可能性があります。
この懸念を解決するのに十分な互換性ソリューションが最新のJSフレームワークにありますか？あるいは、古いブラウザで実行される可能性を考慮して、サーバー側のレンダリングが最善策ですか？
これらの問題についていくつかの調査を行った後、私は今後4つの戦略を念頭に置いています。
クライアント側のレンダリングは避けてください。 JSTLのチャンキーさを愛することを学び、すべてのJSPを使い続けます。
JSP内のすべての静的HTML要素をマークアップし、ユーザーの操作（JS、AJAXの多く）に従って動的に生成された値/プロパティ/要素を入力します。
JSPで最小限のHTMLマークアップを作成し、ページが読み込まれたときに、ビューのすべてにDOMへの追加を入力します。
JSPから完全に移行し、AngularJのようなものを使用します。
基本的に、すべてのオプションは、サーバー側のレンダリングからクライアント側のレンダリングに向かうさまざまな程度を表します。これらのうちどれが最良の行動方針のように聞こえますか？私が見落としたオプションはありますか？
フロントエンドの開発プロセスではまだ完全に新しい技術を統合するのに十分早い段階であり、どの戦略にもかなりの自習が含まれるため、私はWeb開発に新しいので、何も考えるべきではありません。これまでのところ、このモデルは現在のアプローチからの最も劇的な変化ではないため、私はソリューション戦略＃2に傾いています。ただし、将来のビルドを容易にし、コラボレーションで最もアクセスしやすい方法でビルドするために、＃4も見栄えがします。
JSPを介して高度にインタラクティブなページを作成するために必要なJSTL構文は、非常に扱いにくくなっています。プロジェクトを拡張してエンジニアを増やすと、初期の学習曲線が急になり、その後にJSTLの冗長性が原因で、開発プロセスの持続的なスローダウンが発生するのではないかと心配しています。
それは正当な懸念事項です。
JSPの使用は、人気のあるJSフレームワークの数に照らして、フロントエンド開発への現代的ではないアプローチのようにも見えます。 JSPを使用して構築する場合、フロントエンドまたはフルスタックのエンジニアのチームを編成するのは難しいと思います。
使いやすさ、保守性、アプリケーションの特定の機能要件と非機能要件に対する複雑さ、柔軟性、適切性の賢明な管理などの分野で、特定のタスクに適したテクノロジーを選択すると、開発方法を知っている人や、それらを使用してソフトウェアを保守します。
これまでのところ、サーバー側のレンダリングは私のテストにとって素晴らしいものでした-しかし、私たちのアプリが大規模で歴史的な世界的な成功と実に現象である場合はどうなりますか？
それが発生した場合、それが発生した場合、それを修正するための費用がかかるため、それは良い問題になります。すべての大企業がこれを行わなければなりませんでした。彼らは迅速に市場に出すプラットフォームで製品を構築し、ユーザーの数が膨大になったときに（場合によっては、ゼロから）再構築しました。
とはいえ、早い段階で賢明な選択を行えると思います。 ご使用のシステム要件で大規模な過度のアーキテクチャー（そうではない）が要求されない限り、それらを回避し、より機敏で柔軟なテクノロジーを選択することで、全体的なパフォーマンスと適応性が向上します。
クライアントのブラウザーにビューのレンダリングの義務をプッシュすることは、私たちのようなクラウドでホストされるアプリにとって費用効果の高い戦略のようです。私はその考えを誤解していますか？
いいえ。ただし、 このBasecampの記事 をご覧ください。
私たちのアプリは、技術に不慣れなクライアントに販売されます。私は、そのようなクライアントが時代遅れのブラウザを持っている可能性が高いと想定するのは理にかなっていると思います。古いブラウザには、JavaScriptレンダリングとの互換性の問題があり、最新のJSフレームワークではさらに悪い問題がある可能性があります。
もう言い訳はありません。 21世紀にクライアントがコンピューターを使用したい場合、最新のブラウザーが必要です。これまでになく簡単にブラウザーを取得して、許可することができます。自身を自動的かつ無期限に維持および更新します。
これらの問題についていくつかの調査を行った後、私は4つの戦略を念頭に置いています...
将来の方法は、いわゆるマイクロサービスとAngularなどのクライアント側UIです。いいえ、これは一時的な流行ではないと思います。ユーザーはソフトウェアアプリケーションとの高い対話性を要求し、この配置はそれをユーザーに与えることができます。バックエンドのJSON Webサービスは、好きなように構築できます。 Node.JS、ASP.NET Web APIなど。この種のモジュール性を維持することで、他のコンポーネントに影響を与えることなく、1つのコンポーネントを変更できるようになります。
質問に回答して、あなたがこの回答を受け入れることにした場合でも、トピックを別の側面から強調したいと思います。
1）テンプレートシステムとしてのJSP
テンプレート言語として、JSPは他のJSPと同じように優れていると思います。 Thymeleaf がニーズに適していることがわかるかもしれませんが、それは主観的なものです。 JSPは、クライアントにコンテンツを取得するための古い（または成熟した）手法です。 ASPまたはPHPにさえ相当します。
言語としてのJSPの主な欠点は、XMLベースであるため、視覚的なオーバーヘッドやノイズが多いことです。したがって、これは Chameleon （a Pythonテンプレートエンジン）に相当します。そのため、理解しにくい場合があります。
これを行うよりクリーンな方法は、例えばです。 小石 。
2）サーバー側レンダリング
2016年現在、サーバーサイドレンダリングは停止していません。逆に、 Twitter を例にとると、
要するに、コードの大部分はユーザーのマシンではなくユーザーのマシンで実行されているため、クライアント側のアーキテクチャではパフォーマンスが低下するということです。
もちろん、クライアントサイドのフレームワークは React 、 Angular または Vue.Js です。しかし、彼らがすべて共通しているのは、それらが膨らんでいるということです。そして、私はそれらを好きではないので私はこれを言っていませんが、強調したいのは、AngularのようなJavascriptフレームワークを使用すると、一見して実現できないかもしれないコストがかかることです-私たちのデスクトップは高速で、接続も安定していて高速ですが、モバイルを見ると全体像が変わります。
モバイルには主に3つのコストがあります。
1）レンダリング
2）実行中
3）バッテリーの消耗
これらのカテゴリのいずれかでパフォーマンスが悪いと、顧客を失います。これらの多くのパフォーマンスはさらに悪いです。
したがって、この問題を解決するには3つの方法があります。
1）すぐに始められます
2）ページが最初にロードされた後、必要に応じて呼び出しを減らします
3）魅力的なデザインを発表せずに空想を減らす
これは、サーバー側のレンダリングが（again）に作用するところです。最初にページを起動して実行するには、ページの最初のロード時に、必要なだけの情報を配信する必要があります。誰が言った、あなたのサーバーはあなたのHTMLをレンダリングすることだけが必要だと？ JSの起動部分をスクリプトタグでページにレンダリングできます。もちろん、私たちは何年も前に、JavaScriptを独自のファイルに分離するように言われましたが、パフォーマンスを必要とするため、線を少しぼやけなければなりません。
では、JSPはどうでしょうか？式言語といくつかのJSTL（例：<c:if>）必要なものはすべて揃っています。
3）あなたの懸念について
JSPを介して高度にインタラクティブなページを作成するために必要なJSTL構文は、非常に扱いにくくなっています。プロジェクトを拡張してエンジニアを増やすと、初期の学習曲線が急になり、その後にJSTLの冗長性が原因で、開発プロセスの持続的なスローダウンが発生するのではないかと心配しています。
言われたことから：はい、JSPが提供するすべての機能を過度に使用したい場合は、かなりの冗長性がありますが、言語セットを減らすと、JSPは他のテンプレートエンジンとそれほど変わりません。
これまでのところ、サーバー側のレンダリングは私のテストにとって素晴らしいものでした-しかし、私たちのアプリが大規模で歴史的な世界的な成功と実に現象である場合はどうなりますか？ JSPで行われた場合、サーバーはすべてのレンダリングで行き詰まりますか？または、サーバーへのロードバランシング要求とサーバー側のレンダリングをそのままにしておくことで、トラフィックの問題により適切に対処できますか？
この質問は、Webページがどのように組み立てられ、クライアントに配信されるかについて誤った仮定をしています。 2000に関しては、その時点でWebサイトが所有していた何十万ものユーザーすべてにサービスを提供する大きな太いWebサーバーがありました。より多くのパフォーマンスが必要な場合スケールアップが適していました。しかし、今日知っているように、これは限られた程度でしか機能しません。 スケールアップの代わりに、私たちはスケールアウトし、ますます小さなサーバーが負荷を引き受けます。
2000年の文脈では、あなたの質問は理にかなっています：1つのファットサーバーがあり、数百万のリクエストを処理し、すべてのビジネスロジックを単独で実行している場合、パフォーマンスの問題がありましたが、Webサイトのテンプレートが原因ではありません（JSPはプリコンパイルされているため、本当に速いもの）。
今日、機能を分離し、アプリケーションの一部をリファクタリングしてサービスを分離しています（一部のサービスはmicroservicesと呼んでいます）focuseded serviceという用語が好きですまたは自己完結型システムの方が優れています。
したがって、設計によって負荷を分散します。また、テンプレート化の効果はまだわずかです。
上記のパフォーマンスの懸念事項に沿って、アプリが大量のトラフィックを取得し、サーバー側でビューをレンダリングしている場合、帯域幅の使用量は増えませんか？私たちはAWSにデプロイしますが、これは私にとってはなじみのない領域ですが、消費する帯域幅に応じて支払うことになると思います。クライアントのブラウザーにビューのレンダリングの義務をプッシュすることは、私たちのようなクラウドでホストされるアプリにとって費用効果の高い戦略のようです。私はその考えを誤解していますか？
gzippedコンテンツを配信すると、bandwithが消費されるため、budget、あなたは明らかに間違ったビジネスにいます。
この懸念を解決するのに十分な互換性ソリューションが最新のJSフレームワークにありますか？あるいは、古いブラウザで実行される可能性を考慮して、サーバー側のレンダリングが最善策ですか？
これに答えるとトピックから外れすぎます。ただし、すべてのユーザーが最新の状態ではない、またはJSをオフにしているという事実を取り入れた、素晴らしいアーキテクチャスタイルについて触れておきます。それはプログレッシブエンハンスメントの新しいテイクです： ROCA-http://roca-style.org/