Discourse 基于 Rails 和 Ember 构建，这些是支持 Discourse 成功的优秀选择。然而，这一选择是在 2012 年做出的。我不禁好奇，如果项目在 2020 年启动，技术选型会有哪些不同？我也想知道 Discourse 开发团队对替代方案持何种看法：
我不认为这种猜测有什么价值，这有点像问“如果云朵是由美味的棉花糖做的，而雨水是美味的柠檬水会怎样”…… 
话虽如此，我们将继续迭代 Ember.js，确保其符合我们所需的性能参数，这是我最关心的！在这方面也已经取得了巨大的进展！
我很喜欢你愿意向 Discourse 开发团队分享建议。
(我的观点)
我过去三年一直在参与 Discourse 的开发（基于 Rails 和 Ember.js），同时也参与过一些使用 Angular/React 等构建的其他项目。我还大量参与过 Canvas LMS（基于 Rails 和 React.js）的开发工作。
我发现，与其他许多大型产品（包括大量开源项目）相比，Discourse 在速度与性能方面表现优异。Discourse 非常快速、流畅如丝，且稳健可靠。实时事件功能更是 Discourse 的魔法所在。
如今，具体使用哪种编程语言开发其实已不再那么重要。真正卓越之处在于其开发方式的智能程度以及各组件的无缝集成。正是社区成员日夜不停地努力，才让 Discourse 每天都在变得更好。
对我们而言，最好的选择始终是持续改进和优化现有成果。
不妨这样思考：
如果把 Discourse 比作一个人，那么 Ember.js 就是它的血液。当然，你可以说 Ember.js 是“血型 A+”，而其他语言则类似于 B 型、O 型、AB 型等。结论是：与其用新的血型（比如 B+）替换整个血液系统，不如通过提供良好营养和健康生活方式来维持现有血液的健康；试图彻底更换血液系统是行不通的。
此外，我们已经基于 Ember.js 为 Discourse 开发了大量插件。如果我们更换语言，这些插件也将无法继续运行（毕竟 Discourse 本身就是基于 Ember.js 构建的）。
如果你发现 Discourse 存在哪些不足，欢迎分享你的看法，这将帮助 Discourse 团队进一步优化产品。
另外，如果你在考虑更换语言之前有任何具体标准或依据，也请告诉我们。
我们不需要汽车，我们需要更快的马。
感谢 @codinghorror 和 @ashishprajapati 分享见解。我的问题并非旨在提出建议或对选择表示质疑，而是想了解在这个项目阶段，您认为有哪些优缺点。
我完全赞同：框架或语言的选择最终远不如社区和执行力重要。
感谢 @hbm 提供的想法和观点 是的，我同意。
对于开发者来说，Ember.js 太笨重且难以学习，有很多过时的示例和内容。
我个人倾向于 React.js 或 Vue.js，因为它们的学习曲线较低。
我认为这个话题可能有点过时了，四年过去了……