由Hax建议引发的对QWrap的省思

QWrap网站出现第一篇《开站鸣谢》的贴子，是在2011-01-28，再过几天恰好半年。上周Hax同学发表一篇《关于国内前端和JS技术发展乱想》的博客，很慷慨的给中国前端、顺带给QWrap大量建议，也让我再次对QWrap深深省思。

先回应Hax的一些建议吧：
关于“对前端界的四建议：1. 心态开放；2. 融入社区；3. 国际化；4. 专注。”
在融入社区与国际化这两点上，QWrap几乎零分。

虽说有为自己的失败找理由之嫌，也还是先说一下对QWrap的几个发展阶段：
一：核心库阶段：
    QWrap设计规化，
    核心库代码成形，API稳定。
    开源
    阶段完成标识：正式开源
二：试运行阶段：
    在JS熟手群有一定的影响力，收集同行的反馈意见，让QW趋于稳定（API稳定、代码稳定）。
    至少有一套常用组件。
    寻找吃螃蟹的公司或项目当试验品。
    阶段完成标识：试验品上线
三：推广应用阶段：
    推广应用。
    更多其它事…………

2011年一月，QWrap顺利开源，开始了第二阶段的任务。自开源后，一直只是在小范围内传播，传播方式仅限于同学们写一些博文、QWrap网站收集相关博文、一个QQ群、以及热心网友的博文（也包括Hax的博文）与相关同行对外的顺口提及（例如玉伯在介绍Kissy时顺带提了一下QWrap的Retouch）。这些方式全面是面向JS熟手同行，而面向QWrap的真正潜在用户（写页面js的同学）的，只有一个《关于页》和一个《用法参考》。相信也有很多这样的潜在用户扫过相关页面，然后叹一声“又一个轮子”而飘然而过。
“只面向JS熟手同行”，这本身也是我们的阶段计划之一，在这一个阶段，试验品是个大难题，吃螃蟹需要勇气与牺牲，并且团队需要有足够的技术能力解决遇到的问题，并且项目要有足够的复杂度。当时我们的标准是:“团队必须有人有能力在一天内把一个普通难度的jquery组件改装成QWrap组件。”---即：要求有人能既充分了解JQ，又充分了解QW。
为什么会对试吃螃蟹的团队有技术要求？因为JQ有海量的组件，但QW没有，这就必须要求试吃螃蟹的人能够自行解决组件问题。
但后来这个问题因为有啊团队的变化而解决了，QWrap有了一次开技散叶的机会。同时Wed、WaGang已经有了一定量的组件积累，足以应付大部分的业务需求，部分艺高胆大有影响力的Weder开始带领新的团队来试吃螃蟹了。从目前来看，吃螃蟹有风有雨，不过也大略还算顺利，期望他们早点上线，QWrap就能顺利的进入下一个阶段。
这一个阶段里，QWrap渐渐被一些同行知道、关注，也收到了很多反馈。QW现在已经有很好的移定性。美中不足的是，参与组件开发的人不多。
QWrap在设计上为组件开发者作了很多考虑，包括组件的事件机制、无依赖化、可适配性、Retouch方式、Jss应用等。或许是组件开发者们对QWrap的未来没有信心，所以也不愿意花精力去了解这些。----这导致第一阶段的策略有了变化：我们先开发出一套常用组件。更多组件开发者的参与，只能等到他们在项目中使用QWrap时再说吧。
在第一阶段，我们所不愿意看到的事是：有对QWrap了解不深的同学使用了QWrap。----这也许是精神胜利的想法，不过的确就是这么想的。假设QWrap是一个船，他是一个新船，不适合那些听到机器噪音就要求要退票下船的乘客。绝大多数乘客，需要的是座位已麿得很平滑的老船，在试行阶段的QWrap还没这么好。
这种想法很保守，有点畏首畏尾，但是也不会害人害己。有的人需要的是螃蟹，有风险有美味有贡献；有的人需要的是食物，无风险地吃饱。

回到“在融入社区与国际化这两点上，QWrap几乎零分”这个问题点上来，我们之前把推广放在了第三阶段，这种阶段分法的确需要重新检讨一下。在试用阶段完全有必要开始融入社区，进行国际化。
Hax的建议之后，也开始在社区上加力了。目前已注册了QWrap新浪微博，也在寻找合适的同学在twitter或其它国际性社区与团体进行宣传，这也牵涉到国际化，QWrap网站上也会很快加一个英文介绍（现在只有中文介绍）。
所谓的“出口转内销是不二法门”的很现实，现实得心理有点适应不过来，但是也需要认真对待。
Hax的“心态开放”，我想应该是虚心学习的意思吧，这个是必然应该的，努力中。至于第四条“专注”，这一个在分析专门针对QWrap的建议时讲到。

Hax对QWrap的技术建议，大略归纳了下
“注意baseline与标准”
“qwrap这一整个大框架，可以拆分成ModuleSystem/BaseLine/增强库等多个库，每一个都叫不同的名字，可以分别发展团队，”
“Dom补齐、HTML5相关”

关于“注意baseline与标准”，QWrap在开发基础扩充时，都已经是严格的按照标准来做了，如果有标准参考的，都是按标准来，没标准参考的，都会尽量不加，要加也是语义很明确，并且参数尽量少（功能少），不知Hax具体所指的是哪些地方需要改进。
关于“qwrap这一整个大框架，可以拆分成ModuleSystem/BaseLine/增强库等多个库，每一个都叫不同的名字，可以分别发展团队，”，QWrap有一个Apps机制，拆分组合十分灵活方便，目产的QWrap，合成一体，它是组件开发者的福音，如果QWrap拆散了，那这一个目标完全落空。组件与库是可分可合的，但是目前市面上的库都没有做到这一点，除了YUI2，可惜YUI2已经冒失的走到了YUI3。另外，QWrap的Apps机制，让我们按照统一的一套代码，产出专注于模块加载的种子文件(seed.js)、原生对象的增强库(core_retouched.js)等等多种应用，能够做到Hax同学要求的多种库，只是没有去分团队分别开发。
关于“Dom补齐、HTML5相关”，在Dom方面，QWrap有一个dom目录，完成所谓的jquery事实标准所做的事，而html5相关的，这个可能是无法估量的补全，只能通过组件来达到。
这个也牵涉到了QWrap的“专注”，QWrap本身并不大，不过提出了不少其它框架所没有的东西，包括Helper/Wrap/Retouch/Apps/Jss等等，不管闪亮的还是刺眼的，新东西太多，能做的事也太多，多得让人一眼看不出重点，也包括我自己。
回想起我在一篇QWrap蓝图的文章里，为了介绍蓝图，我先说了一大堆别人（Jquery/Prototype/YUI等）提供了什么，才说到QW也提供这些，并且还提供什么什么。“Use it as them”绝对不是个好的广告词，但目前也想不出其它话来总结QWrap………………