原文链接：https://www.oschina.net/news/97966/about-vuejs-good-and-ugly

首发公众号：开源中国（oschina2013）

转载请注明上述来源，其余来源无效

编者注：该文章翻译于 Pier Bover?的“Vue.js: the good, the meh, and the?ugly”，仅供讨论，不代表本站观点。

用新的框架和库总是会让人兴奋，但也有压力。即便经过少量评估，你也永远不会知道你将会碰到什么样的意外情况。

在几乎每天用 Vue 大约两年后，我和它的蜜月期结束了，我终于能从少量角度来写点什么了。

Tips：以下纯属个人观点。

好的方面

响应性（Reactivity）

数据绑定在前台领域是个大问题。现在我们更专注于数据，而不像用 jQuery 一样对 DOM 进行微观管理。Vue 通过双向响应数据绑定系统巧妙地解决这个问题。

为实现这种响应性，Vue 为状态中的每个变量增加了许多 getter 和 setter ，以便它能跟踪更改并自动升级 DOM 。这种方法并不完美，我们稍后会再提到。

高可使用性（Batteries included）

用 Vue ，你无需用 MobX 或者 React Router 等非官方软件包来解决应使用程序的关键部分。Vue 提供了 Vue Router 和 Vuex 。这些都是很好的库，而且是为 Vue 量身定制的。

速度

Vue 非常快。它也许不是最快的，但它的性可以体现对绝大多数 Web 项目来说都是顶级的。你上一次需要每秒渲染和升级数千个 DOM 元素是什么时候？

HTML 模板

这是在 JavaScript 开发者中具备争议性的一个话题。无论你喜欢还是不喜欢，HTML 模板已经在许多语言中进行了数十年的实战打磨，并且是在 Vue 中编写动态标记（dynamic markup）的首选。

此外，Vue 也支持 JSX 。

其余

HTML、CSS 和 JavaScript 的单个文件组件。

轻量。大约 20KB（gzip）。

高可扩展（mixins、插件等）。

文档完善（除了下面提到的少量例外）。

可逐渐采使用，甚至使用作 jQuery 的替代品。

易于上手。

呃……不怎样样的

组件模板（Component boilerplate）

从 React 迁移到 Vue ，我似乎有感受到一股清爽空气，不再四处 bind(this)?或者 setState（）。好极了！但过了一段时间，我开始质疑 Vue 组件语法的有效性。

Vue 组件是用对象创立的，这是定义组件函数的示例：

你将为计算属性、组件状态、监视工具等增加相似的模板。Vue 中几乎所有的内容都有自己的特殊语法和更多的模板文件。

相比之下，Marko?也有相同的东西，但更简洁：

我的重点不是关于能否要用类，而是 Vue 用的是任意对象结构而不是语言特性。

假如你觉得我有点想找事，我不会怪你。 Vue 还提供了基于类的语法，但它实际上更像是事后诸葛亮。

社区？聊天室？（Chat based community）

Vue 社区使用户喜欢在 Discord 上闲聊，这更像是一款专为游戏玩家社区设计的聊天工具。假如你遇到问题，聊天可可以是你最好的选择，由于官方论坛是一片荒凉的土地，而且你也不敢在 Github 上问问题。

聊天很乱，更主要的是聊天的内容无法被搜索引擎索引到。同样的问题（及其相关的探讨）注定要一次又一次地重复。

这种用聊天来解答问题的趋势正困扰着开源项目，我认为它应该中止，根本没有集体学习作使用。

没那么神奇（Not so magic）

只需你不偏离正轨，一切都会很好，但过了一段时间你可可以会发现 Vue 附近有很多小小的 ifs 和 buts 。

比如说：

响应式系统仅跟踪肯定条件下的变化。不要指望它可以提供任何你想要的东西。通常，你可可以需要尽可可以地简化和整理数据以避免头痛。当然，这些都在文档的细则中有进行解释。

过渡系统 不适使用于列表。实际上，你需要用的是 ，它的工作方式略有不同，并且会在 DOM 中引入新元素。此外，有些东西你本期望会是一个已处理的问题，但实际上你必需要自己去实现它。

假如你需要组件实例中的 non-reactive 状态，你将进入一个未知的领域。

等等。

不要误解我的意思，这些都不是什么大问题，但似乎每当你开始动手摸索时，就会出现其它的小烦扰。

糟糕的方面

架构模式不清晰（Unclear architectural patterns）

比方，提一个问题：在组件中还是在 Vuex 中解决 API 请求会更好?

该文档提供了有关如何在 Vuex 中解决 API 逻辑的示例，甚至有一个漂亮的图表：

这能否意味着验证逻辑也适使用于 Vuex ？状态管理器会开始调解所有应使用程序逻辑？

这些都不是很清晰的问题。大多数人会选择直接将?non-state 逻辑插入到 Vuex 操作中，或者者更糟糕的是，直接插入到组件中，由于 Vue 的主页上有一段视频说明：

现在来答复我上面的问题：API 逻辑不应该使用 Vuex 或者组件编写。在少量官方代码示例中，也有很好的说明。

总结

Vue 的用率一直在不断增长，我怀疑这种趋势会很快中止。 它离 React 还很远（至少在中国以外），并且还需要与 Angular 竞争第二名。

在过去，不同于 React 的过于理想化，我认为 Vue 是一个很实使用的库。现在的我依然这么认为，但另一方面，我觉得 Vue 需要在实使用主义之上更注重使用户层面的精致、专注、优雅和简洁。

在用两年后，我对 Vue 的印象一直是积极正面的。我依然相信将我的团队从 React 迁移到 Vue 是一个很好的决定。不是由于 Vue 更好，而是由于它更适合我们。

Vue 可以很好地完成了它的“本职”功可以，并且在其余人失败的领域获得了成功，但起码到现在，客观来说，我并不认为 Vue 有比你技可以雷达中的其余选项有更强或者更差。

就这样。

补充：Vue CLI

上文中没有提到 Vue CLI ，我想解释下起因。

Vue CLI 是一个非常方便的脚手架工具。 在即将推出的 3.0 版本中，它将更加出色，由于它是一个完整的项目管了解决方案。

但是，便利的同时往往会带来更多成本，在我看来，这里的代价是不正当的。 Webpack 并不像很多人说的那么难，创立自己的入门套件可减轻大量配置时间。

当需要的成本低时，定制自己的自己设置产品才更有意义。

上一篇 目录 已是最后