grace和wepy都是辅助小程序开发的开源库，本文对两者做个对比。

注：本文是作者本人的一些拙见，纯粹的技术讨论，不想引起技术信仰之争，欢迎积极、正向的讨论及建议。

自小程序发布后，现在最著名的小程序开发框架就是wepy, 它借助一系列工具，通过预编译的手段实现了和Vue接近的开发风格，可以认为wepy更就是小程序的 vue（但还有一些不同，如布局模板），首先，必须承认wepy是一个好的框架，如果你是Vue开发者，如果要开发一些大的小程序项目，wepy应该是你的不二之选。但是我们换个角度，考虑下面两个问题：

小程序开发者来源

1. 来自前端开发者

   目前来看，如果是一名前端，那么很可能用过Angular/React/Vue中的一个，首先，如果你没有用过Vue, 那么要使用wepy的学习成本接近于学习Vue的成本，这是第一点，学习成本会大一些。其次对于对Angular/React有强烈信仰的开发者来说，他们可能会问一声，小程序就小程序，为什么非得弄成Vue. 在web开发时正宗的Vue都不用，会为了开发小程序再去学习一下wepy?

2. 非前端开发者

   在小程序发布后，想必大多数程序员都想尝尝，而并非只是前端程序员，对于这部分开发者来说，大都会采用小程序原生开发，他们基本不肯能再去学习一个像Vue同等规模的前端框架。

总结一下，站在开发者的角度，wepy 采用了类Vue的开发风格，即是优势，也是劣势。优势是可以让数量可观的Vue开发者轻松过渡，但缺点是提高了其它开发者的使用门槛。所以，一个轻巧易上手的帮助工具就很有必要，而grace就是这样的一个工具。

小程序定位

小程序的定位本身就是“触手可得，用完即走”， 解决想干个啥都得下个APP的历史现象。有了小程序后，不用装太多APP，只有在第一次用的时候花费少量流量下载即可。可以看到，小程序第一次使用时还是要下载，为了减少下载等待时间，节省用户流量，小程序对程序包的大小设置了上线4M, 这也为什么小程序中“小”的含义。 微信的这种限制决定了 小程序一般只是用于实现核心功能，不会用作复杂功能 。这也就决定了，在大多数小程序开发时，我们需要的并不是什么强拽炫酷吊炸天的大框架，而是一些简单的帮助工具，而grace的定位就是一个精巧的帮助工具。在笔者了解的很多小程序，甚至大都是用原生开发的。

下面总结一下主要区别：

1. 定位不同； grace的定位是一个精巧、易用的小程序开发辅助库 ，而wepy是一个功能全面的类vue框架.

2. grace使用简单易上手，wepy对不了解Vue的开发者有不小的学习成本，并且开发环境依赖多，配置比较复杂。

3. grace更贴近于原生，wepy更贴近于web.

   ​

下面我们看看Grace都有哪些功能：

Grace可以干什么

我们看看grace的特点：

1. 轻量、小巧、上手简单
2. 支持和Vue一样优雅的数据响应式
3. 支持数据自动更新、更改缓存、批量更新
4. 强大的网络功能
5. 支持全局事件总线
6. 支持跨页面传值
7. 支持mixins

主打是精巧，可以看到目前核心功能主要涉及三个方面：数据、网络、事件。

数据

小程序是数据与页面渲染分离的，所以在开发中会有大量的 setData 操作，grace为了简化这大量的显式数据更新，实现了和Vue一致的数据响应式-可以通过赋值直接更新数据。与此同时，为了避免频繁 setData 带来的性能消耗，grace不仅支持手动批量刷新而且grace可以自动跟踪页面前后台切换，如果页面切换到后台，则不会再去调用 setData ，而是将变动先缓存，等到页面切换到前台，才会统一刷新，有效避免不必要的性能消耗。

网络

大多数小程序都需会和后台通过http进行通信，为此，grace提供了强大、灵活、良好的Promise API，同时支持全局请求配置、请求/响应拦截器等。更重要的是，Promise风格的API可以支持ES7的async/await。

事件

小程序原生在跨页面通信方面比较弱，为此，grace提供了一个全局事件总线，你可以在任何页面通过注册/触发事件来进行通信。 不仅如此， grace还在事件总线的基础上，实现了更友好的页面数据回传的回调。

除了这些，grace还支持 mixins，提供了一种扩展新功能的方式，它可以在全局给页面添加一些功能，开发者可以自己发挥。

Grace今后的发展

笔者觉得小程序的量级一般都不会太大，为了避免过度设计，grace会一直保持精巧而易用的原则，不会添加太多使用频率比较小的功能。如果大家有什么好建议，或者希望grace添加什么新功能，都可以在github提issue.