web UI 组件化的一些经历

  当年，统计局中的牛人使用原生态的javascript写了一份庞大的报表填报组件。让我不可避免的走上了javascript的组件化开发的路子，开始组织我的web UI组件库，一口气的写下了一堆乱七八糟的组件，且正好赶上jQuery新鲜出炉，看过几段demo，粗粗的瞄了一把代码后，优雅和高效的代码让我一下走到了一个极端，天了，用JavaScript动态生成HMTL是多么美好的一件事情啊，翻看着以前使用taglib化得各种组件，实在是太不堪了，明明可以分散的交给客户端完成的东西为什么偏偏要放在服务器端生成，罪过、罪过，纯粹的客户端生成html，这不就是web UI组件开发的理想模式吗，一切都交给js的组件完成，界面简单的填写着规范化得js组件参数，完成各种复杂的交互性高的功能简直是太完美了，这不，本着这个思路，又重新的按照jquery的插件模型，整个的把组件库给重写了，看着使用者这些组件库开发的一些demo，都已经让自己陶醉了。唉，这不在这种极端的思路的引诱下，偷偷（罪过，这事千万别干了）在项目中把自己写的一颗看似不错的UI组件给加了进来，结果随着功能的深化，里面的js复杂程度越来越高，再加上自己对JavaScript的肤浅认识，造就了一大批旁人的难以维护的代码，自己吃了些苦头倒还好，就是难为了不少后面进来的同事，每念及此，心里便是一阵的慌张。

  慌张不能解决我的问题，于是乎开始了寻找一种更完美方式来组件web UI组件以及这些组件的引入方式，在当年的EXT作者和JQuery作者的一番交锋之后，jQuery 官方的 ui 组件库让我又重新找到了一个方向，模式、模式，要想简单而方便的使用ui组件，一种良好的模式和规划必不可少，一天天的看着jQuery的成长，似乎我的UI组件化也越来越顺利了，再加上firefox这个调试的工具，各种效率更高，使用更加规范的组件的出炉，又有点飘飘然的感觉了。还好这次我没有冒冒然的把东西用在了实际的项目中，仅仅乘着一个研究性的项目把东西拿出来偷偷地实验了一把，看着这些比较规范、比较方便的维护的代码，又是一件不由自主的激动，快速一个个功能往上添加。这个时候，另外一个的问题出现了，庞大的js代码库，纯js动态生成的html，不可避免的影响了网页的加载速度，自己开发的时候用着性能较高的机器，没有什么感觉，可是我们的客户，机器的配置一台不如一台，当js使用达到一定的程度后，虽然尽力的避免了内存泄露，但是总是会在那些个ie中会有些缓慢。无赖啊无赖，这个还是组件的问题啊，革命还尚未成功啊，路还远。

  怎么样才能进一步的提高效率呢，js可以优化的地方已经不多了，css的组织也越来越完善，这时才明白过来，原来自己一直在走一条比较极端的路，一门心思的把精力放在了js本身的优化上，殊不知做了多少本来不该放在客户端生成的东西，服务器的瓶颈根本就不在这么些html的生成啊，样式固化后，靠标签之类的方式生成部分的组件的html，js仅仅是处理一些模型以及动作方面的事情。术业有专攻、只有最佳的前后台配置才能出最好的效果。接下来就是要寻找一条最佳的配置方案了...

  这不，又开始了在新的这个研究性项目中偷偷地把东西拿出来使用标签的方式重写了。工作忙里偷闲的整些自己愿意做的事情，倒是给这目前的枯燥的项目带来了些动力，本来觉着无聊的cognos，用着这些自造的组件去做些集成性的demo，也不是那么的讨厌了。

 

评论

1 楼 hustlxjaw 2009-12-21  

哈哈，在这里看到你的文章了，还是近期发布的，最近我也有这个体会啊，主要有以下几个方面：
1、界面太多逻辑、太多内容还是需要简化和分解
2、很多东西还是用成熟的东西好，自己的力量太小，有稳定的东西优先用，在熟悉的基础上进行扩展，但前提是体系得一样。比如最好别用jQuery的tree，Ext的Grid，yui的panel组合起来，等等。知识传递的时候也忒费劲。
3、组件多样化。比如树形组件，我可能有很多种类型，但这些树都继承自同一个最基础的树形菜单，但是根据不同的需要又衍伸出很多的新特征。这些多样的树又可以通过统一入口方法中的开关来进行切换。以达到分离与结合的目的。
4、模式。js与java的区别还是挺大，尤其是效率上。就像GPU和CPU一样，执行不同的程序，执行速度有非常大的区别。
5、关于组件封装的程度。项目就是项目，是有业务逻辑和特定需求的，无法实现简单的标准化过程，所以有些重复性的劳动和必要的修改还是经常出现的。要根据实际情况来处理。

最近可能会回武汉，到时候给你打电话出来聊聊啊，哈哈。