Web應用程式剛剛興起並取代傳統客戶端應用程式時，技術熱點在伺服器端開發語言。從ASP、PHP到Java、ASP.NET，無論採用哪種技術，作為一個系統核心的業務邏輯都是用一種執行在伺服器端的語言編寫的。架構師習慣將一個應用系統分為多層，檢視層、業務邏輯層和資料層等，而它們也都是以某種伺服器端程式語言，結合html和sql等技術，在伺服器上執行。JavaScript作為執行在瀏覽器中的語言，僅僅是用來完成校驗、介面的零散修改等任務。那時候誰要是提出用這種輔助性的語言來編寫業務邏輯，一定會被當成天方夜譚。然而時光流轉，技術發展，Web系統越來越倚重JavaScript。JavaScript語言的能力和特性被徹底發掘，Ajax成為Web開發的常規，JavaScript框架層出不窮日新月異，昔日的天方夜譚越來越多變成現實。利用某個MVC模式的JavaScript框架，業務邏輯程式碼執行在瀏覽器中，通過RESTful服務和伺服器交換資料，是越來越多功能豐富、外觀華麗的Web應用的技術路徑，推向極致便是所謂的單頁面應用。
在這種趨勢下，一個必然會產生的問題就是業務邏輯真的應該全部從伺服器端移到瀏覽器端嗎？
好處：
1. 更快的響應。Web應用系統響應所費的時間一大部分是用在網路傳輸上。傳統的Web應用每當要執行業務邏輯時，哪怕是很簡單的計算，都要提交到伺服器，再等待返回整個頁面。等到後來採用Ajax技術，伺服器端可以只返回執行業務邏輯後的資料結果，效能就大大提高。更進一步地，如果一開始就將應用的模型資料傳輸到瀏覽器，後續的計算都用JavaScript完成，只有當需要更新資料庫時才返回到伺服器，網路傳輸就更少，系統響應也就更快。而且，應用程式會用到一些無需持久化儲存的臨時資料，比如和介面顯示相關的或者計算時用到的中間資料，對這些資料的運算也都無需在伺服器端進行再傳輸到瀏覽器。這些因素的共同作用就使得Web應用在很多時候的響應速度可以達到本地應用的水平。
2. 更簡單的結構。一項功能通常既包括看不見的運算，也包括使用者介面的變化。如果以傳統的方式來實現，伺服器端程式碼進行業務邏輯的計算，將結果傳輸到瀏覽器，JavaScript再修改html完成顯示上的變化，分別用兩種語言編寫，伺服器端傳送資料前的編碼和瀏覽器端接送資料後的解碼也都需要專門的工作。將業務邏輯轉移到瀏覽器端用JavaScript編寫則會讓程式碼變得更一致，結構更簡單。
3. 更好的伸縮性。程式碼分散到各個使用者的電腦上執行，自然減少了伺服器的負荷。

壞處：
1. 使用者環境的不確定性。不同使用者的電腦配置、瀏覽器種類會給應用程式的表現帶來不確定性。雖然說“萬一使用者禁止JavaScript執行怎麼辦？”這樣的憂慮在如今顯得有些杞人憂天，但JavaScript執行速度、瀏覽器對指令碼的支援乃至快取問題等使用者環境上的差異導致的不確定性比起程式碼集中在可控的伺服器端執行還是大得多。
2. 程式碼的隱私性和安全性。用JavaScript編寫業務邏輯程式碼意味著你的系統暴露在大庭廣眾之下。除卻安全性上的顧慮，單單曝露於眾這一點，就會讓長期以來習慣於要保護程式碼智慧財產權、千方百計隱蔽、加密、混亂化程式碼的軟體公司和程式設計師覺得彆扭，和失去隱私的感覺一樣。不僅如此，伺服器端的資料介面也變得外人可見，因而它們編寫的安全性也需要提高。
3. JavaScript。這一點實際上是見仁見智的。JavaScript與伺服器端語言Java、C#、Python、PHP比起來是不是適合用於編寫業務邏輯的複雜程式碼，你是討厭它的沒有編譯時檢查、難於除錯測試、語言設計上的缺陷還是喜歡它的簡潔、靈活、函數語言程式設計？這一點或許是對於一個程式設計師來說，採用新舊哪種開發模式的決定因素。

曾經的客戶端應用程式，被稱為胖客戶端，以此對比Web系統所用的瀏覽器是瘦客戶端。風水輪流轉，如今隨著一個系統中越來越多的程式碼用JavaScript編寫，瀏覽器又逐步變成富客戶端。然而背後的動因和邏輯都是一樣的，那就是使用者是上帝。前一次轉換是為了省去使用者安裝和更新的時間，後一次轉換是為了讓使用者享受到更快的速度和豐富的功能。在手機開發領域，模式乾脆又回到了客戶端——App，因為本地執行的App不僅速度更快、可以離線執行，還能呼叫攝像頭、地理位置、話筒聽筒等手機硬體功能，總之就是讓使用者有更好的體驗，而這背後的程式設計師們則或者啃書本更新技能，或者長江後浪推前浪。