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 开始。
评论