通过一张图走进 Vue 2.0

这可能是字最少的一篇了,都在图里 - -

文字介绍稍后抽空再补补

Code Review for Vue 2.0 Preview

是的!Vue 2.0 发布了! 源代码仓库在此

首先,当我第一次看到 Vue 2.0 的真面目的时候,我的内心是非常激动的

Demo

来个简单的 demo,首先把 dist/vue.js 导入到一个空白的网页里,然后写:

当然,在大家阅读下面所有的内容之前,先想象一下,这是一个运行时 min+gzip 后只有 12kb 大小的库

<script src="./dist/vue.js"></script>

<div id="app">
  Hello {{who}}
</div>
<script>
  new Vue({
    el: '#app',
    data: {who: 'Vue'}
  })
</script>

你将看到 "Hello Vue"

然后再看一个神奇的:

<script src="./dist/vue.js"></script>

<div id="app"></div>
<script>
  new Vue({
    el: '#app',
    render: function () {
      with (this) {
        __h__('div',
          {staticAttrs:{"id":"app"}},
          [("\n  Hello "+__toString__(who)+"\n")],
          ''
        )
      }
    }
    data: {who: 'Vue'}
  })
</script>

这个是 compile 过后的格式,大家会发现首先 #app 下不需要写模板了,然后 <script> 里多了一个 render 字段,Vue 在运行时其实是会把模板内容先转换成渲染方法存入 render 字段,然后再执行,如果发现 render 已经存在,就跳过模板解析过程直接渲染。所以在 Vue 2.0 中写一段模板和写一个 render option 是等价的。为什么要这样设计,稍后会我们会涉及到。

阅读剩余部分...

Vue 2.0 发布啦!

原文:https://medium.com/the-vue-point/announcing-vue-js-2-0-8af1bde7ab9#.cyoou0ivk

今天我们非常激动的首发 Vue 2.0 preview 版本,这个版本带来了很多激动人心的改进和新特性。我们来看看这里面都有些什么!

更轻,更快

Vue.js 始终聚焦在轻量和快速上面,而 2.0 把它做得更好。现在的渲染层基于一个轻量级的 virtual-DOM 实现,在大多数场景下初试化渲染速度和内存消耗都提升了 2~4 倍 (详见这里的 benchmarks)。从模板到 virtuel-DOM 的编译器和运行时是可以独立开来的,所以你可以将模板预编译并只通过 Vue 的运行时让你的应用工作起来,而这份运行时的代码 min+gzip 之后只有不到 12kb (提一下,React 15 在 min+gzip 之后的大小是 44kb)。编译器同样可以在浏览器中工作,也就是说你也可以写一段 script 标签然后开始你的工作,就像以前一样。而即便你把编译器加进去,build 出来的文件 min+gzip 之后也仅有 17kb,仍然小于目前的 1.0 版本。

不是普通的 Virtual-DOM

现在 virtual-DOM 有点让人听腻了,因为社区里有太多种实现,但是 Vue 2.0 的实现有与众不同的地方。和 Vue 的响应式系统结合在一起之后,它可以让你不必做任何事就获得完全优化的重渲染。由于每个组件都会在渲染时追踪其响应依赖,所以系统精确地知道应该何时重渲染、应该重渲染哪些组件。不需要 shouldComponentUpdate,也不需要 immutable 数据 - it just works.

除此之外,Vue 2.0 从模板到 virtuel-DOM 的编译阶段使用了一些高阶优化:

  1. 它会检测出静态的 class 名和 attributes 这样它们在初始化渲染之后就永远都不会再被比对。

  2. 它会检测出最大静态子树 (就是不需要动态性的子树) 并且从渲染函数中萃取出来。这样在每次重渲染的时候,它就会直接重用完全相同的 virtual nodes 同时跳过比对。

这些高阶优化通常只会在使用 JSX 时通过 Babel plugin 来做,但是 Vue 2.0 即使在使用浏览器内的编译器时也能做到。

新的渲染系统同时允许你通过简单的冻结数据来禁用响应式转换,配以手动的强制更新,这意味着你对于重渲染的流程实际上有着完全的控制权。

以上这些技术组合在一起,确保了 Vue 2.0 在每一个场景下都能够拥有高性能的表现,同时把开发者的负担和成本降到了最低。

Templates, JSX, or Hyperscript?

开发者对于用模板还是 JSX 有很多的争执。一方面,模板更接近 HTML - 它能更好地反映你的 app 的语义结构,并且易于思考视觉上的设计、布局和样式。另一方面,模板作为一个 DSL 也有它的局限性 - 相比之下 JSX/hyperscript 的程序本质使得它们具有图灵完备的表达能力。

作为一个兼顾设计和开发的人,我喜欢用模板来写大部分的界面,但在某些情况下我也希望能拥有 JSX/hyperscript 的灵活性。举例来说,当你想在一个组件中程序化的处理其子元素时,基于模板的 slot 机制会显得比较有局限性。

那么,为什么不能同时拥有它们呢?在 Vue 2.0 中,你可以继续使用熟悉的模板语法,但当你觉得受限制的时候,你也可以直接写底层的 virtual-DOM 代码,只需用一个 render 函数替换掉 template 选项。你甚至可以直接在你的模板里使用一个特殊的 <render> 标签来嵌入渲染函数!一个框架,两全其美。

流式服务端渲染

既然迁移到了 virtual-DOM,Vue 2.0 自然支持服务端渲染和客户端的 hydration(直接使用服务端渲染的 DOM 元素)。当前服务端渲染的实现有一个痛点,比如在 React 里,渲染是同步的,所以如果这个 app 比较复杂的话它会阻塞服务器的 event loop。同步的服务端渲染在优化不当的情况下甚至会对客户端获得内容的速度带来负面影响。Vue 2.0 提供了内建的流式服务端渲染 - 在渲染组件时返回一个可读的 stream,然后直接 pipe 到 HTTP response。流式渲染能够确保服务端的响应度,也能让用户更快地获得渲染内容。

解锁更多可能性

基于新的架构,我们还有更多的可能性有待开发 - 比如在手机端渲染到 native 界面。目前我们正在探索一个 Vue.js 2.0 的端,它会用 weex:一个由中国最大科技公司之一的阿里巴巴的工程师们维护的项目,作为一个 native 的渲染层。同时从技术角度 Vue 2.0 运行在 ReactNative 上也是可行的。让我们拭目以待!

兼容性以及接下来的计划

Vue.js 2.0 仍然处在 pre-alpha 阶段,但是你可以来这里 查看源代码。尽管 2.0 是一个完全重写的项目,但是除了一些有意废弃掉的功能,API 和 1.0 是大部分兼容的。看看 2.0 中一模一样的官方例子 - 你会发现几乎没有什么变化!

对于部分功能的废弃,本质上是为了提供更简洁的 API 从而提高开发者的效率。你可以移步这里 查看 1.0 和 2.0 的特性比对。如果你在现有的项目中大量地使用着一些被废弃的特性,这意味着会有一定的迁移成本,不过我们在未来会提供更详实的升级指导。

现在我们还有很多工作没有完成。一旦我们达到了令人满意的测试覆盖率,我们将会推出 alpha 版本,同时我们希望能在五月底六月初推出 beta 版。除了更多的测试之外,我们也需要更新相关库(如 vue-router, Vuex, vue-loader, vueify...)的支持。目前只有 Vuex 在 2.0 下可以直接使用,但是我们会确保在 2.0 正式发布时所有东西都会顺畅地工作。

我们不会因此而忘记 1.x 哦!1.1 将会和 2.0 beta 独立发布,提供六个月 critical bug fixes 和九个月安全升级的长效服务 (LTS)。同时 1.1 还会包含可选的废弃特性警告,让你为升级到 2.0 做好充足的准备。尽请期待!

务实的小而美

随意分享几则自己近期的感悟

人不够?

我自己发现周围的同学越来越把一句话挂在嘴边,那就是:我们就这么些人,想搞定这件事情是远远不够的

说白了,大家觉得“人多好办事”,“规模”这个词很多情况下几乎就是个褒义词。

但是今天有些变化正在悄然发生,比如人类的学习能力越来越强,同时信息技术越来越发达,学习新知识的门槛越来越低,比如各技术领域的成熟度越来越高,比如移动时代前所未有的技术挑战,在有限的硬件性能和网络带宽的情况下,越是“规模”的东西越难以维持;比如体力和知识都逐渐远离核心竞争优势等等

拥抱社区,“我们有更多人”

一件事搞得起来搞不起来,逐渐不取决于我们的团队有多少人,而取决于我们有没有让这件事情发生在最广阔的舞台上,因为一个技术团队再多人,哪怕一百多人,相比起任何一个知名技术社区都是九牛一毛,而一个集团、一个国家、一门语言的社区,相比起全球的互联网社区,也都是渺小的。所以今天,我们想在技术上成就一件事,未必需要很大的团队,未必需要很多人在身边

同时,我们也不能小看个体在科技发展中所起到的关键作用。技术的不断融合和碰撞也加速了这件事情。所以更重要的不是团队有多少人,而是团队有没有能够真正起到关键作用的个体,找到对的人,比组建一支上百人的团队要重要得多

从社区汲取最好的技术

我敢说,抛开具有真正技术驱动力的公司,绝大多数公司的技术工作都能够在社区找到现成并且适合的方案,也都不太需要最高精简的科研探索。一个务实的技术方案,一定是在大量的社区成熟技术基础上建立起来的,再加上一点点针对自身业务独特性的技术实践。不过看上去“没什么自己的东西”罢了,如果大家很介意这东西“得是我自己的”,那么你需要继续考虑这个问题:自己搞出来的东西能不能比今天社区的更好,能不能发展成更好的社区,是否可以在社区中的深度参与从而把“别人的”变成“自己的”

在社区中施展+检验自己的技术

然而社区不应该只有索取,还应该有奉献,如果你发现有件事情是别人也会再次遇到的那种事情,但社区没有合适现成的东西,那么恭喜你,赶紧开工吧

有的时候觉得社区化的技术发展也有它残酷的一面,同类的方案或工具库基本上也就全球数一数二的几个能生存下来,并且体现出可观的价值,稍微差一点的,也许绝对实力没有差很多,但只要不是第一,所产生的价值和影响力就少得可怜了。所以想掂量掂量自己,看看是不是这块料,不妨放到社区里跟大家一起来一场真正的PK吧!也别自己憋着,别觉得“等我弄得再完善一点再给你们看”,因为在社区化的技术发展中,这样做只会让自己越来越没有价值和勇气把它拿出来了。当然也不必贪多,哪怕是一个小小的功能,如果做到最好,能够被全球的开发者使用,那也是极好的

合理的把技术运用在工作中

我们在工作中逐渐对人的评价,会由评价其绝对的技术实力,转向评价其运用各方面技术解决实际问题的能力。这两者之间有一个比较形象的比喻,就好比我们学生时期背单词,拿出任何一个单词来,都能立刻说出它的含义、发音、常用短语、同义词、反义词、各种形态,但面对具体的对话场景不知道该用哪个词最合适最得体,这是比较典型的一种现象。其实前者就像是一个人的技术实力,后者就像是一个人的解决实际问题的能力。所以新知识新技术不光要学,还要学以致用,如何合理运用技术解决实际问题才是我们真正希望看到的。

把工作中的必经之路和常见任务萃取出来沉淀为最佳实践

现在回到“小而美的务实方案”这件事情上。我们认为看上去很重要、工作量很大、需要很多人来做的工作,是可以充分拥抱社区,汲取最好的技术,同时发挥关键角色的关键作用,并把技术合理运用在实际需求上。整件事情的成败有很多因素,但是“规模”这个因素显然不在考前的位置了

基于这样的思考,我觉得,自己喜欢的团队,是一个小而美的团队

Vue.js 1.0.0 发布了!

作为“打入敌人内部”的第一件事,转载一下 Vue.js 1.0.0 新世纪福音战士 (其实发这篇文章的时候已经 1.0.3 了) 正式发布的博文 ^_^

Vue.js


Hi HN (Hacker News)! 如果你还不熟悉 Vue.js 的话,可以通过这篇文章 (英文)对其有个总体印象。

在经历了 300+ 次提交、8 次 alpha、4 次 beta 和 2 次 rc 之后,今天我很荣幸的向大家宣布 Vue.js 1.0.0 Evangelion 正式发布了!非常感谢所有参与 API 重设计的同学们——没有来自社区的贡献这是不可能完成的。

模板语法改进

1.0 的模板语法解决了很多微小的一致性问题,并使得 Vue 的模板更加简洁且易于阅读。最值得留意的新特性就是 v-onv-bind 的语法简写:

<!-- 简写版 v-bind:href -->
<a :href="someURL"></a>

<!-- 简写版 v-on:click -->
<button @click="onClick"></button>

当使用一个子组件的时候,v-on 用来监听自定义事件,v-bind 用来绑定属性 (props)。这些简写让子组件变得更易用:

<item-list
  :items="items"
  @ready="onItemsReady"
  @update="onItemsUpdate">
</item-list>

API 清理

Vue.js 1.0 的总体目标是使其适用于更大型的项目。这也是很多 API 被弃用的原因。在被弃用的 API 中,除了很少被用及之外,最常见的理由就是它会导致可维护性被破坏。特别是,我们弃用了难以维护的功能,并把组件提炼隔离开,使其不会对项目其它部分产生影响。

比如,在 0.12 中默认资源 (asset) 方案会隐性降级到组件树中的父级。这使得组件中的可用资源非常不确定,并且取决于在运行时的用法。在 1.0 中,所有的资源都基于严格模式进行解析,也没有了隐性降级。inherit 选项也被移除了,因为它很容易导致组件强耦合,无法提炼。

更快的初始化渲染

1.0 用 v-for 指令 (directive) 取代了 v-repeat。除了提供相同的功能和更直观的作用域之外,v-for 将初始化渲染大列表和大表格时的性能提升了 100%

更强大的工具

在 Vue.js core 之外,还有很多令人激动的东西:vue-loadervueify 的新升级,包括:

  • 组件热加载。当一个 *.vue 组件被编辑之后,其所有活跃实例都可以在页面不刷新的情况下完成热转换。这意味着你不需要重新加载 app 就可以完成诸如样式或模板的小调整;而 app 本身及其被转换的组件的状态可以被保留,这大大提升了开发体验。

  • 局部 CSS。通过在你的 *.vue 组件的 style 标签上简单加入一个 scoped 特性,该组件的模板和最终生成的 CSS 就会被奇妙的重写以保证组件的样式只被应用在其自身的元素上。最重要的是,父组件的特殊样式不会泄露到嵌套的子组件当中。

  • 默认支持 ES2015。JavaScript 一直在进化。你可以用最新的语法写出更简洁生动的代码。vue-loadervueify 现在会直接转换你的 *.vue 组件中的 JavaScript,无需额外的设置。今天,就来写未来的 JavaScript 吧!

结合 vue-router,Vue.js 现在不只是一个库了——它提供了一个构建复杂单页应用的稳固基础。

下一步?

如一般 1.0.0 所提倡的,核心 API 将会保持稳定服务于可预见的未来,库也做好了产品级别的准备。未来的开发会专注于:

  1. 改善 vue-loader 并使其做好产品级别的准备。

  2. 捋顺开发体验,比如更好的开发者工具和 Vue.js 项目/组件脚手架的 CLI。

  3. 提供更多诸如教程和示例的学习资料。