使用ASP.NET MVC：我陷入了在服務器和客戶端（比如jQuery模板）上渲染我的視圖的過程中。正如我聽到有人說的那樣，我不喜歡混合兩者的想法。例如，有人說他們會渲染服務器端的初始頁面（比如一堆評論的列表），然後當添加新評論時，他們會使用客戶端模板。要求在代碼的兩個不同區域具有相同的渲染邏輯，這讓我想知道人們如何說服自己這是值得的。ASP.NET客戶端與服務器視圖呈現
你用什麼理由決定在哪裏使用？
使用ASP.NET Web窗體時，您的論點如何改變？
人們這樣做的一個原因是因爲他們希望他們的網站通過搜索引擎索引，但也希望獲得最佳的用戶體驗，所以爲此編寫客戶端代碼。考慮到你有限制和目標，你必須決定什麼是有意義的。不幸的是，從技術角度來看，最具商業意義的東西似乎並不總是最有意義的。
服務器端渲染的一個優勢是您的客戶端不必使用JavaScript以使您的頁面正常工作。如果您依賴於JQuery模板，則幾乎不得不假設您的頁面在沒有JavaScript呈現的情況下不會有任何內容。對一些人來說這很重要。正如你所說，我不希望兩次使用相同的渲染邏輯，因爲你有冒着讓它不同步的風險。
我通常更喜歡利用部分視圖來生成大多數內容服務器端。使用直線HTML的頁面往往會比加載後必須「構建」的頁面快一點，這使得初始加載速度更快。
我們爲我們的應用程序開發了一個基於事件的AJAX體系結構，它允許我們生成一段內容以響應操作的結果，並基本上將任意數量的命令發送回客戶端代碼說「使用這個呈現的局部視圖的結果來替換ID爲'X'的元素」，或者「用這個作爲內容打開一個新的模式彈出對話框。」這是有益的，因爲服務器端代碼可以更多地控制AJAX請求的結果，而無需編寫客戶端代碼來處理每個操作的每個意外事件。
另一方面，像這樣將服務器置於控制之下意味着請求必須在客戶端知道要做什麼之前返回。如果您的視圖渲染基本上是基於客戶端的，那麼您可以立即在UI中「發生」一些事情（例如立即插入新評論），從而提高網站的「感知速度」。此外，互聯網連接通常是大多數網站真正的速度瓶頸，因此通過網絡發送較少的數據（JSON）往往可以使事情更快。所以對於我想要非常順利地響應用戶交互的元素，我經常使用客戶端渲染。如Jarrett Widman所說，在過去，搜索引擎優化也是一個大問題，如Jarrett Widman所說。但我的理解是，大多數現代搜索引擎都足夠聰明，可以評估他們訪問的頁面的初始JavaScript，並找出加載後頁面的實際外觀。 Google甚至會在您的網址中推薦the use of the "shebang"，以幫助他們瞭解如何索引由AJAX動態加載的網頁。