我们使用Dojo（1.9.3）作为构建单页面应用程序的JS框架。然而，我们在Dojo的怪癖上花费了太多时间，所以即使是简单的任务也需要很长时间才能实现。由于缺乏适当的文档，我们经常不得不求助于阅读源代码然后实现变通方法。
我觉得如果我们转移到其他框架，我们会加快开发速度，并且更容易维护代码。我们的代码库相当大，因为它是一个复杂的应用程序，所以我们没有时间一次性重写整个事物。因此，我希望将Dojo与其他框架结合起来，以便我们可以逐步远离Dojo。我在业余时间只涉及这些其他框架，并且只写了一些小的示例应用程序，所以我觉得我不能真正说出它们是否会与另一个框架很好地配合，所以我希望有些你在那里可以。
我一直在研究的框架 - 根据我的简短调查按照我喜欢的顺序，但我可以自由地说服我。
虽然主要的问题是它是否可行，但如果您认为这样做是一个坏主意，请提供建议。
我可以从Dojo结尾处说的最多的是Dojo本身是一个工具包，而不是框架本身，因此通常不应该干扰其他脚本或框架。另一方面，相反的情况并不总是如此。因此，虽然我无法代表您列表中的所有选项，但我认为Dojo本身不会妨碍您。
我能想到的一个可能的例外是，如果有任何框架增加了原生原型，特别是 Object因为这会影响所有对象中的可枚举属性，并且会对任何用于... in循环的脚本造成严重破坏 hasOwnProperty。
我能想到的唯一另一个例外是，由于某些原因，任何有问题的框架是否与AMD模块加载器不能很好地共存。
话虽这么说，我还建议你把框架的“承诺”带到一点点 - 你说现在你发现用Dojo实现的东西需要努力，你自然列出的框架很有吸引力，因为它们使通过提供模式和约定，应用程序开发的某些部分很容易 - 但您应该问的问题是，在您需要在外部或违反这些约定时执行某些操作时，您的框架有多难以完成工作？ Dojo可能有学习曲线，但通常不会 避免 你做任何事情。
我可以从Dojo结尾处说的最多的是Dojo本身是一个工具包，而不是框架本身，因此通常不应该干扰其他脚本或框架。另一方面，相反的情况并不总是如此。因此，虽然我无法代表您列表中的所有选项，但我认为Dojo本身不会妨碍您。
我能想到的一个可能的例外是，如果有任何框架增加了原生原型，特别是 Object因为这会影响所有对象中的可枚举属性，并且会对任何用于... in循环的脚本造成严重破坏 hasOwnProperty。
我能想到的唯一另一个例外是，由于某些原因，任何有问题的框架是否与AMD模块加载器不能很好地共存。
话虽这么说，我还建议你把框架的“承诺”带到一点点 - 你说现在你发现用Dojo实现的东西需要努力，你自然列出的框架很有吸引力，因为它们使通过提供模式和约定，应用程序开发的某些部分很容易 - 但您应该问的问题是，在您需要在外部或违反这些约定时执行某些操作时，您的框架有多难以完成工作？ Dojo可能有学习曲线，但通常不会 避免 你做任何事情。
你可以一起使用它们，但它也取决于你想要做什么。某些操作可能比其他操作花费更多时间进行集成。
我只有Ember.js和AngularJS的经验，但这些框架中的一个共同概念是数据绑定。数据绑定允许您简单地更新模型，视图将反映模型中的更改。
但是，这些通常不适用于小部件。小部件（如Dijit库）创建自己的DOM，因此，像Ember.js或AngularJS这样的框架不会“意识到”这些更改，并且在这种情况下无法更新视图。
要使其工作，您必须将您的小部件包装到组件（Ember.js）或指令（AngularJS）中。这种包装的一个例子可以在 这个答案。
依赖加载可能会令人困惑。 AngularJS带有自己的依赖注入系统，这意味着你必须为Dojo模块使用Dojo AMD加载器，为AngularJS使用AngularJS依赖注入。据我所知，两者很好地协同工作（我已经看过使用RequireJS AMD加载器的示例，所以它应该是可行的）。
使用Ember.js，我在使用AMD加载器时遇到了更多麻烦。 Ember.js（Tom Dale）的创建者不相信AMD，我看到有几个问题试图用AMD加载器加载Ember.js组件。
这一切都取决于您希望如何使用这些框架以及您想要做出的额外努力。对我而言，看起来你甚至不确定如何使用这些框架，因为React.js或Polymer与AngularJS或Ember.js的目的完全不同。