框架層面：
近幾年前端發展很快，前端之所以叫前端因爲前端是已經可以獨立成爲一種職業了，js也不再是十年前的玩具了，以前富客戶端RIA的應用可能會用flash/flex或是silverlight，現在可以使用js來完成大部分的功能，因此js作爲一門前端的支撐語言也不僅僅是進行的簡單的編碼，越來越多框架性的東西出現了。越來越多的開發模式轉變爲後端只是吐json的數據源，而前端做所有UI的事情。
- MVC
MVC實現職責分離是很好的，大多數網站在後端都會引入MVC框架，對於一個前端負責所有呈現和前端業務邏輯的網站來說，使用MVC框架也是很有好處的。Javascript的MVC框架現在很多，http://www.infoq.com/cn/news/2012/05/js-mvc-framework。每一個框架其實都有其特點的，但是前端的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程序的示例http://www.cnblogs.com/lovecindywang/archive/2012/09/11/2680055.html個人覺得這樣的分層就比較一目瞭然的。
- 合併和拆分的平衡
很多時候架構上的東西就是一種權衡，如果有固定的標準的話也就不需要架構師了，我們只需要按照固定的標準去做就行了。比如，一個頁面上使用了10個腳本文件，5個樣式文件，按道理說合併成兩個文件可以達到最小的請求數，但這樣一定是好的嗎？這個10個腳本和5個樣式文件中有很多或許是其它頁面也需要公用的，如果僅僅簡單的合併在一起反而可能增加用戶的下載流量，因此怎麼規劃通用的東西合成一個文件，框架的文件單獨，而每一個頁面都有自己獨特的腳本和樣式，也是一種學問。
性能層面：
- 性能檢測
諸如YSlow和PageSpeed等工具可以分析出前端的性能問題，在這裏就不展開討論了。對於前端來說由於涉及到用戶的客戶端環境和網絡環境所以情況不是這麼單純，但是我們可以做到的就是在我們的可控範圍之內儘量減少用戶域名解析數量，減少用戶下載的數據量，增加併發等等。其實說白了，我們就是清理管道使得管道更大，或者增加更多的管道，或者就是儘量讓管道之內的水少一點了，這樣就可以更順暢。
- 性能分析
現在有一些工具可以對Javascript的性能甚至是DOM解析的情況進行細緻的分析，比如dynaTrace AJAX Edition，通過這樣的工具我們可以分析我們的腳本代碼以及頁面佈局是否合理，從開發的角度來全面瞭解和優化我們的前端代碼。客戶端的資源雖然不像服務端的資源這麼重要，但是爲了給用戶的機制體驗最好還是對客戶端的性能消耗有所優化。