大橙子网站建设,新征程启航
为企业提供网站建设、域名注册、服务器等服务
译者按:通过使用Angular的经历,作者已经完全转为Vue粉了!我们Fundebug目前还是用AngularJS 1,坦白说,学习曲线蛮陡的。
目前创新互联已为超过千家的企业提供了网站建设、域名、网页空间、网站托管、企业网站设计、临潼网站维护等服务,公司将坚持客户导向、应用为本的策略,正道将秉承"和谐、参与、激情"的文化,与客户和合作伙伴齐心协力一起成长,共同发展。
为了保证可读性,本文采用意译而非直译,并且对源代码进行了大量修改。另外,本文版权归原作者所有,翻译仅用于学习。
在Rever, 我们刚刚发布了使用Vue.js完全重写的网站。经过16周紧张的开发,总共commit了641次。现在回过头来,感慨当时对框架的选择是正确的。
在8个月之前,我们还在用Angular 2做网站开发。更加精确地一点,我们用的是Angular 2 beta 9。坦白的说,这个产品当时是由一家外包公司开发,而我们一直对它的方方面面都不满意。不管是UX/UI,还是架构上,甚至Angular 2本身。
在我继续抱怨之前,我要承认Angular 2 beta 9和Angular 2.0是完全不同的产品,但这也是Angular的一个问题所在。从beta 9到2.0.0,有8个beta版本, 8个RC(release candidate),以及2.0.0本身。也就是说,如果要更新到2.0.0,需要升级17个版本。我们也尝试过从beta 9升级到2.0.0,但是因为太多的依赖都破坏了,导致整个更新非常的复杂。同时,我们开始反问自己选择Angular 2是否正确,因为Angular开发团队已经着手Angular 4了。当我们好不容易完全更新到2.0.0的那一天,又需要考虑如何更新到Angular 4了。太浪费时间,太浪费精力了!
我们曾经不喜欢,现在依然不喜欢的就是Angular 2 默认使用Typescript作为开发语言。我知道Angular 2可以直接使用JavaScript,但是在Angular 2中使用JavaScript几乎等于重写整个项目。我不认为Typescript为开发增加了附加值,甚至更加糟糕了。我发现我们的编码速度反而变慢了。在JavaScript中很简单的事情,比如定义一个对象,如果使用Typescript就会变得复杂。在你决定使用Typescript之前,我强烈建议你读读下面这两篇文章。Typescript并不是每个人的最佳选择。
我依然记得使用Angular 1是多么的简单。虽然它也有不少问题,但是和其它框架比起来,真的容易。Angular 2却把Angular的优点丢弃了。对于Angular 2, 我的结论很简单:Angular 1 和 Angular 2就是雷锋和雷峰塔的关系。
所以,你想想我们需要在一个未经过测试的系统上更新17个版本,同时还要实现新的功能,现在的代码本身有着一大堆的bug,代码质量很差,毕竟当时的开发者几乎都不在团队里面了,只有我一个同时要应对很多问题。我为了正确使用Typescript,需要到处去找正确的文档。Angular 2已经开始升级Angular 4,然而我连Angular 2都还没升级成功。太多的负面因素快速累积起来。
因此,我们做出了决定:如果升级花费太多的时间,我们就应该考虑其它方案了。
React:第一个最明显的选择是使用React, 因为每个人都在使用它,如果没有,那么也在讨论它。而且,它有Facebook在后台撑腰,不担心维护问题。但是,React本身不是框架,如果要使用,你需要添加额外的东西。
我们将所有的指标列了出来:
接下来,我亲自使用React和Vue.js来给出一个评估,而不是通过Google告诉我答案。在此之前,我从来没有用过React和Vue.js。我们他们重写了如下部分:
仅仅使用了几天,我已经被Vue.js惊讶到,我已经可以完成一个演示Demo给CTO和团队其他成员。我已经很好的理解了Vue.js的基本概念,定义可扩展的架构。最重要的是我非常喜欢使用Vue.js的方式写代码,我可以感觉到明显比React快。
使用React比想象中难,要在Redux和MobX中做出选择并没有只有一个完美整合的方案好,就像Vue.js搭配的Vuex。如果对于一个框架没有使用经验的时候,可以让最开始的决策变得简单。如果你知道这个框架有官方的库,将会更有自信。同时,我觉得Vuex的反应比Redux快,不够也许只是个人感觉。
JSX也是一个问题,因为我们不能重用HTML,不够Vue.js在某种程度上支持我们这么做。 我不喜欢内联模板(inline template), 而React将JSX/HTML和JS混合到一起。我一直坚信将不同的功能部件分开才是正确的做法,混到一起看上去太丑了。
使用Vue.js的编码速度远远超过React,因为不需要学习JSX。而且,一个新的开发者加入团队之后,他只需要一个小时的培训就可以上手工作。这一点对我们非常重要。打开一个Vue文件,里面包含了使用HTML和Angular 1相似的标签。一个vue文件还包含样式和JavaScript部分。你只需要学习一点点Vue.js的基础知识就可以理解它们。
为了快速开发,好的文档也很重要。Vue.js的文档简直太赞!指导、示例、问题和API文档都非常清晰。在开发中遇到的问题几乎都可以通过文档找到答案。我们开始担心很多问题都是中文的,结果发现所有的资料都有英文版本。
经过一周的考虑,我认为Vue.js非常不错。可是周边的人都没有用过,无法给出中肯的建议。我得到的唯一一个意见就是“看上去很酷,不过我从来没用过”。React最受大家关注,Angular 2其次。我开始寻找本地是否有使用Vue.js的开发者,结果真的找到了,让我觉得不在孤单。而且我的技术圈子本来就很小,所以没有注意到谁在生产环境使用Vue.js。
在我们考虑选择Vue.js还是React的时候,同时有考虑到要重写我们的移动端。React Native看上去是一个不错的选择。如果我们真的决定用React Native做移动端,可以复用桌面端和移动端的代码,对决定选择React有很大的加分。不过,我最终决定不考虑这个情况也许不会发生的情况。从我的经验来看,使用Node.js已经让我可以在前端和后端重用非常多的代码。
在我写这篇博客的时候,网上有很多关于Facebook将React的版权许可改为BSD+Patent的讨论。根据Facebook的解释,这个版权许可防止他们被专利流氓(patent troll)。虽然这不是影响我们决定的一个主要因素,但是如果你使用React,而React有相关版权问题,你也不想听到。
换个角度,Facebook可以说是React的一个负担,而不是助力。这也是为什么一个独立的基金或组织来维护开源软件项目更好。IBM做了一个很好的示范,当他把Strongloop买下来以后,把Express.js捐给了Node.js基金会。来自社区的压力和IBM的期待,使得软件一直很好的维护下去。Twitter也是一个很好的例子,他们使用MIT协议发行Bootstrap,这样再也没有人会讨论Bootstrap的版权问题。
在我做出最终决定之前,我在网上调研了很久。有一张开发者对现有JavaScript状态的调查吸引了我的注意力。我承认,作者并没有用非常严谨的科学的方法去调研,但是却给我们提供了很多非常有用的信息。如果你想阅读原文,请点击The State Of JavaScript: Front-End Frameworks。
衡量指标 | Angular 2 | React | Vue.js |
---|---|---|---|
稳定 | 是 | 是 | 是 |
有强大的社区 | 是 | 是 | 还不够大 |
后盾 | Laravel和阿里巴巴 | ||
文档清晰 | 是 | 是 | 是 |
容易上手 | 一般,Typescript难学 | 还可以 | 是 |
可以集成Bootstrap | 是 | 是 | 是 |
大小 | 566K | 139K | 58.8K |
易复用 | 是 | 只有CSS | 是,HTML和CSS |
编码速度 | 慢 | 一般 | 快 |
反应速度(Reactivity) | 还可以 | 快 | 快 |
基于组件 | 是 | 是 | 是 |
总的来说,在我们的评估中,Vue.js胜出。在StackOverflow有很多问答,官方文档十分清晰,代码体积小,和Bootstrap完美集成,由Laravel和阿里巴巴支撑。虽然社区还不够大,但是已经足够大了。
选择Vue.js是一个正确的选择,虽然我花了不少时间来说服CTO。我很感激他总是提出一些有用的难问题,使我可以保证我的决定是100%正确。如果我的决定真的做错了,将会非常后悔的。我想直到他亲手写了一个组件发现相当的容易才真的完全确信Vue.js的能力的。
我没有说React不好,它拥有那么大的一个社区,我感到非常震撼。它有它的好处,jQuery的社区更大,但没有使它成为一个我们想要使用的好的框架/库。我们想要简单,而Vue.js拥有这一点。如果你还是不确定,可以读一读下面这篇文章:Comparison with Other Frameworks。
Fundebug专注于JavaScript、微信小程序、微信小游戏、支付宝小程序、React Native、Node.js和Java实时BUG监控。 自从2016年双十一正式上线,Fundebug累计处理了9亿+错误事件,得到了Google、360、金山软件、百姓网等众多知名用户的认可。欢迎免费试用!
转载时请注明作者Fundebug以及本文地址:
https://blog.fundebug.com/2017/09/20/why-we-moved-from-angular2-to-vue/