Instant2FA在2016年选择Ember替代了React

这是instant2fa.com在使用了React.js两年以后重新选择Ember的考量分享。

instant2fa是一种可以为任何网站添加两步认证的应用服务，能让应用者在不到一小时内完成集成。

每个新项目都需要百万个技术决策。 幸运的是，我们花费4年经验建立公司的Clef产品，这是一个由两百万网站使用的两步认证产品，这会使我们的大部分决定能够立即见到成效。 我们的后端服务使用Python，SQL和Flask构建，并利用我们花费多年工作的所有工具和库。

但是，前端则是另外一个不同的故事：我们在生产中使用React和flux（由reflux驱动）已经两年半，但是当我们开始考虑如何构建Instant 2FA时，我们想知道使用更完整功能的框架如Ember或Angular是否更好？

由此开始评估 Ember，有两个主要的假设驱使我们的好奇心：

1.约定超过配置。 因为Ember会自己处理很多事情，React需要其他库的组合配合来做，我们将能够更多，更快工作，没有决策疲劳的痛苦。

2.渐进增强和幸存的框架炒作周期。 由于Ember具有非常强的社区，是非常致力于使Ember打造现代Web应用程序的最佳方式，我们或许可以使用最新，最好的技术。

当我们敲定这些推测以后，发现了令人信服的证据，最终导致为我们的应用程序选择Ember。

约定超过配置
React最好的一点是，因为它只是一个视图层，它可以很容易地被添加到一个预先存在的JavaScript应用程序。 三年前，当Clef的前端基于我们自己的面向对象JavaScript框架构建时，我们开始探索React是否可以帮助我们，这是最好的部分之一。 我们不是立即切换到新的框架，而是逐步用React组件替换不同的组件 - 只在必要时在React之上添加额外的逻辑层（如redux来处理数据流）。

随着时间的推移，我们自己融入了React生态系统。 不同的库会彼此重复，但能工作。 我们用了：
coffeescript
React视图
reflux for data flow
react-router 2 for routing
jQuery.ajax for network requests
underscore for utilities

几个月前，我们做了一个小的项目，我们必须从头开始创建一个客户端应用程序。 我们使用React一起进入视图层，但考虑到过去几年生态系统的戏剧性演变，我们最终使用了一个非常不同的组合：

ES6
React for the view
redux and redux-saga for data flow
react-router 3 for routing
fetch for network requests
lodash for utilities
webpack for module building
post-css & css-modules for styles
karma, mocha, sinon and chai for tests

每一步我们都询问自己：这个库包选择错误了吗？在React生态系统中使用工具配置我们框架，但是主要关心我们的配置是帮助我们还是伤害我们。

将高级架构技术决策委托给在域中经验有限的工程师通常会导致错误决策。 我们是一个由4名工程师组成的Clef团队，但由于我们定期在5个平台（iOS，Android，后端Python，客户端JavaScript和WordPress插件）上维护代码，我们的工程师中只有两个真正致力于我们的React应用程序。 在这个边际项目作为一个团队的工作结束时，我们为自己制定了一套后来经常被证明不稳定的工具，它们阻碍了我们完成工作。这里体现了配置繁琐的问题，如果工具框架能够自动配置一些场景，也就是公约大于配置，那么很显然会提高生产力。

我们每个工程师有一半时间使用JavaScript，因此这意味着超过一半编写代码的人将是相对缺乏经验的JavaScript工程师。 相对缺乏经验与前端工程 - 使得公约大于配置这个好处特别显现。

当我们开始使用Ember实现Instant 2FA时，Ember为我们做出所有这些公约大于配置的决定思想 -是非常诱人的 。

mber内置了测试，测试在创建新单元（模型，路由，服务，序列化器等）时自动生成。 而我们在构建最后一个React应用程序，我们花了几天时间设置测试工具，验收测试以及所有其他必要的工具，以便拥有一个快速，易于使用的测试套件，我们仍然不断对我们自己的这种设置感到失望。 Ember在框架中构建了接受和单元测试，我们希望这将使我们的代码更容易在每个级别进行测试。

在构建部署这块，Ember公司是由ember-cli ，处理构建的每一步，这个工具链带有开箱即用的默认值（例如ES6和模块），但围绕这个标准建立的社区是最强大的部分。

在我们以前的设置中，每次我们需要改变构建build以实现特定的目标时，我们需要编写自定义代码。 一个很好的例子是在我们的代码部署时将源映射上传到Sentry。 在我们的React应用程序中，我们在完成webpack构建之后，是在shell脚本中执行了这一操作。

使用ember-cli，几乎所有我们需要补充的的新一步，都可作为Ember插件，由于Ember强制执行约定，这些插件几乎总是开箱即用。 因此，我们的构建和部署逻辑已经从一系列自定义JavaScript和shell脚本逻辑转变为不同模块的干净组合，这些模块由不同社区维护着。

数据流和建模
Ember的数据流和持久性的默认实现依赖于ember-data，而在 React中，使用redux与redux-saga，总是试图搞清楚如何将它们用在我们的项目中，而我们与ember-data已经建立了怎样做事方式-即使其中的一些模式感到有点过时，因为ember-data和ember-cli都是统一由ember核心团队维护的。

服务器端呈现
Ember FastBoot能激活服务器渲染，在任何Ember应用中使用一个命令，在我们以前的React应用程序中探索了服务器端渲染，我们知道对于围绕React的每个库配置都有一个同样复杂的服务器端渲染设置。 服务器端呈现出来的不是我们需要的，因为有些我们还没有激活启用它。现在使用一个cli命令，而不是捆绑一个大项目，这减轻了我们的负重。

渐进增强
当讨论渐进增强的主题时，它通常指从纯HTML＆CSS到高级交互式JavaScript应用程序驱动的逐渐增强网页。

对于浏览Web应用程序的用户，他们的体验应该根据其使用的浏览器支持（或已启用）的技术是逐步增强的。 用户在没有JS支持的浏览器中将获得一个纯粹的HTML和CSS体验 - 虽然它可能较慢或笨重，仍然可以工作 - 而一个用户使用提供JavaScript的现代浏览器，他们的体验完全是现代。 换句话说，通过逐步增强，我们满足用户的需求，也许最重要的是， 他们得到最好的经验，而他们自己无需做任何工作。

渐进增强的最好的想法应该在JavaScript框架和库是显而易见的，我们称这种为渐进开发人员体验（Progressive DX），它是的Ember框架和社区所定义目标之一。

在React生态系统中，渐进增强最常见的是通过创建新的库包。 Flux范式和单向数据流的概念是一个特别好的例子。当Facebook首次发布Flux架构时，一些小型库包实施了这种模式（其中一个是reflux，也是我们开始使用的库包）。 随着时间的推移，这些库包中的许多已经消失了，而社区周围形成了其他社区（如redux），但是概念的演变最常见的是通过引入新的库包。对于在概念层面发展的每次新迭代，一个新的库或工具需要被添加到您的工具：或搭售渐进增强的语言， 开发者需要改变他们的工具以获得最佳的体验。

相比之下，Ember的目标之一是给开发者当前总是可用，而不需要做任何工作（或尽可能少）,带给开发者最好的体验 。

在核心团队评估期间，大家对Progressive DX这点感觉一致：Ember Fastboot（服务器端渲染），glimmer（更快的渲染引擎），可路由组件（单向数据流）和服务（隔离关注）都是Ember体验逐步增强的例子，通常可能是直接从其他框架已经引入的模式中借用，让Ember用户享受最好的网络技术。

更多见原文：
Choosing Ember over React in 2016

[该贴被banq于2016-11-17 11:48修改过]