Sometimes I am contacted by consultants or businesses regarding Durandal as it compares to other frameworks. And sometimes the questions that are asked take the form of “So and so says Durandal isn’t as good as Framework X because of Y. Is this true?” Frequently the people making the original statements aren’t basing them on correct information. Other times, they ignore the imperfections in their “framework of choice.” Below is a list I was asked to address recently for a customer who was very happy with Durandal, but who was receiving some pressures from a 3rd party who wanted them to switch to Angular.

1. Angular supports large scale applications better.

Durandal supports large apps at leastas well as any other framework. I would say it supports them better because it is built from the ground up on RequireJS, which is a stronger and more flexible module system than Angular's. If you choose Angular for a large project, you will likely have to go through the process of building infrastructure and integration with a solution like RequireJS anyways. With Durandal, it's supported out of the box. Additionally, Durandal's module system, being based on AMD, doesn't introduce any presentation-library-specific code into your app modules. Even if you integrate RequireJS with Angular, you will still have to deal with Angular modules, thus ending up with two module systems in your app. With Durandal, you just build standard modules, as apposed to Angular modules. What is important about that is that RequireJS is forward looking, with a planned path to ES6 native modules and will provide a smooth transition when the time comes. Additionally, if you choose TypeScript as your language, you will find the experience to be gorgeous, since TypeScripts's language support for modules compiles directly into AMD modules. If you are using Angular with TS, you are always going to have the second layer of modules, not supported by the language and the generated code will have those two module systems as well. In actuality, I think it’s fair to say that Durandal is the best framework available today for large app development. It scales linearly from the smallest of apps to the largest with ease.

2. Angular has better community support and Google backs it.

I can't argue with Google financially backing Angular. If having a big company backing a JS library is a concern, that's an honest +1 for Angular. I can tell you that if you look at my personal open source project history, you will find that I've been more consistent than Google has with their developer projects. Currently, Google has multiple internal presentation tier libraries that are competing with one another. They aren't all going to be supported going forward. Furthermore, large initiatives such as Dart, have not chosen Angular as their library. (The Dart team chose Polymer, another Google initiative, after they had dumped a 3rd Google library.) If you look across Google's developer projects, you will also find that they are not shy to frequently break APIs and even kill products without much notice. You can't choose a Google product thinking it has Microsoft's "10 year" support promise. It doesn't. I’m not sure you really get much advantage from Google’s backing at all, if any. It might even be worse.

Regarding better support, I'm not sure that's true at all. For example, Durandal has commercial support options available, with SLAs of course, and Angular does not. We have an active community communicating in our Google group and plenty of activity on SO as well. How big do you need your community to be? From what I can tell, most people are getting great help from our community and those that want even more have opted for commercial support. I can tell you that every single support customer I have has been very happy.

3. Angular binding is easier than Knockout/Durandal.

This complaint usually refers to the need to use ko.observable et al instead of normal JS object attributes. However, Durandal 2.0 eliminates this need for ES5 browsers. That said, I believe this is not an entirely sincere complaint. The reason is that you still need to manually interact with the binding machinery in Angular. You need to really understand how scopes work in Angular and you need to work with those directly in many cases. You also need to understand the "digest cycle" and in certain cases, manually interact with it. Those concepts can be a significant learning hurdle in Angular, but they don't exist at all in Durandal. Some people may also like the html binding syntax in Angular better, but if you use Knockout 3.0 and Knockout Punches with Durandal 2.0’s observable module you will find that Durandal's experience is actually superior to Angular's. We can use normal properties, have more efficient and scalable data binding due to no digest cycle and we have a nice, rich declarative (and extensible) syntax. Finally, I'd like to point out that it's much easier to learn how to build custom binding handlers on top of Knockout's system than Angular's. Building custom bindings in Angular is a bit cryptic. There are usually lots of ways to do "similar" things but with subtle differences between them. You really need to understand the process very well, understanding how scopes, digest and even parsing work sometimes.

4. Angular has better support for existing UI control libraries like Kendo or Ignite.

5. Angular is easier to get started with.

I'm having a hard time understanding this one. If you are using Visual Studio, just install the VSIX, then do New Project => ASP.NET MVC 4 Web Application =>Durandal SPA Template. That's it. You have a runnable, pre-configured navigation application. Just start adding pages. You can also use Mimosa, which has a single command line statement to generate a new Durandal project with the same capabilities. Alternatively, you can grab the HTML starter kit, unzip it and you are ready to go with the same setup. I'm not sure how to make it easier than unzipping a file or doing a "File => New Project". If the criticism is referring to Angular's ability to just add the library and then immediately start writing binding expressions in the page without a model or project structure….sure that's pretty simple, but nobody builds a real application like that. That's demo code and falsely represents the real app building experience. If you want to build a real app with Angular, you have to go through all the steps of setting up a project structure, creating modules and controllers, configuring routing, etc. I think if you go through those steps you will see that the Durandal equivalents are actually simpler and more standards-based. But, you don't have to do that because we provide you with great starter kits.

6. Angular has more free training.

It’s possible. Angular has been around longer. However, Durandal is growing pretty rapidly and is being spoken about at tons of conferences and code camps around the world. There are plans in the works to expand training options too. That said, there are pay training options with Durandal. I realize this is about "quantity" and "price" but if you want quality training, there are pay options for Durandal that can easily be afforded by most companies and individuals. I think a better question might be about quality of training materials, in which case I’d say that the frameworks are roughly equal. That said, we’ve got some big plans in this area that will be surfacing in the near future.

This should put to rest a few common objections which are frequently based on misinformation. This isn't an attempt to cut down Angular, but rather to show that Durandal is as capable. In many cases, Durandal does actually excel beyond other frameworks. I could go into detail concerning some of it’s unique benefits beyond what is mentioned here. It has many. But I wanted to focus on common, incorrect arguments that I have heard. Hopefully this helps to clear things up a bit.