框架層面：近幾年前端發展很快，前端之所以叫前端因為前端是已經可以獨立成為一種職業了，js也不再是十年前的玩具了，以前富客戶端RIA的應用可能會用flash/flex或是silverlight，現在可以使用js來完成大部分的功能，因此js作為一門前端的支撐語言也不僅僅是進行的簡單的編碼，越來越多框架性的東西出現了。越來越多的開發模式轉變為后端只是吐json的數據源，而前端做所有UI的事情。
MVC
MVC實現職責分離是很好的，大多數網站在后端都會引入MVC框架，對于一個前端負責所有呈現和前端業務邏輯的網站來說，使用MVC框架也是很有好處的。Javascript的MVC框架現在很多。每一個框架其實都有其特點的，但是前端的MVC框架會和后端的有些不同的。比如前端的MVC框架可能會做一些M和V元素的雙向綁定，對于后端來說往往是單向的比較多。通過引入MVC框架我們可以讓同一個頁面做很多事情，通過一個不刷新的頁面實現一個應用程序的根基，還可以很清晰地進行MVC的分離并且突出M的概念，這是沒有框架所辦不到的。
通訊
對于一個比較復雜的頁面可能會有比較多的Javascript模塊，如果要進行模塊之間通訊的話(比如一個頁面有左邊菜單和導航以及列表，左邊菜單點選一級分類之后要通知導航加上去這項，并且通知列表重新讀取數據并刷新，然后從導航刪除這個選擇的話要通知列表重新獲取數據，通知菜單顯示所有)。對于比較復雜的通訊，如果把模塊模塊之間進行強耦合直接調用其它模塊的函數的話是不利于可維護性的，我覺得可以引入發布訂閱機制，每一個模塊做了什么修改把信息發布出去，關心這個信息的人訂閱這個信息，并且在回調函數里面做相應的操作就可以了。可以使用Amplifyjs作為發布訂閱的框架。
模板
對于前端來說和后端一樣一個比較麻煩的問題就是往往會在腳本里面把html也混在一起，個人覺得是這樣的，如果對于非常瑣碎一些dom修改問題倒不大，如果是大塊的html拼接的話，數據和html甚至是css混合在一起，那么代碼的可維護程度非常差。此時可以考慮使用一些模板引擎來分離數據和表現，比如Twitter hoganjs。由于很多模板引擎，比如大胡子引擎不僅僅是針對前端的，后端語言也有相應的引擎，因此甚至可以把模板放在文本文件中，前端后端共同使用一套模板引擎，也就是說現在的代碼偏向于服務端渲染的那么就在后端使用模板，如果要以后改為客戶端渲染了這套模板可以直接被前端使用。 資源示例
類庫
除了框架之外還有很多類庫，比如jquery，underscore，linq.js(linq to javascript)，jscex(wind)反正后端有啥現在前端也有啥，盡情發揮想象吧。用好這些框架可以大大改善生產力的，腳本能做的事情真的比想象的要多的多。我是做后端的前端知道的不多在這里列出的可能只是九牛一毛。
依賴
可以使用Requirejs、Commonjs之類的組件來管理腳本之間的依賴，好處很多的，我們的模塊只需要寫清楚需要依賴什么，Requirejs自然會幫我們按照一定的次序加載進來，這樣我們既不用擔心順序問題也不用擔心組件的版本號問題。基于Requirejs它具有豐富的配置，即使是我們進行了靜態資源合并也完全能處理，只要通過配置把組件配置到相同的服務端生成的一個路徑上即可，不過以前在做的時候發現它會自動加上.js 擴展名，不過完全可以通過改Requirejs源代碼解決。在架構上我的觀點是既然使用開源的東西，遇到問題了就不要去怕改源代碼。我們一定不能停留在框架的使用者，定制框架甚至向作者貢獻自己的代碼沒有這么難。 設計層面：
職責分離的理念
雖然我們都知道CSS樣式、JS行為以及HTML結構。個人覺得只有HTML是必須的，也就是說如果一個頁面沒有樣式沒有腳本的話它應該是一個清晰的頁面，可以大致表現出頁面需要表現的內容，只不過樣子比較難看，并且也是交互的。如果說很多功能是ajax實現的話那么就把交互工作轉到服務端實現服務端的渲染。多了樣式只是布局上樣子上更好看，多了腳本只是交互性上更友好，不需要刷新頁面，但是少了也不代表這個網站就是廢物了，現在有很多理念其實目的是一樣的。如果達不到這個境界至少我們要很明確的讓css、js和html履行自己的職責，不要把過多的事情賦予不相關的組件。比如盡量不要在html中包含操作性的腳本代碼，而是應該直接在腳本中選擇dom元素進行操作，盡量不要在腳本中包含大段的html代碼而是應該從模板讀取然后把數據填充進去，也盡量不要在html代碼中包含大量內嵌的樣式而是應該通過選擇器選擇進行樣式賦值。 資源示例
分層和目錄結構
對于一個比較復雜的大型的項目，合理規劃目錄結構也是很重要的，你可能會說腳本和樣式分兩個目錄就可以了，但是如果一個復雜的項目有幾百個腳本都列在一個文件夾下嗎?后端有分層的概念其實前端完全也可以有分層的概念，有表現層、業務邏輯層和模型層，然后是下面的數據訪問ajax層，當然還會有常量的文件，我反問覺得前端的分層可以超大型項目的ios或android程序來靠。比如之前我做的一個ios程序的示例,個人覺得這樣的分層就比較一目了然的。
合并和拆分的平衡
很多時候架構上的東西就是一種權衡，如果有固定的標準的話也就不需要架構師了，我們只需要按照固定的標準去做就行了。比如，一個頁面上使用了10個腳本文件，5個樣式文件，按道理說合并成兩個文件可以達到最小的請求數，但這樣一定是好的嗎?這個10個腳本和5個樣式文件中有很多或許是其它頁面也需要公用的，如果僅僅簡單的合并在一起反而可能增加用戶的下載流量，因此怎么規劃通用的東西合成一個文件，框架的文件單獨，而每一個頁面都有自己獨特的腳本和樣式，也是一種學問。 性能層面：
性能檢測
諸如YSlow和PageSpeed等工具可以分析出前端的性能問題，在這里就不展開討論了。對于前端來說由于涉及到用戶的客戶端環境和網絡環境所以情況不是這么單純，但是我們可以做到的就是在我們的可控范圍之內盡量減少用戶域名解析數量，減少用戶下載的數據量，增加并發等等。其實說白了，我們就是清理管道使得管道更大，或者增加更多的管道，或者就是盡量讓管道之內的水少一點了，這樣就可以更順暢。 資源示例
性能分析
現在有一些工具可以對Javascript的性能甚至是DOM解析的情況進行細致的分析，比如dynaTrace AJAX Edition，通過這樣的工具我們可以分析我們的腳本代碼以及頁面布局是否合理，從開發的角度來全面了解和優化我們的前端代碼。客戶端的資源雖然不像服務端的資源這么重要，但是為了給用戶的機制體驗最好還是對客戶端的性能消耗有所優化。
