当年,统计局中的牛人使用原生态的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,也不是那么的讨厌了。