6 大主流 Web 框架优缺点对比

是该读些评述和做一些总结的时辰了。当我们开始写这个系列博客的时辰，我们知道 JavaScript/web 应用框架并不太好总结。我们全力对这个不行答复的题目作出答复：我该用什么样的框架?

在这篇文章中，我们将对这个系列中所提到的每款框架做一个总结，包罗我们以是为的刚强和弱项。其它，我们为你留下了一些值得思索的题目。

我是否必要行使框架?

假如不实行答复这个题目就是我们的失职，这越来越成为社会上某些人的口头禅，在收集平台上的争论也已经成长到如同不必要特殊编写 API 能更简朴建设 Web 应用那样的境地。就像本系列中全部的内容一样，我们的答复也多半是依据这些内容。

固然无框架也能正常事变，可是，这也是有价钱的。那些主张无框架手写 Javascript 的人，那些凡是会被我们以为是斯德哥尔摩综合症(情绪上会依靠他人且轻易受打动的人)的人，健忘了收集平台上有多套快速成长的 API ，至少有三种差异的技能，三种截然差异的语法。web 平台类型并确定了高出 12000 个 API，究竟上赏识器中的维恩图也表现了这些庞大差距。

假如你是一个有着深挚技能和履历的人，确实可以坦诚的不行使框架。但你团队的其他成员呢?你部下的那些人呢?可能当你的抉择把你本身陷入逆境的时辰呢?这种环境下，我们将会看到一个不消框架的团队在睁开冒险，最后他们会发明本身建设了一个必要本身着手维护的框架。接着就会呈现探求人才的题目，他们不必要知道框架是怎样事变的，只必要探求会挪用收集平台 API 的高级手艺人才可能一些自称有履历的人才，最后却发明穷乏利于团队成长的手艺深度和履历。

团队应该停止卖弄等价(false equivalence)的陷阱，很显然，在 web 技能的应用方面具有创新性的公司在不绝进步他们的市场代价和竞争力，Google、Facebook 和 Netflix 公司都是很好的例子。可是大大都公司不是这样，他们应该认可这一点。

Angular 2+

有什么上风?

Angular 2+ 的最大上风在于它的风行水平。也有人以为它和 Google 亲近相干的名字，会影响团队行使它。Angular 1 的敏捷风行是由于那些来自其他交互式应用措施开拓情形的人会发明对付开拓单页面 web 应用措施具有相似的模子-视图模式。通过对 Angular 1 举办当代化演变和从头构建框架的某些部门，Angular 2+ 已经真正的发作了，大量的正式的和非正式培训机构数目都让人印象深刻，开拓者有很强的市场竞争力。对付用户来说它有一套用于构建用户界面的富厚组件，这也是本系列中少有的几个框架可以或许做到这点。

有什么瑕玷和挑衅?

我们认为 Angular 框架着重于在单个页面应用措施中建设用户界面并没有处理赏罚构建完备的 web 应用这个更大的存眷点，假如不赶早确定下来，这将会导致整个项目难以维护，在现实项目中，运行时提供不属于焦点框架的技能每每让人认为不行思议，这大大低落了 TypeScript 对最终开拓者的代价。

将来将何去何从?

Angular 5 方才宣布，这看来是 Angular 已经乐成的印证了快速宣布版本的理睬，在 Google 的一连支持下，Angular 会越来越成熟。

像很多的大型组织一样，Google 具有多重(破碎)的人品，从外表上看，Angular 团队和那些专注于赏识器尺度的团队之间显得很调和。但我们的概念是，调和只是一层薄薄的窗户纸。Angular 团队对付 web 组件和渐进式 web 应用没有一个真正办理方案。我们以为，业界广泛承认的尺度将会在 Angular 框架中会慢慢实现，这将会影响到怎样更好的构建 Angular 应用将成为一此中/恒久的风险。

何时选择 Angular 2+

假如你必要在一个大型的框架内获取技能资源，框架内的技能凡是很轻易移植;可能你必要在框架中实习开拓职员，而且还要有必然的信念，他们会在短期内得到必然的开拓手段，这样的话你可以思量 Angular 2+ 。必要留意的是 Angular1(angular.js)与 Angular2+ 是截然差异的，个中的应用、技能和履历不能直接移植到 Angular2+ 的开拓中去。

假如你的 web 应用可以或许很好的转化为尺度的模子-视图模式，那么你也可以忽略其他直接思量行使 Angular2+ 。

假如你对 Google Material UX 计划模式满足，那么 Material Angular 是遵循该模式的一种快速、简朴且靠得住的方法。

React + Redux

有什么上风?

React 和 Redux 的最大上风在于它们相对简朴和专注。做一件工作并把它做好长短常坚苦的，但这两个库都很有用地完成了它们的方针。固然对付某些状态容器要领也许是外部的，但大大都开拓职员照旧可以轻松把握观念，并相识单向数据系统布局的甜头，简化大量的用户界面应用措施。

有什么瑕玷和挑衅?

React 和 Redux 最大的瑕玷不是它们是什么，而是它们不是什么。要构建一个成果富厚的 Web 应用措施，你必要很多成果，一旦离开 React 和 Redux 和其他一些库的焦点，你将发明一个很是分手的社区，拥有无数的办理方案和模式，不轻易整合在一路。

因此，固然 React 和 Redux 都长短常专注的库，但缺乏履历的团队照旧会很轻易地天生不行维护的办理方案，而不是意识到他们所做的选择会导致机能不佳或错误。纵然有履历的开拓职员也也许意识到，一个疏松的架构或老例也许会在将来困扰他们。

假省钱是一种对本身的诱骗，组织范畴内回收 React 和 Redux 将轻松低落无服从题目。没有其他库和模式的普及约定和尺度化，尺度化 React + Redux 较量于我们正在回收的 JavaScript 来编写我们的应用措施服从要高。

将来将何去何从?

Facebook 和 React 最近从繁琐的附加专利纠纷中抽离，他们熟悉到，就像其他项目一样，更普及的社区可以或许进步本身的声音。我认为这有助于 Facebook 意识到他们还不能更好地相识我们，信托我们来引导项目。但愿这将继承贯串项目标特点和技能偏向。

很难猜测 React 和 Redux 的将来。可是，将库齐集在一路，确实会显著进步顺应性，大大都React + Redux 模式城市促进一个疏散的系统布局，从而可以轻松地举办重构和迭代。两年前，各人喜好的照旧React + Flux，但整个社区很快就拥抱了Redux。思想或模式的其他重大转变也许很轻易被采用。这种要害手段也许会一连到将来。

何时选择 React + Redux ?

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!