Weex meets Vue，记一次 Weex 前端团队的讨论

_介绍一下背景，这次讨论发生在 JSConf 期间，正好 @yyx990803 难得和团队其他同学见面认识_

领衔主演：@yyx990803  
主演：@DoranYun @Hanks10100 @IskenHuang @Jinjiang @MrRaindrop @songsiqi @terrykingcha @vczero @yuanyan @Tancy @Fkysly

![](https://gw.alicdn.com/tps/TB1eNzMNXXXXXayXXXXXXXXXXXX-1080-1080.jpg)

_(文字内容是借助某知名语音识别服务做的，里面很多语音识别出来的比较口语化的东西我们做了保留，总体上感受会比较真实，但是读起来不一定顺畅)_
## Scene 1 面基环节
- **@Jinjiang** 我们相互介绍一下吧
- **@Hanks10100** 我花名是 门柳，在负责 JS Framework 的工作
- **@MrRaindrop** 我是大法，是做 HTML5 Render 这块的
- **@vczero** 我是vczero，之前主要是做ReactNative这块社区的
- **@Jinjiang** 他有一本ReactNative中文的书刚出
- **@yyx990803** 哦
- **@Jinjiang** 但他现在是我们的了
- **everyone** (笑) 卧底、卧底
- **@yyx990803** 可以提供ReactNative的珍贵的信息
- **@vczero** 我现在“卧底”到这边做社区啊 (笑)
- **@Fkysly** 我是早弦
- **@yyx990803** 哦，就是微博上那个 早弦mfe
- **@Fkysly** 对然后现在在做 Weex JS Framework 这部分
- **@Jinjiang** 早弦是最早Weex团队，他当时在这实习
- **@yyx990803** 对对
- **@Jinjiang** 然后现在正式过来了
- **@yyx990803** 赞赞赞
- **@Jinjiang** 我，我就跳过了
- **@Tancy** 我叫晓田，以前我主要是做手机淘宝这边 HTML5 性能优化的事情，Weex 还参与的比较少，现在逐步负责 Weex 性能相关的工作
- **@DoranYun** 我叫云冬，今后会跟晓田一起参与性能优化相关的事情
- **@Jinjiang** 二位是那个长期做，手机淘宝前端性能优化的。前期我们有一个“一秒法则”，就是一秒钟打开，所以跟首屏加载和网络相关性多一些。现在因为做Weex，我们的命题有一些变化就是做 runtime 的 JavaScript 的性能。
- **@yyx990803** 那可以有性能的优化，反馈到Vue的这个主干里面也是可以的
- **@Jinjiang** 而且我们最近还跟 UC “攀上关系”了，认识了些v8的工程师，给我们提供一些建议和经验
- **@Tancy** 他们的经验非常丰富

(大家发现 @terrykingcha 人不在，@Jinjiang 介绍 @terrykingcha 渚薰)
- **@Jinjiang** 他有一件事情是 2.0 preview 发那天我们连夜加班，赶出一个 Weex 支持 Vue 的版本就是我们两个干的，可能你有印象
- **@yyx990803** 对对对对对
- **@Jinjiang** 我觉得今天就是算相互认识一下，现在我们算一个团队了，也欢迎一下 (@yyx990803)
- **everyone** (鼓掌)
- **@Jinjiang** 然后我觉得今天就主要是大家就打打个照面，相互熟悉一下。接下来我们可能更多的机会，工作是在线上，所以相互先(认识一下)
## Scene 2 聊到一些 JS Framework 工作的细节
- **@Hanks10100** 我就好奇这个以后这个工作方式，怎么就是我们怎么参与这个Weex，我们怎么参与Vue
- **@yyx990803** 所以我其实我这两天在想这个事儿，就是现在我们不是有一个 weex-vue-framework，我在想，有没有可能过一段时间，就干脆把 weex platform 的 code 就直接放到 Vue 的这个主仓库，就是现在不是我有 platform 这个 folder，现在里面有一个 web，干脆就把 weex (folder) 放到 Vue 的主仓库里面作为一个 target，这样就避免……因为现在等于说两边分支，如果主干有更新，我是难以同步，所以干脆就放到一起，然后尽可能的，在两个platform之间，其实有一些module代码是可以共有的，或者稍微改一改就行，尽可能避免来回导
- **@Hanks10100** 那我们这个仓库就是我们现在，为此这个仓库怎么用你们这个
- **@yyx990803** 我考虑的话就是说这样，就是比如说weex-vue-framework就去作为一个Vue主仓库的一个fork，其实他本身就是runtime的代码
- **@Jinjiang** 只是 github 关系上看不出来，回头我们可以重新 fork 一下
- **@Hanks10100** 对于 Weex 主仓库和 Vue 主仓库，这两个仓库怎么怎么用那个
- **@yyx990803** 我现在本地我就直接 npm link……对这个对发布上也可能有个问题，但是，可以做成这样，Vue主仓库里面的release这个脚本做两套，一套是Vue本身发布到npm，然后另一个再添一个weex release的脚本发布到weex-vue-framework这个包。我大概这样设想了一下，具体怎么做还可以再考虑。
- **@yyx990803** 现在Weex依赖的HTML5 Runtime本身就是打包在里面的吗？
- **@Hanks10100** 两个版本，一个有，一个没有
- **@Jinjiang** 这个我觉得这个将来也可以调整
- **@yyx990803** 现在就比如说我现在用的那个就是跑vue的那个分支是作为一个npm依赖，然后require一下，所以所以可能之后也是作为一个npm的包。作为一个依赖，这样的话，两边这个更新起来也可以解耦
- **@Hanks10100** npm依赖改起来的话可以改很细节那些东西吗，比如指定到某个分支
- **@yyx990803** 因为就是最终我们的依赖是也发布到npm包为主啊，所以具体我们这个原代码里面怎么弄无所谓，就是最后你只要保证就是说，release script 一个是只发布vue的东西，一个发布weex的东西，确保这个发布出来的东西两边是相对独立的
- **@yyx990803** 因为我现在就是我自己，在本地弄的时候，就我在port一些，我最近加的东西，其实没必要这么搞
- **@Jinjiang** 这里我还有一个想法，现在我们如果就通过 npm link 的话，其实单个仓库不是很好做测试，现在可能也是一个问题。
- **@yyx990803** 噢，对，就是，比如说在weex-vue-framework里面做了改动但是没有办法直接跑
- **@Jinjiang** 对，你必须跟weex主仓库link，合起来才可以测，而且现在也没有自动化，反正这是现在的状态，将来我觉得这一块，我有一个不成熟的想法，就是可以写一个端上可以正常工作的virtual-DOM的一个test driver，类似 web test driver 那样，然后可以单独发一个npm的包，这个包可以用来测，就说，包括将来可能别的框架，也想接weex的话，他可以拿这个做通用API
- **@yyx990803** 然后就你就只是asset渲染出来的结果
- **@Jinjiang** 对，看一下渲染出的那个JSON对不对。
- **@yyx990803** 哦，就类似一个virtual render
- **@Jinjiang** 类似
- **@yyx990803** 恩，这也是个不错的想法，但是这个前提就是保障render本身的正确性
- **@Jinjiang** 是，就是这个测试框架本身需要经过测试
- **@yyx990803** 对
- **@Jinjiang** 而且有可能还有版本迭代
- **@yyx990803** 对，就比如说Weex核心做了改动这个测试也得改
- **@Jinjiang** 这是一个我已经想到的，我不知道你怎么看，或者你有什么更好的建议
- **@yyx990803** 我是觉得有人力做那是个不错的想法，但是如果只是两个link在一起测的话，有什么
- **@Jinjiang** 就有这个test driver，你不需要link，但是，嗯，它也许也有偏差，但是可以做一些简单的
- **@yyx990803** 比如说在ci上面，你写个脚本，每次weex-vue-framework有更新，你把这两个核心仓库clone过来……两边……搞一搞……然后两边再跑一下
- **everyone** (笑)
- **@yyx990803** 当然，这个可能就
- **@Jinjiang** 量级重了一些
- **@yyx990803** 比较hacky，对
- **@Jinjiang** 或者就在进一步，我可以接一个HTML5的Render，然后再做类似 nightwatch 我觉得也是行得通，但是纯native
- **@yyx990803** 它的infrustructure复杂度就比较高了
- **@Jinjiang** 现在我们我们的ci，JavaScript还蛮快，加上安卓和ios就会慢，也许这个test driver是一个折中的点
- **@yyx990803** 可以试一试
## Scene 3 (渚薰来了) 讨论 loader
- **@Jinjiang** 刚好介绍一下渚薰，对之前那个weex-vue-loader，现在的 weex-loader 也都是他包办的
- **@yyx990803** 接下来可能要把weex-vue-loader稍微升级一下
- **@terrykingcha** 我在开发当中，因为也是参考了1.0版本的vue-loader嘛。问些细节啊，你的做法是把每个block都extract出来，然后在我要去用它嘛，那这个其实会产生一些问题，第一个比如说我在检查那个sourcemap的时候，会产生一堆同名文件带很多参数这个东西
- **@yyx990803** 对对对
- **@terrykingcha** 这个这个东西就给人感觉我，我真的想去找他的原始码的话，会不会产生一些困惑，因为你点进去那些很多extract出来的东西，其实都还是那个原始的，有部分的生成码，有部分才是真正的源码。
- **@yyx990803** 现在是8.x的loader
- **@terrykingcha** 我觉得这个应该是webpack本身的机制吧
- **@yyx990803** 我很久没用1.x的loader了，2.0的loader好像还是可以正常工作的
- **@terrykingcha** 工作是没有问题，但是它会产生一堆不可预期的一些中间文件，然后通过sourcemap找断点
- **@yyx990803** 对因为我当初这么设计的主要原因是因为把每个block单独require之后，就等于说它可以有自己的loader chain，可以直接复用其他的loader，主要是出于这个
- **@terrykingcha** 因为在在看你那个逻辑之前，我自己想过，但是那种方式就会就是最早我也做过loader，只是我没有用那个extract的方式，直接 compile，然后很快就发现，我加不了 loader chain 的，后来用 extract 的这个方式给我感觉非常那个，怎么说呢，就是眼前一亮的感觉
- **@yyx990803** 这个其实最早也是我先写的browserify的vuerify，就是也是直接compile，然后接一起。然后我做vue-loader的时候想不出来怎么做，就先按那个方法做，后来有一个荷兰的一个人，他跑来跟我说，你可以这样这样这样，他这个办法是他去专门问了webpack的作者，那个作者告诉他说，你看我这个loader是这样写的，然后发现噢原来可以，他再给我发了个pr，然后我再根据它那个后面改，然后改成现在这个样子
- **@terrykingcha** 或者说这个其实本身也是webpack的他没有把这一类的机制什么的
- **@yyx990803** 对它的文档怎么讲，webpack里面其实能做的事情非常多
- **@terrykingcha** 但是都想不到，我们不深入到它的源码里面就想不到
- **@yyx990803** 他们现在2.0在花很大力气做文档，其实Browserify的文档也……我也是很多里面API，找半天，不知道怎么搞只能去看人家的
- **@terrykingcha** 那现在rollup那么火，那rollup的loader有必要做吗？
- **@yyx990803** rollup，其实他现在弱就弱在，就是说，它是完全依托于ES Modules所以对于资源的处理完全和webpack不在一个量级上，而且很多一些功能，比如说这种更强大的插件机制，loader chainning，code split，它都没有，而且可能他也永远不打算做，我觉得rollup的定位本身就是库打包，我现在所有的库都是rollup加上bublé，生成的代码尺寸很小
- **@terrykingcha** 对他基本上tree-shaking做的很好，我现在可能也类似于这种方式，自己库用，然后业务上代码还是webpack，还是功能确实挺强大的，支持很多东西，然后接下来确实一起再把weex-vue-loader完善一下
- **@terrykingcha** 还有一个sourcemap的问题，我发现如果devtools写成sourcemap以后，在Chrome里面debug会不准
- **@yyx990803** 对，偶尔是会有这个问题，其实我也研究了一阵子，没找到这个根源所在，我觉得可能是webpack本身
- **@terrykingcha** 但是我把它换成inline-source-map就对了
- **@yyx990803** 对，就是我也不知道，这个里面确实是有很多神秘的
- **@terrykingcha** 就是然后那天我们又试了一下，我虽然是用sourcemap，但是我们用另外一个版本的DevTools，是对的，到底是Chrome的原因，还是DevTools的原因还是webpack的原因，我也有点搞不清楚，反正差个两到三行，这个问题也困扰我蛮久的
- **@Jinjiang** 感觉不太像是sourcemap这个库的问题，因为它有问题的话，inline-source-map也会有问题
- **@yyx990803** 对
- **@Jinjiang** 但是webpack和Chrome就是两个大坑了……
- **@yyx990803** 是的，这里面中间能发生问题的环节太多了，所以我也一直没有时间一个一个去看
- **@terrykingcha** 不过现在现在在用那个vue1.0写的时候，我自己在写的时候，发现倒是正常的
- **@yyx990803** 很多时候怎么讲，就是断点啊，我在开发的时候都是很正常的，然后过一会就会用户说，唉，为什么我这个就差了一行……就差一行，然后我就是……我知道为什么真的就是……完全无头绪……
- **@Jinjiang** 噢，我想到细节，script标签如果不折行，立刻写代码的话
- **@yyx990803** 有可能，对
- **@Jinjiang** 因为你会把script注释掉
- **@yyx990803** 有可能
- **@Jinjiang** 或者中间有一些不可见字符折了行了，这个很难讲
- **@yyx990803** 我为了保证行数正确也做了很多hack，比如说我把他extract出来的时候，先把所有的地方全部用空白注释填上
- **@Jinjiang** 如果是一行的话，可能这个注释会
- **@yyx990803** 有可能，我默认用户就是script后面换一行的，哎，这种具体遇到了issue再解决吧
## Scene 3 谈谈 Vue 2.0
- **@Hanks10100** 我想问一下，你在ppt里说，1.0(时间开销)是vanilla的两倍，然后2.0只有1.29倍，这个中间做了哪些改变？是virtual-DOM的原因吗？
- **@yyx990803** 综合来讲的话，1.0最大的问题，制约1.0性能的最大的问题在于，就是做大列表的时候，每一个重复的段落都是一个fragment，然后这个fragment无论是从内存和这个就是生成的开销上来讲，其实还是一个比较重的东西，对于2.0的virtual Node来讲，是重一个量级的东西，这个是1.0主要的一个性能点，其实1.0优化的话，最早的时候，比如说做v-for，那个时候还是v-repeat的时候，每一行是一个实例，那个时候就很重很重，然后后来把它优化成了一个fragment，比实例要轻很多。但比单独的一行元素可能还是重。现在virtual-DOM了之后，所有的v-for就完全没有任何额外的开销了，跟普通的元素是没有区别。所以2.0在所有的列表，在首屏渲染方面要比1快很多
- **@Hanks10100** 我看到你提交的的stream-render的branch了
- **@yyx990803** 现在优化完之后，跟原本的runtime速度基本是一样的了
- **@Jinjiang** 基本在一个量级上
- **@Jinjiang** 我在这个地方其实还有一个细节，想求证一下，或者确认一下。因为我理解，现在像你刚才说的从1.0到2.0之后呢，从fragment变成一个正常element的开销了，但是如果我的数组非常长的话，我做了一次更新，整个这个for循环还是要算一下
- **@yyx990803** 对
- **@Jinjiang** 那如果列表特别长，那在1.0的情况下，他的开销是差量的，比如说我push一个item，他只会生成最底下的那个element，然后整个数组等于是用引用去diff一下，那个diff还蛮快的吧应该
- **@yyx990803** 恩
- **@Jinjiang** 那如果变成2.0这个机制之后，我假如说已经有1000条，我说得夸张一点，1千条，我又加了一条，整个这个render的过程是要1001次去计算吗？这个地方性能怎样
- **@yyx990803** 这个地方是这样的，就是1.0的fragment它是一个constant的，就是生成一个fragment之后我们就一直存在那边，就是说1.0的更新他是mutable的一直在里面，新多一个fragment我就新创建一个fragment插进去，然后作一次比较，2.0里面的virtual node是一个“用过即抛”的，每一次渲染我都生成它，但是非常轻，然后比如说1000个列表，我两边1000个virtual node的list，然后我是直接用了snap DOM 的算法，它的算法是，比如说你插入了一个东西，他会先从两边列表头开始比对，如果是同一个，就patch一下，如果这些东西都是组件的话，就组件没有变的话，他就直接跳过
- **@Jinjiang** 对，patch比较还是蛮快的
- **@yyx990803** 对patch的比较是非常快的，那就是他就一路就这么一路下去，直到遇到有一个的不一样patch，他会切换到从尾部开始比较，然后尾部开始一路比较上去，比较到最后就会发现插入的那一个多出来，他就把这个东西插入进去。所以说这个效率是非常高，其实就是我贴的那个benchmark里面有这个这些相关的，比如说他创建1000个，然后插一个，然后每隔10个更新一次，这些就是说小量更新都有，包括benchmark
- **@Jinjiang** 但你前边提到的整个生成的过程
- **@yyx990803** 你是指就生产整个vnode的开销吗？
- **@Jinjiang** 对我在想他即便相比传统的DOM已经很轻量了，但是如果在手机上，然后大家同时可能开了很多应用或者这个应用同时还在算别的东西，这个时候的效率怎么样？
- **@yyx990803** 这个效率还是怎么讲，benchmark已经把这些每一次的时间都算在里面，还是比1块，从绝对数值上来说，虽然看上去好像开销挺大的，但他确实是很快，不然virtual-DOM这个东西就不成立了。因为，怎么讲呢？里面也做了一些特定的，比如说每个virtual node尽量用，一个确定的v8的hidden class，都是我们创建一个新的vnode，所有的属性全部列出来，只有在需要的时候再把他设上去，就是这个东西是在v8里面是优化的不能再优化了
- **@Hanks10100** 这个我们之前也问过v8的同事，他就说不要不要往里面动态在加某些属性再删某些属性
- **@yyx990803** 对，每一个vnode的形状都是非常确定的。就是他一出来所有的属性都在上面，所以每一次他创建的时候就是一个效率非常高的一个过程，就是说从理论上来讲，可能会有这样的顾虑，但是我觉得以实际bench为主，因为从现在比较下来说，它确实比1的实际效率在绝对数值上更好，不用担心太多，如果实在不放心，咱们写一套benchmark，就是针对顾客
- **@Hanks10100** 专门测一下手机上的长列表
- **@yyx990803** 长列表的另一个是我们现在已经做了长列表的stream render。嗯，当然这个生成还是得一次性生成。其实他是这样的，比如说你有个1000个东西的列表，确认这个列表的时候，比如说它是一个组件，每个组件里面有很多的子的tree，在比对这个本身这个列表的时候，那些子tree是不会生成的，你只生成了顶层的这1000个node，这1000个node非常cheap
- **@Hanks10100** 就没展开
- **@yyx990803** 在你patch之前，这些子node是根本不展开的，如果是你是组件的话
- **@Jinjiang** 噢，明白了
- **@yyx990803** 所以说，如果你要追求这点，其实应该把它们做成组件。这样的话你在diff的时候，第一次render只生成了root node，比对一下，有变化的，我们才会再去重新 render
- **@Hanks10100** 这就是在使用上有技巧，就把它……
- **@yyx990803** 对所以有一个很有意思的现象就是在1.0里面你用更多的组件是绝对性能会损失的。2.0里面在很多情况下，有时候你把它拆分的更紧了，反而会有性能上的优势。大部分情况下，就是你说你在desktop上面是基本上不需要顾虑什么性能，手机上肯定还是会需要针对性的那些，但是就说这个我觉得还是要以benchmark为主，有用例，有benchmark才能针对性的做
- **@terrykingcha** 我想问一些设计上的细节问题，其实很多的directive都有modifier，这些modifier默认都是不开启的，我在写很多应用的时候，sync这种modifier经常会被用到，虽然sync的双向机制有的时候会带来很大的开销，但是我发现，我在用的时候，到处都需要写这个modifier，是否有一种机制，通过某种方式全局默认把这个开启
- **@yyx990803** 2.0已经没有sync了，2.0其实是可以实现的，但是现在更倾向于，因为sync的主要原因，就是说你写的代码，就是说，一旦你用了sync之后，你的子组件里面可能就不存在显式的跟外界交互的就会看见，说我一个方法，里面是设置这个this.a=123了。然后你根本不知道，这个东西其实对外部产生的副作用，这个东西就是用了很多之后就，我就发现，看别人代码，用sync多了知会，你看一下子组件，完全不知道他在干什么，调用了一个方法，然后改变了一个prop，然后你不知道，这个prop在这个发现这个这个组件自己都没有用这个prop，你都不知道他在干什么。那你要跑到所有的这个调用它的父组件里面去看他哪里用了sync你才知道这个东西的副作用在哪里
- **@terrykingcha** 就是有些人在这方面会设计得过度了一点
- **@yyx990803** 从理论上来讲，2.0现在的组件机制足够灵活，你可以自己做出类似sync的这种语法糖，但是从框架层面我决定把他拿掉，就是发现水平不够的人滥用他的比较多一点，所以现在的现在就怎么讲，Vue在设计上，2.0 可能有一些用户会觉得拿掉不习惯，但是本质上是为了防止一些初学者，他把这个东西用得过度，一些容易用过度的地方就，牺牲一些便利性，但是防止他们回过头来再骂我。
- **@terrykingcha** 大家肯定觉得不好的地方肯定都是作者的原因，而不会说自己自身的原因
- **@yyx990803** 他会说“你这个东西，你知道会有这个问题干嘛还要给我用？”，然后就在那儿骂我 (笑)，然后拿掉他又要骂我 (众人笑)。
- **@terrykingcha** 我之前刚开始2.0的时候，我尝试在工程里面用了一下，遇到一些不可预料的问题，包括loader和语法糖方面的问题……
- **@yyx990803** 什么时候？
- **@terrykingcha** 在前两周的时候
- **@yyx990803** OK
- **@terrykingcha** 可能是文档这块，文档是一大块，因为没有比较完整的文档，所以自己去猜测到底是应该是什么样子的
- **@yyx990803** 恩，2.0现在怎么讲，升级的话，很大程度上取决于你用了多少……他有一些地方确实比较就是不是那么明显的行为上的变化，我尽可能的在github issue里面尽可能列出来，但升级的时候还是可能遇到一些问题吧，可能最好的办法就是在2.0的升级guide出来之后，彻彻底底的过一遍，再开始升级会好很多。因为我自己像现在的DevTools完全升级到2.0大概就需要半天时间，当然原因是因为我自己从来不用那些我拿掉的功能 (笑)。就是我会拿掉，就是因为我发现我自己写东西的时候很少会用到，从本质上来讲，就是说，很多事情不用他们也可以实现。
- **@terrykingcha** 你说等文档写完了就发布，给我们的感觉就好像是又有期待，有感觉好像遥遥无期的感觉。
- **@yyx990803** 哦，那不至于，其实现在文档绝大部分团队已经写好了，现在有一个很给力的成员，文档基本上都是他写的，写得很详细，我现在基本就做修订，guide已经100%完成了，我现在修订，大概做了1/3左右，差不多就是一个礼拜之内的事情，但是还要做router和vuex的2.0文档，可能再加个两三天。但是文档这个东西其实就是需要静下心来做嘛
- **@Hanks10100** 我们是先放上去。然后文章至今还不怎么全，现在英文版有了，现在都还没有中文版……
- **@yyx990803** 文档这个东西很大原因就是现在经常有人用了2.0跑来开个issue说，唉，你这东西怎么跟1.0不一样？我说文档里面还没写到……
- **@terrykingcha** 现在其实大家做这类开源的项目，都会把文档排在整个项目开发周期的后面的吗？有没有存在一起进行或文档先行的
- **@yyx990803** 这也确实挺难的，因为你本身迭代完成之前写文档就意味着文档要一起跟着你的东西一起迭代，他本身对成本是很高，怎么讲我写文档的话，文档这两种，一种就是API Reference，你这个可以工具自动化生产，但这个东西说实话，你给用户直接去看他也看不出什么，光看一头污水，他也不知道你这个到底是怎么样，所以你肯定需要有一个比较人性化的这种文档，就是从怎么上手，怎么一步一步做，然后常见的这些pattern怎么处理，肯定得有一些这样的文档，这些东西是你要整合整个东西，做完之后去想好了才能写出来的，所以你很难一边写代码一边写文档
- **@Hanks10100** 得回过头来再从“他”的角度
- **@yyx990803** 对对对，这个写文档就是你很重要，就是要你要放在用户的角度，我什么都不懂，我是个小白，就你怎么样能写的，他能把你这个东西跑起来
- **@terrykingcha** 我最近也在尝试一种方式，就是，我会先脑子里设想好了，如果我想用这么一个库，我应该怎么样去用，我正在尝试着，我先把guide给写出来，我觉得我应该这么去
- **@yyx990803** Documentation-Driven Development
- **@Hanks10100** 相当于开发的，先写测试完好
- **@terrykingcha** 我觉得这个这个写API用起来这样挺舒服的，都挺好玩的
- **@yyx990803** 其实我很多时候是这样，就比如说我想做个新功能，我就先自己写一些这种示例代码，就我觉得最后用起来应该是这样的感觉，我觉得也是，也是可行的，但是就是这个比较适合这种以示例为主的文档，就是举例说，我们要实现这种东西会这样写，你可以先把代码
- **@Jinjiang** 目标性比较强
- **@yyx990803** 对
- **@Jinjiang** 甚至是你重构的时候，我觉得1.0到2.0，感觉你就是先把1.0的一个examples全部拿来
- **@yyx990803** 对，中间，我是用1.0中的examples作为e2e的test，我把他先改到我想用的新文档的做法，然后看能不能跑起来
## Scene 4 Weex该如何发展
- **@Hanks10100** 现在文档有各种语言版本
- **@yyx990803** 这个其实挺麻烦的
- **@Hanks10100** 你在这个推广上有没有什么技巧？就假如说现在我们Weex想打开这种国际市场啊是吧？嘿嘿，该该怎么做？
- **everyone** (大家会心一笑)
- **@yyx990803** 文档的诚意自己还是蛮重要的，现在我们看Weex的文档，用gitbook，怎么讲
- **@Hanks10100** 我们也觉得定制性不好
- **@yyx990803** 可以用一个static site generator专门做一个，其实成本也不高，因为都是markdown，稍微做一个那个，这样显得比较有诚意一点。多语言，比如说想抓国内的用户，中文的文档还是不可少的。
- **@Hanks10100** 我们怎么能吸引外国开发者来贡献Weex呢
- **@yyx990803** 我觉得一个是我肯定可以帮帮忙，另一个就是我觉得对于外国开发者而言，首先可能他们本身对阿里的了解就不够，对他们来讲，阿里就是这个“神秘国度某个不知名庞大企业”，业内人士他可能都知道，跟阿里有打过交道的他知道，但是对于比如说普通的这种普通开发者而言，他可能就是阿里巴巴，对他们来说，就好像我们听说沃尔玛在用一个什么技术，也不会太关心吧，所以可能这可能是个相辅相成的东西，是先有阿里的技术声誉，还是先有Weex来打开这个东西
- **@Hanks10100** 是互相的一个过程
- **@yyx990803** 对，我觉得最能吸引开发者是上手的这种实例
- **@Hanks10100** 恩
- **@yyx990803** 就是说，文档本身是一块，可能就是你写的英文的那种教程。然后你发在medium上，现在都是这样的。比如说，等到咱们的这个vue的这个版本能跑起来了，可以来一篇medium上的文章，比如说creating native app using weex，然后尽量写得通俗易懂，老少咸宜，就是保证，就是随便一个懂点前端的人看到这篇文章跟着你这个教程最后能做出一个原生应用
- **@Jinjiang** 无脑写就行
- **@yyx990803** 对，对这个东西吸引力其实是很大的
- **@Fkysly** 就像国内的什么“从零手把手教你写东西”
- **@yyx990803** Weex的宣传在国外是有一个劣势的，就是在于阿里本身在国外还没有像facebook、google这样的默认光环，就比如说google、facebook，他要出一篇文章，大家就一股脑，哇，牛逼，快学。现在我们是等于说阿里在国外就是等于说是有点，大家对你是一个，就将信将疑地说，唉，你这东西到底靠不靠谱，我不知道。这对国内开发者而言，阿里是有很强的这种这个声誉在后面，但是你要在国外推广，你就丧失了这个先天优势。所以就要从这个基层打起，能够直白上手的实例。然后大家看了之后，我们会意识到说，唉，还有这么一个东西。然后推广渠道的话，以一定固定的频率出一些这样的上手型的教程，然后当你有一定篇幅，然后就是这个东西，就有点写完一篇之后，在medium上发布，然后在Twitter上面维护一个账号，在各种渠道，比如说HackerNews、Raddit，这些地方同步发布，然后另外一个就是说，按一定的周期来做这件事情，就比如说每隔2到3个礼拜发一篇这样的东西。因为这个东西是这样的，就比如说你在HackerNews上同一个时间点发一篇东西，可能只有整个HackerNews用户基数20%~30%会看到你这篇文章，另外70%看不到，你隔一段时间换个内容再发一遍，可能会抓到覆盖到新一批
- **@Jinjiang** 我感觉HackerNews他刷的好快
- **@yyx990803** 对，因为就是我观察Vue的相关的东西，在HN上已经出现过好多次了，大概有五六篇upvote超过上百的东西，但是每一次出来还是会有人说，唉，我以前没见过这个东西，所以说就是对，时效性其实很强的，你一篇东西可能发到各个渠道那一段时间推广的热潮过去之后，可能最终reach到的用户基数只有百分之十几，所以你要有周期性的不停的多发几篇，然后每次有不一样的东西，然后比如说发到第三第四篇了，然后会有一个人第一次看见你这篇东西，他就会说，诶，有点意思，他再回头去看1234
- **@Hanks10100** 就像之前那个国内大概8:20发那种行为，很有讲究的
- **@yyx990803** 这东西确实是有点讲究，我也没有，就是很刻意的去做，但是就是在做的过程中，慢慢就发现，确实是有这样的因素
- **@Fkysly** 说到这个话题啊，其实像国外的一些开发者，包括很多国家的跟国内的开发者之间，有什么区别或他们贡献上面有什么风格都不一样吗？
- **@yyx990803** 我觉得总体而言，我觉得国外的开发者这种可是这个critical thinking更好一点，他们会更加知道就是说看到一个东西，它会自己去想，这东西到底靠不靠谱，适不适合我，国内太多开发者会比较容易跟风，国外跟风的，嗯，就是怎么讲，也有，但是很多就是即使是很普通的开发者，他也会自己去，就是说，他们更多的就是会看重上手的实际去做的这个体验，就是我实际用了觉得好就是好不好就是不好，觉得会比较在意，就是说你这个东西本身的这个不是看……当然了，就是，除非你这个背后的推广力量实在太大，像google啊什么之类的，还是会有无脑跟风的
- **@vczero** 刚才聊到文档方面其实跟我们现在规划的研究规划也有些一致的地方
- **@Fkysly** Vue在发展过程中肯定有很多社区的一些力量贡献对吧，然后其实我们为自己在考虑，Weex能不能集中一些核心的开发者，或有有兴趣的一些开发者，然后我们希望能够去用他们的力量去来影响，对，所以我们就没有那个可能没，不是很清楚，比如说怎么去跟核心这些开发者沟通，然后让他们能够参与到我们这些工作，然后大家去相互就是协作，真正的去做到一种开源开放的状态
- **@yyx990803** 我觉得要形成这样的生态，第一还是Weex本身是已经达到一个能够很直接的，被任意一个新的用户拿过来，就可以直接投入到生产当中这样一个程度，因为驱动他们会回头来贡献给你东西的首要原因是他们在实际工作中用你的东西得到了好处，对吧，如果它只是拿来试验试验玩玩，他是没有什么动力去回馈你的。他只有就是说他用Weex作出了一个东西，他觉得，唉，Weex是帮到我了，有好处的，我以后还会用，他才会有动力去说，我在实际用的时候发现我需要这个功能，Weex没有，我自己搞，撸了一个，回头分享出来了，这个这种东西就很好了，我们可以拿来把他放大，谁在用Weex的时候贡献了这个模块，大家可以用这样子
- **@Hanks10100** 我想起来个反例，就是 xxx，我至今搞他那个demo都没有跑通
- **everyone** (众人笑)
- **@Hanks10100** 你还要写service、template，然后各种东西，比较麻烦
- **@vczero** 我有个想法就是你怎么去发掘比较有特色的人呢？其实我也发掘了几个，但是有些发掘，它是有热情的，功底不扎实……怎么去维护这群人一起做事
- **@yyx990803** 其实Vue运用社区也有这个问题，就是React社区很强的一点，就是他里面很多热情的人本身确实也很牛逼，他能搞出一些很屌的东西，像Vue社区里面有很多很热心的人呢，处于一个高端使用者的状态，但是他没有到达，就是说他自己能搞出一个，就是说很酷的一个东西，自成一派，React社区最强大的地方，就是它里面有很多领袖级的人物，这个很难强行去培养，如果没有这种先天优势的话，还是先着重于我们能改进的地方都做好了，然后才会有这样的人愿意来这个社区里面贡献东西。
- **@Fkysly** 相比别的框架，然后其实我们有的时候会觉得Vue可能比较酷，或者说比较简洁对吧？你觉得就是说你用Vue的时候感觉很爽，就会有这种感觉，像你用苹果的东西你会感觉，诶，确实很简洁，我看到那个屏幕然后看到那个操作然后就解决了，在这个方面，你比如说Vue估计也有可能是你自己的设计的一些思考，因为我看我看你的个人履历，就是说之前是做设计的，是不是跟你做设计中design，可能会有一些简洁的一些思考
- **@yyx990803** 肯定是有关系的吧，我觉得就跟共通的地方在于做设计，其实我以前也是，就是慢慢，一开始注重一些外表，比如说我最早开始，就是是照猫画虎，就是做一些这种很酷很炫的东西，后来就是我就在学设计的过程中，我就想说，到底是什么，就是决定说这个东西是好设计，这个东西是坏设计，本质上而言，设计是为用户服务的，就是说，你如果不能结合，说，首先你要站在用户的立场，第二是你这个设计要达成怎样的，一个传达的目的，你要完成这两个东西才能够格说是设计，不然的话就只是在堆砌堆没有意义的东西
- **@vczero** 要么实用，要么优雅，要么死路一条
- **@yyx990803** 对，所以就是嗯，所以在做做所有的东西时候，我首先考虑，所以就是说就跟苹果一样，就是说你每一个细节，你考虑的是，就类似于用户开箱的时候，跟你用户上手的时候，每一个你觉得说会可能让用户不爽的地方，我就像强迫症一样，想办法我怎么把它藏起来或者改掉，或者说通过修改API让用户感觉不到它的存在，就是说，如果就是说我会意识到说我的这个用户体验里面有一个明显的瑕疵在那边，我就觉得说受不了，有强迫症，就是一定要把它改掉，所以就是可能就是有的时候，就你得强迫自己去。就是说，站在用户的角度，就想象自己是一个非常非常非常挑剔的用户，你去买一台电脑，你去买电脑，然后先是这个客服态度不好，然后给你一个包装，上面有一个洞，然后拆开来说这个开机要等很久，然后看了说明书半天不知道怎么用，然后你这个心情就很糟糕了，比如说你用苹果的话，店面很干净，很漂亮，然后拿到东西盒子包装很酷炫打开来直接就可以用，就是，这里面很多细节，其实都是靠，就是说有意识的去把它填掉吧
- **@Hanks10100** 客户第一，阿里价值观
- **@Fkysly** Weex其实应该也像Vue这种学习体验
- **@Jinjiang** 这个方面，我们蛮多工作要做的
- **@yyx990803** 我觉得Vue之所以就是说能吸引这么多人，本质上，可能这一点还是很重要，因为Vue在最早推广的时候，没有什么，就是说，大公司给他背书，也没有什么，就是本质上，就是说有人用了他觉得被吸引了就来用，就是就是很单纯的这样的理由
- **@Jinjiang** 这足以说明它的价值
- **@Fkysly** 用户体验做得特别好
- **@Hanks10100** 就刚开始吸引来的那些用户都是就是喜欢它，他觉得他好
- **@yyx990803** 说得粗暴一点，就是让用户爽
- **@vczero** 对，这就是易用，那么现在我发现，无论是Vue还是Weex，越做越大，包括工具层面，怎么跟易用去平衡
- **@Jinjiang** 通过渐进式框架？
- **@yyx990803** 对，所以这也是为什么我选要做渐进式的，其实现在也是，就是Vue有一部分部分，比如说那个cli的模板那部分就觉得做太大，我考虑可能会把webpack那个模板重新简化一下。就其实这个东西是一个很难平衡的点嘛，就像最近React做的那个create-react-app
- **@Jinjiang** 对我也留意到了
- **@yyx990803** 他现在issue多的不得了，大家都想把自己想要的功能加进去，然后，所以他们那边维护的人也很头疼，就是说到底怎么取舍，怎么平衡，就是说我这个东西需要达成什么目的，到底帮用户做多少事情，哪些事情你应该让用户自己去figure out，哪些事情，我们做掉，就说，如果你决定要去做一件事情，那你就把它做得很，要把它做好，就是说你得保证你整个体验是顺畅的，如果你决定说让用户去做这件事情，我觉得有两种选择，一种是说这是一个完全的user space的，你做这件事情跟我们无关，另一种就是说我们，并不把它作为我们产品的核心体验的一部分，但是我们提供你这个optional的这个东西，你要用的话你可以用，但是他并不是强制的。这样的事情其实也得很小心的做，因为等于说是挖坑嘛，挖坑不慎就是……
- **@Jinjiang** 引火上身
- **@yyx990803** 对引火上身，挺累的，我现在有意识的在这个限制这个新坑的数量
- **@vczero** 现在好多开发者是这样的，比如到Weex社区他一看之前发布了那么多文章啊，很多新的功能、调试工具，大家吓到了，需要这么多东西去搞Weex这首先是第一印象，以前的人跟着Weex在跑，能够看到一些变化，但是现在做的东西比较多了，到开发者面前的时候就是一个大盘子，他不知道抓哪个好

(录音中开始有比较大的杂音出现)
- **@yyx990803** 我觉得Weex相对于Vue来说还是有一定优势的。就是说原生开发比起Web来讲，模式还是相对更固定一点。你可以对于用户想要什么做出更多的预设，Vue之所以要做成渐进式的，就是因为Web上面的项目，从轻到重，种类太多，你有的这个用例跟那个用例需求完全不一样，那你做原生应用的时候，相对来说大部分原生应用，最后出来的东西相似度还是相对更高一些，这样的话你可以做的预设越多，你可以帮用户做的事情就越多，就是说这个就跟设计里面做用户调研一样，就是说，你考虑说，比如说Weex的目标是给90%的这种类型的应用提供最好的体验，你把这些用户作为典型，去分析他们的需求，去分析他们的这个常见的这种知识背景，他们会上手，需要上手的时候，不需要做的，哪些事情，就还有就是一个很重要，就是考虑一些从外部开发转过来的这些用户，他们常见的需求，尽量去把这些需求作为核心竞争力，把这个企业
- **@vczero** 现在Weex是两拨人，有痛点的，第一波人就是Web转过来的，这些人想让Weex足够强大，就说啥都能有，然后native的同学转过来对JavaScript不了解，但是它就局限在某个点，它做出来的东西很局限，这就应该是个悖论
- **@yyx990803** 以Weex设计的角度来讲，可能还是更偏重一些这种吸引Web的开发者，会更容易做社区，本身Web是一个很容易活跃起来的社区，再加上既然这个用的是Vue的这个语法的话，本身对Web开发者会更友好，当然也不是一定的，这个可能还是要做一些用户调查之类的东西
## Scene 5 场外问答环节
- **@Jinjiang** 我这边代表场外同学问几个问题，对，就是有有几个人，今天没来嘛，我这边有3个问题。第一个你可能熟悉，是元彦 @yuanyan ，先帮元彦问一个问题，问题是这样的，实际上今天这些JS框架，虽然大家是不同的框架，他可能做的事情是，或者说考虑的点是差不多的，比如virtual-DOM、组件化，在这个地方你你觉得怎么样？
- **@yyx990803** 这个东西是这样的，就是说，大家最终要解决都是一样的问题，对所有的框架都是为了让你做个app，区别在于你是选择什么样的路径到那边。那么这个路径而言，就是说，对于一个已经就是说掌握了这些所有的东西而言，那么它可能只关注的是这个本质的东西，他会觉得说这些东西没什么区别，但是对于使用者而言，大家有不同的背景，就是人有不同的起始点，有些人他会以他的背景，他学React或觉得不习惯，累，或者用Angular不习惯，累，或者有些人，他用惯了React再用Vue，觉得不习惯，不爽，对吧，这个本质上技术是为开发者服务的，那么你不能就是简单的说，因为技术最终本质上做的东西是一样的，其它技术都没有存在的必要。因为如果说既然大家都已经能用swift的去做ios，为什么还要有Weex？对，就是因为它提供不同的开发体验，它可以让不同的开发者群体去做到他们以前不能做的事情，这个意思它存在的意义。
- **@Jinjiang** 然后第二个问题是替斯肯 @IskenHuang 问的，斯肯同时是业务上合作和Weex线上发布系统的主力，然后他有这样一个问题，因为我们在发布Weex代码的时候，他是个JS Bundle嘛，然后，我们希望在服务器上也可以把组件从CDN做一个复用，我介绍一个背景，早期YaHoo有一种combo的CDN URL写法，就是用逗号分隔开，然后很多JS会拼在一起，那现在比如说像webpack打包出来的东西是没发这样用的，那从从Vue的角度怎么能够，就是说我，我组件之间可以复用，然后可以，我们可以用类似拼接的方式可以组成一个页面，而不是webpack那样的。我多解释一下，就是能不能直接concat那么简单？这不需要借助工具
- **@yyx990803** 这样的一个前提就是你的组件都是全局的
- **@Jinjiang** 对，另外呢，就是要去重。说白了
- **@yyx990803** 然后这个这个组件你提到说就是他是，是指所有的，用Weex写的组件，还是指是Weex核心的那些组件
- **@Jinjiang** 所有的组件
- **@yyx990803** 这个东西其实最近最近在推上炒得很凶，就是大家一般框架作品在跟google的人吵，webcomponents html imports 的事情，其实在 HTML 层面 html imports 做的就是这个事情，他基于两个假设，一，浏览器支持 html imports，第二，浏览单都支持 http 2.0，这样的话，html imports 那个规范本身是带去重的，对所有的包。你用同一个资源文件，它就自动先帮你去重了，然后他自带缓存，因为服务器端有http 2.0，所以不用打包，然后再加上你服务器可以做push，如果客户端可以做pre-cache，就整体上而言，就是说你的整个就没有打包概念，全是全动态请求，完全靠服务端，就是说，你可以在第一次加载的时候，你直接在header里面把你要pre-cache的东西整个全一股脑发过去，然后服务端就所有的东西跟你push过去。就是理论上是这样是可以的，如果在Weex的runtime里面做一个http 2.0的client，然后服务器端也全部支持http 2.0 push。
- **@Jinjiang** 那如果我们等不到http 2.0呢……对于一个业务的同学他全都在考虑今天的方案
- **@yyx990803** 对最近我就是跟他们在medium上跟他们在吵，就是，我就说，你告诉我说，现在就要我弄这个东西，我不敢用啊，对，我怎么知道用户的浏览器支持http 2.0呢？
- **@Tancy** 但我们已经全面支持了
- **@Jinjiang** 但是你看我们今天的发布结构还是这样的
- **@Tancy** 我们客户端服务端两边都已经支持了http 2.0
- **@yyx990803** 就是如果你对客户端服务端有完全控制的话，理论上现在就可以做
- **@Jinjiang** 那我们的createInstance的机制也要改了，就是一个组件、一个组件的create
- **@yyx990803** 嗯，我们在就是在微博上讨论一个问题，就是说，webpack打包的一个特点是，就是说你的依赖跟先后顺序是deterministic的。就说你知道说我这个东西import之后
- **@Jinjiang** 不接受实时的再加载
- **@yyx990803** 比如说我的子组件，肯定在父组件之前先被创建之类的，就说，动态加载就会产生一个瀑布式的依赖问题。你的这个所有的东西的最终渲染出来，时间就会受制于你的网络的这个情况，会增加很多不定因素。然后同时你所有的东西都得全局注册。这是两个限制，就是说，我也最近也在想这个事儿，就是我觉得，至少从目前来讲，Vue这方面还不敢去做这个事情
- **@Jinjiang** 你觉得这里缺一个轮子吗？
- **@yyx990803** 这个问题就在于说这Weex的立场来讲，对client有完全的控制权，所以其实是有一个的优势可以尝试做这个东西，甚至可以研究一下 html imports 这个 spec，看看里面有什么可以借鉴的
- **@Jinjiang** 好最后一个问题是代表颂奇 @songsiqi 问的，颂奇是我们transformer的作者也给vue-loader也发过issue做过贡献。我本来希望让他问一个跟sfc有关的，然后他说没有，想问一些八卦的问题
- **everyone** (众人笑)
- **@Jinjiang** 对，他蛮好奇，你的时间精力怎么分配的，因为看你提交也非常多，产量非常高嘛，然后也知道你每天飞来飞去
- **@Hanks10100** 怎么做到效率这么高的
- **@yyx990803** 现在效率已经比以前低多了，有了孩子以后我感觉我效率折半，哈哈，现在就是每天真正能focus的时间比以前少了很多，但是从时间上来讲，我感觉两方面，一方面是就是单纯的这种纯效率，就比如说我一开始说我开始修这个bug，到我修完他要多少时间，这个效率，我觉得是得益于，就是说我对代码，这个底层代码的控制，就是我对他的控制权以及，就是说写得还算不错吧，个人觉得，就是就是说代码结构比较合理的话，知道要修bug，就很容易定位，知道怎么修，就比较快，另外一个就是，其实我工作还是蛮没有规律的嘛 (此处省略一部分内容)
- **@Jinjiang** 这个可以公开讲吗？
- **@yyx990803** 这个还是不要了吧
- **everyone** 哈哈哈哈哈哈
- **@Jinjiang** 你现在的这个工作方式或者生活方式，家人怎么看
- **@yyx990803** 也其实挺有规律的，就固定，就是白天该上班的时间，我就待房间里做，现在因为我现在没办法，我一下班我老婆就进来说：来吧看孩子吧
- **everyone** 哈哈哈哈
- **@yyx990803** 没有借口这个……我以前没孩子的时候，晚上还可以。
- **@Jinjiang** 然后那像这样在家工作，在美国是一个普遍的吗？
- **@yyx990803** 还蛮常见的，在美国这样的可能会多一点，国内其实这样的也不少，但就是这个东西最大的挑战就是说你怎么迈出第一步，在你有稳定工作的时候，这个事情就是感觉风险很大，所以我也是等于说是各种机缘巧合，最后才敢这么做
- **@vczero** 那你觉得现在是有风险还没风险了
- **@yyx990803** 肯定还是有风险的，但在我可以接受的范围内

(告一段落)

音频原版上传到了土豆：
http://www.tudou.com/programs/view/pUJRUCbeBaI/


Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Weex meets Vue，记一次 Weex 前端团队的讨论 #77

Scene 1 面基环节

Scene 2 聊到一些 JS Framework 工作的细节

Scene 3 (渚薰来了) 讨论 loader

Scene 3 谈谈 Vue 2.0

Scene 4 Weex该如何发展

Scene 5 场外问答环节

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Weex meets Vue，记一次 Weex 前端团队的讨论 #77

Description

Scene 1 面基环节

Scene 2 聊到一些 JS Framework 工作的细节

Scene 3 (渚薰来了) 讨论 loader

Scene 3 谈谈 Vue 2.0

Scene 4 Weex该如何发展

Scene 5 场外问答环节

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions