Hacker News Reader

Comment by alkonaut | Hacker News Reader

I have been working with .NET for 11 years since 1.0beta (On the same application, i.e. have been continously pushing a massive codebase through every released version of the framework yet!), so to me this so huge. It has felt like I would have to go do Javascript, or go back to java, if I wanted to leave the .NET ecosystem or do something radically different. Not anymore. Feels like not just Windows-based server (asp.net) and desktop (WPF/WinForms) apps are .NET based in the future, but a good chunk of what today is Node.js, Java, Objective-C and so on will be .NET, and hopefully F#, in the future.

If you want a high-level lang runtime with good IDE support, you can just use .NET now. You know, unless you want Ask toolbar.

View on HN

So, you'd rewrite in JavaScript versus dealing with Mono?

Not sure I follow you here, rewrite what?

Sorry my misunderstanding. When you said it sounded like you'd have to go to Java/JavaScript, I thought you meant for the application you've been writing.

Either way, I meant that even before this announcement, Mono was a choice (I use it at fairly high-scale server apps) in many cases. It wasn't C# and Windows or Java for anything else.

Yeah, Mono was at least realistic in the last year(s), but it was always a bit of a guessing game whether something was going to work or not.

Having an official linux/mac os ASP.NET will be huge, even if the functinoal difference is minor compared to Mono. Just knowing it will work tomorrow, and after the next major release is huge.

Yesterday I would rather have chosen Node.js than a .NET solution for a small service on Linux, simply because it's safer. Tomorrow I'll be back to rather having pineapples shoved up my nose than write JS.

Node's like, one of the worst choices, due to the idiotic package manager. They ship essentially every function call as a separate package. It's actually a thing to take a dependency on "sha1" and literally pull in a package just for that one bit.

Using Node/Grunt/Bower to build a straightforward run end site (just to compile static outputs) required npm installing over 13 thousand files. Now imagine on a build server, starting clean, each time? Yeah, it takes a very long time just to download that stuff or do anything with it. Insane.

And at the end of it all, it's just JavaScript on the server, like ASP did in the 90s. With a cumbersome async API. OK.

And then add sometimes not properly defined version dependencies (or developers abusing version numbers a bit) and you have a dependency hell when running npm update -g will almost definitely break something.

I love yeoman, great scaffolding tool, but it depends on so many packages that sometimes it simply doesn't work because some package it depends on did something silly. So once you have a working set up, don't update it if you absolutely must.

That shouldn't be the case in 2014.

You really should not be installing dependencies for anything globally. Instead, add them as dev-dependencies and call them in the package.json `scripts` property. The only npm package you really need installed globally is npm itself, and you can almost always let the package manager handle that for you.

Reply on news.ycombinator.com