3 ms·

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

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.

alkonaut 12y ago
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.
- MichaelGG 12y ago
  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.
  - gedrap 12y ago
    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.
    - Havvy 12y ago
      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.

alkonaut 12y ago

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.

MichaelGG 12y ago
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.
- gedrap 12y ago
  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.
  - Havvy 12y ago
    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.