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).


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.

  • 1
    I look forward to seeing it. Aug 30, 2013 at 4:29
  • 1
    "Reaching the zen state of full asynchronicity has always been the holy grail of server-side developers." Really? I believe it is fad that NodeJS brought and that there is minimal performance gain from going full asynchronous.
    – Euphoric
    Aug 31, 2013 at 11:35
  • @Euphoric It's hard to argue with node's ability to handle massive scale gracefully. Hardly any platform can bear 100K concurrent connections with such a simple implementation
    – talkol
    Aug 31, 2013 at 13:16
  • Related: programmers.stackexchange.com/q/124046 Aug 31, 2013 at 19:07
  • 1
    The fact that it is not synchronous code is the key really. There are certain problems that have been solved with synchronous code ( web servers, in general, but not limited to ) for a good reason. The designers had the choice to use asynchronous code, as they knew all about it, without having to depend on 'compiler magic', but they didn't. Just because there is a new keyword hat makes it a little less treacherous for the common man to dabble in threads doesn't mean asynchronicity suddenly applies to whole new problem domains. Sep 1, 2013 at 17:28

1 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.

  • 1. I meant goodbye JS in server-side, wasn't talking about clients at all. 2. You need an ecosystem where contributors will provide async-enabled code and developers could clearly see what's async and what not. You are correct it's more of an ecosystem, not a framework. 3. Full asynchronicity is defined as none of your code will block and wait for something, not as having 100% async functions. You don't need to make your compute code async.
    – talkol
    Aug 30, 2013 at 10:15
  • 4. Asp.net MVC does not play well if you only use parts of it. It's monolithic and you're expected to use their routing and view engine. It's also inconvenient to pull those out without using the entire thing. 5. I really don't see this thing built on top of MVC. Not all web architectures in the world should be designed as MVC. 6. Did you try to implement an async http asp.net handler in Mono, it isn't really supported currently.
    – talkol
    Aug 30, 2013 at 10:18
  • 3. Every synchronous method blocks. It may only block for a few milliseconds, but it still blocks. 4, 5 and 6: Nothing is stopping you from writing a Node.JS workalike in C#. Aug 30, 2013 at 17:14
  • @talkol I think it is unwise of you to be mocking node.js fanboys, since your question and comments make you sound very much like the C# version.
    – itsbruce
    Aug 31, 2013 at 12:07
  • @itsbruce By any means I did not mean to mock node.js or its fans, sorry if it somehow came out looking like I was. If anything, my proposal to do something similar in C# shows my admiration to its design
    – talkol
    Aug 31, 2013 at 13:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.