拔赤谈前端：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 开始。