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