.NET & Funky Fresh



  • <script type="text/javascript" src="http://ws.amazon.com/widgets/q?ServiceVersion=20070822&amp;MarketPlace=US&amp;ID=V20070822/US/bluspiconinc-20/8001/8b68bf4b-6724-40e7-99a5-a6decf6d8648"> </script>
Durandal vs. Framework “X”

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 least as 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.

I'm not sure what this statement is based on. We have people using Durandal with all sorts of libraries, including Kendo and Ignite. We even have documentation on Kendo integration as part of our official Docs and Infragistics has even blogged about using Ignite with Durandal. We also have great support for libraries like Breeze. I've personally used Durandal with tons of 3rd party libraries without issues and have seen the community do the same.

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.

7. Angular has better documentation.

I'd just have to flat out disagree with this. Personally, I don't like Angular's docs. We've also had a number of people contact us directly to say that they specifically chose Durandal because it had better, more useful documentation than Angular. It is a big matter of opinion, I guess, depending on what your expectations are. Here's what Durandal has: a getting started guide, lots of "targeted" how tos, docs on integrating with other popular libraries, docs on how to build native apps, docs on build processes, docs on customizing the framework and in-depth references docs. In the next couple of weeks, we are releasing more docs. I take a lot of feedback from the community on the documentation and treat those requests the same as requests for bug fixes and features in the framework. We've also taken plenty of community contributions.

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.

Posted 10-07-2013 8:41 PM by Rob Eisenberg


About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)