QCon第一天，GMTC全球移动技术大会联席主席、手淘技术老大庄卓然（花名南天）在Keynote上宣布跨平台开发框架Weex开始内测，并将于6月份开源，同时他们也放出官网：http://alibaba.github.io/weex ，可以在上面申请内测资格，以及下载Android版Demo把玩。
在大会后我对庄卓然做了一个采访，对一些大家关心的问题得到官方的回复，整理在这里。所有该发的不该发的我都发在这儿了，为了涨粉我也是拼啦~
Weex基本信息
- 官方支持iOS、Android、HTML5.
- Write Once, Run Everywhere。一次编写可生成三平台代码。
- DSL模板学习超简单，直接写HTML、CSS、JS。这意味着可以直接用现有编辑器和IDE的代码补全、提示、检查等功能。
- 轻量级、可扩展、高性能。
- 集成花样多，可在HTML5页面嵌入，也可嵌在原生UI中。
Weex的由来
Weex的前身是WeApp，一个用JSON配置原生UI组件来实现动态化的框架，关于类似这个的思想，可以在天猫这篇配置中心实践中看到，已经很牛了，Weex是WeApp的进化版本，加上ex去掉App，就成了现在这个名字。他们还编了个段子：
You give us a few weeks, so we bring you a weex.
这个段子要表达的意思，你get到了吗？
与Vue.js的关系
如果对前端有所涉猎的同学会发现，Weex的DSL风格与一个前端的MVVM框架Vue.js比较像，那么它们的关系是什么呢？
Weex由多个关键模块组成，分别是DSL transformer、JS Framework、HTML5/iOS/Android Renderer和工具链 ， 其中JS Framework就直接使用了部分来自Vue.JS的代码。不过这种使用也是遵守开源协议的（Vue使用MIT协议，Weex使用Apache协议），Weex团队在源码的说明文件中记录了来自Vue.JS和其他开源项目的贡献。
为什么不用React Native
手淘和天猫曾经尝试过React Native，然后放弃了。但是把它的思想吸收过来，结合Web Component和Vue.js，然后就成了Weex.
关于这个问题，庄卓然列举了一些原因：
- 因为手淘之前有WeApp，从WeApp进化到Weex是很自然的选择，抛弃自己的解决方案去用别人的反而很奇怪。
- React Native的JSX、CSS in JS写法都很别扭，淘宝有很多ISV（即各种店铺），他们之前只会Web技术，写这个有门槛。另外，HTML标准在过去二十年内经受了检验，HMTL/CSS/JS对应的结构、样式和行为，天然分离，代码的可维护性会更好。抛弃标准自己发明DSL也不明智。
- React Native重视平台独立性，不能做到100%代码共用，实际上还是要学习各平台的特性，Weex希望做到100%共用，即一次编写到处运行，进一步降低开发门槛。
- React Native在一些地方的性能上还有问题，手淘希望能自己主导优化的进程，否则会很被动。
关于KPI项目
去年在手淘向外界宣布有这个项目的时候，引起大家的关注，有人在知乎提了个问题，有人回答说是KPI项目云云。所谓KPI项目，就是为了完成KPI而做的项目，但实际之后不维护等等。
手淘在这个问题下面并没有正式回应，据庄卓然表示，其实KPI项目看从什么维度去理解，任何一家公司去做一个创新都会有目标，有目标的话都可以被理解为是一个KPI项目。在他的角度来看，是不是KPI项目不重要，重要的是目标定得对不对，想解决的问题是不是核心问题。
关于维护，涉及到阿里现在的开源策略，我们看下一个问题。
为什么还要内测，不直接开源？
其原因是，阿里调整了开源策略。在过去，阿里集团开源了不少项目，但其中很多没有后续维护，这也是被诟病为KPI项目的原因之一。其实阿里自己也想改变这种情况。
现在，手淘做开源，希望真正为社区创造价值，而不是把公司的一坨代码处理一下往外一丢，别人在使用的时候还要花很多功夫处理，这样的开源项目意义并不大。阿里希望发布出去的开源项目都是有生命的，能好好的维护起来。
在Weex去年双十一在线上验证之后，其实就准备开源，但有很多准备工作要做，比如文档、配套的工具等等，过去的四个多月一直在做这些事情。在集团内部也进行过测试，集团BU、UC包括高德、天猫等都有很多同学参与进去贡献DEMO和代码，到了4月份觉得适合放出来了，所以宣布内测。
内测这个是类似产品运营的思路，希望能像打造产品一样打造开源项目，和一般的开源项目的快速迭代不太一样，目前来看也并不能说哪个更好。
阿里百川在6月份会有一个生态大会，面向阿里生态体系内的商家和客户，当然也包括开发者。到时候会在大会上宣布开源。