对无线电商动态化方案的思考（三）
Jinjiang opened this issue · comments
之前两篇我们分别谈到了对无线电商动态化的理解，以及我们自己的技术方案：Weex，今天我们分享一些其中的技术细节
data-binding
首先要介绍一下我们是怎么做到数据绑定的，首先，我们对上层撰写的代码遵循了传统的 mustache 书写习惯。即：
<template>
<text style="color: {{mainColor}}">{{title}}</text>
</template>
<script>
module.exports = {
mainColor: '#FF9900',
title: 'Hello Weex!'
}
</script>我们的 transformer 对这样的语法的解析思路非常简单直接，即：
- 不含 mustache 语法的值，直接做为最终返回值
- 含 mustache 语法的值 (如
{{xxx}})，转换为：function () {return xxx}
所以上面的模板最终会被转换成：
{
type: 'text',
style: {
color: function () {
return this.mainColor
}
},
content: function () {
return this.title
}
}在客户端的 JavaScript 引擎中，我们会进行这样的判断：
// parent, key, value, updater, data
if (typeof value === 'function') {
updater = value
parent._bindKey(data, null, key, updater)
}
else {
data[key] = value
}只要是函数类型，就进行数据绑定，否则一次性赋值，简单易懂易用。
这样在相应的数据发生改写的时候，界面结构和样式会通过 _bindKey 和 updater 自动触发更新。
关于如何在 JavaScript 上实现数据监听，也算是一个很重要的细节，不过市面上已经有大把优秀的实现案例了，我们也没有在这个环节上做特别的事情，所以不做赘述。(p.s. 在 Weex 的 JS Framework 中，我们复用了 Vue.js 的数据监听 (observer/*.js) 和依赖收集 (watcher.js) 的代码实现，在此特别要感谢一下！)
transformer
在 transformer 中，我们主要的工作就是对 HTML、CSS、JavaScript 代码进行解析和重组。这里我们用到了三个非常重要的库：
- HTML 解析工具：htmlparser
- CSS 解析工具：cssom
- JavaScript 解析工具：uglify-js
用 htmlparser 可以把 HTML 转换成 JSON
var fragment
var handler = new htmlparser.DefaultHandler(function (err, data){
fragment = data
})
var parser = new htmlparser.Parser(handler)
parser.parseComplete(content)
...用 cssom 可以把 CSS 转换成对象供二次处理
var css = cssom.parse(content)
var rules = css.cssRules
rules.forEach(function (rule) {
rule.selectorText
rule.style
...
})用 uglify-js 可以把 JavaScript 代码进行细节解析处理
// 遍历语法树
new uglifyjs.TreeWalker(function(node, descend) {...})
...
// 格式化代码
uglifyjs.parse(code)
...而且因为有了 transformer，我们可以把传统 mvvm 需要在客户端甚至 DOM 上完成的模板解析、数据绑定语法解析等工作提前处理完毕。所以免去了客户端运行时现解析模板源文件的负担。更酷的是，因为模板解析是不依赖真实 DOM 的，所以我们可以大大方方的把语法设计成 <img src="{{xxx}}"> 而不必担心任何副作用。而高级的表达式、过滤器等数据绑定语法也都可以在 transformer 这一层提前处理好，这样在撰写体验持续增强的情况下，运行时并不会产生额外的负担——这都要归功于我们引入了这一层 transformer
debugger tools
我们为 native 界面调试设计了贴心的远程调试工具，主要解决三个痛点问题：
- 调试 JavaScript 代码，任意设置断点 debug
- 运行命令行代码 (Console) 对程序做实时的判断
- 渲染结构的树形审查
解决问题的办法是：
图：远程调试工具工作原理
- 客户端设置一个开关，可以把 JS Bridge 对接到一个远程的 websocket 服务器，而不是对接到本地的 JavaScript 引擎
- 本地准备一个网页，其中运行了完整的 JavaScript 引擎的代码，并且也可以链接到一个远程的 websocket 服务器，这样客户端的 native 层和本地网页里的 JavaScript 引擎就串联起来了
- 原本通过 JS Bridge 的双向通信内容可以被 websocket 连接记录下来
- JavaScript 引擎里的所有代码都可以通过本地浏览器的开发者工具进行 debug 和 console 控制
- 开发一个简易的 Chrome Devtools Extension，可以得到 Weex 实例的界面结构，并以目录树的方式呈现出来。
这样，一个客户端开关，一个 websocket 服务器，一个本地的 JavaScript 引擎页面，一个开发者工具扩展，我们就实现了 Weex 的远程调试。
图：开发者工具的审查元素功能扩展
unit test 和 ci 实践
Weex 的 JavaScript 引擎作为一个相对底层的项目，品控需要做到非常严格和极致，否则一个小小的失误在客户端长期运行之后都有可能带来灾难性的后果。
本次 Weex 的开发当中，我们认真实践了基于 mocha、chai 和 sinon 的单元测试，每个源代码的文件夹都放了一个名叫 __test__ 的文件夹，里面放了这个目录下所有同名的 JavaScript 文件，每个文件的内容都是当前文件夹内对应文件的测试用例。
图：所有的源文件都在同级目录下有一个 __test__ 文件夹放相应的测试代码
在项目中后期，我们还引入了集团内部的一个 ci 系统，每次开发新功能，先开一个分支，然后写测试用例，最后进行代码实现知道跑通所有的 test case，搞定之后发起 merge request，ci 系统会自动在线上运行所有的回归测试，再次验证其正确性和各项指标。
图：项目分支管理
图：CI 实践
其实有关项目品控的话题还有很多，我们也在逐渐实践当中。
isomorphic (同构)
我们已经在内部版本实现了简单的服务端渲染，有了这个东西会怎样呢？
一旦我们可以在服务端直接渲染出界面的 JSON 结构，客户端就可以绕过 JavaScript 解析过程，直接根据 JSON 结构把界面渲染出来。与其对应的逻辑控制稍后也会初始化好，并和界面效果最终保持同步，但在整个过程中，首屏加载的时间会进一步缩短。而且，更令人兴奋的是，如果当前界面刚好没有交互逻辑，甚至后期的 JavaScript 也不需要参与了，这是一条更短的链路！
反哺 HTML5
通过对 Weex 技术方案的探索，我们把组件化开发、transformer 机制、同构等理念反哺到 HTML5 开发，会有什么样的惊喜呢？
那就是一个极简的针对无线前端的 HTML5 MVVM 库：我暂时取名叫做 v.js
v.js 的名字来自著名的 MVVM 库 Vue.js，我希望这个库更适合移动端，目前它可以具备所有 MVVM 的核心功能，通过 transformer 提前解析模板，运行时更快速，体积是 Vue.js 的 1/3，而且支持服务端的同构。这些都是基于移动端现状的二次改进，目前还在细节构思和研发当中。希望不久的将来可以跟大家见面。
<template>
<div>
<img src="http://www.taobao.com/favicon.ico" width="32" height="32" onclick="foo"></img>
<span style="color: red;">Hello{{name}}!</span>
</div>
</template>
<style>
.title {color: red;}
</style>
<script>
module.exports = {
data: {
title: 'World'
},
methods: {
foo: function (e) {
this.title = 'V'
}
}
}
</script>基于 v.js 的源文件
v.js 的展示效果
{
"ref":"0","type":"root","attr":{},"style":{},
"children":[
{"ref":"1","type":"div","attr":{},"style":{},"component":"...",
"children":[
{"ref":"2","type":"image","attr":{"height":"32","width":"32","src":"http://www.baidu.com/favicon.ico"},"style":{},"event":["click"]},
{"ref":"3","type":"span","attr":{"value":"HelloWorld!"},"style":{"color":"red"}}
]
}
]}同构的 JSON 数据，方便 native 快速渲染
<root ref="0">
<div ref="1">
<image ref="2" height="32" width="32" src="http://www.baidu.com/favicon.ico" onclick="$fire"></image>
<span ref="3" value="HelloWorld!" style="color: red"></span>
</div>
</root>同构的 HTML 代码，方便浏览器快速渲染
篇幅有限，写了三篇还是觉得不够，期待和大家更多的交流。我晚上再针对大家频繁问及或感兴趣的问题做一个整理。欢迎继续阅读大家近期针对 Weex 的常见问题汇总整理
阿里无线前端团队更多精彩的内容还在后面排队，我这边对无线电商动态化方案的思考就先写到这里了：）
我们已经在内部版本实现了简单的服务端渲染，有了这个东西会怎样呢？
一旦我们可以在服务端直接渲染出界面的 JSON 结构，客户端就可以绕过 JavaScript 解析过程，直接根据 JSON 结构把界面渲染出来。与其对应的逻辑控制稍后也会初始化好，并和界面效果最终保持同步，但在整个过程中，首屏加载的时间会进一步缩短。而且，更令人兴奋的是，如果当前界面刚好没有交互逻辑，甚至后期的 JavaScript 也不需要参与了，这是一条更短的链路！
跟我自己原本想做的东西基本一致-->通过JSON生成页面。只不过weex 在生成JSON之前加多了个transformer，其实不止是 webcomponents ，换成其他也是可以进行转换，因为思路已经在那里了。而这个核心的**一样可以用来构建pc页面，相当于打造了一个积木系统去快速搭建专题页面了。
只不过目前我们大多数页面仔还是面多浏览器比较多而非native，weex可能会引起前端开发者对native的青睐，也可能未必。~
在移动端浏览器上的表现能否更上一层楼？这让人很期待。
很好，很强大。~
nice
效率好高 先占坑 等下来读
持续关注
Model -- (js)transformer--- H5 view
| |
(native)transfromer |
| interactive (interface)
native view ----------------
Model (component way)
transformer ( v.js or native)
transformer很好，解决了一些痛点。站在了vue.js, react.js的肩膀上，不过还是挺好的。
这些思路真是值得学习！太棒了。
这篇看不懂的干货多起来了……期待。
强大
大家近期针对 Weex 的常见问题汇总整理
设计初衷
我们希望移动客户端可以具备动态发布的能力同时不失良好的性能和体验
这里面有三个关键要素，同时也是 Weex 的侧重点：
- 轻量：首先每次远程请求的数据量级太重就无法愉快的通过网络实时同步或更新了，还有就是客户端的包也是比较小巧的，可以较低侵入性的接入不同的业务
- 跨端统一：每次发布只需要一份源代码，多端差异会尽可能抹平或收敛在不影响数据和描述的范围内
- 横向可扩展：我们希望客户端提供的能力不仅限于团队自己产生的基础组件和 API，大家可以对原生组件或业务功能做针对性的定制和抽象，同时高扩展性也可以帮助 Weex 核心保持在一个小巧的体量
我们并不是一个人在战斗，市面上已经有很多非常优秀的技术可供参考和使用，Weex 希望集优秀技术之大成，快速落地，解决业务上“最后一公里”的问题。
另外除了介绍设计初衷，也想强调一下 Weex 不是什么：
- 不是一个 HTML5 库或开发框架
- 不是一套全新的技术
- 不是为了解决纯 native 开发的体验问题
- 不是一个以自身为中心的移动应用开发框架
一套代码同时运行 3 端？
是的，这是基于动态性业务需要的考虑，也是工作效率最大化的必然产物
如何做到“热更新”的？
也就是我们所说的“实时/动态部署”：通过 JS 进行描述和控制，把传输体积做到最小，把运算量降到最小，加上配套发布机制
感觉就像 React + MVVM 合体
Weex 是结合了 React Native 和 Vue？
这用的应该就是 Vue.js 吧？
这几个问题统一解答一下。
很多同学也开玩笑说这就是个“vue-native”，对此我没什么可否认的。团队在前期考虑移动端动态性解决方案的时候，包括整个实施过程中，对我们影响最深远的应该就是 React Native 和 Vue.js 了。我们也不介意晒一下这套技术方案背后的“幕后英雄”们：
- Vue.js：我们从 Vue.js 借鉴了 MVVM 的独特优势，并复用了 Vue.js 中数据监听和依赖收集部分的代码
- React Native：我们从 React Native 中获得了 Virtual DOM 和在客户端引入 JavaScript Engine 的灵感，完善我们的动态化逻辑处理和 JS Bridge 接口设计，同时复用了 csslayout 这个 native 布局计算的库，它把标准化的 flexbox 布局引入了 native 的世界
- mustache：我们数据绑定语法设计的灵感来源
- webcomponents 系列规范：我们通过对 webcomponents 长期的学习和探讨，摸索出了自定义组件封装和 template/style/script 三部分描述组件的最佳实践 (其实
vue-loader也是这个思路) - 还有一些手机淘宝常年的底层技术积累，如集团 Hybrid API 统一设计规范、底层的图片库、网络库等，都能够让我们能够快速实现自己的想法，快速在业务中完美落地，快速产生它的价值！
终于知道 @Jinjiang 为啥之前一直在研究 webcomponents & vue.js 了
呵呵是的，我在准备这套技术方案早期几乎见人就问 MVVM 和 React [偷笑]
可以透露一些心路历程
今年早些时候在 ShenJS 的时候，我自己也有幸和 Vue.js 的作者尤小右当面探讨过这些问题。我记得直接问了他是否对“Vue Native”这样的东西感兴趣，小右说自己的精力会先集中在 Vue 1.0 上，但随后小右提到一个观点：
实际上 Virtual DOM 可以理解为就是一个 AST，如果依赖收集能够和 AST 再结合起来，应该会不错
同时也在之后的一次技术交流的场合跟贺老聊到这件事：
- 如果能够把传统 MVVM 的模板解析过程提前或不经过 DOM，性能表现应该会更好
- 今天我们周围大量的移动端界面并没有复杂的数据结构和交互逻辑，如果能够把 MVVM 和 Virtual DOM 结合起来，应该也是一个不错的思路
还有一次和达峰聊到 React，我们都看过源码，有一个相同的感受，就是 React 的量级还是有点重，有点“过度实现” (记得原词是 over-implement，R 粉请原谅我这样讲)，尤其放到移动端。所以不论是 React.js 还是通过 React Native，我们想达到动态化的目的，都不一定是最好的选择
这些经历都给了我很多信息和思考
再后来，集团很多兄弟团队都在做着各式各样的 React Native 的尝试，看得到大家各自的突破和成绩，也不时看到一些瓶颈和无奈，尤其是体积、性能和可控度上。我不由得思考这样一个问题，就是 React Native 对于“动态化”这件事来说是否是最合适的基础？我们是否可以取其精华，汇集各路优秀的观点和理念，做出一个更合适的“最后一公里”技术方案？
再综合之前的一些想法和周围朋友的鼓励，最后如大家看到的，我在团队提出并实践了现在的这套 Weex 技术方案，并且有机会通过双十一主会场这样的业务得到了检验。
Weex 和 React、Vue 相比优缺点希望讲解下
上面一个问题的答复中其实提到了不少，我不太善于也不热衷评价别人，但 Weex 是一个特点鲜明目的很明确的技术方案，而且会继续在这条路上不断走下去，同时 React 和 Vue 也都非常赞！
似乎对 SEO 不太友好
目前 HTML5 的版本确实都是通过 JavaScript 生成界面的，从 SEO 的角度看是非常不理想的，不过有 2 件事：
- 从目前手机淘宝所处的业务形态和环境来看，SEO 并不是一个关键的问题
- 后期我们可以通过“同构”的技术手段实现服务器端预渲染，并生成 HTML 代码，这是可以做到对 SEO 友好的
研发过程中踩过那些坑？
还蛮多的，说几个刻骨铭心的
- 安卓下没有系统自带的 JavaScript 引擎直接可用，我们单独引入了一个叫 duktape 的引擎，但是后来发现效率太低了 (完整渲染主会场需要好几秒钟)，后来果断又连夜加班换了 v8
- 即便换了 v8 引擎，在手淘大团队“1s法则”的原则下，中低端安卓机的性能依然是很大的问题。native 尝试了多种接受 Virtual DOM 加载的策略，最后在 iOS 下选用了总耗时最短的一次性接受所有 Virtual DOM 的策略，而 Android 选用了按“楼层”分段加载 Virtual DOM 的策略，这样的话 Android 的总加载时间其实变得更长了，但是首屏渲染速度大大提高
- JS Framework 的代码为了配合各端的性能调试，引入了一些 FLAG 机制，即客户端运行 JS Framework 的时候，不同的平台会设置不同的 FLAG 参数，JS Framework 在多端还能够保持同一份代码，但是执行不同的加载策略 (其实整个系统优化过程中我提供了不止这两种 FLAG)
- 在 csslayout 布局实现中，文本和图片的尺寸和浏览器中的 CSS 不一样：是需要明确指定宽高的，而不会自动撑开。我们对文本实现了“自动撑开”
- 在 HTML5 版本中，为了应对懒加载等策略，我们设计了一个叫做
onappear和ondisappear的非标准事件，当元素被滚动到可视区域时，appear事件会被触发，而滚动出可视区域时，则会触发disappear，然后图片可以选择在appear的时机完成首次加载，商品分类的横向导航条的“自动定位”功能也是借助每个商品楼层的appear和disappear事件实现的 - 切记 JavaScript Core 默认是没有
setTimeout的，当然这个很好再实现 - 在没有远程调试工具的情况下 native 的实现和适配工作异常痛苦——一提到这个就觉得团队的 native 同学很了不起！索性我们现在有工具了
- 移动端 native 界面的资源复用是一个非常重要而且棘手的问题，它直接决定了应用的内存、帧率和稳定性
- 浏览器里多写几个甚至几十个
<div>没什么大不了的，但是在移动端结点数是一个很关键的要素，所以不能滥写容器，能省则省
另外也顺便抛一些尚未解决的问题，非常希望得到大家的指点和建议！
- 因为移动设备的资源非常有限，所以就算同时打开多个 Weex 实例，也只能公用一个 JavaScript 实例，如何有效的让多个实例在 JavaScript 引擎**存是个关键的问题
- 如何优雅的设计动画和表单的语法并合理的实现，是否照搬 HTML Form 和 CSS Transition/Transform/Animation 是最好的选择？
- 如何合理设计上层的 IDE 或可视化工具/编辑器
- 如何同一个 URL 或二维码，客户端请求到的是 JS Bundle，而浏览器打开的是一个 HTML5 页面
是否会开源？
我们非常希望乐于开源，和更多人一起分享和共建 (我们已经在刚结束的旧金山 QCon 上宣布了未来开源的打算)，现在我们的 native 底层还依赖着很多集团私有的架构和服务，比如基于阿里的图片 CDN 做了加载策略的深度优化，基于阿里的底层网络库做了数据请求的深度优化等等。所以这会有个过程 (如果你迫不及待想体验……机会也是有的，你懂的)
最后还是再次感谢大家的关注，大家提出来的问题我会继续和大家一起探讨
这个大前端的实现思路不得不让人佩服
好激动的样子
等开源再说
淘宝又造了个轮子，希望开源库能走出国门，与国际接轨。
期待开源
阿里之前搞了这么多MVVM框架，终于搞出一个像样的出来了
针对业务场景，将合适的技术整合在一起，形成解决方案，就是创新了，也多亏了有这样的团队支撑
后端渲染服务应该是用phantomJS做的吧
能谈一下研发的各个时间节点么：）
赶紧刘明
前排啃瓜子~
star再看~~
跟目前我们项目开发方式某些地方很相近，组件化的方式，提一个小小的建议，在定义组件绑定数据的时候，
<script>
module.exports = {
data: {
title: 'World'
},
methods: {
foo: function (e) {
this.title = 'V'
}
}
}
</script>除data、methods属性外，加一个options属性，可能对后期组件的应用场景带来更多的可能。目前我们组件绑定数据是这样的：
<script>
module.exports = {
opts:{
editable:true
},
data: {
title: 'World'
},
actions: {
foo: function (e) {
this.title = 'V'
}
}
}
</script>
大公司自己研究，小公司使用开源就好了，这是要累死程序员的节奏啊。有好多不懂的东西要学习:)
请问如何解决多人协作时 css的命名冲突
<template>
<div>
<img src="http://www.taobao.com/favicon.ico" width="32" height="32" onclick="foo"></img>
<span style="color: red;">Hello{{name}}!</span>
</div>
</template>
<style>
.title {color: red;}
</style>
@stephenzhao 可以看一下vue loader，在编译组件的时候会给相应的dom加上随机属性，并且将所有css选择器也加上了同样的随机属性，以此来解决scope css的问题
React 组件内部采用 js 本身替代了 mustache 这样的“小语言”，有了更大的灵活性。换句话说就是抛弃了 template 这个概念。这个我觉得挺好的。
令人激动的架构！
再补充一些：今天被同时问到了两个问题
- Weex 大量借鉴了 Vue，所以应该叫 Vue-native
- Weex 是顺着 WeApp 一路走过来的 (也是 HTML5、native、服务端三端同事一起搞出来的，但说得像只有前端搞定的一样)
所以，大家谁都觉得不爽，不然我们把这个技术方案的名字改叫 WeApp-Vue-Mustache-Native-*** 比较合适…… 另外索性W3C没介意这事儿不然名字更长
或者我在前端圈说这是Vue-Native，在大阿里内部说这是WeApp+，然后在美国 QCon 上说这是 Ali-React-Native
(以上玩笑，也算是在起名字这个地方自嘲一下)
也再多说一些
第一，Weex 的 we 开头一个很重要的层面正是为了代表我们是传承了 WeApp 的很多东西，包括 native 技术栈和团队。两个e是因为如果一个e发音就变了，当然这个名字还有其他方面的因素
第二，Weex 在前端 DSL 这个层面是非常接近 Vue 的，但是整套技术方案，前前后后汲取并引入了很多东西，直接用 Vue-native 也不太妥 (事实上 Vue-native 就是我自己早期起的开发代号，后来跟 native 同事聊的越多越觉得也不太妥，之前我们文章里截图都被大家挖出来了这也没什么可否认的)
第三，我们给技术方案起新名字的时候，确实想过起一个 V 开头的名字，讨论细节就不宜多说了
第四，即便没有上面的那些顾虑，Vue 这个名字在我这个脑残粉看来真的是很“神圣”的，带 Vue 字样的这个名字我也不好直接乱用吧，毕竟这从 Vue 的角度看是“在野”的，做得有模有样也许小右觉得不错，做不好把人家牌子都砸了你们说是吧我究竟把名字起成啥样你们能满意呢 - -
另外简单八卦一些我和小右、Weex 团队的事情：）
我个人长期在关注 Vue，也力所能及为 Vue 做些布道和文档的工作，也比较早的时候私下和小右交流过把 native 化的想法，这些讨论现在还在持续
另外目前 Weex 的团队构成并不只是前端，团队平时一起协作配合非常好，大家也普遍觉得比之前的 WeApp 更进一大步了，我把这些东西通过我们前端的博客发出来，也第一时间跟团队进行了交流。有同学也感叹说前端有一些天然的技术交流和分享的优势，其它技术圈似乎交流分享的少一些。大家甚至还在想要不要大家也都从各自的角度多写一点，尤其是 Weex/WeApp 的野史，找寒老师 @wintercn 几个人转转。所以我一开头提到的听到的声音应该是某些人的自己的猜测或错觉吧……
说到这里还是要再次感谢一下Vue，感谢一下 WeApp、Dynative、AliReactNative、鸟巢、WVC、PageKit、WindVane，Webkit，感谢一下团队的通力合作
大家不介意的话还是把关注的焦点回到技术方案本身吧：）
@andyforever 你提到的 options 字段可否有一些更形象的运用场景呢？我觉得这个字段和 data 蛮接近的
@stephenzhao 一方面是 @skyline0705 提到的方法，是用在 HTML5 环境下的，另一方面 Weex 自身会对样式先在组件内部做内联处理再发给 native 渲染，所以天然回避了这个问题。两者最终达到的目的和效果是一样的
option 这个字段看起来就像各种插件的参数，也就是为了达到组件复用的目的吧。
这不是重复造轮子，很期待看 release 后的版本。
我更喜欢把weex叫成weed!!!!，觉得真心牛逼
@Jinjiang 场景如定义一个Grid组件，data用来存放columns、rows数据，options用来定义grid的各种属性，比如editable是否可编辑、rowHeight行高、enableColumnReorder是否可以点击列排序等；
定义一个tree组件，options这个对象属性可以有checkable是否可以复选、dblclickExpand双击展开等。
如@jincdream 所说，提高在不同场景下的复用性，跟data参数混合在一起就不免有些混乱了
像组件我们分出tpl、css、js三个外在属性文件一样，组件数据绑定也可以固定成options、data、methods（actions），这是组件的内在属性。
@andyforever 这个感觉和元素自定义的 attributes 蛮接近的，尤其是 virtual dom 抽象化之后
@andyforever 我是觉得
组件主要不是用来复用的，是用来分治的。
有完善的组件系统，应该也有完善的版本管理了，不同功能的需求应该在不同的版本之中去体现。不然组件就会变得越来越复杂。例如你现在的editable:true，大概是可以编辑的意思吧，目前可能只有一个能不能编辑的分支，但后面的可能需求会增加，我这里可以编辑，但我这里编辑的时候可能要加上高亮，下划线，字体颜色改变什么的。。这时候，editable:false的配置也就有了冗余的代码。所有我觉得这并不是值得发展的方向。
不过肯定有一些是可变动，而那些就像是react的props和state，其实我们真正所需要的只是props而且，options应该要被放弃了。
@jincdream 不敢苟同。
对于不同的项目来说，最坏的结果是分治（不同项目能复用同一个组件当然是最好的）。对同一项目来说，分治是解决不了问题的。
像你说的props和state只是名字的区别，当然在模板上定义还是在数据绑定时定义，仁者见仁智者见智。
@Jinjiang 看了楼主的 Weex 的介绍了，和自己一直想要的开发方式几乎一模一样。现在最大的疑问是有两个，第一，编写的HTML(我暂时这么叫吧)在浏览器中是HTML的方式，那么在原生中，是不是转换成了原生的组件，如果是，这个组件和HTML的标签的对应关系你们怎么处理。第二，就是假设是把HTML转成了对应的原生组件。那么，如果别的公司要用自己的一套组件，比如我在H5中创建了一个 mg-slider 的组件，那么这个公司在原生层面，要做出对应的 Weex 的原生组件，需要怎么开发？
@andyforever @jincdream 二位的看法我中和一下，首先 props 和 state 可以分别理解为原始数据和最终展示相关的数据，类似 Vue 里的 data 和 computed 的感觉但不完全一样，因为在 Vue 里如果原始数据不需要加工就能直观的进行展示是不需要刻意转换成 computed 的。第二这些 config 我更倾向于用 webcomponents 的思路抽象成 custom attributes (也有个流行的叫法是 directive)，这个我上一条也提到过，比如类似 <x editable>...</x>、<input type="checkbox" checked value="..."> 这种的——其实你会发现在 Weex 里我对 attr/props/data/config 等概念做了简化，都统一在了一起，即自定义元素外面写的 attr 就对应最里面的 data。我希望这里不要搞得太复杂太特殊，这会带来一些封装不完全和不严谨但是简单易用的优势也是很明显的，尤其今天的手机上复杂界面并不多，业务上更看重的是“动态性”方面的能力和灵活性。
@niluanxy 如果跟你想要的几乎一样那我们还觉得蛮有面子的：）
问题1：其实我们最主要的组件就是容器 (对应 HTML 里的 <div>)、文字和图片，绝大部分内容都可以直接拿这三类组件 + Flexbox 布局搞定。我们主要就是原生实现了这三个核心的组件 + 引入 csslayout
问题2：如果创建了新的组件，则可以用 webcomponents 的方式规范好，然后扩展成“builtin component”集成到native里
赞同勾股的，我希望这里不要搞得太复杂太特殊，这会带来一些封装不完全和不严谨但是简单易用的优势也是很明显的，保持组件的易用性其实很重要。
刚刚想了下，可以复用的组件，其实是有的，这些应该往往是被依赖的核心组件了吧。
比如
其实我们最主要的组件就是容器 (对应 HTML 里的 < div >)、文字和图片
这里其实就是三个核心组件，而其他的组件都依赖于它们所形成的吧。
@andyforever 主要是 editable 这个词可以让联想到很多功能，如果只是单独的一个编辑快关，那它就像是一个可依赖的核心组件了，在不同项目上复用是没问题的。如果是为了能够让更多项目复用而写的一个组件，那这个组件应该是不健康的。我们大可以把这个开关editable之前的功能抽离出来，再各个不同的项目上进行各自对editable的封装。:)
因为移动设备的资源非常有限，所以就算同时打开多个 Weex 实例，也只能公用一个 JavaScript 实例，如何有效的让多个实例在 JavaScript 引擎**存是个关键的问题
不知道我理解的问题对不对，和你们团队的同学沟通过，在引擎加载js的时候，强制把这个js包含在一个function里面，至少可以杜绝各个js之间的变量冲突。当然，你还需要屏蔽window等全局变量。
没有看太明白，有个问题确认下，最终在native端执行的时候，是只有一个js引擎呢，还是也有xml和css的引擎？RN是只有js。
你们这么牛，马云知道吗？
其实大家都知道JS HTML CSS的这种前端开发模式在现在各种框架的支持下是最高效的，但是因为web页面在移动端的性能问题所以才搞这种写法是web的方式，但是运行是native的。不过我想知道为什么web也没这种dom树渲染的方式性能会差会卡呢？如果这个问题解决了是不是这些什么个xxx-native好像都没什么意义了呢？
66666！总之WEEX是吸收了RN和vue.js的一些设计**并且更加适合手淘和猫客内的前端开发，集团内部赶紧推广起来：）
@Jinjiang 那明白了，其实就是相当于做了一个虚拟机一样，选择H5最主要的元素，以及兼容上Flex布局的语法，这样来达到对应到原生组件的效果，了然了，确实目前来说这种方式最实际，也最容易应用起来。
@yutingzhao1991 好问题，我个人的看法是 webkit 的优化侧重点主要还是沿袭了 PC 端的一些典型场景，也许未来会发生一些改变，但是这个节奏比想象中慢得多，而且 iOS 下只有他自家的 webkit 可以使用，我们无法控制这件事情
@Jinjiang 是啊，记得12年的时候html5火得一塌糊涂，最后呢？发现还是要走native。有时候还是要务实啊，当年的html5就是太执着于web技术了，但是最终的决定权还是在用户还是在整个生态环境。目前感觉这个方向是靠谱的，web的开发模式+各个端各自的组件view。�也许某一天ios和andriod官方都借鉴并支持目前web前端的这种更有效的开发模式了。 JS >= ObjectC + Java + ...... :D
弱弱地问，weex 应该怎么发音？
问一下 加入 v8 后对客户端的体积有什么影响
如何同一个 URL 或二维码，客户端请求到的是 JS Bundle，而浏览器打开的是一个 HTML5 页面 // 判断来路和根据特定规则进行跳转不行么？
感谢分享，对于服务器js更新后该如何下发到客户端，并对比出需要更新的部分进行局部刷新这块比较感兴趣，这里weex是如何做的呢？借鉴了virtual dom吗？
我没理解错的这个transformer
1 如果运行在uc这样的浏览器里面 相当于是服务器端渲染
2 如果运行在手机淘宝里面的web view 是app原生渲染
是这样吗？
@qqqzhch transformer 会把 template, style, script 都转换成一段段 json 或 js，这样客户端只运行 js，不必同时解析 html/css 这些语法，你这里提的服务端渲染，出来的应该是个完整的 virtual dom 了，但是这里的 js 还会继续进行数据监听和绑定，然后才是生成最终的 virtual dom 再发送给 native 端渲染
"一旦我们可以在服务端直接渲染出界面的 JSON 结构，客户端就可以绕过 JavaScript 解析过程，直接根据 JSON 结构把界面渲染出来。与其对应的逻辑控制稍后也会初始化好，并和界面效果最终保持同步，但在整个过程中，首屏加载的时间会进一步缩短。而且，更令人兴奋的是，如果当前界面刚好没有交互逻辑，甚至后期的 JavaScript 也不需要参与了，这是一条更短的链路！"
这个地方请教一下，客户端什么情况下会拿到JSON，什么情况下拿到JS呢？
对于有动态业务逻辑的需求，肯定是需要用JS。但是仅仅是动态UI，是不是只用JSON就能解决问题？
@miniflier 等于先把初始化的virtual dom先生成优先加载并渲染，然后再把动态逻辑“补”上去，具体实现是有一些窍门的，已经不是什么行业秘密了
我觉得weex的项目的确是一个KPI的项目！
从双十一来看只是非常简单的页面再用，说实在的只是对电商的一些些（很少的页面有作用），其次由于事件跨线程的延迟 会导致事件处理的操作延迟到界面渲染上面去，这增加了 从事件发出到UI响应的时间。是一种巨大的性能的倒退的做法!!! 其实JavaScript的性能不是很高，采用大量的js的代码运行维持Native的界面运行，对内存和CPU都是浪费！
其次week一起来就拉起 排版线程(注意是排版线程)和JSCore的线程，无端端就增加了好几个线程(由于JSCore自己还会起线程)，这不得不说是一个性能的倒退和浪费。其次很多事件不支持，手势不支持(由于手势是持续的事件反馈，跨线程走message队列显然做不到及时响应)。在IOS下这种性能还说的过去，在安卓上面这种东西不得不说有点垃圾！！非常典型的不计较开销的做法！
最后总结下 为了实现一些些 很少的界面的动态化+配合web前端的开发胃口(其实为了页面动态化，完全可以利用java+网络+lua实现这个东西，而且性能更好)。简单的上线双十一的很简单的页面是不具备说服力的(当然忽悠上层不懂技术老板是可行的，(一下子跨三端，一次编写导出运行 多么诱人！！))。
所以说我个人认为这是一个KPI项目！
@@@在说说RN，这是一个很坑的项目。native代码风格和规范来说说是facebook发布的 吓一跳(对比Google的Chorme的代码)，原来美国佬也有这么随便写程序的！我以为只有我天朝才有！RN的话和Weex同理。从问题的出发点就是错的！Web前端的确很多人在用innerHtml的方式在更新dom，所以需要virtualDom 需要diff 这个无可厚非，**还是挺牛的不得不承认。但是问题出现在ios和android前端并不存在这个问题~ 你简单的把web前端的问题假设成移动设备native前端的问题，然后给出同样的解决方式是不是太过于坑了！
@@@有很多种可以做到移动端native的及时性上线变动（非app版本替换）的方法。兼容三端确实不简单，但是RN不是一种好的解决方案，如果非要说RN是一种好的解决方案，只能说他对web前端的意义还是有的。
国内现在一阵大风说RN这个好 那个好！是不是真的符合大家的场景，还是一味的跟风做KPI项目！
鄙人 去年一直在用 淘宝的app 在魅族的魅蓝手机上面！ 2G内存！ 淘宝的APP 那是卡的感动人。IOS倒是还可以！寄希望于IOS可以早日吃点安卓的市场，说不定就可以从机器的角度规避RN此类框架的性能问题
5年前就听说 性能不是问题，机器愈来愈好，到今天这个CPU过剩时代，我们还是搞出了性能问题，在厉害的硬件也抵不住操蛋的程序！
还有多个weex实例公用一个jscore的话，那么一直不释放这个jscore的确性能有加强。但是谁能保证前端代码没有内存泄露，如果泄露了那就呵呵了！ 这个也是一个坑！
其实阿里他们就是炒红了vue.js，来带动炒作他们的weex!
只能说真的写的好多
读读，视野打开更多。
最后在 iOS 下选用了总耗时最短的一次性接受所有 Virtual DOM 的策略，而 Android 选用了按“楼层”分段加载 Virtual DOM 的策略，这样的话 Android 的总加载时间其实变得更长了，但是首屏渲染速度大大提高.
我说怎么安卓的加载时间就是比iOS的长，还以为是苹果机高端些，原来是加载策略的问题~
另外很好奇这个按“楼层”分段加载Virtual DOM是如何实现的？
😄 👍
@jellychen 我昨天为了买个东西（在6s上），先用浏览器访问淘宝，然后动不动就提示错误，没招了，只能安装淘宝客户端，看了一眼，190多m，不知道是不是用weex做的，没有感觉到什么好的体验。（我们在用vuejs）
请问最后的例子里，为什么不是：
<span style="color: red;">Hello{{title}}!</span>?