From those two I would rather go for .NET core. But as this still is a work in progress and much more brittle than the .NET world was before you might also look

From those two I would rather go for .NET core. But as this still is a work in progress and much more brittle than the .NET world was before you might also look into a more stable ecosystem if your projects and time planning require that. JVM based stuff or even Go might fulfill that. I think .NET core will be great in a year, but up to then still some work needs to be done which might cause some trouble for early adopters: The tooling story needs to be finished. Currently .NET core is somehow in a transition phase from old (msbuild old) to intermediate (project.json) to new (msbuild new) tooling, which means several .NET projects all use different tooling. Additionally lots of libraries on the .NET ecosystem might not yet be compatible with .NET core. But I guess most are moving in that direction and will be there sooner or later. I worked a little bit with node.js and got the following impressions: The node.js core libraries work well and are mostly good to work with. If you use typescript on top the language is actually really good - I even prefer some things to C#. Tooling is so-so. There are lots of good tools, but there are also dozens of them. It takes quite some time to discover which ones work for you and your team. Most other ecosystems provide much more streamlined solutions for builds and other tasks. The reason why I would personally not favor node is it's ecosystem. It's gigantic and consists of lots of very small modules. You often end up with dozens of dependencies in a project for even the smallest things. Lots of libraries on the ecosystem are of poor quality - however this is nothing special to node but it's the general case for free or non-maintained libraries than float on the internet. However in an ecosystem of lots of tiny libraries it's much more likely that one of those things accidentally slips into your product and will cause you headaches. If you build an end product you also often want to have a good overview on what libraries end up in your product, and what is their version, quality and licensing situation. You might even want to have a self-hosted or forked version of those to guarantee long-life support. This gets much harder the more libraries you have. In the .NET or Java ecosystems you can rely on a bigger and well maintained standard library as well as on more defacto standards (like ASP.NET), which will make this job easier. But they might also get in your way as soon as you want something from which they don't natively support.