拔赤谈前端：KISSY的自成体系是一种趋势

Kissy是阿里前端自己开发的前端框架，目前最新的版本是Kissy 1.3.0，下一个版本1.4.0计划将在今年十月发布。在最近的阿里技术嘉年华上，InfoQ编辑对淘宝前端工程师李晶（拔赤）进行了采访，了解有关Kissy框架和他分享的Kissy Mobile相关的一些信息。

嘉宾简介：李晶，花名拔赤，淘宝前端工程师，具有多年前端开发经验，在团队协作、组件开发、移动Web App等方面有深入研究，曾经参与淘宝首页、KISSY等项目开发。他翻译过《JavaScript Web富应用开发》、《JavaScript权威指南（第六版）》。

InfoQ：先简单的介绍一下Kissy吧。在你看来，最初开发Kissy的时候已经有了jQuery，淘宝自己也在用YUI2，为什么还会开发这样一套框架呢？

拔赤：KISSY是阿里前端自己开发的开源前端框架，根据阿里自己的业务有很多定制和本地化，力争大而全。KISSY最初是由玉伯发起，最开始是一款设计精密的编辑器控件，后来提供一个轻的核心代码集合，为了弥补YUI2在语法、编程模式和代码复用模式上的缺失。YUI2和jQuery在当时都有一些棘手的缺陷是无法满足淘宝团队协作的场景。

1）YUI2体积过大，在完成同样功能的情况下页面JS体积要比KISSY多一倍，5年前网速没有像现在这么快，这样的体积严重影响页面载入速度。所以当时我们需要体积更小的库。

2）jQuery虽然提供基础的Ajax和Dom封装，但缺少Loader，这样就无法管理团队协作和多人开发，而淘宝从08年开始团队协作就已经是主流了。

因此，体积小巧、支持团队开发在当时看来是最迫切的需求，而当时的开源类库都无法满足（YUI3之后才内嵌了Loader、像第三方JS加载器requirejs和labjs在几年以后才陆续出现），所以KISSY从开始就走了一条自主探索的道路，一直到今天。

InfoQ：你主要参与的Kissy组件有哪些？能说说你是怎么参与到里面的吗？

拔赤：从最开始的Loader、Ajax，到后来的Calendar、Slide，我从开始就参与到KISSY的核心代码贡献中。因为KISSY源码托管在Github上，所以只需fork一份代码，就可以为它贡献代码。这也是大多数开源类库的组织方式。

InfoQ：Kissy在描述中表示要服务使用中文的工程师，所以项目说明、文档当中都有大量中文。这一方面对中文用户友好，另一方面也制约了Kissy在国际化方面的发展。你会不会觉得这样太迁就那些不愿意学英文的工程师了？

拔赤：KISSY的首要目标是服务阿里集团，其次是国内用户，再次是国际用户，所以我们目前会优先考虑中文。所以不管是注释还是文档，我们都会优先使用中文，对国内用户友好。再一个，我们自己的英文水平也高不到哪里去，没必要强求开始就写英文文档和英文注释，还是把主要精力放在代码结构和质量上。关于KISSY的国际化，我们会在KISSY 1.4.0时打一些补丁，支持一些组件的国际化。至于是不是迁就那些不愿学英语的工程师，他们学英语不会选择用KISSY来学习，这也不符合KISSY给自己的定位。

InfoQ：根据Kissy Mobile的项目介绍来看，它重点关注pageview的切换。这方面目前有没有比较业界推荐的标准处理方法？Kissy Mobile试图解决什么问题？

拔赤：KISSY Mobile是一套面向移动端的功能特性集合，pageview切换是其中一个，名叫Mobile App Toolkit，也是我这次分享的主题。关于处理多页切换的框架也有一些，比较流行的是jQuery mobile，但正像第一个问题那样，jQuery Mobile也无法解决目前我们的业务上的关键问题，比如页面切换是基于post请求？或者面向低端移动机型提供降级方案？

KISSY Mobile App Toolkit主要解决那些想将Web做App化的产品，并且Web会和Native整合，并力争做到和Native一致的用户体验。如果你的项目有这种需求，你需要尝试下KISSY mobile app toolkit。

InfoQ：Kissy即将发展到1.4版本。新版本有哪些值得关注的特点？

拔赤：1，种子文件会变的更小；2，CSS选择器会面向移动端做性能优化，性能全面超越zepto。这两个特性应该是接下来这个版本最重要的功能。面向移动端的优化是一种趋势，而KISSY应该在这个方面做得更好，更懂得企业应用场景和需求。

InfoQ：现在整个国内前端领域，各家大公司自己各搞一套框架，各自维护；小公司只能跟随，如果跟错了队就会很惨。你觉得未来的趋势会怎样？会有统一的上游，大家一起维护，还是大家渐行渐远？

拔赤：从KISSY创立起到现在，可以看到KISSY的自成体系是一种趋势，但凡大一点的网络公司都不约而同的选择自建技术体系，也就是之前很多人提到的我们在教堂和集市之间选择前者。原因很简单，要想用好jq/zepto/bb之类的“小”库，必须配合模块加载器（不管是静态打包还是动态合并）建设起一套组件机制并生长出一个组件库，因此不如从开始就自建。所以大公司的技术体系都趋向封闭或半封闭，真正的开放只存在于没有公司背景的Github社区里。因此，很可能我们最终只能一定程度的打破KISSY的“封闭”。而其他公司包括全球顶尖互联网公司也是一样的路数，所以要想做大，早晚要自创体系。拥抱开源只是创立之初处于成本考虑的一种权宜之计，真正做精只有从0开始。