我是在接近结尾的时候写的# EmberJS2019窗口，这意味着有很多话要说已经说过了.正如我在阅读今年的帖子时所看到的，有几个主题我一次又一次地提到：

• 精简和模块化框架
• 扩大恩伯社区
• 登陆我们新的建造系统，刺绣

这些观点本身都很重要和有价值，我希望2019年路线图RFC能够解决所有这些问题。不过，许多讨论这些问题的帖子都提到了一些我认为值得更明确讨论的问题。

在过去的几年里，我看到越来越多的恩伯人表现出一种将世界划分为几个部分的心态美国和他们．它体现在社交媒体互动和博客文章，在Ember Discord服务器的日常聊天，甚至是我们框架聚会和会议谈话的方式。我认为这是由看到Ember成功的愿望驱动的，并说服其他人他们应该像我们一样喜欢这个东西，但它最终会对每个人都造成伤害。

以上三种方法的共同点是，如果我们实现了它们，它们可能会帮助我们开始消除这种心态。扩大我们的社区意味着引进有其他工具经验的开发者，这可能会模糊内组和外组之间的界限。简化框架并采用绣花将使我们更好地与更广泛的Web生态系统中使用的标准实践保持一致。

不过，我对#EmberJS2019的希望是，我们能更进一步做一个积极的努力去拆除美国和他们心态，有意参与更广泛的Web开发社区。

我们为什么分裂？

为什么我们作为一个群体会自我认同作为一个群体？有一些历史技术因素推动我们朝着这个方向前进，还有一些一般的社会学现象¹这可能有助于形成和加强这一群体。

技术原因

作为一个框架，余烬之所以有价值，很大一部分是因为它在应用程序和基于它构建的发布库中都有强大的约定，如果没有一个拥有并接受这些约定的社区，这是不可能的。事实上，共享、一致解决方案的愿望是我们历史上与其他Web生态系统分离的一些技术原因的根源。

Ember的富对象模型早于类作为一种语言特性引入之前，但一旦类成为ES2015规范的一部分，Web开发世界的其他大部分人就采用了它们。几年后，惯用代码仍然使用原始的Ember对象模型，因为ES类本身的表达能力不足以捕获相同的含义。

ES模块也是一个类似的故事:Ember团队在JS工具的大部分工作都集中在如何为浏览器绑定CommonJS模块上的时候就已经在它们上面下了赌注。当然赌ES模块是一个好的,日益成为用户的默认,但与此同时发表在cj很多代码格式和灰烬开发人员离开要么需要编写复杂的构建代码把这些库灰烬之后还是滚自己的约定。整个班级ember-xyzaddon出生时唯一的工作就是获得xyz库导入构建，无需手动配置。

谢天谢地，今天这两件事都不是真的。即将推出的Ember辛烷值版将鼓励使用ES类（感谢类字段和修饰符建议)全面的，并且余烬汽车进口使在构建中包含第三方库的过程变得微不足道，不管它们使用的模块格式是什么。

很长一段时间，没有这些东西是现状，这意味着为Ember项目编写的代码看起来不像你在其他任何项目中编写的代码. 如果您在一个上下文中开发的代码在另一个上下文中不可用，那么这两个上下文之间的开发自然会变得孤立。规范会漂移，相似问题的不同解决方案会演变，最终你会得到彼此看起来非常不同的实践主体。

社会原因

当然，技术因素从来不是唯一起作用的因素。人们自然地聚集在一起的倾向美国和他们是这是一个被广泛研究的社会学现象，其最终结果是，社会群体可能是一种自我强化的结构。

需要澄清的是,我们作为一个群体有自己的身份是一件好事，也是一件健康的事情．在今年的EmberConf主题演讲中，Yehuda Katz说道谈到芹菜测试这是一种确保你在决定如何建设时按照自己的价值观行事的方式。Ember作为一个框架，在软件开发中优先考虑一组特定的价值观，这意味着作为使用Ember的自选群体，我们通常也分享这些价值观中的大部分。

因为我们对社区认为重要的东西有共同的理解，我们通常可以直接跳到讨论的核心，因为许多通常可能导致自行车切线的决定已经提前达成了默契。当我们看到一个公共插件时，我们也可以知道它的设计很可能是我们自己所做决定的结果。

所有这些都提高了生产率在我们的社区，但它也可以帮助我们远离它之外的项目。在评估问题的解决方案时，很容易忽略那些“不是余烬之路”的解决方案，而不需要太多考虑，这意味着这些项目不必看到余烬人的大量投入，从而进一步扩大了差距。

我们错过了什么？

Ember社区只占整个Web开发的一小部分，这必然意味着许多正在进行的创新都发生在我们的形象墙之外。如果我们忽略了这一点，这意味着我们可能会错过社区之外发生的新想法和改进。这也意味着我们可以轻松地重新发明轮子，s等待时间和精力自己解决问题，而不是从已经存在的更强大的东西中获益。

相反，如果我们确实开发了一些新颖和有价值的东西，但它只能在Ember项目的环境中使用，那么对世界其他地方来说，这是一个错失的机会。考虑到2019年反复出现的主题之一是扩大Ember社区，为生态系统贡献有用的框架未知工具可能是吸引其他人加入的一个好方法。

我们如何前进?

我们已经朝着一个积极的方向前进了！如上所述，Octane编程模型有助于降低来自其他框架的开发人员的进入壁垒，并且auto-import使得在您的Ember项目中使用任意的npm包变得更加简单。

跟踪人们在#EmberJS2019中一再提出的事情会让我们在这条路上走得更远。对Ember本身进行精简和模块化将进一步降低开发人员第一次学习框架的门槛，而扩大社区本身将自然有助于消除这种障碍美国和他们心态作为群体内与群体外的分界线已经不再那么清晰。

在技术方面，采用绣花将提高我们与不是专门为Ember设计的工具的互操作性。它的目标之一是显式构建阶段，在此阶段之后，所有的Ember约定都被“编译出来”。在此之后发生的任何处理都可以由任何理解符合标准的JavaScript的工具执行。这有可能大大降低使用为通用Web项目设计的捆绑和分发新思想和技术进行试验的障碍。

你提到了深思熟虑?

上述所有事情都会自然而然地推动我们朝着正确的方向前进，但我敦促我们作为一个社区，积极努力利用我们作为更大生态系统一部分的地位，并鼓励其他人也这样做。

在你分享的东西的框架上要考虑周到．它可以是超级满意{tweet |贴|给谈论}侵吞的琐碎在安博但{10 x更多的代码| | 4 x慢还是一个尚未解决的问题}在框架x很高兴庆祝我们的选择的工具是擅长的事情(和那些努力使这样!),但不仅仅是得分的一种方式。如果你打算以这种方式参与，那就真诚地去做，并考虑是什么权衡导致了这种情况，而不是永远保持这种心态我们是非常擅长做某事他们吮吸。

考虑不是为Ember定制的解决方案。也许你会发现一些开箱即用的东西，或者你可以在它周围做一个轻薄的包装。无论哪种方式，你都可以通过采用一些已经经过战斗测试的东西来节省自己的时间和一些麻烦。

询问您正在构建的内容是否需要特定于余烬. 如果你做如果你想从头开始构建一些东西，并且打算公开分享它，请考虑它是否只适用于Ember项目。如果没有，也许你可以将解决方案的核心作为一个普通的JS包发布，并在插件中包含特定于ember的部分。或者,与auto-import获得牵引力今天和刺绣正在形成的未来，你可能不需要一个插件在所有！

一个很好的例子是为Ember建立一些东西，然后面向更大的社区@桑塞利科夫的海市蜃楼项目²这个ember-cli-mirageaddon已经成为许多Ember社区默认开发工作流的一部分，但是项目的大部分内容对于任何编写基于浏览器的应用程序(从远程数据源获取数据)的人都是同样有用的。然而，Mirage是专门为Ember项目构思和开发的，在其生命周期的大部分时间里，基本上不可能在任何其他环境中使用它。

现在，正在进行提取@miragejs/server完全不依赖框架的包ember-cli-mirage插件将被重写为该包的消费者，以继续提供我们已经习惯的特定于余烬的位，但核心系统将可用于任何项目，无论其工具选择如何。

“我们”和“我们所有人”

没有他们，只是越来越大的圈子美国这个Ember community isn't separate from the broader Web development one, and we shouldn't conceive of it that way. Our community is a part of that larger one, and cliché as it may be, everyone stands to benefit if we act accordingly and embrace it.

⤴️1.请注意，社会学绝对是不我的专业领域，在讨论它的过程中，我主要是将我的观察结果与我在维基百科上读到的内容相匹配，并在心里说“哦，嘿，这完全合适！”

⤴️2.Mirage当然不是唯一一个这样做的项目，但它现在是一个非常突出的例子。Chris Krycho的真正的神话图书馆和我们自己的里程碑项目也是以这种方式构建的项目的例子。