我由Angular转向React,为啥

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了我由Angular转向React,为啥相关的知识,希望对你有一定的参考价值。

React速度很快
  与其它框架相比,React采取了一种特立独行的操作DOM的方式。
  它并不直接对DOM进行操作。
  它引入了一个叫做虚拟DOM的概念,安插在javascript逻辑和实际的DOM之间。
  这一概念提高了Web性能。在UI渲染过程中,React通过在虚拟DOM中的微操作来实对现实际DOM的局部更新。
跨浏览器兼容
  虚拟DOM帮助我们解决了跨浏览器问题,它为我们提供了标准化的API,甚至在IE8中都是没问题的。
  模块化
  为程序编写独立的模块化UI组件,这样当某个或某些组件出现问题是,可以方便地进行隔离。
  每个组件都可以进行独立的开发和测试,并且它们可以引入其它组件。这等同于提高了代码的可维护性。
  单向数据流让事情一目了然
  Flux是一个用于在JavaScript应用中创建单向数据层的架构,它随着React视图库的开发而被Facebook概念化。它只是一个概念,而非特定工具的实现。它可以被其它框架吸纳。例如,Alex Rattray有一个很好的Flux实例,在React中使用了Backbone的集合和模型。
  纯粹的JavaScript
  现代Web应用程序与传统的Web应用有着不同的工作方式。
  例如,视图层的更新需要通过用户交互而不需要请求服务器。因此视图和控制器非常依赖彼此。
  许多框架使用Handlebars或Mustache等模板引擎来处理视图层。但React相信视图和控制器应该相互依存在一起而不是使用第三方模板引擎,而且,最重要的是,它是纯粹的JavaScript程序。
  同构的JavaScript
  单页面JS应用程序的最大缺陷在于对搜索引擎的索引有很大限制。React对此有了解决方案。
  React可以在服务器上预渲染应用再发送到客户端。它可以从预渲染的静态内容中恢复一样的记录到动态应用程序中。
  因为搜索引擎的爬虫程序依赖的是服务端响应而不是JavaScript的执行,预渲染你的应用有助于搜索引擎优化。
  React与其它框架/库兼容性好
  比如使用RequireJS来加载和打包,而Browserify和Webpack适用于构建大型应用。它们使得那些艰难的任务不再让人望而生畏。
  不幸的是,目前的JavaScript版本并没有提供一个打包和加载的模块。(在未来的ES6版本上将使用System.import来解决这个问题)。
  幸运的是,我们有RequireJS和Webpack这些漂亮整洁的替代品。React是由Browserify构建的,如果你想操作图像资源或者编译Less和CoffeeScript,Webpack或许是一个更好的选择。
  需要另一个开发框架来配合React吗?
  可以使用React来构建用户界面,但是你仍然需要进行AJAX调用,应用数据过滤以及其它Angular已经实现的功能。
  如果还需要另一个额外的JavaScript开发框架,为什么不使用Angular?
  框架由一系列模块和规则组成。如果我们不需要它的一些模块,甚至想将某些模块替换,该怎么做?
  其中一种实现模块化且能更好地进行依赖管理的方法是通过包管理器。
  但是,在Angular中怎么进行包管理呢?这还得取决于你,但是得记住,Angular是自成一体的。你很可能需要让第三方包去适配Angular。
另一方面,React仅仅只是JavaScript而已。任何用JavaScript写的的包都不需要用React去封装。
  使用npm和Bower这样的包管理器更好。我们可以选择自己的组件和工具集。需要明确的是:这比使用像Angular这样的综合性开发框架更复杂。
  就这方面而言,React的好处是鼓励使用npm,npm已经拥有了很多现成的包。你可以从完整的初学者工具包中选择一个开始构建React应用的包。
  转向使用React也不是一帆风顺的!
  由于Angular是一个应用开发框架,它带来了很多便利。我放弃了一些好的功能比如:封装好的AJAX用于$http服务,$q用于应答服务,ng-show,ng-hide,ng-class和ng-if作为模板的控制语句——所有这一切都让人惊奇。
R  eact不是一个应用开发框架,所以你需要考虑如何处理构建一个应用程序的其它方面。例如,我正在参与一个叫做react-utils的开源项目,它可以帮助React进行更简单便捷的开发。
  就目前而言,社区也在积极的贡献一些类似的组件来填补这一方面的空白。React Components就是这样一个非官方的网站,你可以在这儿找到类似的开源组件。
React的信条不鼓励使用双向绑定,这也给处理表单数据和编辑表格数据带来了很多痛苦。
  无论如何,当你开始理解Flux数据流和存储,事情就变得简单、清晰和简单。
  React是新生的。这需要一些时间让它周边社区发展。在另一方面,Angular已经非常流行了,且有大量的可用扩展(例如 AngularUI和Restangular)。
  虽然React的社区刚起步,但是发展得非常迅速。像React Bootstrap这样的扩展就是一个很好的证明。早晚会拥有更多更丰富的组件,这只是一个时间问题。
  总结
  如果喜欢Angular的方式,在一开始你可能会不喜欢React。主要是因为它是单向数据流且缺乏开发应用程序的一些功能。最终很多事情还是需要自己来考虑。
  然而当开始习惯了Flux的开发模式和React的设计理念,我相信你会看到它的美。
  Facebook和Instagram都在使用React(因为他们在领导这个项目)。
  GitHub最新的源码编辑器Atom就是用React构建的。
  雅虎邮箱也正在使用React重构。
  React已经被大量的应用程序和科技公司所关注。
参考技术A 基于DOM的程序执行。在Angular的执行过程中过于依赖DOM操作。在Angular应用的执行时,会首先扫描所有的DOM,再通过指令进行编译,这让不利于开发者进行调试也很难判断程序执行顺序。
双向数据绑定是一把双刃剑。随着组件增加,项目越来越复杂,双向数据绑定带来性能问题。
双向数据绑定是如何影响性能的?在JavaScript(ES5)中,并没有实现当变量或对象改变时发出通知的功能,Angular的实现方法被叫做“Dirty-checking(脏检查机制)”,通过跟踪数据的改变再动态更新用户界面(UI)。
在Angular的作用域中任何操作的执行都会引发Dirty-checking,随着绑定数量的增加性能就会越低。
双向数据绑定的另一个问题是,如果页面上有许多拥有动态数据的组件,这意味着也会有很多的数据来源,如果管理不好会让人感觉混乱不堪。但公平地说,这是开发人员的方式方法问题而不是Angular本身的缺陷。
Angular自成一体。Angular的任何操作会引起digest cycle对注册过的监听器的遍历,以实现组件动态地同步数据。这会和其它的依赖产生兼容性问题。
如果你使用的其它JavaScript库也需要改变数据就必须用Angular的$apply函数去封装。
或者如果它是一个工具库,你就需要把它转换成一个服务。似乎其它JavaScript库都必须经过改动才能和Angular进行交互操作。
依赖注入。JavaScript目前没有自己的包管理器和依赖解析器,AMD、UMD和CommonJs很好的解决了这个问题。不幸的是Angular并没有很好地利用这些规范,Angular甚至实现了一个自己的依赖注入(DI)。但是公平地说Angular使用RequireJS依赖项注入的非官方实现已经有了。

我由Angular转向React,为什么?

【编者按】Kumar Sanket为Toptal公司的全栈Web开发者/工程师,他在一篇文章《Why I Ditched Angular for React》中对Angular和React进行了对比,他表示Angular在快速开发大型Web项目上很受推崇,但其也存在的种种缺陷,如过于依赖DOM操作,双向数据绑定带来性能问题等。而React作为由Facebook和Instagramin领导的新开源项目,为JavaScript应用开发者提供了新的开发方式,同时具有速度快、跨浏览器兼容、模块化等优点,也是这些优点,让Kumar Sanket选择了React。下面为该文章的译文。


几年前,我的代码因充满了jQuery选择器和回调函数而十分凌乱,后来AngularJS的出现很好地解决了这个问题。


使用AngularJS开发的项目拥有极好的可维护性,AngularJS拥有一系列简单易用的功能,有利于快速开发大型的Web项目。


初识时,AngularJs的双向数据绑定和所有的数据源都放在Model中的设计理念让我惊叹,在实际的开发中,有效地减少了应用程序中的数据冗余。


随着应用频率越来越多, AngularJs的一些缺陷也渐渐体现,在使用过程中的不如意让我决定寻找一个它的替代品。


以下就是我对Angular的一些不满。


基于DOM的程序执行。在Angular的执行过程中过于依赖DOM操作。在Angular应用的执行时,会首先扫描所有的DOM,再通过指令进行编译,这让不利于开发者进行调试也很难判断程序执行顺序。


双向数据绑定是一把双刃剑。随着组件增加,项目越来越复杂,双向数据绑定带来性能问题。


双向数据绑定是如何影响性能的?在JavaScript(ES5)中,并没有实现当变量或对象改变时发出通知的功能,Angular的实现方法被叫做“Dirty-checking(脏检查机制)”,通过跟踪数据的改变再动态更新用户界面(UI)。


在Angular的作用域中任何操作的执行都会引发Dirty-checking,随着绑定数量的增加性能就会越低。


双向数据绑定的另一个问题是,如果页面上有许多拥有动态数据的组件,这意味着也会有很多的数据来源,如果管理不好会让人感觉混乱不堪。但公平地说,这是开发人员的方式方法问题而不是Angular本身的缺陷。


Angular自成一体。Angular的任何操作会引起digest cycle对注册过的监听器的遍历,以实现组件动态地同步数据。这会和其它的依赖产生兼容性问题。


如果你使用的其它JavaScript库也需要改变数据就必须用Angular的$apply函数去封装。


或者如果它是一个工具库,你就需要把它转换成一个服务。似乎其它JavaScript库都必须经过改动才能和Angular进行交互操作。


依赖注入。JavaScript目前没有自己的包管理器和依赖解析器,AMD、UMD和CommonJs很好的解决了这个问题。不幸的是Angular并没有很好地利用这些规范,Angular甚至实现了一个自己的依赖注入(DI)。但是公平地说Angular使用RequireJS依赖项注入的非官方实现已经有了。


学习进阶难。使用Angular需要学习大量的概念,包括但不限于:


  • 模块

  • 控制器

  • 指令

  • 作用域

  • 模板

  • 链式函数

  • 过滤器

  • 依赖注入

用好Angular是非常难的,不是一朝一夕的事情。


以上的原因导致我改用React。


React又哪里牛了?


React是一个由Facebook和Instagramin领导的新开源项目,用于构建用户界面,为JavaScript应用开发者提供了新的开发方式。


事先声明:React并不是AngularJs那样的一个应用程序开发框架。把他们作为同一个类型来比较是不公平的。


2013年五月,当JSConf EU大会上被推出时,它“单向数据流”和“虚拟DOM”等概念把观众震撼了。


React是用于构建用户界面的。引用官方主页上的说法:“对开发者来说,React就是MVC中的V”。你可以自由地写独立的组件,在这一点上或多或少优于Angular的指令集。


React省思了目前Web开发中遇到的一些问题并作出了最佳的实践。


比如,它鼓励的单向数据流,并坚信组件是被数据驱动的状态机。


然而大部分其它类似的框架都是直接操作DOM,React并不喜欢这种方式且尽量避免这种方式。


React恰如其分地提供了定义一个UI组件所需的最基本的API。它遵循UNIX的信条:做一件事,做到极致。


为什么我开始使用React?


以下是我喜欢React的一些地方。


React速度很快


与其它框架相比,React采取了一种特立独行的操作DOM的方式。


它并不直接对DOM进行操作。


它引入了一个叫做虚拟DOM的概念,安插在JavaScript逻辑和实际的DOM之间。


这一概念提高了Web性能。在UI渲染过程中,React通过在虚拟DOM中的微操作来实对现实际DOM的局部更新。


跨浏览器兼容


虚拟DOM帮助我们解决了跨浏览器问题,它为我们提供了标准化的API,甚至在IE8中都是没问题的。


模块化


为你程序编写独立的模块化UI组件,这样当某个或某些组件出现问题是,可以方便地进行隔离。


每个组件都可以进行独立的开发和测试,并且它们可以引入其它组件。这等同于提高了代码的可维护性。


单向数据流让事情一目了然


Flux是一个用于在JavaScript应用中创建单向数据层的架构,它随着React视图库的开发而被Facebook概念化。它只是一个概念,而非特定工具的实现。它可以被其它框架吸纳。例如,Alex Rattray有一个很好的Flux实例,在React中使用了Backbone的集合和模型。


纯粹的JavaScript


现代Web应用程序与传统的Web应用有着不同的工作方式。


例如,视图层的更新需要通过用户交互而不需要请求服务器。因此视图和控制器非常依赖彼此。


许多框架使用Handlebars或Mustache等模板引擎来处理视图层。但React相信视图和控制器应该相互依存在一起而不是使用第三方模板引擎,而且,最重要的是,它是纯粹的JavaScript程序。


同构的JavaScript


单页面JS应用程序的最大缺陷在于对搜索引擎的索引有很大限制。React对此有了解决方案。


React可以在服务器上预渲染应用再发送到客户端。它可以从预渲染的静态内容中恢复一样的记录到动态应用程序中。


因为搜索引擎的爬虫程序依赖的是服务端响应而不是JavaScript的执行,预渲染你的应用有助于搜索引擎优化。


React与其它框架/库兼容性好


比如使用RequireJS来加载和打包,而Browserify和Webpack适用于构建大型应用。它们使得那些艰难的任务不再让人望而生畏。


不幸的是,目前的JavaScript版本并没有提供一个打包和加载的模块。(在未来的ES6版本上将使用System.import来解决这个问题)。


幸运的是,我们有RequireJS和Webpack这些漂亮整洁的替代品。React是由Browserify构建的,如果你想操作图像资源或者编译Less和CoffeeScript,Webpack或许是一个更好的选择。


我需要另一个开发框架来配合React吗?


你可以使用React来构建用户界面,但是你仍然需要进行AJAX调用,应用数据过滤以及其它Angular已经实现的功能。


如果我们还需要另一个额外的JavaScript开发框架,为什么不使用Angular?


框架由一系列模块和规则组成。如果我们不需要它的一些模块,甚至想将某些模块替换,我该怎么做?


其中一种实现模块化且能更好地进行依赖管理的方法是通过包管理器。


但是,在Angular中怎么进行包管理呢?这还得取决于你,但是得记住,Angular是自成一体的。你很可能需要让第三方包去适配Angular。


另一方面,React仅仅只是JavaScript而已。任何用JavaScript写的的包都不需要用React去封装。


对我而言,使用npm和Bower这样的包管理器更好。我们可以选择自己的组件和工具集。需要明确的是:这比使用像Angular这样的综合性开发框架更复杂。


就这方面而言,React的好处是鼓励使用npm,npm已经拥有了很多现成的包。你可以从完整的初学者工具包中选择一个开始构建React应用的包。


转向使用React也不是一帆风顺的!


由于Angular是一个应用开发框架,它带来了很多便利。我放弃了一些好的功能比如:封装好的AJAX用于$http服务,$q用于应答服务,ng-show,ng-hide,ng-class和ng-if作为模板的控制语句——所有这一切都让人惊奇。


React不是一个应用开发框架,所以你需要考虑如何处理构建一个应用程序的其它方面。例如,我正在参与一个叫做react-utils的开源项目,它可以帮助React进行更简单便捷的开发。


就目前而言,社区也在积极的贡献一些类似的组件来填补这一方面的空白。React Components就是这样一个非官方的网站,你可以在这儿找到类似的开源组件。


React的信条不鼓励使用双向绑定,这也给处理表单数据和编辑表格数据带来了很多痛苦。


无论如何,当你开始理解Flux数据流和存储,事情就变得简单、清晰和简单。


React是新生的。这需要一些时间让它周边社区发展。在另一方面,Angular已经非常流行了,且有大量的可用扩展(例如 AngularUI和Restangular)。


虽然React的社区刚起步,但是发展得非常迅速。像React Bootstrap这样的扩展就是一个很好的证明。我们早晚会拥有更多更丰富的组件,这只是一个时间问题。


总结


如果你喜欢Angular的方式,在一开始你可能会不喜欢React。主要是因为它是单向数据流且缺乏开发应用程序的一些功能。最终很多事情还是需要自己来考虑。


然而当你开始习惯了Flux的开发模式和React的设计理念,我相信你会看到它的美。


Facebook和Instagram都在使用React(因为他们在领导这个项目)。


GitHub最新的源码编辑器Atom就是用React构建的。


雅虎邮箱也正在使用React重构。


React已经被大量的应用程序和科技公司所关注。


本文为CSDN编译整理,点击“阅读原文”可查看全文并参与讨论。



以上是关于我由Angular转向React,为啥的主要内容,如果未能解决你的问题,请参考以下文章

我由Angular转向React,为什么?

为什么我从 Angular 转向 React

我从Angular 2转向Vue.js, 也没有选择React

为什么我弃用 Angular,转向 React

为什么绝大部分前端团队还是无法重视Angular

[译] 为什么我放弃了 React 而转向 Vue。