Why use NancyFX?
blog.jonathanchannon.com
blog.jonathanchannon.com
But, I am resistant to invest much in NancyFX. I can't see where it fits in the enterprise world where most .NET devs live. With 4 choices already (WebForms, MVC, Web API, WCF) for developing sites/apps/services, I just don't have a good story for inserting Nancy into the mix.
My primary goal, in developing for enterprise, after meeting customer requirements, is to build things that are simple to maintain and can be picked up easily by any other .NET developer. I loathe custom/in-house frameworks for that reason and while NancyFX has a strong community as far as I can tell, there's no guarantee that community won't tire and move along.
I'll keep an eye on it, but for now, skipping over it.
There is no guarantee that MS won't tire and move along either. At least with OSS like Nancy, you don't have to worry about MS sunsetting a product your company relies on. You can continue to develop it long after the project has died.
The various hosting options also means that we can easily host Nancy from inside a console app or Windows services. Now anything can have a REST API. Who needs WCF?
Bonus point: We followed Nancy's example of using rake on Windows and now we're doubly happy. Rake and Albacore have revolutionised our Windows build process.
The bad: getting a consistent convention for setting up your response methods has been some work, as there are so many ways to make one. Routes are EXTREMELY extensible, so you end up trying to do things you probably shouldn't. Lots of dynamics (at least the way we use it), and the dynamic type has a lot of side effects.