關于服務器與客戶端應用程序渲染的討論很多。 雖然沒有“一刀切”的解決方案，但我將嘗試從不同的角度主張客戶端（特別是AngularJS）。 首先是建筑。

建筑

做得好的架構已經明確定義了關注點分離（SoS） 。 在大多數情況下，最少的高級配置為：

• 數據存儲
• 服務
• API
• 介紹

這些層中的每一層都應僅具有上述知識的最少知識。 服務需要知道在哪里存儲數據，API需要知道要調用什么服務，并且表示層只能通過API與其余的服務進行通信。 這里要注意的重要一點是，應該不存在有關下面各層的知識。 例如，API不應該知道誰或什么消費它。 它不應該具有表示層的知識。

對于這些層中的每一層都應該說更多，“現實世界”中的情況要比這復雜得多。 但是，對于本文的其余部分，重要的要點是，表示層通過API與服務器進行通信，而API對“外界”一無所知。 隨著越來越多的機器和設備類型（筆記本電腦，移動設備，平板電腦，臺式機），這種分離變得越來越重要。 后端應僅提供業務邏輯和數據。

技能專長

考慮開發人員的技能是該體系結構的重要方面。 例如，如果開發人員習慣于使用Java工作，則除非設計有明顯的優勢，否則不應該設計基于C＃的系統。 這并不意味著不應使用新語言（誰說Scala和Clojure？）來提高技能。 只是必須考慮團隊的生產力，并且編程語言的知識是重要的要素。

無論現有知識如何，應用程序的類型都需要一些技能。 例如，如果應用程序將網站作為表示層，則必須具有HTML，CSS和JavaScript知識。 有一些框架可以用來避免對該知識的需求（即Vaadin ）。 但是，這些框架的使用只會推遲不可避免的事情：接受HTML，CSS和JS是一種瀏覽器可以理解的語言。 問題僅在于您是直接采用它們還是使用其他方式（即Java或C＃）為您編寫它們。 后一種情況可能會給人以更快的速度做事的印象，但是在許多情況下，當需要做那些“翻譯”所不支持的事情時，需要付出一些代價。

服務器端更容易應對。 對于每種技能，都有更多選擇，并且有好的（如果不是很好的話）解決方案。 我們可能會爭論Scala是否比Java更好，但是兩者都能提供足夠好的結果，并且學習新語言的決定要困難得多（盡管我認為開發人員應該通過嘗試新的語言和框架來不斷擴展自己的知識）。 可以使用Java，Scala，C＃，Clojure，JavaScript / NodeJS等對后端進行編碼。我們在瀏覽器中沒有那么奢侈的地方。 Adobe Flash已死， Silverlight從未升空。 Vaadin之類的工具最初旨在緩解JavaScript帶來的痛苦，這是由于我們看到HTML和JavaScript的不斷改進而逐漸失去了作用。 “瀏覽器”世界瞬息萬變，情況與不久前大不相同。 歡迎來到HTML5的世界。

可以說對于移動設備的開發也是如此。 沒有一種語言能適合所有人。 我們無法使用Java開發iPhone應用程序。 盡管在某些情況下HTML是解決方案，但在另一些情況下則需要進行“本機”開發。

唯一的常數是，無論是Web，移動設備，臺式機還是Google Glass ，它們都應使用API??與系統的其余部分進行通信。

我要提出的觀點是，在完成工作所需的語言采用與每個新項目中切換到新語言之間必須保持平衡。 有些語言是必須的，有些是很好的（但不是強制性的）。 使用Web時，HTML，CSS和JavaScript是必須的。

服務器與客戶端渲染

由于我們已經確定，在網站（誰說應用程序？）的情況下，帶有CSS和JavaScriptHTML是必須的，而試圖為我們創建HTML的工具是“邪惡的”，因此問題仍然是誰呈現HTML。 對于瀏覽器的大多數歷史記錄，我們習慣于在服務器中呈現HTML并將其發送給瀏覽器。 有很強的理由。 前端技術和框架還很年輕且不成熟，瀏覽器存在嚴重的兼容性問題，并且通常來說，使用JavaScript會很痛苦。 那張照片不再有效。 Google向我們展示了在許多情況下瀏覽器與臺式機一樣好。 JQuery通過讓我們以相對簡單的方式來操作DOM，徹底改變了我們使用JavaScript的方式。 發布了許多其他的JS框架和庫。 但是，直到最近，還沒有什么可以替代舊的模型視圖控制器（MVC）模式。

對于所有小型站點，服務器呈現都是必須的。 還是？ AngularJS改變了我們感知MVC的方式（實際上，它是模型視圖的，但是我們不要被束之高閣）。 可以在客戶端中完成，而不會犧牲生產力。 我認為，在許多情況下，隨著AngularJS生產率的提高。 還有其他客戶端MVC，例如BackboneJS和EmberJS 。 但是，就我的經驗來看，AngularJS沒有什么比這更好的了。

AngularJS并非沒有問題。 讓我們看一下客戶端與服務器端頁面渲染的優缺點。 在客戶端，我假設使用AngularJS。 為了進行比較，服務器端可以是任何東西（Java，C＃等）。

AngularJS缺點

頁面呈現速度較慢，因為瀏覽器需要執行DOM操作的額外工作，監視綁定數據的變化，向服務器執行其他REST請求等。第一次打開應用程序時，它需要下載所有JavaScript文件。 根據應用程序的復雜性，這可能是問題，也可能不是問題。 現代計算機完全有能力接管額外的工作。 移動設備比舊計算機功能更強大。 在大多數情況下，客戶不會注意到瀏覽器需要做的工作量增加。

與舊版瀏覽器的兼容性很難實現。 需要在服務器上呈現其他頁面。 該參數的權重取決于您是否關心（非常）舊的瀏覽器。 罪魁禍首是Internet Explorer。 如果應用了其他指令，則版本8可以工作（以某種方式）。 不支持早期版本。 將來的AngularJS版本將放棄對Internet Explorer 8的支持。您可以決定是否對IE8及更早版本的支持很重要。 如果是這樣，則需要提供替代頁面，這將導致額外的開發時間。 根據應用程序的復雜性，非AngularJS開發中可能會存在相同的問題。

搜索引擎優化（SEO）可能是最大的問題。 目前，緩解此問題的最常用技術是在服務器上預渲染頁面。 這是一個相對簡單的過程，需要少量代碼即可在任何屏幕上使用。 有關更多信息，請參見如何創建HTML快照？ 和Prerender.io 。 2014年5月，出現了一篇關于“了解網頁”的更好的文章，這給我們帶來了一個好消息，那就是Google能夠執行JavaScript，從而解決（或正在解決）嚴重依賴JS的網站的SEO問題。

AngularJS專業人士

如果性能良好（更好地使用JSON，客戶端緩存等）， 服務器性能將提高。 客戶端和服務器之間的通信量減少了。 服務器本身不需要在將頁面發送給客戶端之前創建頁面。 它只需要提供靜態文件并使用JSON響應API調用。 減少了流量和服務器工作量。

AngularJS的設計考慮了測試需求。 連同依賴注入，模擬對象，服務和功能，編寫測試非常容易（比我所使用的大多數其他情況更容易）。 單元測試和端到端測試都可以編寫并快速運行。

正如架構部分所建議的，前端（幾乎）完全與后端分離 。 AngularJS需要了解REST API。 服務器仍然需要傳遞靜態文件（HTML，CSS和JavaScript），并在爬網程序訪問時預渲染屏幕。 但是，這兩項工作不需要系統其余部分的任何內部知識，并且可以在同一或完全不同的服務器上完成。 簡單的NodeJS HTTP服務器可以達到目的。 這種解耦使我們可以獨立地開發后端和前端。 通過客戶端渲染，瀏覽器就像是Android，iPhone或桌面應用程序一樣，是API使用者。

不需要服務器端編程語言的知識。 無論采用哪種方法（服務器或客戶端渲染），都需要HTML / CSS / JavaScript。 不將服務器端混入此圖中，將使前端開發人員的生活變得更加輕松。

Google對Angular的支持是一個加號。 像Google這樣的支持者更有可能繼續全力以赴地提供支持和未來的改進。

一旦習慣了AngularJS的工作方式， 開發速度就會提高。 可以大大減少代碼量。 由于無需重新編譯后端代碼，因此我們幾乎可以立即看到前端的更改。

摘要

客戶端與服務器端渲染的這種視圖應謹慎對待。 沒有“一刀切”的解決方案。 根據使用的需求和解決方案，上面列出的許多優點和缺點都是無效的，或者也可以應用于服務器端渲染。

在許多情況下，選擇服務器端渲染是為了避免陷入HTML，CSS和JavaScript。 它使習慣于使用服務器端編程語言（Java，C＃等）的開發人員更加輕松地認為無需學習“瀏覽器”語言。 而且，在許多情況下，它會與后端代碼產生（通常是無意的）耦合。 兩種情況都應避免。 我并不是說服務器端渲染不可避免地會導致這些情況，而是使它們更有可能發生。

這是一個勇敢的新世界。 客戶端編程與以前完全不同。 至少有很多原因可以嘗試一下。 無論做出何種決定，都應使用足夠的信息，只有通過實際經驗才能獲得這些信息。 嘗試一下，不要放棄第一個障礙（會有很多障礙）。 如果您選擇不采用此路線，請做出明智的決定。

像AngularJS這樣的客戶端MVC遠非完美。 他們還比較年輕，還有很長的路要走。 許多改進即將到來，我堅信Web的未來將朝著這個方向發展。

翻譯自: https://www.javacodegeeks.com/2014/07/server-vs-client-side-rendering-angularjs-vs-server-side-mvc.html

總結

以上是生活随笔為你收集整理的服务器与客户端渲染（AngularJS与服务器端MVC）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。