Do we need even more web frameworks in C# now that async await is here

Question

Developing endless frameworks for web application, websites and web services is always great fun. It's one of the richest areas where you have 100 different ways of achieving pretty much the same thing.

Even with all this abundance, I've recently managed to find myself missing a web framework in C#.

I feel that the new async-await API of C# 5.0 is really going to change the way server-side code is written. Reaching the zen state of full asynchronicity has always been the holy grail of server-side developers. But it always was too complicated and took too much code. Shamefully, 90% of the web frameworks in the world are still blocking. That's why I think node.js became so popular - it offers cheap asynchronicity.

But now, with async-await, C# is going to steal the show and become the new "asynchronous wonder child". Goodbye JS (in server-side, don't get pissed off). At least that's the case for me, C# just became sexy.

Does this new era call for a new generation of web frameworks?

I'm missing a web framework, or more of a web ecosystem in C# that's reminiscent of node.js Something like node.cs. It's fundamental principals:

• Promise of full asynchronicity. Every package in the ecosystem must offer async-await API. I can't even imagine anymore accessing a DB and blocking when doing it. In addition, the core itself should be built around async interfaces - with flows looking like this.

• Package-based and modular. C# is notorious for having bloated monolithic web frameworks. I want to mix and match. I want a choice between 10 view engines (written by 10 different people), and a choice between 10 routing engines. These things should not be part of the core.

• Lean and concise code. I'm sorry but frameworks in C# never seem agile. Everything is always so overfeatured. Layers and layers of abstractions until you have no idea what's really going on. Don't get me wrong, those huge frameworks are good for many things, just not everything.

• Reduce vendor-lock. I'll be nice to offer hosting alternatives to IIS. Maybe come with its own optional async web server like node. Although IIS should be supported as well. Mono support on Linux is important, with async integrations to nginx and friends.

I haven't been able to find an ecosystem with these characteristics. If it existed, it would draw developers towards the great benefits hidden inside the async-await pattern.. that is unique to C# (in production at least).

Edit:

Sorry my question wasn't clear. I'm asking:

1. Are you familiar with an existing solution that fits my requirements?

2. If not, do you think it's something worth writing? Do you find it useful? Would you use it as an alternative to the currently available web frameworks in C#?

3. What critiques and praises do you have for the proposals listed above if I were to create a framework that addresses said proposals.

Answer 1

1. "Goodbye JS"... Really? C# is a server-side language. The appearance of async in C# is not going to affect client-side languages and frameworks like Javascript at all (except that calls Javascript makes to the server will return faster).

2. "Does this new era call for a new generation of web frameworks?" The beauty of async is that you can use it anywhere server-side; it doesn't require framework support, nor do you need a special framework to use it. You can make any C# method asynchronous, just by changing the code and return type a little bit.

3. You don't need full asynchronicity. You only need to make asynchronous those long-running methods that are blocking your users. By that metric, you will find that only about 10% of your methods will need to be made asynchronous.

4. While the .NET Framework Class Library may seem bloated to you, you don't have to use all of it, or even any of it (well, except for the part that makes ASP.NET and ASP.NET MVC work). Use only what you need. Code the rest yourself.

5. "Layers and layers of abstractions." Then come up with your own design for your business domain. Nothing prevents you from doing that. ASP.NET MVC is already fairly lightweight, and it is both extensible and configurable to your liking.

6. Vendor lock: You don't have to use Microsoft's IIS or their compilers; you can use Mono instead.