4 ms·
What exactly is the point here? If you want to write C#, just use ASP.NET and MVC 4. You will certainly save yourself a lot of headaches, and you can still do
by tomkludy 14y ago
What exactly is the point here? If you want to write C#, just use ASP.NET and MVC 4. You will certainly save yourself a lot of headaches, and you can still do everything async, etc. From what I can tell, the purpose of Node.js is to reduce the number of technologies that a web dev has to use and understand. You already need to use JavaScript on the client side, so using the same thing on the server side allows code reuse, knowledge sharing, etc.
It seems like what the author really wants is ASP.NET on the server, and Script# on the client side. Then the whole stack is C#. Or perhaps he would find TypeScript an acceptable middle-ground on the client. But I don't understand why you would choose Node.js on the server if you hate JavaScript, does not compute.
- erik-kallen 14y agoReason to use Node.js on the server without liking Javascript: I like the framework. Framework != language (or at least it should be).
- davidlumley 14y agoSidenote: Node.js isn't a framework, it's a platform.
- tomkludy 14y agoI'm genuinely curious which feature(s) of node you like better than ASP.NET. I have used both and find them quite similar as far as "raw" capability. ASP.NET however has all of the things you were asking for: great Intellisense, great tooling (for instance integration with Entity Framework), great libraries available (such as SignalR), code in C# or any .NET language (including F#), rich async support... I like node too, but to me, the reason to choose it is either if you want to remain platform-neutral, or if you really like Javascript.
- axefrog 14y agoI would imagine he's referring to the non-blocking IO and evented model. ASP.Net and friends use threads for everything, which allows for heavier processing, but also is more restrictive in terms of concurrency.
- tomkludy 14y agoMVC 4 also allows non-blocking IO. Mark your controller as "async" and use async calls within your controller method. The evented IO model is nice, but nothing earth shattering. Same can again be accomplished with async IO calls, which are trivially easy in .NET 4.5.
- mattmanser 14y agoMVC is actually pretty damn clunky. It has a lot of built-ins which are just frustrating (like IPrincipal, ugh). Also there are loads and loads of weird quirks that pop up as soon as you start trying to do anything like returning JSON. MVC was a huge step forward from the old ASP.Net, but it's still making a lot of frankly odd decisions or suddenly bizarre behaviours in the background (e.g. http://stackoverflow.com/questions/1975983/how-can-i-disable-http-keep-alive-in-asp-net-mvc http://stackoverflow.com/questions/1975983/how-can-i-disable...) I think one of the reasons node.js is so great is that it just cuts out almost everything and gives you direct control over what is returned. MVC still mucks around with everything trying to be 'helpful' as it's really built on ASP.Net in the background. To many of us, javascript is still one of the worst mainstream language around today. Still, why not just make node.cs instead one wonders? Perhaps the existing ecosystem.
- ConstantineXVI 14y agoFWIW, I've found NancyFx[0] fairly non-clunky as far as .NET goes. It's more of an analogue for Sinatra than Node.js, though. [0] https://github.com/NancyFx/Nancy https://github.com/NancyFx/Nancy
- MatthewPhillips 14y agoAgreed, if you're forced to use C#, Nancy at least does it sanely (and RESTfully!).
- deleted 14y ago[deleted]
- tomkludy 14y agoI personally find those "helpful" things to be truly, well, helpful. For example the input validation, anti-forgery token validation, simple cache control, etc. Again, not saying you can't do these things in node. The two technologies can easily accomplish the same goal. But if your primary concern is avoiding JS, why would you choose a technology that is built entirely upon it? Node.cs might make more sense, I agree. I have a feeling the existing ecosystem might bring its own problems with the author's approach, because your C# code may have trouble integrating with those existing libraries, if the underlying generated code does not behave as the Javascript library expects.