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。