Not more than month ago when this project was announced people were praising it. (No wonder, it features a fairly complete subset of C# - it's free and open source, it works and it's great - mad props to the creator keep up the good work!)
Now when the author presents a use case people are throwing rocks. (At least this is my impression by reading some of the comments).
I don't know about you, but I feel bad about it. It's the same story everytime a topic of compiling to JS is brought up. The JS "crowd" steps in with their "wisdom" of why it's a bad idea to do "X" and all they do is criticize...
Writing node.js applications in C#
31–38 of 38 posts
Re: Writing node.js applications in C#
#32Earlier quoted context omitted.
MVC 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/q…
can you elaborate on the quirks around returning JSON with asp.net MVC? its a pretty common usecase.
The biggest thing I can think of is how it defaults to throwing an exception when attempting to return JSON for a GET request. You could disable this easily enough, but I never understood the rationale behind the decision, and it was a momentary frustration every single time. Hopefully they've changed that in MVC 4.
Re: Writing node.js applications in C#
#33When I read about Node.js, the first selling point people mention is how you can reuse code on the client and server sides. For me, the main selling point is that it's Javascript. When I see new variants of js, developed to "fix" js, it makes me want to cry.
Currently, reusing code on client and server is far from the first selling point. Companies like Meteor and Groupon are pushing in that direction quite heavily, but for mere mortals it's still limited to reusing a few core libraries like underscore, async or templating. Reusing experience and knowledge, and reducing the cost of context switching, those are very clear and positive advantages. On the topic of sharing c…
Thanks for the "pipe dream" link, I found the conference talk on youtube and enjoyed it a lot. The reusable code 'function' of node is still too non-obvious to achieve without the right mix of tools and this talk gave a nice intro for a solution.
Re: Writing node.js applications in C#
#34Earlier quoted context omitted.
I'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…
I 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.
MVC 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.
Re: Writing node.js applications in C#
#35Earlier quoted context omitted.
can you elaborate on the quirks around returning JSON with asp.net MVC? its a pretty common usecase.
The biggest thing I can think of is how it defaults to throwing an exception when attempting to return JSON for a GET request. You could disable this easily enough, but I never understood the rationale behind the decision, and it was a momentary frustration every single time . Hopefully they've changed that in MVC 4.
There is an exploit made possible by returning 'unwrapped' json in response to GET's. This details it fairly nicely: http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-js...
Re: Writing node.js applications in C#
#36Earlier quoted context omitted.
There's a load of little things that are gotchas, but an example that pops into my head is that it wasn't compatible with default jQuery for example. If you didn't ask specifically for a content-type of application/json, which jQuery didn't by default, it would throw a hissy fit. It meant mucking around with the ajax object meaning you couldn't use certain jQuery shortcut methods. Regardless of what you 'told' MVC to…
By default MVC 4 will return JSON so you don't need to specify the content-type unless you want something that isn't JSON.
It's not the return type, it was the request type. It didn't like if you requested it with plain/text instead of application/json. Which was jQuery's json method's default.
Re: Writing node.js applications in C#
#37Earlier quoted context omitted.
By default MVC 4 will return JSON so you don't need to specify the content-type unless you want something that isn't JSON.
It's not the return type, it was the request type. It didn't like if you requested it with plain/text instead of application/json. Which was jQuery's json method's default.
plain/text gives you JSON in MVC 4. I understood what you were saying, the default in MVC 4 is now to return JSON unless you specify otherwise.
Re: Writing node.js applications in C#
#38Earlier quoted context omitted.
It's not the return type, it was the request type. It didn't like if you requested it with plain/text instead of application/json. Which was jQuery's json method's default.
plain/text gives you JSON in MVC 4. I understood what you were saying, the default in MVC 4 is now to return JSON unless you specify otherwise.
Yeah, but this is my whole point. Finally in version 4 they stop mucking around with the requests before they give it to you. Someone, somewhere in the depths of MS clearly believe they understand HTTP better than you do. And keep guessing what you really 'meant'.
Even though they quite clearly don't understand and actually really don't get HTTP. For example take the fact that it's nigh impossible to get the actual request body in ASP.Net. Who's bright idea was that?
In reality every single interface, every single framework they've produced so far has shown a woeful lack of understanding about the web in general and pretty much how it's used outside their world. And I say this as someone who's primarily programmed in VBScript, VB6, C#, Silverlight, ASP.Net and ASP.Net MVC.
I keep almost jumping ship and then they just kinda fix it and I stick around hoping they're not going to make the same mistakes. But they do, jeesus, MVCs ajax stuff is unsurprisingly fucking awful.
But that's the problem with MVC and anything MS led, they don't get the web, they don't get javascript, they keep making incredibly silly decisions.
A good example. Every time I hear 'unobtrusive' js, I just want to scream. They're the cause of this made up problem. No-one else was doing js like that in 2010, no-one else needed unobtrusive javascript. Just MS. There's no such thing as unobtrusive javascript, there's just not writing idiotic magic code like a fucking retard like MS constantly do when it comes to javascript.
And don't even get me started on their 'web services' or WCF. Both deserve to die in a fire.
TL;DR; I love C#, think it's the best language available today by far. I hate asp.net though.