DurandalJS 项目的所有者现在在谷歌工作，致力于 AngularJS Next (v2?) 除了保持 DurandalJS 的当前版本。这两个框架正在融合。
http://blog.angularjs.org/2014/04/angular-and-durandal-converge.html
对于一个新的 mini-SPA 项目，哪个框架是升级路径的最佳选择？
我注意到 Rob Eisenberg 列出了一些帮助现有 DurandalJS 用户为下一个版本做好准备的技巧，所以看起来会有一个可用的升级路径，但我想知道从 AngularJS 升级到下一代框架是否会简单点。
http://eisenbergeffect.bluespire.com/preparing-for-durandal-nextgen/
需要明确的是 - 我更关心的是为 future 做出正确的选择(大型 SPA，拆分为多个迷你 SPA)而不是我当前的需求。
最佳答案
我不确定现在哪一个是最好的选择......实际上我会说他们都没有足够的 future 储蓄。 Angular 2.0 肯定不同于 1.0，当然也不同于 Durandal。
尽管如此，框架本身可能并不那么重要。我认为您应该专注于分离可重用组件中的代码。无论是 Angular Service/Factory/Provider 还是 Durandal 中的一个干净的 Require 模块，它实际上都无关紧要。将它加入"new"框架应该只是添加适当的包装器的问题。至于 2 路绑定(bind)，请使用 oberserver 插件来维护干净的 POJO。
从我的 Angular 来看，NG2 中最重要的变化将是生命周期事件的支持，因此即使现在在 Durandal 中使用这些事件，NG2 也会以某种方式支持。至于合成，肯定会有一种方法可以在 NG2 中轻松模拟。
对于当前的工作，在我看来，对于当前使用的框架的决定来说，唯一重要的两件事是 RequireJS 的使用和框架的简单性。当然你也可以将它添加到 Angular，有几个关于这方面的指南，但 Durandal 是从头开始构建的，考虑到了 RequireJS。尤其是在较大的项目中，这可以避免您因缺少或错误的依赖项而头痛。至于第二个论点 -> 将 Durandal 移植到 Angular 并不是什么大问题，因为它是以一种简单易懂的方式编写的。反之亦然可能是一个完全不同的故事。将您的自定义指令实现为模板和 ko-bindings 的组合可能会变得非常困难:)
所以作为结束语，如果它是一个小项目，但需要持续支持以及 future 对 NG2 的更新，我会选择 Durandal。除了 RequireJS 之外，一切都是可交换和适应性的。就 Angular 而言，我不确定新的 DI 系统将如何彻底改变开发方式，因此这对我来说是一个阻碍。
顺便提一句。这是 design-document for NG2 。所以正如你所看到的，所有重要的东西都会改变:
关于angularjs - 鉴于 DurandalJS 和 AngularJS 的融合，应该为新项目选择哪个？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/25089666/