Watch your NuGet dependencies

Since its introduction in 2010, the NuGet package manager has gradually become the default method of adding (Open Source) external libraries to .NET projects. Much easier than downloading all those libraries separately and keeping track of everything.

But be careful: always check the dependencies of the NuGet package you want to install. It might very well be possible that the package depends on a package that your own project already depends on. Even worse are packages that come with an additional 20 packages or so. There always comes a day when you want to upgrade just a single package and another package that also depends on this package prevents the possibility to upgrade or simply breaks with the new version.

Therefore, I always try to follow these rules when adding new NuGet packages:

  • Don’t add packages with dependencies to other packages that your project itself already depends on;
  • Only add packages with a minimal amount of dependencies.

With these rules in mind you’ll find that future upgrades of NuGet packages are less problematic (and don’t install packages that depend on jQuery, but that’s for another post :-))

MvcPaging 2.1

Today, a new version of the MvcPaging library was released. The only new feature in this release is the option to add strongly typed route values.
In the past you had to add extra route values for the page links like this:

@Html.Pager(Model.Items.PageSize, Model.Items.PageNumber, Model.Items.TotalItemCount).Options(o => o
    .AddRouteValue("Filter.Name", Model.Filter.Name)
    .AddRouteValue("Filter.City", Model.Filter.City)
    .AddRouteValue("Filter.PostalCode", Model.Filter.PostalCode)
)

We’re assuming a viewmodel with an ‘Items’ property as the IPagedList and a ‘Filter’ property for extra filter attributes.

From version 2.1.0 you can use the new AddRouteValueFor method to get rid of the strings:

@Html.Pager(Model.Items.PageSize, Model.Items.PageNumber, Model.Items.TotalItemCount).Options(o => o
    .AddRouteValueFor(m => m.Filter.Name)
    .AddRouteValueFor(m => m.Filter.City)
    .AddRouteValueFor(m => m.Filter.PostalCode)
)

It looks like a small new feature, but behind the scenes, we had to make the Pager and related classes model-aware by creating typed versions (Pager<TModel>). This was a relative big change and therefore the version number jump to 2.1. Adding the model-awareness opens up a lot of new extension possibilities.

See https://github.com/martijnboland/MvcPaging for more info or to get the code or get the NuGet package from http://www.nuget.org/packages/mvcpaging.

Update: there is a live demo now at http://demo.taiga.nl/mvcpaging.

Durandal vs Angular – a real world comparison

durandal-240angular-240

As promised in my previous post, I’ve also built an AngularJS version of the Moped web client for Mopidy. Moped is an HTML 5 music player app that uses Web Sockets to communicate with the Mopidy music server.

moped-all-720

The first version of Moped was built with the DurandalJS framework and I’ve built another version with Angular. These two JavaScript frameworks are getting a lot of attention these days (Durandal especially among .NET developers) and are very alike feature-wise. Of course, building the same application twice is  pretty dumb, but at least I learned a lot and it makes up for a nice comparison. The code of both versions can be found at GitHub: https://github.com/martijnboland/moped/tree/master/angular for the Angular version and https://github.com/martijnboland/moped/tree/master/durandal. Oh and before you ask: I’m not going to do an Ember or Backbone version ;-).

Getting started

I’ll put this simply: Angular is easier to get started with than Durandal. There are no dependencies, almost no ceremony. Just a single .js file and a massive amount of tutorials on the web.
BUT: while Durandal might be a little bit more complex to setup, it does a better job of leading developers into to the pit of success by choosing sensible defaults and conventions that scale better when your projects grows in size. With Angular it’s surely possible to choose a structure that scales well but most examples are pretty naïve and are only suited for small apps that will likely grow into big mess.

Data binding

Both Durandal and Angular support two-way data binding of JavaScript objects with HTML elements, but they use a different technique. Durandal uses KnockoutJS for binding and Angular has its own binding system. See this post by John Papa for a more in-depth comparison.
I think, from a development perspective, the Angular way is superior to Durandal. The binding syntax is cleaner and easier to learn and you don’t have to deal with observables. People often warn that the Angular way of binding is slow with many bound elements, but I didn’t notice that up until a couple of thousand bound elements.

Code size

The amount of lines of code that you have to write don’t say all that much, but we’re all lazy developers aren’t we? Well, the Angular version of Moped has 1200 lines of JavaScript and the Durandal version 1030. The difference is mainly because the Angular version has some unit tests and the Durandal version has none (yes, shame on me).

Testing

Angular makes testing so easy that it’s almost impossible to not do it. Even the simplest tutorials already show how to test. I wouldn’t say that testing with Durandal is that hard, but it’s a different ball game.

Documentation & examples

Official Angular docs are great and official Durandal docs are great.
Angular has one problem however: there are many articles and blog posts that can be considered either outdated or simply not so good. Be careful and always check post dates and comments.

Community / momentum

No doubt, Angular is the no. 1 JavaScript framework of the moment in terms of users/followers. The Durandal community is much smaller and seems to be populated mainly by (former) .NET developers. This isn’t bad per se. The discussions and answers in the Google Groups for both platforms mainly differ in volume and not so much in quality. If you’re a fan of 3rd party plugins however, you’ll find that the smaller Durandal community results in way less plugins (even with the available KnockoutJS plugins).

And the winner is…

There is no clear winner. Technically both frameworks are equally capable with only relatively small differences left and right.

My pick at this moment would be Angular. For me, it has a few edges over Durandal that are mostly related to personal preferences but I also find the small community of Durandal and the fact that it is developed by only one person a little bit worrying. We’ll have to see what future brings.

However, at the time of writing, Durandal runs a kickstarter campaign to fund the next generation of the framework. I really hope that this next generation of Durandal is going to kick the butts of all the other frameworks. The plans look promising and I think that Google doesn’t need another monopoly with Angular.

Opinions? Please leave a comment.

Moped: a web client for the Mopidy music server

piA little while ago, I treated myself on a Raspberry PI with the goal to make it a music server for our living room that can be operated from a phone, tablet or PC.

There are several audio software solutions for the PI and one of these, Mopidy, promised to do exactly what I wanted. It’s a server that plays audio and it can be configured with a lot of backend and frontend options. Currently I use it to play Spotify music and radio streams.

The only issue I had was that none of the available HTTP clients worked exactly the way I’d like. A quick peek in the source code of one of the clients revealed that it wasn’t really complex at all, so why not build a new client?

This proved to be an ideal situation to experiment with client side JavaScript frameworks. Mopidy comes with a nice Web Sockets interface and a JavaScript library that handles all communication, so I could purely focus on the client itself.

For a first version, I picked the Durandal framework because it appears to have quite some traction amongst .NET developers and I was just curious to see if it fits my development style. Also, Bootstrap 3 is being used because it has excellent support for responsive web apps.

A few weeks later and the first version is now on GitHub. I’ve planned to also build an Angular version because that’s my other weapon of choice nowadays and I think it makes up for a nice comparison.

moped-all-720