只接受发布货源信息,不可发布违法信息,一旦发现永久封号,欢迎向我们举报!
1064879863
16货源网 > 餐饮行业新闻资讯 > 微信小程序开发 >  如何评价 wepy 这款小程序开发框架?


如何评价 wepy 这款小程序开发框架?

发布时间:2019-09-06 14:50:11  来源:网友自行发布(如侵权请联系本站立刻删除)  浏览:   【】【】【
这个框架明显没有经过复杂项目的测试,自带N多无语bug,稍微复杂一点的正常用法就会出现bug,以至于实际项目中使用时多数时间在为它改bug提PR,它是重写vue而不是适配vue,是重新发明了个轮子,并
如何评价 wepy 这款小程序开发框架?这个框架明显没有经过复杂项目的测试,自带N多无语bug,稍微复杂一点的正常用法就会出现bug,以至于实际项目中使用时多数时间在为它改bug提PR,它是重写vue而不是适配vue,是重新发明了个轮子,并不是明智的做法,所以vue生态里的好东西都没法拿来直接用...第一次在框架级别用BAT系的东西,早前听说阿里的不靠谱,实际怎么样没用过不评价,可以确定的是腾讯系的也太...不靠谱了吧。

号称拥抱开源的腾讯贡献的啥,我觉得完全是找人免费给它开发除错的

另外感觉这个项目腾讯没投入几个人的资源在维护,更新响应都很慢...,以后会慎重决定是否使用BAT框架级别的东西

用过vue,angular1,2,react,一句话,这是我用过的最让我郁闷的框架,没有之一。

另外小程序原生也是各种bug,在此离题了不吐槽

血坑,wepy基本组件都有bug,比如repeat组件,issue里多达好几页的控诉,半年多了,没有人理,不得不采用各种hack方式实现功能,以至于写到一半,在想要不要重写。

腾讯的js生态,基本都是拿几年前的解决方案硬怼,连业界流行的轮子能用好的都不多,更别说输出技术产品了

之前总听说不用BAT的框架,因为老是弃坑,就为了KPI。


可是阿里最近几年的开源项目,优秀如antd,egg,antv 等,都是用在自家产品上的,不是KPI产品,而且质量好,诚意满满。


反观腾讯开源的东西,前段时间被吐槽的那啥,日志监控的那个,还有这个wepy,还有自家的微信小程序,只能说是满满的槽点。不使用现有的成熟技术,而要自创垃圾武功。


正是应对了那句话,不是因为不想开源,而是因为代码写的太烂才不敢开源。

py后缀然后是js写的?

在腾讯和阿里都呆过一段时间,说说我的感受吧。仅为我个人的主观看法!

BAT这三家公司,个人认为在前端领域排名:A>B>>T。

A和B都有不少比较优秀的开源产品,A有antd、egg、weex等,B有echarts,而T有什么?小程序?这个wepy?还是之前被吐槽得体无完肤的TSW?恕我直言,这几个东西真心拿不出手啊。

有人肯定会反驳我:”小程序那么大的用户体量,你瞎了吗“。

好吧,难道小程序不是因为微信的超大用户量,所以才有那么多开发者?那些小程序开发的坑,就不用我多说了吧,谁用谁知道。不过不得不说的是,微信是腾讯为数不多的、重视技术的事业群,但是投入的人力还是太少了,比如小程序吧,我印象中维护小程序的是一个t3的哥们和一个刚毕业没多久的小伙。反观阿里,antd、egg、weex都是有专门的团队维护的,而且响应速度还是很快的。

回到正题,之前用过wepy。相对于原始的小程序api,这个框架还是提高了开发效率的(这里要给开发wepy的帅哥点赞,据说这个框架也是他自主研发的)。不过,在使用过程中,依然好多坑,而且虽然号称代码风格类似于vue,实际上还是相差甚远,这点我好想吐槽。

腻了腻了。

一直在使用知乎,但几乎很少出来回答问题,竟然被at了,作为 WePY 作者,我还是出来说几句吧。


  1. 开源的背景

它不是一个KPI开源项目,也不是一个为了开源而开源的项目,应该算是一个自外而内的开源项目。我本身是在一个业务团队,本职工作是要保证业务99.999%的可用性,与开源没有任何关系。而开源纯属个人爱好。这个项目一开始只是自己在摸索着去解决小程序开发过程当中的一些问题。16年11月份在内部开源后并没有受到太多关注,于是放在 Github 个人账号开源,其间还因为某些原因还面临被下架风险。Github开源后外界关注度越来越高之后,内部才开始被重新关注,然后少数内部团队才开始投入使用,也就是我说的自外而内的开源。大概是在17年初腾讯开源的同事同我,以及当时我在的团队沟通想将项目回迁至 Tencent 域下。大概17年年底才走完流程正式迁入Tencent域下、至此才完成了所谓的“转正”。发展到现在,微信讨论群组里WePY的开发者大概有5000多人,现在 google 随意一搜就能看到很多的很多很多的资源,或者直接看这里:

aben1188/awesome-wepy

因此,如果说这个项目真的是没有什么价值,那应该也不太对吧。


2. 开源的目地

WePY 的对外开源的目地并不是要去分享一个很成功的解决方案,而是我认为这套方案能够解决在小程序开发中遇到的一些实际问题,并且希望能借助外界的力量去帮助一起完善这套方案,因此在功能并非十分完善的情况下就开源了。在众多开发者帮我踩坑的过程当中去迭代,因此从最开始一天一个npm版本到后来一个星期、一个月一个 npm 版本。这些不就是我理解的开源应该做的事情么?我提供方案为开发者提供便利,开发者在使用时帮助一起把方案做得更完美。事实上,从我在微信群里收集的评价来看,这个项目的确是帮助了部分开发者:


3. 代码质量问题

这个问题我从来没有逃避,不只一次我在对外的分享里提到过 WePY 存在很多问题,我也多次私下跟朋友吐槽这个项目写得太差太草率,项目应该是10月份开始的,大概就花了4个周末的时间,勉强算8天,然后就上Github了。项目有单元测试但是只覆盖到核心库部分,编译那一部分是完全没有测试的,后面没有继续把这里补齐就是因为代码写得几乎不可被测试,改造的成本无疑于重构代码。因此这里的质量可想而知,所以我也经常说当前的star数与项目本身的质量严重不对等。项目最初的想法就是解决小程序npm资源引用,以及组件化开发的问题。在早期确实能提供不错的开发效率。大概在17年11月份,官方自己推出了组件化方案,那这个时候 WePY 带来的效率提升反而没那么明显了,反到是 bug 都给暴露出来了。一直以来我都想重构代码,但到这个时候才意识到重构迫在眉睫。这也是为什么我要做2.x的版本。


4. 项目维护问题

目前来说,在腾讯内部,整个项目还是在由我一个人在维护,目前总的Issues数约1200,PR数接近200。除了少数 Contributors 会帮忙回复一下之外,大部分都是由我自己处理,私下发zip包给我,我帮忙定位的bug的也不在少数。前段时间因为一些个人原因没有办法即使关注到项目,导致项目的未处理的Issue涨到了400多,几乎不太可能逐条处理,因此最近才引入 Issue Bots 自动关闭 Inactive 的 Issues。然后对新的 Issue 再逐条处理。这一部分也是我一直在思考和摸索的,如何能去提高 Issue 和 PR 质量,如何协调维护的时间成本。总而言之,这个项目我是一直投入精力在关注,维护的。维护成本比我想象的大太多了。


5. 腾讯开源

从我个人的角度来看腾讯在开源上的成绩的确是离其它国内大厂还是有不小的差距。但是难道大家不应该更去关心一下腾讯在开源上的成长吗?曾经那么封闭的微软,现在在开源上做出的成绩不一样是有目共睹的呢?为什么一定要去拿过去做的不好去否定它未来的可能呢?腾讯现在正在关注开源,也想为开源做一些事情,比如在还未结束的LC3中,已宣布腾讯正式成为Linux 基金会白金会员。而在腾讯内部也慢慢有越来越多的人想要加入开源。那么为什么外界一定要带着嘲讽的态度去打击腾讯开源呢?让那些有开源想法的人打消念头?腾讯开源更多的是需要鼓励和支持。


最后:腾讯开源环境其实也是代表了国内的开源现状,到底能有多少能媲美国外的优秀开源项目呢?还是少一些浮躁,多做些有意义的事情吧。有想法多去提一些比较有建设性的意见,多提些有意义的 Issue 和 PR。

从产品角度而言,小程序是一款非常成功、迎接微信生态、开发便捷的软件。应用场景就目前而言实在是丰富得多姿多彩,一年多两年实践到达这个程度确实很厉害。


从程序员角度而言,这玩意,就是垃圾中野鸡战斗机,作为一名程序员甚至没感受到来自微信小程序团队为「开发者」着想的念头,反而每次推送小程序更新内容都是「与产品相关的改动」,我不说全部吧,但是大部分的都是。所以说,这个产品是谁来写代码的?


小程序大部分的更新都只是为了产品经理,而不是考虑程序员的生活水平。说是便捷开发,但是我起手写的第一刻起,就想着如何造 DSL。事实证明是对的,原生越写越痛苦。


WePY 这个框架的出现,算是符合了我的第一想法:DSL,也正是这个框架,才给后面的各种乱七八糟小程序框架打开了一个大门。个人觉得无可厚非,你们真的那么苛刻,其实可以看看 Vux 作者的开源简介(这是我唯一一个点赞的 Vue 项目,vue 本身我都没点赞。。),开源的今天,大家似乎忘记了,很多开源项目是公益项目

我觉得奇葩的是,明明都是腾讯,小程序没有用这些语法,而是单独再做一个框架出来。

小程序本来就是个根基不稳的框架了,我这边很多同事都不信任这些在烂的框架上搭的框架。

我年纪真的大了,看不懂框架,我还是用API就可以了,实在没办法又看API又搞框架

本身TX自己整的这一套小程序环境就已经不敢恭维了,完全不顾开发者体验新建一堆DSL,wepy不论是从代码质量还是维护力度上来看,都远没有匹配它目前的star数,然后更揪心的是它处于小程序的上层,这就不是简单的1+1=2个坑的问题了,有可能变成一个天坑


所以我认为从小程序提供原生组件化的特性以来,wepy的存在意义就在不断变小,如果是有一定复杂度或者中型大型的项目,不建议再使用此开发框架,工程方面可以考虑自己定制一套构建流程


但一方面来说,我尊重每一个开源项目和它的作者,毕竟是公益性质,不能苛求别人做到何种程序,希望wepy越来越好

已经转mpvue了,wepy实在是有点难上手,或者应该说是IDE的支持不够好,相比之下,mpvue就可以无脑撸了,跟平时开发没有区别

不支持typescript我很焦灼

当时刚看到作者在微信群里分享wepy的时候感觉很惊艳,但是它里面的组件系统实在不敢恭维,一到3级,有循环就绑定不了数据,还有组件里引用静态资源的问题也很让人头疼,且有限的插件系统感觉开发起来非常难受,准备下一个项目转mpvue

1. 感谢作者的分享。
2. 问题挺多的,尤其是组件方面,不建议使用。

wepy 有点不伦不类(很久没做小程序了,只针对发布的第一版),在当时没有其他框架的情况下还算可以,怎么说也比原生舒服,但是在有 mpvue 的情况下考虑他?只能说是信仰。除非大改乃至于重构,否则这个项目已经没有价值了,现在的设计以及代码质量完全对不起那么多的星,不知道是急于上线抢市场还是什么目的,一开始设计的就太草率,完全不像是这个年代的东西。

不过 wepy 在刚出来的那个时间还算是可以吧,也确实带动了其他小程序框架,从这点来说,wepy 对于小程序开发生态发展的推动无疑是值得肯定的。

最后就很想吐槽微信,既然都山寨了语法,为什么不山寨的彻底点?都 2016 年发布的东西了,还不支持 npm 和组件化?如果微信官方在工程化方面做的好一点,或者干脆就彻头彻尾的山寨一个 Vue,哪还来的这么多事。广州就不是一个适合做技术的地方,日子太舒服了

本人用了2天就改原生了,但不是框架不好,而是不适应这种开发方式,果断转了原生。

原因:在wepy中异步this.data=data需要放在$apply(func)里面或写在后面加持,当然不止这里 。就因为这一点果断转原生语法了,因为虽然每次都要this.setData,只能单向,但是起码语法统一,而且在语法层面上不用顾及其他框架束缚,这点mpvue比较牛逼。但值得一提redux是个好东西。

最后为wepy作者点赞,框架思路是不错,名字也改的不错"我们的py"

一直在使用知乎,但几乎很少出来回答问题 但作为使用者 还是得说一句 这框架是真的垃圾

腾讯这么nb的公司,依然写出了小程序、小程序文档、小程序开发者工具、wepy、weui

忍不了了,作为开发者一点都不安心,感觉有很多坑在等着我。这不,又有一个了- -

责任编辑:
热门阅读排行
© 16货源网 1064879863