AngularJSは、双方向のクライアント側データバインディングを使用します（AngularJS開発者ガイドから）：
サーバー側のテンプレートエンジンとAngularJSの双方向クライアント側のデータバインディングを組み合わせて使用することを検討している人はいますか。このようなもの：
ページのパーツ（コンポーネント）だけにAngularJSを使用することを考えていますか？それは良い考えでしょうか？
あなたがすでに同様のアプローチの経験を持っているかどうか、そして何が欠点と利点であったかを聞きたいです...
Angularは完全なUIレンダリングクライアントフレームワークです。あなたはそれにデータを供給することができます、そしてそれは適切なhtmlをレンダリングします。Angularは、それ自体で、どのサーバーからも完全に切り離されたテンプレートソリューションです。
あなたがやろうとしていることは、Angularアプリケーションをサーバーに再結合することです。それはより多くの作業になり、利点はほとんどなくなり、サーバーテクノロジーを切り替える能力は失われますが、Angularアプリケーションはそのままになります。
本質的には、サーバーにJavaScriptをレンダリングさせたくないのと同じ理由で、これを実行したくありません...すべてのHTMLをレンダリングしてきた長年のおかげで、それはあまり明白ではありません。サーバーで。
最終結果は重要なことです。UIが適切に機能し、アプリケーションの保守が容易であること。ソリューションの保守が容易であることがわかった場合は、それを実行する必要があります。JSONをホストするだけのサーバーでストレートHTMLとJavaScriptを使用するよりも、保守がはるかに簡単であるとは想像しがたいです。
私はあなたと同じジレンマを抱えていました。サーバー側のテンプレートエンジンとしてSMARTYを使用した経歴があり、最近AngularJSを使用し始めました。
完全分離の本質では、両方の溶液を混合することが適切だと思います。つまり、ページの一部を両方のテクノロジーと混合せずに、両方のテクノロジーを別々に使用します。
たとえば、ユーザーがまったく操作しないリストページがある場合は、サーバー側のテンプレートを完全に使用できます。
ただし、ページに多くの操作とユーザー側の操作が含まれる場合は、Angularを使用する必要があります。
SPA（シングルページアプリケーション）を使用している場合は、サーバー側のテンプレートをまったく使用しないでください。
最近作成したcordovaアプリでは、一種のミックスを使用しました。フォーム、リスト、ヘッダー、メニューなどのコンテンツを角度を付けて修正します。RTEのコンテンツなどの一部の部分や、ディレクティブngBindHtmlで追加したテンプレートを頻繁に変更します。背後にある考え方は、クライアントがレイアウトを変更したい場合、または現在不明なコンテンツをアプリに配置したい場合に、アプリのコンテンツページを柔軟にすることです。しかし、私は提案します：あなたがアプリを簡単に維持することができるなら（長い展開/承認プロセスはありません）、あなたはそれを角度のある方法で行うべきです（しかしSEOを念頭に置いていません;）。