vqudominiapp 2019-06-26
grace和wepy都是辅助小程序开发的开源库,本文对两者做个对比。
注:本文是作者本人的一些拙见,纯粹的技术讨论,不想引起技术信仰之争,欢迎积极、正向的讨论及建议。如果你还不了解Grace, 请参考:微信小程序开发神器-Grace
Github: https://github.com/wendux/grace
自小程序发布后,现在最著名的小程序开发框架就是wepy, 它借助一系列工具,通过预编译的手段实现了和Vue接近的开发风格,可以认为wepy更就是小程序的 vue(但还有一些不同,如布局模板),首先,必须承认wepy是一个好的框架,如果你是Vue开发者,如果要开发一些大的小程序项目,wepy应该是你的不二之选。但是我们换个角度,考虑下面两个问题:
目前来看,如果是一名前端,那么很可能用过Angular/React/Vue中的一个,首先,如果你没有用过Vue, 那么要使用wepy的学习成本接近于学习Vue的成本,这是第一点,学习成本会大一些。其次对于对Angular/React有强烈信仰的开发者来说,他们可能会问一声,小程序就小程序,为什么非得弄成Vue. 在web开发时正宗的Vue都不用,会为了开发小程序再去学习一下wepy?
在小程序发布后,想必大多数程序员都想尝尝,而并非只是前端程序员,对于这部分开发者来说,大都会采用小程序原生开发,他们基本不肯能再去学习一个像Vue同等规模的前端框架。
总结一下,站在开发者的角度,wepy 采用了类Vue的开发风格,即是优势,也是劣势。优势是可以让数量可观的Vue开发者轻松过渡,但缺点是提高了其它开发者的使用门槛。所以,一个轻巧易上手的帮助工具就很有必要,而grace就是这样的一个工具。
小程序的定位本身就是“触手可得,用完即走”, 解决想干个啥都得下个APP的历史现象。有了小程序后,不用装太多APP,只有在第一次用的时候花费少量流量下载即可。可以看到,小程序第一次使用时还是要下载,为了减少下载等待时间,节省用户流量,小程序对程序包的大小设置了上线4M, 这也为什么小程序中“小”的含义。 微信的这种限制决定了小程序一般只是用于实现核心功能,不会用作复杂功能。这也就决定了,在大多数小程序开发时,我们需要的并不是什么强拽炫酷吊炸天的大框架,而是一些简单的帮助工具,而grace的定位就是一个精巧的帮助工具。在笔者了解的很多小程序,甚至大都是用原生开发的。
下面总结一下主要区别:
下面我们看看Grace都有哪些功能:
我们看看grace的特点:
主打是精巧,可以看到目前核心功能主要涉及三个方面:数据、网络、事件。
小程序是数据与页面渲染分离的,所以在开发中会有大量的setData
操作,grace为了简化这大量的显式数据更新,实现了和Vue一致的数据响应式-可以通过赋值直接更新数据。与此同时,为了避免频繁setData
带来的性能消耗,grace不仅支持手动批量刷新而且grace可以自动跟踪页面前后台切换,如果页面切换到后台,则不会再去调用setData
,而是将变动先缓存,等到页面切换到前台,才会统一刷新,有效避免不必要的性能消耗。
大多数小程序都需会和后台通过http进行通信,为此,grace提供了强大、灵活、良好的Promise API,同时支持全局请求配置、请求/响应拦截器等。更重要的是,Promise风格的API可以支持ES7的async/await。
小程序原生在跨页面通信方面比较弱,为此,grace提供了一个全局事件总线,你可以在任何页面通过注册/触发事件来进行通信。 不仅如此, grace还在事件总线的基础上,实现了更友好的页面数据回传的回调。
除了这些,grace还支持 mixins,提供了一种扩展新功能的方式,它可以在全局给页面添加一些功能,开发者可以自己发挥。
笔者觉得小程序的量级一般都不会太大,为了避免过度设计,grace会一直保持精巧而易用的原则,不会添加太多使用频率比较小的功能。如果大家有什么好建议,或者希望grace添加什么新功能,都可以在github提issue.
最后,贴出Github地址,如果觉得对你有用,欢迎star, 如果有什么建议,欢迎issue。
Grace项目地址:https://github.com/wendux/grace