爲了避免頁面刷新的Web應用程序，有幾種方法可以生成標記HTML標記生成：客戶端VS.服務器端，你的觀點？
a）使Ajax調用，在服務器端生成標記（HTML），並返回它作爲響應，操作與DOM的客戶端的新內容。
b）創建一個Ajax調用，以JSON格式返回數據，在客戶端使用模板引擎和JavaScript更新DOM。
我可以考慮以下的考慮，你對這些選擇有什麼想法/經驗？
1）語言：對於上述方法A，您可以在服務器端以任何語言進行編程。方法B需要JavaScript。
2）服務器端實現的可重用性：JSON重新調整電話與比較調用返回的HTML標記更多重用（這是不是一個真正的關注，如果有應用之外沒有消費者）
P，S。 ： 1）這裏有一個類似的問題 - Creating HTML: PHP server-side vs. jQuery client-side。在我的場景中，我建議使用像tmpt，ejs這樣的客戶端模板引擎。
2）在服務器以及客戶端，我打算使用MVC模式。
再次，正確的答案是根據情況。
如果您要將數據提供給客戶端小部件（如自動完成或數據表），那麼使用JSON即可。儘可能原始地提供數據，以便相關組件易於消化。
如果您只是簡單地顯示數據，或者在對話框中打開頁面，我建議使用服務器端來編譯HTML。不要讓數據傳輸方法改變通常生成HTML的方式。如果您通常將服務器編譯爲HTML，請不要讓AJAX請求要求它改變您的決定。 innerHTML是一種將HTML快速獲取到DOM中的非常有效且高效的方法。
實際上，這兩個選項都需要JavaScript，因爲您需要JS for Ajax。
我已經使用了這兩種方法，它確實取決於您的應用程序。我不認爲'一般'一個比另一個好。一些想法：
我會說這取決於ajax調用的是什麼。
如果您對頁面進行了相當大的添加或更改，請讓ajax返回完成的標記。
如果您對頁面的各個區域進行小的更改，然後將其返回爲json並執行操作客戶端。
這一切都歸結爲目的，但無論在哪種情況下，都需要javascript支持（無論服務器端語言如何，響應都需要相同）。
我認爲它歸結爲您的舒適區。我使用ASP.NET MVC並使用這兩種方法。根據我的經驗，服務器端標記生成往往更清晰，更易於調試。無論何時，您在客戶端和服務器之間劃分視圖操作時，都會引入複雜性。我認爲現在簡單是一個價值很低的軟件質量屬性。
在ASP.NET MVC中，服務器端代碼遵循其組織中的衆所周知的約定，具有良好的調試器支持和工具集成。
相反，雖然有最佳實踐，但JavaScript代碼組織通常基於各個開發人員的意見。我傾向於使用Firebug進行JS調試。我沒有發現VS調試器在客戶端更好。兩者都無法與調試服務器端齊頭並進。考慮到這一點，我傾向於傾向於服務器端標記生成，但是當我需要時需要使用AJAX。無論何時，當你在服務器和客戶端之間拆分視圖操作時，你都在引入複雜性並使其難於維護和調試。
至於返回JSON的「可重用性」，我會打電話給YAGNI。首先，返回標記意味着操作更加原子級的服務器端，而客戶端AJAX更簡單地檢索它。其次，如果你真的需要JSON實現，那麼這是一個簡單的重構。
總結一下，我嘗試使用一條經驗法則，「一個新的'普通的joe'開發人員需要多長時間才能理解並修改這段代碼？」從長遠來看，你所做的任何事情都可能是一件好事。
我使用ASP.Net MVC與Razor作爲我的視圖引擎。在客戶端，我開始使用JavaScriptMVC（http://www.javascriptmvc.com），這有助於在客戶端標準化MVC模式。您對服務器端代碼的看法易於管理和調試。如果我要進行服務器端標記生成，我打算使用部分視圖，因爲我不想爲小視圖更新過多刷新頁面。感謝您分享您的想法。 – patelsan 2011-03-01 02:14:17
我也會研究JavaScriptMVC。好的提示。我也使用partials進行小視圖更新。但是，只要知道您何時通過「小更新」的次數即可。我們做了一個儀表板應用程序，其中所有的小部件通過AJAX獨立更新，並從控制器返回部分視圖。但是，事實證明，當數據更改受到影響時，大多數其他小部件也需要更新。所以，最終，我們可能會刷新整個頁面。 – 2011-03-01 03:04:55
感謝您指出KnockoutJS，我用MVVM完成了Silverlight，所以它看起來非常熟悉。您是否將其用於生產應用程序或意識到在生產環境中使用的人員？整個概念對於JavaScript來說看起來很新穎，所以不知道它有多成熟。 – patelsan 2011-03-01 02:18:00
是的，我在生產中使用它在2個應用程序，它的工作原理:) – 2011-03-09 00:27:27