为什么 Ember 对后端工程师来说感觉自然

Source: Dev.to

背景

我从来没有真正为学习前端框架而苦恼。
我苦恼的是在使用它们时，感觉自己在构建的东西不够稳固。

大多数时间，我都在做后端工作。做前端时，通常是一次性冲刺——搭建某个功能、验证一个想法，或把系统连通起来让它真正可用。很多时候我都是独自完成。每次回到前端工作时，我都会遇到同样的问题：

• 一切都变了。
• 模式也不一样。

在我真正开始构建之前，我必须重新上手。我没有时间去做这些。

重新发明模式的问题

我可以自己构建一套模式或快速开发的配置，但这只在下次需要时有效——到那时，底层的东西又变了。不断重新发明的循环让保持高效变得困难。

Ember 为什么适合我

这些年我多次拾起 Ember、放下再重新捡起。每次大约一小时后，我就能重新变得高效。并不是因为什么都没有改变，而是因为 Ember 的演进感觉像是逻辑上的延续，而不是一次替代。

• 上一次我在 Ember 中启动项目时，我了解到 Ember Data 正在被淘汰，Warp Drive 正在引入。在大多数前端生态系统里，这会是一个红灯，意味着我必须重新学习一些根本性的东西。而在 Ember 中，Warp Drive 感觉是下一步的合乎逻辑的演进；我不需要重新思考一切是如何运作的。

Ember 并不是为不断重新发明而优化，它优化的是连续性。我习惯于结构重要的系统，而 Ember 在一开始就提供了这种结构：

• 路由 合理易懂
• 服务 行为可预测
• 明确的存放位置

它不要求你去决定如何组织应用，这让人松了一口气。我不想花时间去决定东西放哪儿；我想直接去构建。

一致性胜于灵活性

大多数前端框架提供灵活性——你可以随意组织结构。这听起来很棒，直到你必须维护它、几个月后再回来看，或交给别人。灵活性解决了你当下的问题，但 Ember 选择了一致性。

它并不完美——Ember Data 有它的怪癖——但这些权衡是有意为之。Ember 并不想成为万事通；它的可预测性会产生叠加效应。我不需要一个让我可以做任何事的框架，我需要一个能帮助我始终如一地做正确事的框架。我不想每次启动项目都重新搭建前端架构，我想直接开始构建功能。

结论

这就是 Ember 对我来说感觉自然的原因——不是因为它更容易，而是因为它让我不再与工具抗争，直接去构建。