開發EXTJS一年半了，一邊做Java一邊做Extjs。我也在EXTJS官方的國際化資源文件中提過一個修正版的中文資源包，現在在最新的3.1.0版本中的國際化資源文件就是我去年提的那一版修正版。
我在項目中積累了不少失敗的經驗和心得，我們單位在國內應該是第一批使用Extjs開發大項目的公司吧，大約兩年前就開始準備了。
那麼，我就我在開發Extjs中遇到的一些困難、問題以及前後臺搭配的一些衝突上做一個簡短的介紹吧。
1.前期不夠投入
這個怎麼說呢？在前期調研的時候沒有引起足夠的重視，總以爲Extjs嘛，無非就那麼點控件，那麼點東西。new一個window我能使就行了。需要一個grid 我就加一個gri d。結果導致代碼運行效率的極度低下，變量名沒有好的管理。採用過程式的編程，而不是OO思想。這個是最大的敗筆，此問題至今沒有被解決（我進去上班的時候他們已經編寫了N行代碼了，重構是不現實的了。）。目前還有很多公司依然偏執的認爲，EXTJS就是JavaScript 嘛，在牛也是JS。最後，出現問題之後，就開始說：“Extjs效率太慢，無法容忍。根本不適合開發大型項目。”
2.對API的不瞭解，以及資料匱乏。
這個直接導致了N多無用的代碼，說出來不怕大家笑，我曾見過ComboBox不使用displayField和hidden Field 來獲取value和rawValue，反而是自己在哪裏寫了N多行代碼來獲取這兩個值。（不過大家也要認識到，當時做EXTJS的國內很少很少，能寫出來，也算不錯了。）那麼，這種偏執，導致了自己的代碼經常性的報錯，不可預料的一些錯誤。焦頭爛額之中忽然看到百度或者Google 上有這方面的資料。恍然大悟。後來網上資料慢慢多了，又出現新問題了，那就是下面要說到的問題。
3.不相信自己的能力，過度依賴百度和Google
我剛進單位的時候，我寫一個繼承（ext end）。都要問：“這是什麼寫法？我沒見過呀。百度Google上沒見過呀，這樣寫能行嗎？”。這個思想的產生，不是因爲別的，而是因爲在開發初期不重視 EXTJS，偏執的埋頭寫自己的代碼造成了很多損失之後，開始產生了不自信。從而當出現問題之後，沒有自己去反思爲什麼會出現問題，焦頭爛額之後就直接去開帖子問別人，百度一下，Google一下。不優先考慮API和它的源碼。這導致自己的不自信。認爲，如果從百度上抄來的代碼不能運行，那是別人的錯而不是自己的錯。別人寫的代碼自己在百度或者Google上沒見過，就認爲不行。三思而後行。
4.前臺與後臺的那些糾紛
大家知道，Extjs中很多數據要顯示出來，必須要有一個字段對應後臺的數據，例如grid中的columnmodel，我前臺有id，後臺也要傳送一個 id字段我才能顯示數據。但是在實際開發中，出現問題了。後臺建庫建表的時候，從未徵求過表示層的意見，也是近似偏執的認爲，建庫建表與表示層沒關係，到時候處理一下塞到前臺讓他們顯示就得了。這下苦了表示層了，一條數據上來，字段與前臺不對應，怎麼辦？比如，前臺一個grid中的字段顯示的是年月日，而在數據庫 中年月日是三個字段（只是打個比方），那麼我就要在Action做字段拼接，而這個步驟，應該是在數據查詢上來的時候就拼接好的（實際應該在業務邏輯層做這個事情）。結果導致了什麼？Action當中充斥了大量的StringBuilder和循環，搞得Action中雜亂無章。好不容易發現來了一條比較順手的數據，只要JSON-lib轉換一下就搞定，可惜，裏面居然有length之類的敏感字段。苦悶。爲了多個表的數據兼容（例如A表和B表要同時顯示在一個Grid裏面，A表B表字段不一致），更是寫了無數的邏輯處理。當然，我這裏描述的可能有點問題，實際開發中的困難真的是只可意會不可言傳……
5.頁面邏輯與後臺邏輯分不清
打個最簡單的比方，我需要截取時間，來將某個視頻截取出一段用於播放，這個邏輯應該在什麼地方做？頁面嗎？我想不應該吧，JavaScript可以做時間運算，但是這個運算最終要把運算結果傳遞到後臺，再由後臺將切割好的視頻流發送到前臺，爲何我們不能在後臺完成這個邏輯？JavaScript畢竟不擅長來處理邏輯。一旦遇到異常，JS總是要花跟多的時間去處理這個異常，相反，Java是很擅長做這件事情的。
6.JS的調試
還是那句話，由於前期（在我進入公司之前）不重視表示層，並且由於各種原因。有些東西不能在火狐上跑，就拋棄了火狐，認爲我們的東西只要運行在IE上就行了，寫了一堆不兼容火狐的代碼。這下慘了，親愛的火狐以及Firebug離我而去，調試成了我們每天茶餘飯後必談的話題。最後我找了個折中的方法，CommonJS插件來調試，可是由於種種原因，在IE6上運行的效果不理想。於是我不得不使用log4JavaScript在哪裏死磕。浪費了時間。浪費了精力。
下面，我就我所遇到的一些問題提出一點開發上的建議
1.保證自己代碼的命名規範，JS中的註釋一個都不能少，Java通過Eclipse能定位到變量所在的文件，JS你Control健按死了也定位不過去（Spket 只能定位到聲明，不能定位到文件）
2.保證自己所寫的模塊能個單獨運行、測試。模塊與模塊直接不應當耦合過於緊密。過度的耦合你會發現，當我要替換某個模塊的時候顯得相當的困難。
3.在討論數據庫、後臺、整體流程的時候，表示層一定要豎起耳朵來聽，不要到時候因爲數據庫少了一個字段來在Action做表連接查詢。
4.要讓別人知道，JS其實不像他們想象的那麼簡單。
5.多看API，多看源碼，少上Google和百度。堅決不拷貝網上現有的例子作爲己用。
6.出了問題先查原因，多寫筆記。錯誤肯定不會只出現一次。
7.打理好自己的JS文件，動一個西一個，名字詞不達意你會痛苦的。
8.你不是一個人在戰鬥，你不是在以學習的心態來寫EXTJS，你現在是在用它來創造價值。一個人的力量是薄弱的。
我個人感覺Struts1與Extjs配合的其實不是很盡如人意的。相比較來說，Struts2要好一些（實際上Struts已經沒有存在的必要了，Servlet或者SpringMVC也能很好的解決需求。）。JSON-Lib的版本，我覺得Struts2目前自帶的版本過低，有機會最好替換成最新版的JsonLib。還有就是，前臺如果沒有特殊的需求，就用HTML頁面吧，JSP也是要編譯的，首次運行比較慢，而我們做開發，幾乎都是首次運行。這樣能減少不少時間。
能省掉的代碼儘量省掉，過多的代碼只會造成你的bug增加，沒有任何好處。
敢於懷疑，很多時候（特別2.0）。有些BUG是由於EXTJS自身帶來的，而不是因爲你代碼寫的有問題，所以，看清楚究竟是哪裏出了問題，對你來說能把握住問題的關鍵。
Extjs是基於JavaScript的，也許你覺得你根本不會JS也能寫出一個window，覺得這樣就可以了。但是你錯了，如果對AJAX沒有一個深入的瞭解，你永遠都只停留在會寫，而不會上升到怎麼去寫的更好這個層次上來。如果你僅僅是爲了逃避繁瑣的CSS、DOM和JavaScript而使用 EXTJS，我勸你最好還是花時間去了解一下。我不會害你的，放心。
不要偏執，如果看這篇文章的過客是一個準備用EXTJS來開發的調研者（經理大人或者主管大人），希望您能有足夠的重視，EXTJS寫的不好，會讓您大失所望。必要的精力和資金投入，是必須的。並且請在開發週期上稍微長一點。
Extjs就像EJB，未來的路怎麼樣，自己琢磨。存在即是理由，說EJB爛的，EJB依然在很多地方被應用。說EXTJS不適合大型項目的，試了纔有發言權。輕量級與重量級的孰優孰劣，自己考慮吧。
也希望高手達人能分享自己的心得與經驗，讓我從中受益。不過本帖不歡迎擡槓的人跟帖，討論問題而已，好自爲之。客觀評價。
謝謝。
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/zhangxin09/archive/2010/06/28/5700502.aspx
