「前端架构」React和Vue -CTO的选择正确框架的指南


「前端架构」React和Vue -CTO的选择正确框架的指南文章插图
快速总结:为项目选择正确的Javascript框架或库是CTO和项目经理的基本任务 。 然而 , 选择的范围很大程度上取决于几个因素 , 如项目时间、学习曲线、框架性能和团队规模 。 这篇文章旨在指导他们选择正确的javascript框架(或库):React vs Vue 。
React vs Vue -选择正确框架的CTOs指南
这是一个值得你考虑的案例!
Rever Inc. , 一家硅谷公司 , 在构建他们的最后一个MVP之前 , 将将近10,000行Angular.js代码移植到了Vuejs上 。
好吧 , 他们需要使用的Angular版本的发布被延迟了 , 这是不可预见的 , 他们等不起 , 因为这会浪费时间和资源 。
直接引用Luis Elizondo (Rever的工程总监)的话——
在为我们评估正确的选择框架之前 , 我必须亲自动手 , 所以我给了React和Vue.js几天时间来回顾每个不可能被谷歌回答的决策点 。 由于我对它们一无所知 , 在两天结束时 , 我将重新评估我在重写我们将要迁移的实际项目的某些部分时走了多远 。
在评估了两个框架之后 , Luis和他的团队决定使用Vue , 因为他们发现Vue比React更容易使用 。
现在想象你自己处于一个类似的情况 , 你的1000个小时的努力都是徒劳的 , 这不是你自己的错 。
考虑到项目的截止日期很紧 , 太多的产品经理和CTO落入了一个常见的陷阱——他们选择了一个让他们轻松开始的框架 , 而没有考虑框架随时间的影响 。 然而 , 他们很快就意识到最好事先评估用例并选择合适的框架 , 以避免任何类型的问题 。
在这篇博客文章中 , 我将比较React和Vue的几个因素 , 这些因素将帮助我们评估需要的正确技术 。
在进行深入的比较之前 , 你可以先问自己一些问题 , 这样你就可以对这个问题有一个全面的了解 。 这些问题只是帮助你评估React和Vue之间正确框架的因素 。
React vs Vue: CTO和项目经理的比较因素

  • 代码有多干净和直观?
  • 框架支持模块化吗?
  • 开始使用这个框架有多容易?它是否支持JS导入?
  • 框架的测试和调试方面有多好?
  • 我的队友和我能够轻松地学习这个工具吗?
  • 框架在性能方面是如何脱颖而出的?
  • 从项目开始算起 , 在5-10年以上的时间里 , 这些代码会给我带来更多的麻烦吗?或者在那些年里 , 我将被一个几乎无法维护的遗留应用程序所束缚?
  • 框架支持服务器端呈现吗?
  • 框架适合轻量级还是重量级应用程序?
  • 这些框架的顶级实用程序是什么?什么时候使用它们是正确的选择?
现在你有了问题 , 让我们通过将这些因素与React和Vue并置来深入研究问题的实质 , 了解它们的区别 。
React和Vue的代码质量比较代码有多干净和直观?首先:能够让您快速浏览大型项目代码的框架应该是理想的选择 。
显然 , 对于许多CTO和项目经理来说 , 一切都归结为“代码通过测试的速度有多快 , 以及这些测试如何处理类型” 。
请注意 , 要提高代码质量 , 还有很多事情需要考虑 。 例如 , 单元测试、linting和类型检查是我的团队和我在Simform积极执行的事情 。
我不会在这里拐弯抹角地提到所有这些实践 。 因为我相信类型检查确实能提高代码质量 , 所以让我们比较一下Reactjs和Vuejs , 看看它们是否支持任何方式的类型检查 。
React的静态类型检查React确实利用了JavaScript ES6基础作为代码语法 , 但是它是否支持编译时的类型检查之类的功能呢?
嗯 , 是的!
你可以用Flow来做静态检查 , 它是Facebook开发人员开发的TypeScript的替代品 。 它允许您向代码中添加类型 , 然后在构建(编译)时删除它们 , 以保留正常的Javascript代码 。
[注:如果你喜欢TypeScript , 但仍然想使用React , 那么你最好去 , 因为TypeScript对JSX有很好的支持 , 这可能就是微软在最新版本的office中使用它的原因]
Vue中的静态类型检查Vue还利用Javascript ES6语法来编写代码 。 然而 , 当涉及到静态类型检查时 , 在Vue中使用Typescript就不是那么简单了 。 有一些课程是关于如何将Typescript和Vue一起使用的 , 但是在复杂的项目中是否值得考虑仍然不清楚 。
幸运的是 , 您可以将flow与Vue集成并启用静态类型检查 。
React和Vue的模块化框架支持模块化吗?
根据模块化原则 , 您的应用程序必须划分为独立的模块 , 每个模块代表单一的目的或功能 。 这一原则也被称为单一责任原则 。
“做一件事并把它做好”——Unix哲学
让我们用一个简单的现实生活用例来理解模块化: