使用Dojo的痛苦经历

2007年6月项目准备开始了，刚来到一个新的项目组，什么都是新的，除了我自己。

需要一个新的框架来开发项目，香港的同事决定使用Dojo，DWR， 我开始学习使用dojo，时间很短，但是我还是基本上熟悉了dojo的基本控件和架构。在此基础上搭建起了项目的基本框架。这是一个单页面，基于ajax和dojo widget的系统，一切都那么的新奇，又充满挑战，但是既然dojo有这么多后台，又有香港同事的推荐，我显得自信满满。

框架搭建的同事，也开始后了紧锣密鼓的招兵买马，一起都像是从零开始。陆陆续续，招了5个程序员和一个测试员。开始了整个项目的快速开发，由于需求由香港负责，而且需求做的比较细致，基本上问题很少。Dojo 却是麻烦不断。

首先的一个坏消息是当我们做完了几乎全部300个页面的时候，dojo宣布0.43不在得到支持，取而代之是完全不同的dojo0.9。 而且dojo0.9 还不是稳定的版本，问题多多，让我们骑虎难下，最后还是决定按兵不动。 随之而来，是dojo1.0，dojo1.1 的陆续发布，但是一直都无法让我看到希望的曙光。 与之相对的是ext在国内的广泛使用和热烈追捧。

Dojo 的控件有很多奇怪的地方，日期选择控件的行为非常怪异，与国内的使用习惯很不相同。而且样式极其丑陋，当字体放大缩小的时候更是丑陋。显示的格式和保存的格式需要分别指定。我们修改了大量的代码。

dojo 的下拉框也被用户投诉，过滤之后一定要再选择一次或者按回车才能选定结果，前台值和后台值分开操作也带来很多不变。

dojo 的验证文本框颜色现实有bug，我们不得不修改代码

dojo的对话框也有问题，对话框中无法在弹出对话框。对话框的操作和控制很不灵活。

js代码不利于管理，容易发生命名冲突。

 

致命的问题发生在项目的后期，在客户的系统进行测试时发现。dojo的性能非常差，在赛扬2G的电脑上，一个页面显示的时间竟然需要17秒。简直就是噩梦。

另外使用dojo的对话框时出现cpu占用100%而且一直不回落下来。

页面载入完成的时候，它有将整个页面重新刷新一次，又需要花费额外的5到8s时间，不仅花费更多的时间，而且严重影响客户体验。

 

还有开发过程中碰到的无数问题，虽然一个一个被解决，但是无疑是一次一次痛苦的煎熬。

 

最后，在性能面前，我被dojo彻底打败，如此的速度是任何客户都无法忍受的，客户不可能为了这个系统全部升级电脑cpu。而且还有很多未知的问题可能还没有被发觉，不如内存泄露，可能导致资源耗尽，内存耗尽。cpu 的占用可能在使用时间长了之后越来越高，等等，这些都是我担心的问题。

 

使用Ajax或者说Rich client，一定要谨慎啊。使用新的技术和框架，一定要谨慎，这是我的教训，希望给同行们一个参考。

 

评论

32 楼 suxy 2008-05-22  

dojo没那么差了，我以前用过，不要用dojo.require，把你用到的文件，打包，压缩，cache，性能还是可以的。

不过dojo需要自己修改的地方确实挺多的，我用的是0.31.

31 楼 yiaduo 2008-05-22  

shatuo 写道

kimmking 写道

expression 不能用。

需要对代码进行性能和压力测试
最好能逐行 分析。
找到问题的根源再下结论。

dojo的widget问题太多，使用dojo，这些东西都要重新编写，dojo的parse问题也很大，它的那个模板缓存机制也需要改善，总之，使用dojo，挑战就来了。

模板的问题，需要用internstring做提取，然后缓存这个string效率会好很多。
使用dojo,和jquery等比较，它不算是lightweight的，因为他考虑了太多，而他所考虑的大部分内容目前还不是国内的大部分开发用户所能考虑到的。
如果你的代码从长远的考虑要考虑各种应用环境，支持各种语言，要卖到国外去，要做到没有license的问题，要想以后做offline,air等有可能会做的事情，dojo应该是目前来看好的选择。

30 楼 sp42 2008-05-22  

家家都有本难念的经，难为了Ajax库开发者，难为了Ajax库使用者！
希望付出了就能有回报，总之在开放性的web技术上，我们相信路线是正确的！

29 楼 shatuo 2008-05-22  

kimmking 写道

expression 不能用。

需要对代码进行性能和压力测试
最好能逐行 分析。
找到问题的根源再下结论。

dojo的widget问题太多，使用dojo，这些东西都要重新编写，dojo的parse问题也很大，它的那个模板缓存机制也需要改善，总之，使用dojo，挑战就来了。

28 楼 cscs31 2008-05-22  

感觉使用DOJO的人还不在少数啊，可是在这里讨论贴里很少看到DOJO的，基本都是EXT的，是不是现在国内实际做项目的很少用DOJO，是DOJO不适合还是DOJO有些什么问题？EXT既然更改了开放代码的协议，国内商用的机会是不是会大量减少？

27 楼 kimmking 2008-05-22  

expression 不能用。

需要对代码进行性能和压力测试
最好能逐行 分析。
找到问题的根源再下结论。

26 楼 csf177 2008-05-22  

jelly 写道

大家都在回避我所提到的致命的问题，就是性能的问题。特别是下面的问题：

shatuo 写道

dojo的渲染机制有没有改善方案，每个页面都渲染两次，特别是第二次，很慢的，几十控件就要近10秒钟，想想办法。

一个页面如果超过10秒，那么是不是会让人跳楼。
我现在做的项目之所以立项，正是因为前面的系统比较慢，所以性能问题变得无法回避。
现在客户的要求是一搬的页面载入的时间必须4，5s。
特别复杂的页面10多s。
现在即使简单的页面在配置比较差的情况下竟然需要10s以上，特别是如果系统使用的越久，就越来越慢。
当然，dojo0.43 是老版本，新版本是不是解决问题，我不敢保证。但是冒然升级到1.1 ，却也是一个巨大的风险。
现在我们开始考虑暂时放弃dojo，毕竟性能对我们来说是至关重要。现在正在考虑修改的方案，比较头疼。

jelly 我提点比较实际的想法 可能有些唐突

我觉得从你的描述中看 你并没有掌握效率的根本问题
DOJO有很多问题 我也借你的帖子对DOJO小小发泄了一下
不过你想在所要面对的问题 不是将问题推向DOJO 而是搞清楚效率问题究竟出在哪里 对使用DOJO的反思应该留给下一个项目 在找到问题所在之前 试图靠升级框架解决问题是不合适的

页面加载时间仅仅是表面现象 你现在要做的是找出时间瓶颈
首先应该确定的是 时间消耗在CPU时钟上 还是内存页置换上（因为网页内存泄露很多 所以很难说时间不是因为内存申请或者物理内存不足导致的换页耗费的） 如果你不是局域网
而且从你说的"系统使用的越久，就越来越慢" 内存泄露是很有可能的。（如果是DOJO自己内存泄露那就比较麻烦了）

80%的时间消耗在20%的代码上 你应该很清楚这个道理 所以你应该观察时间消耗的位置 是集中于某一个控件 还是平均分布在所有控件上。如果是平均分布，你则应该搞清楚是控件生成的哪个阶段消耗了如此多的时间。

其实网页上CPU长期100%的情况不多 除了死循环和跑一些bt算法 就只有expression能做到了

最坏情况下 你可能需要重新实现某些DOJO的组件。

Good luck.

25 楼 jiakechong 2008-05-21  

怎么国内很少使用gwt-ext,
写的全是java代码,编译后全是js+html .界面也很漂亮, 应该爽死了

24 楼 yiaduo 2008-05-21  

jelly 写道

大家都在回避我所提到的致命的问题，就是性能的问题。特别是下面的问题：

shatuo 写道

dojo的渲染机制有没有改善方案，每个页面都渲染两次，特别是第二次，很慢的，几十控件就要近10秒钟，想想办法。

一个页面如果超过10秒，那么是不是会让人跳楼。
我现在做的项目之所以立项，正是因为前面的系统比较慢，所以性能问题变得无法回避。
现在客户的要求是一搬的页面载入的时间必须4，5s。
特别复杂的页面10多s。
现在即使简单的页面在配置比较差的情况下竟然需要10s以上，特别是如果系统使用的越久，就越来越慢。
当然，dojo0.43 是老版本，新版本是不是解决问题，我不敢保证。但是冒然升级到1.1 ，却也是一个巨大的风险。
现在我们开始考虑暂时放弃dojo，毕竟性能对我们来说是至关重要。现在正在考虑修改的方案，比较头疼。

dojo自带的theme test载入最多也就4，5秒吧，所有的dojo控件都囊括了。如果说你是几十个控件的话，我认为不是一开始页面render都需要解析出来的，比如dialog之类的，完全可以lazy parse的，使用dojo.parse.

23 楼 yiaduo 2008-05-21  

jelly 写道

yiaduo 写道

prophet 写道

可以说我们会载入上百个js文件，本地大概10s左右

....考虑做custom build吧，上百个... 合并成一个再做压缩，后台cache. 前台cache,性能会好很多很多。

下载js的时间对于局域网的应用来说应该不会有太多问题。
而且暂时我们都测试到下载js的时间还是比较短的。但是dojo渲染页面的时间比较长。

我估计你们是不是大量的应用了诸如contentpane, layoutpane之类的widget,我觉得还是不要使用js做布局管理，那是Css的任务。

22 楼 jelly 2008-05-21  

yiaduo 写道

prophet 写道

可以说我们会载入上百个js文件，本地大概10s左右

....考虑做custom build吧，上百个... 合并成一个再做压缩，后台cache. 前台cache,性能会好很多很多。

下载js的时间对于局域网的应用来说应该不会有太多问题。
而且暂时我们都测试到下载js的时间还是比较短的。但是dojo渲染页面的时间比较长。

21 楼 jelly 2008-05-21  

大家都在回避我所提到的致命的问题，就是性能的问题。特别是下面的问题：

shatuo 写道

dojo的渲染机制有没有改善方案，每个页面都渲染两次，特别是第二次，很慢的，几十控件就要近10秒钟，想想办法。

一个页面如果超过10秒，那么是不是会让人跳楼。
我现在做的项目之所以立项，正是因为前面的系统比较慢，所以性能问题变得无法回避。
现在客户的要求是一搬的页面载入的时间必须4，5s。
特别复杂的页面10多s。
现在即使简单的页面在配置比较差的情况下竟然需要10s以上，特别是如果系统使用的越久，就越来越慢。
当然，dojo0.43 是老版本，新版本是不是解决问题，我不敢保证。但是冒然升级到1.1 ，却也是一个巨大的风险。
现在我们开始考虑暂时放弃dojo，毕竟性能对我们来说是至关重要。现在正在考虑修改的方案，比较头疼。

20 楼 yiaduo 2008-05-21  

prophet 写道

可以说我们会载入上百个js文件，本地大概10s左右

....考虑做custom build吧，上百个... 合并成一个再做压缩，后台cache. 前台cache,性能会好很多很多。

19 楼 yiaduo 2008-05-21  

shatuo 写道

dojo的渲染机制有没有改善方案，每个页面都渲染两次，特别是第二次，很慢的，几十控件就要近10秒钟，想想办法。

什么叫两次渲染? 不明白你的意思。

18 楼 yiaduo 2008-05-21  

xxqn 写道

yiaduo能否介绍一下dojo如何做package的。

这个dojo的官方站点的文档很清楚了吧。像java一样按照文件目录结构自己规划好package,比如com.xx.js.utils, com.xx.js.utils.array, com.xx.js.model 等等。

根据页面的使用情况，使用custom build做出比较多的layer.将页面上所需要的js合并成一个大的压缩过的，混淆过的js文件，尽可能的防止在页面初始化的时候进行dojo.require同步装载。那么你的应用性能无疑是最佳的，每个页面只装载需要的js内容，甚至说我只会用到某几个function,其他的不需要，那么我就不打包进来。当然如果页面有可能会用到某个function,但是用户使用的概率很小，那么这样的则可以进行同步的装载，load on demand. 当然甚至你可以自己做到在页面初始化完毕之后，采用异步的方式去装载那些并非是页面初始render时候所需要的js,这样的话，用户在需要的时候，有很大可能这个function已经在上下文中了。

17 楼 zerozone 2008-05-21  

sp42 写道

dojo没ext那么多license问题。
SmartClient不知怎么样，使用LGPL的license。这不，就见到一个用户前来咨询ext-->SmartClient的情况（估计受license的影响）：

引用

Is there any better way to migrate from Ext to SmartClient?

引用

For example, take the "Array Grid" Ext example source:

new Ext.grid.GridPanel -> isc.ListGrid.create
columns -> fields
stripeRows -> alternateRecordStyles

Then in each field:

id/dataIndex -> name
renderer -> formatCellValue
sortable -> canSort
header -> title

http://forums.smartclient.com/showthread.php?p=7615#post7615

Ext、SmartClient改变license，个人认为确实是基于商业利益而作出的调整。此前，SmartClient一直纯商业运作，Ext则在LGPL的“庇护”下快速成长（相信作者本人也没有预料到Ext发展如此之快），但各有各的烦恼。

SmartClient公司（确切说是Isomorphic）的客户一直不是很多，但该公司能坚持7、8年之久，估计还是赢利的。推出LGPL版本的产品，目的还是吸引更多客户，他们的商业策略是靠推销高端组件或定制服务来挣钱，想要使用LGPL实现自己的商业应用估计是没有希望的，只能玩玩而已，因为此版本的所包含的精简服务端组件不允许部署，见http://www.smartclient.com/product/smartLGPL.jsp。而且，所谓LGPL版本，在开放源代码方面也只是做个样子，因为SmartClient开放了基本组件的源代码，更基础的源代码还没有开放，即使开放也没有什么意义，原因是看惯了Prototype和Ext的源代码，读真正的SmartClient源码会让人疯掉的。

在SmartClient实际开发过程中，会遇到组件扩展或一些诡异问题，都会由于无法找到类似ext-all-debug.js那样的源代码让你放弃跟踪转而请求SmartClient帮助，要是遇到扩展或性能提升，估计只有买商业组件了。没有服务端的SmartClient，什么都做不了。

综上所述，推出LGPL协议的SmartClient，最终目的还是商业利益。

至于是否选择SmartClient，我觉得要综合考虑很多因素：

首先，选择框架不能基于道德评判。就像不应该因为“开源”盲目选择Ext一样，也不应该因为是商业一概排斥。更不能把所谓的不道德和背信（试想SmartClient的老用户看到开源版本，是否会像大批Ext的支持者一样批判SmartClient）作为选择框架的条件。

其次，适合的才是好的。对于专注商业应用而非技术本身的客户，采用SmartClient这类不透明的Ajax框架，做应用更加快速和专业。看到有人哭诉采用dojo导致的种种bug和版本不兼容，使用专业和组件化的库、购买专业的服务，不是更明智吗。当然前提是要有足够的money。

声明，根据我本人的实际经验，在Ajax框架中，SmartClient无论在效果、功能、标准化和扩展性上，都算得上是比较好的框架。至于性能，我还没有足够的经验和数据来证明。

无论如何，我觉得Ext中途改变license，还是不太“讲究”的。看GWT-Ext的作者如何说http://jroller.com/sjivan/entry/update_on_future_direction_of1。

The first is the ethical aspect of a company choosing to change licenses on a dime and the questionable way they got to the point they have. There are several other excellent Javascript libraries like SmartClient that haven't gained the recognition they deserve and community support only because they were honest and consistent in their licensing model. While its no big deal to many to buy a (currently) reasonably priced commercial Ext license, supporting such a move from LGPL to GPL is an extremely bad precedent to set in the OSS community that has flourished on the basis of trust.

作者还提到SmartClient是一个非常出色的框架，只是没有被大家认可。

16 楼 czwlucky 2008-05-21  

个人觉得dojo太麻烦了，要记很多＂包＂名和意义，如果有很好的开发工具支持可能就会好用了．

15 楼 shatuo 2008-05-21  

dojo的渲染机制有没有改善方案，每个页面都渲染两次，特别是第二次，很慢的，几十控件就要近10秒钟，想想办法。

14 楼 cscs31 2008-05-21  

请教大家dojo的package的管理模式：）

13 楼 prophet 2008-05-21  

如果楼主做的RIA的话，我想不应该有那么多的页面的吧？一般的RIA也就是几个页面，否则你总是载入页面怎么行？是不是架构有问题？


我现在也在用dojo 1.0做RIA，基本上只有一个页面，也就是初始载入慢一点（可以说我们会载入上百个js文件，本地大概10s左右），其他的都还好，包括性能都是可以接受的。另外我们想把载入js做成lazy load的方式，这样进一步提高初始速度。

至于命名冲突，这个在dojo应该管理的非常好了，跟java的package几乎等效，不明白LZ怎么会有冲突的问题，可能对dojo没吃透？

不过我也要承认Dojo有些东西确实考虑的很不周全，有很多bug，但是作为企业开发，你总不能指望一个开源框架把你的需要都做出来吧，总是要改点代码的吧？