Vue.js 使用感受

之前一直对 vue.js 很感兴趣,但一直不知道拿 vue.js 来做什么,前几天想了一下不如拿 vue.js 来重新建博客吧。现在你看到的这个博客就是用 vue.js 做的。 写这篇博客主要来谈一下 vue.js 的使用感受,顺带谈一下现在前端的一些新技术,包括 webpack , postcss。

在使用 vue.js 的过程中,我觉得的是很爽的,这是对比之前使用 ember.js, vue.js 给我带来的感觉。 稍后我会比较一下 ember.js 和 vue.js 。如果说用 vue.js 很爽的话,那么 vue.js 配合 webpack 那简直就是…… 我都不知道该怎么来形容了,我只能说很爽 很爽 很爽。webpack 就是一前端神器,之前没使用 webpack 之前,我想不就是一个搞模块化打包的东西吗,有什么啊? 但是使用了 webpack 之后我发现已经离不开它了,因为什么? 因为太他妈好用了。webpack 让原本松松散散的前度的架构,有了一个很好用的工具来组织了。webpack 视一切的前端资源为模块,对于不同的资源,你只需要配置相应的 loader 就行了,当你需要加载某一个资源的时候,只需要 require 它就可以了,就这么简单。你甚至可以在资源里面 require 其他的资源。我觉得 webpack 好就好在它实现的十分自然,为什么这么说了,设想一下当你 require 一个东西的时候,它就使用相应的 loader 来加载,而且 loader 也是可以串接的,这样资源就顺着一系列 loader 组成的管道给引进来了,这就好比 linux 里面的 pipeline。 而当资源通过 loaders 组成的管道的时候,你就可以让 loader 来动态的修改加载的资源了。我来举个例子你就会发现我为什么说 webpack 让这一切这么自然, 比如说我们之前使用 gulp 来 minify css 文件,gulp 是来执行一个任务, 让加载相应的文件, 再把minify 之后的资源写入另外一个文件。但是对于 webpack 你只需要 require 这个css 文件,然后再给你原本加载 css 资源的管道再串接一个能 minify css 的 loader 就行了。webpack 这么一搞让许多前端的工具的处境很尴尬,比如说 grunt gulp ,除非你真的想执行什么特殊的任务,不然真心用不上它们了。 还有 browserify ,它跟 webpack 比就简直弱爆了。当然还有 bower。 对于 sass 和 less 这样的 css 预处理器来说, postcss 是可以在一定的程度上替代他们了,因为就像 postcss 的名字一样, 它是 css 后处理器。sass 和 less 能做的事,postcss 基本都能做,但 postcss 能做的事情, sass 和 less 却不能做。比如说给 css 自动添加 prefix , minify css 等等。

为什么说 webpack 和 vue.js 结合起来很爽呢? 因为 vue.js 本身它并没有一个给定好的架构让你去按着这个架构去写,这也是 vue.js 灵活的一个体现,你既可以在传统的 web 应用的某些地方使用它, 也可以用它来构建 SPA 应用。而 webpack 正是给了 vue.js 一个合适的架构来构建你的应用, 让你写起 vue.js 来更加舒服。虽然 vue.js 才用了几天,但 vue.js 有一种让我相见恨晚的感觉, 之前一直在用 ember.js, 虽然用的也不怎么好,我也来说一下 ember.js 和 vue.js 之间的一些差异。我最早开始接触 ember 是在去年,那时候 ember 还是 1.09 吧,当初为什么开始学习 ember 是因为当初社区里面的人说 ember 对 rails开发者来说更友好,而且向后兼容的更好,不会像 angular 那样,2.0 出来后把你打回原形。 对写 rails 的人来说是很友好,这一点不假,很多东西是和 rails 很像的, 包括 convention over configuration 这一点。 但向后兼容这一点就不能让人苟同了,之前还不觉得,1.10 ,1.11. 1.12 都没事,可是到了 1.13 ember 1.0 的最后一个版本,把我差点搞死,是这样的,1.13 几乎就是 2.0,只是 它还是会向后兼容,会有警告信息,如果你在 1.13 中运行应用没有警告信息的话,那么你就能完全无痛的升级 2.0. 但我升级到1.13 后, 一运行,一大推警告信息让我欲哭无泪。这就是你 ember 说的向后兼容更友好? 就给我一大堆 deprecated 信息让我自己慢慢弄? ember 1.0 到 2.0 不仅让 默认的 restful api 变成 json api , 而且也慢慢在弃用 view 和 controller ,朝 component 的方向发展。 最后我的自己写的那个 ember 项目不得不重写,我这还好,因为本来就觉得之前写的挺差的,正好就当重构呗。 但如果是一个大项目,估计头都大了。

ember 有一点做的很好,那就是它的路由,因为 ember 是以 URL 为中心的,这一点是很好的, 因为如果构建 SPA 应用的话,URL 是关键。 但是现在让我很头疼的却正是 ember 的路由,因为现在 ember 的 component 并不是 routable 的,这就意味着必须还是得有时候用 controller ,比如说当要用 params 的时候。 而 ember 官方是不推荐用 controller 的。这就很矛盾了,一方面 ember 官方让你尽量少用 controller ,推荐你用 component, 但是 ember 的 routable component 却迟迟不来, 这就让你写起 ember 来很是不爽。这还是 ember 自身的问题, 因为 ember 一开始并不是以 componet 为中心的,是以 URL 为中心的,而现在确硬要强推 component ,这就出现了问题,我很期待 ember 怎么解决 routable component 的问题,ember 又能否能拿出来一个优雅的方案呢? 反观 vue.js ,因为 vue.js 一开始就是以 component 为中心的,所以现在 vue.js 现在要加一个 router 就很自然,很轻松地就让 component routable 了。vue.js 就把这个问题解决的相当好, 你需要 router 那你就用 vue router 呗, 你不用 router 的话也没啥。 可 ember 就做不到这一点。我喜欢 vue.js 还有一个原因就是它更加简洁。当然也不能说一个框架就比另外一个框架好,场景不同就各有各的优势,ember 很大的优势在于它的生态,该有的都有了。ember data 和 ember cli 就是一个列子,用起来还是很爽的。而 vue 的优势在于它更加简洁,灵活和小巧,能适应的场景更多,也相对更加的简单易用。 这就好比是 rails 和 sinatra。

说了这么多,还是容易看出来,现在前端 component 绝对是趋势,因为 component 的好处太多了,能让资源得到极大的复用,也能写出更好的代码。而 router 绝对是一个用来做的 SPA 框架必须要有的。现在前端技术和工具日新月异,这是好事,而且我相信能够留下来的技术和工具,都是能让开发者更舒服开放的, 和让用户有更好的体验的。