smartGWT的缺點

JS的特性決定了它的重要性，也帶給了開發人員無數的煩惱，文法松散，測試困難，調試困難，可讀性差，可維護性差。水準參差不齊的程式員寫出來的JS代碼可以千差萬别。而JAVA，作為一種成熟的開發語言，各種相關的輔助工具一應俱全。在日常開發中，有時候很難讓專門的前台工程師去寫JS，背景工程師寫Java，一是因為人手不一定夠，二是寫前台的時候也需要知道背景知識，而一旦讓Java工程師同時負責Java和JS，則會相當痛苦。在協調上，開發組裡面一個優秀的JAVA工程師可以很相對輕松地為新手設計好pattern，也比較容易糾正一個JAVA新手犯下的錯誤，而JS則很難。正因為如此，GWT應運而生。

GWT提供了非常優秀的Java API和widget，使得Java開發人員可以使用Java語言來編寫前台代碼（AJAX），GWT編譯器會編譯成（從執行效率角度）優化過的JS代碼。這樣，所有Java世界的工具和思想，都可以應用到AJAX的開發中來，包括unit testing，debug，java的design pattern，java的版本控制，maven，hudson，等等。

GWT作為一個基礎庫，其提供的API比較底層，widget庫也比較簡單，帶來的優點是可擴充性很好，但缺點是開發人員想要一些基礎的功能都需要自己擴充，使得開發效率受到影響。SmartClient 和SmartGWT 在一定意義上解決了這個問題，它們基于GWT，提供了豐富的widget庫，以及很好的前背景資料互動能力，比如ListGrid和各種DataSource的互動，使得它們成為非常流行的UI開發架構。

任何架構都不可能沒有缺點，筆者所在的團隊（Java背景，無JS經驗）花2個月時間用SmartGWT寫了一個項目的前台實作，最初的幾周進展極其順利，需要的基本控件，比如Window, HLayout, VLayout, TabSet, DynamicForm等都十分完美，基本的ListGrid和背景REST service互動也很順利，但到第二個月進入到細節處理階段的時候，就發現了一些非常費時費力且很難解決的問題。

1、widget庫還是不夠完善，比如SelectItem，選擇支援多選并設定多選格式為Grid之後，無法設定空值，以及auto-completion的suggestBox沒有好的實作，GWT有，但使用這些UI framework的一個重要原則就是不能混用 ，否則要麼編譯出來的JS一團糟，要麼在浏覽器上顯示的效果不堪入目。。。（這些UI framework的開發團隊都會在其首頁寫明如若和其他架構混用，後果自負~~）

2、Documentation不夠好，有些類、方法甚至沒有documentation。當然，SmartGWT showcase是加分的，但仍顯不夠，且裡面大部分widget的使用都過于基本，對于實際開發中啟示意義不大。

3、對IE支援不夠好，尤其是IE 6、7、8的相容問題。

4、因為筆者的項目基于OSGi，最後要打包到war裡面有二十多個bundle，其中隻有一個是SmartGWT (UI)，UI測試的時候必須啟動其他的項目，REST service無法處理UI發起的request。這樣帶來的問題是無法在開發模式下debug SmartGWT，因為其他的bundle和它都不是繼承(inherit)關系。最後筆者的團隊隻能在浏覽器的developer console裡面log和debug。