
Ask HN: Node vs. .NET Core - prmph
For a medium-size web SaaS project with a roughly equal mix of computation and IO demands, which of these would you recommend?<p>A bit of my background as it relates to the question: I was an MS Web Stack guy for years and years, but I have spent the last few years getting a solid grasp of Node, and I use ES6 and a lot of third-party and custom npm packages and tool-chains. So I have a basic understanding of the pros and cons of the two platforms.<p>However, .NET core seems to be a game changer, and I wonder of anyone with relevant experience can help me update my understanding of the relative strengths and weakness of the platforms
======
aikah
.NET core, no question. NodeJS ecosystem is brittle. Yes there are a lot of
libraries ... mostly unmaintained and low quality. Quantity isn't quality.
.NET core is moving extremely fast and is backed by Microsoft. There is no
debate here. And frankly , do you really want to use a language that is as
weakly typed as Javascript to write mission critical code ? That's madness.
The JS ecosystem is nowhere near .NET's. And C# is way more enjoyable as you
can benefit from static typing and way less verbose than Java.

EDIT: A great thing is that you can directly interact with .NET core
maintainers, which is definitely a plus. They are paid to write the framework
so they are doing this fulltime, unlike people who maintain this or that
nodejs library. Just look at the state of Express for instance... it's just
rotting since TJ abandoned ship. no, NodeJS ecosystem is definitely a mess.

~~~
nikon
I'm a .NET developer, but I think you're missing the point.

JS, while having a (huge) amount of issues documented to death on HN, also has
a huge momentum and community behind it.

It's going to take a while for that to happen for .NET Core. Most people are
are still skeptical of "M$", regardless of how it is now cross platform and
pretty fast.

~~~
roryisok
I wish people would stop it with this M$ nonsense. It's pretty juvenile, and
worse, every time I read it my brain tries to pronounce it. How the hell am I
supposed ot pronounce M$?

------
Todd
I think they each have their place. More and more of what I do involves rich
client work and so I often need Node just to build the client.

For API work, I think .NET is just getting better and better. Now that it's
cross platform with Core, there are fewer impediments to choosing the right
tool for the job.

With my projects it comes down to whether I use MVC for a more server-focused
app or Node for one that's more client-focused. If you do use Node, you have
the option of building universal/isomorphic apps. Of course, it mainly comes
down to how you like to build your server side pieces, and which environment
and ecosystem you prefer.

My current project is mostly MVC (we haven't moved to Core, yet) with a WebAPI
piece, but I still use Node to build our rich client pieces. They're built
with React and TypeScript. This allows us to continue building primarily a
server-side app, while gradually migrating to more of a rich client approach.

The downside with Core is that it's still a work in progress. They've just
released 1.1 but tooling is still not quite there. It might be closer when VS
15/2017 is released. One big piece is their move away from JSON project files
back to a more flexible XML-based csproj model. They should be there soon.
It's just indicative of growing pains.

The other big thing for me is EF7/Core, which is a rewrite of Entity
Framework. There's a lot to look forward to here, but it's not at parity with
EF6. If you're starting a new project, it's probably OK. If you have to
migrate, it could present serious pain. It's the primary reason we haven't
been able to migrate to Core, yet.

Regardless, if you used to use .NET and you haven't tried Core, you absolutely
should. You don't even need VS. You can run VS Code and you can develop on
Win/Mac/Linux/\+ and you have the same choices for deployment. Also, as others
have mentioned, their new Web server, Kestrel is also getting very fast.

~~~
Maarten88
With the aspnet JavaScriptServices package [1], you can have universal apps on
aspnet core. It runs javascript packages from the aspnet runtime, and this
works very well.

There is a yeoman scaffolder that sets up your aspnet core projects with
React, React/Redux, Angular 2 or Knockout, complete with typescript, babel and
webpack hotloading on the frontend. Just do a "dotnet migrate" to migrate to
the project to the new csproj format.

[1]
[https://github.com/aspnet/JavaScriptServices](https://github.com/aspnet/JavaScriptServices)

------
FlorianRappl
It all depends (as usual). For professional projects I would choose .NET Core
over Node.js, however, this is mostly due to the language preference (in my
opinion C#/.NET is much better to scale and test).

That being said I find it troubling that many things are moving and that so
many libraries are yet unported. I wanted to do something with Azure Media
Services - nope; does not work with .NET Core yet. Wanted to do some simple
image manipulation - out of luck again! The search for libraries was a huge
PITA as most of the times when something seemed to be a true fit the support
for .NET Standard was simple not existing.

Plus the most lightweight buildpack still adds 300 MB with a compile time of
some minutes - whereas Node.js only used 50 MB and took 10 seconds. The
startup of a .NET Core application also takes some time. The initial request
is in the seconds range, subsequent requests are, however, faster than with
Node.js.

So even though I would love to use .NET Core for most projects, I can only
recommend it partially right now. Node.js may be better to just spawn some
micro services, where you can easily change to something else once needed.

------
int_19h
Look at the libraries available on either stack covering your project's
domain, and any other scenarios involved.

And I don't just mean look at what's there! Look at how long it has been
there, its version history (stability, major breaking changes etc). What kind
of user feedback there is - look at their bug tracker etc, and search for it
on Stack Overflow. Maybe even skim through their code, and think about what
your attitude towards it would be if it was a PR for _your_ project.

Then decide.

(This approach is generally applicable for any kind of "which
language/framework do I use for X - Y or Z?" question.)

------
cygned
I am managing (as a tech lead) a couple of node projects, ranging from small
apps to projects being developed for more than a year. And although I always
liked node and although I kinda live in JavaScript every day, I am looking
forward to replacing the backend in new projects with something different
(going to use Clojure).

The reason is that the whole JavaScript eco system can be extremely
frustrating. Here a couple of examples:

\- If you install dependencies with npm there's a good chance you have minor
version changes - which would be okay according to semver, but we have two
challenges there: (a) even minor updates can introduce bugs and (b) a lot of
JavaScript developers don't really care about breaking changes that much.

\- Documentation is huge problem. Even good libraries/frameworks often have an
awful documentation and I often have to spend time in third party code finding
out how things should be used

\- Many libraries get abandoned because the developers moved on. That's very
sad. Especially, if there are bug reports pending, open pull requests from
volunteers and so on.

Maybe other eco systems have the same challenges, but that's my current
feeling about node.

------
doublerebel
What is your goal, investment or bootstrapping?

If you're trying to make a POC as fast as possible to get investment, use
whichever language you are fastest in, even if it's not perfect. Be OK with
the idea of throwing it away when you write a better V2 after investment.

If you're planning to bootstrap and need to rely on stability with a very
small team for a long time, choose whichever lang you know best how to make
repeatable success, even if it takes longer.

There's also no reason everything has to be written in the same lang. I'm NOT
saying go full tiny microservices, but use what is efficient where it makes
sense.

E.g. I run a TLS terminator in C (bud), it's one binary and one config file.
My service discovery is Golang (consul), again one binary one config. Think
Unix philosophy, one tool for one job. And if you're using an automatic
services router like Fabio, Envoy, or Traefik, it's super easy to connect
these services regardless of lang. (There really is no equivalent for these in
Node, especially not up to my production standards.)

This pattern has served me well across three startups (inc. medium SaaS) and
countless projects. I'm primarily Node but I would definitely recommend using
.NET where you see it providing a clear solution for one of your concerns.

------
mping
It really depends on what devs are you looking for, location, etc. Some places
have lots of node devs doing freelance, others are more of a Java culture,
etc. Node shines on hitting the ground running, assuming you don't have strong
CPU requirements. Don't know much about .NET Core, but I assume its ecosystem
is like Java but 10-50x smaller, which means you would be treading unfamiliar
terrain some times.

I guess .NET is enjoying its 15 mins of fame because it targets Linux now, but
they will eventually have to catch up with the competition (debugging, build
tools, etc).

If you have legroom, .NET can be fun (I think the language is great), but if
its a "serious" project I'd go with the JVM. You will waste less time with all
the stuff around deploying an app and focus more on business.

------
scandox
Interesting how little love there is for JS here. Is this a trend or a case of
a vocal (large) minority vs a quiet majority? It's a genuine question because
most of my choices are based on the level of support and popularity a
language/ecosystem is likely to have over the next 5 years.

Given that basis and given that JS is in the browser, it always seemed to me
that there couldn't be a safer choice.

~~~
douche
JS is the lowest-common-denominator. Everybody at least kind of knows it,
because you don't have any better option if you want to do anything in a
browser (Even if you transpile, you end up having to know JS to figure out how
to configure your transpilers and build process, and drop down to debug the
emitted code). So there's a lot bigger pool of people that "understand" and
can do JS than for possibly any other language these days. Maybe Java is
bigger still, but I wouldn't be surprised if it's not.

That doesn't mean it's good, or that you'd want to use it if you didn't have
to and had other options.

------
pabloski
"For a medium-size web SaaS project with a roughly equal mix of computation
and IO demands"...if you aren't forced to choose between these two, try
Golang.

~~~
LeonidasXIV
Or Haskell.

------
bruce_one
Do you "enjoy" one more than the other?

(I recently realised how important that is to me, so I'd posit that it may not
be worth underestimating as part of the equation :-) )

~~~
billpg
I tried learning PHP some time ago, back when it was pretty much the only
choice for cheap web-hosts. I stopped when I realized that life is way too
short for PHP.

------
zihotki
I would bet all my money on .NET Core. I'm also .net dev with many years of
experience and was quite skeptical about the platform last years, but since
birth .NET Core, since they bought Xamarin and Mono, went from closed source
to open source model, went to Linux, did amazing job on performance and
stability of .NET Core I see that the future of the core is very bright. It's
not mature now but good enough for many project, IMO.

------
TheOsiris
I'm curious why you think .NET core is a "game changer". I used to be a .net
guy for years as well but I haven't been keeping up as of late.

~~~
pnsn
Also according to some benchmarks net core os the fastest "mainstream
framework" beating node 4x.

~~~
ryan-allen
Without even looking at benchmarks it'd have to be faster because it's
compiled, right?

~~~
hudo
its mostly web server benchmark (Kestrel in .net case). So receiving bytes by
OS kernel driver, passing them to http server, then to the app, app replies
with simple response. Not so relevant to most of us IMHO, since our app code
is like 10000x slower than web server can handle, but nice to see .net in
first 10:) By looking at computation speed (chess engine?), i would say c#
beats Js easily there (should be on-par with Java, but Java has some neat
tricks in JIT and can be faster in same cases).

But definitely new .net core feels so much snappier than full fx. Im currently
porting few apps (they are simple, no big libs), and so far everything works
fine. It took me awhile to catch up with MS changes, since they're iterating
little bit to fast... Using full vs 2015 update 2 + r#, and little bit of vs
code on ubuntu (r# is still huge productivity booster, i can't switch to vs
code yet). Also waiting for Jetbrains Rider, which will bring r# to all
platforms!

------
salex89
Sorry for the hijack, but what's the state of .NET Core development on Linux?
I'm dominantly a Java/Scala dev (although using other langauges) and I'm kinda
used to working on Linux...

~~~
kodfodrasz
It should work with VS Code, if you use a supported distro. Having tried
dotnet on Fedora (unsupported) it did not work. It works OK in docker
containers, but then you don't have debugging... I think the next stable
release iwth new tooling and more supported distros will improve it greatly.

~~~
Kipters
It's supported now [0]

If you're used to JetBrains tools, there's also their Rider EAP [1]

[0]
[https://www.microsoft.com/net/core#linuxfedora](https://www.microsoft.com/net/core#linuxfedora)
[1] [https://www.jetbrains.com/rider/](https://www.jetbrains.com/rider/)

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

------
rpeden
The correct answer might be _both_.

There's a really nice ASP.NET Core SPA Service plugin[1]. Basically, it
handles integration between ASP.NET Core and Node/Webpack/React or Angular 2
so that when you run your application from Visual Studio or the .NET CLI, you
also get React/Angular server side pre-rendering, hot module reloading, and
server/client side route syncing that mostly just works.

[1][https://github.com/aspnet/JavaScriptServices/tree/dev/src/Mi...](https://github.com/aspnet/JavaScriptServices/tree/dev/src/Microsoft.AspNetCore.SpaServices)

------
mmgutz
I would pick node simply because it is more mature. How good is the Postgres
.NET Core package for example? Last I checked it was still being worked on
(with good progress though).

For me it's not about .NET Core vs node but how good is it on the platform I
use. I'm still not seeing any real evidence that people are using .NET on
Linux with non SQL Serer databases for moderate trafficked sites. I need to
see proof that the new .NET stuff is on par with the JVM or node for stability
on other platforms than Windows. (been down the mono/xsp path before)

------
richmarr
Personally I find Node easier to move fast with, so for me it can be a good
fit in immature markets before product-market fit. On the other hand it can be
a pain to deal with memory leaks & handling errors cleanly and in isolation,
so maintenance can be a pain. In more mature markets with less product churn
required to reach stability .NET might work better

Another thing to take into account is how likely you are to hire a team around
it, and what skills are more easily available where you are (or remotely if
you like)

------
big_paps
If the computation-part should run server-side, definitely use .net

------
rmanolis
I would recommend Golang. It is faster than Node.js and lighter on the memory
footprint than C#. Easy to learn, with types and good documentation. And it
has the libraries for a medium size project. Actually on my projects I use
only 3 languages. Golang, Python(Django) for server side stuff and Javascript
for front-end.

~~~
nikon
It's easy to learn, but coming from C# it's painful. You're constantly
Googling where is X and Y in Golang. Eventually I think you either gel with it
or become frustrated and ditch it.

------
evolighting
When I learn node, it looks strange in many aspect. I always wander why not
using then in browsers, leaving only the IO part on the server?

BTW,I'm asking a question, not providing advice. I know there are APIs and
Copyright Protection issue and so on. But when comes to general，they are just
javascript, even with the same engine.

------
herbert_B
I'd go for a Java based language in the first place. It's been available on
all the major platforms for years, and the community is huge. Dot net core
isn't. That said, I would probably avoid Node because I tend to dislike coding
in JS. But that's a personal preference, of course.

------
skun
Full disclosure: We [0] have been a .NET/Windows house since the product was
launched 8 years ago.

When RC1 of .NET core was announced, we jumped on it (in spite of all the
limitations that it came with) and haven't been disappointed. We've been
working on a product whose pilot version handled to the tune of 40K requests
in a day on a 1GB/1Core Linode box

\---

As far as choice of platform goes, it all comes down to a few factors for me

1\. What the team is comfortable with:

    
    
        This is *crucial* and in retrospect it is the biggest contributing factor
        that helped us take our next product to production -- fast. If you have a
        team that is comfortable with .NET then just go for it. Everything else can
        be figured out later.
    

2\. What the ecosystem is like:

    
    
        If you have a fair idea of what you're building out, scout the ecosystem
        and see if it offers everything that you need. We more or less found
        everything that we needed except a good Excel wrangling library.
    

\---

Also I feel the .NET core VS Node question is skewed because comparatively,
Node is a platform that has been around for _much_ longer and has _much_
bigger adoption.

Keeping this in mind, there will definitely be problems with .NET Core. Eg: If
you're looking to reference a class library that is running with the full
framework then you'll be hitting a few hurdles and stoppers.

The good part however is that it is constantly under work and we're able to
actually see the performance improvements. [1][2]

The bad part however is that it is constantly under work so expect flux.
[3][4]

\---

Experience wise, its been great working with .NET Core. Projects like VS Code
make it a breeze. To me, C# has always been a well architected, beautiful
language and now I'm able to write it in the way I want to -- without using a
bloated IDE like Visual Studio and run it where I want to -- On cheap linux
boxes without worrying about licensing costing.

For us at Logic Soft, .NET core really was a lifesaver when our next logical
transition was the web and we were a .NET house shipping software on windows
:)

Footnotes: [0]: [http://logicsoft.co.in](http://logicsoft.co.in) [1]:
[https://www.techempower.com/blog/2016/11/16/framework-
benchm...](https://www.techempower.com/blog/2016/11/16/framework-benchmarks-
round-13/) [2]:
[https://github.com/aspnet/KestrelHttpServer/pull/1138](https://github.com/aspnet/KestrelHttpServer/pull/1138)
[3]:
[https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-t...](https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-
to-project-json/) [4]: [http://ivanz.com/2016/05/17/farewell-project-json-
hello-msbu...](http://ivanz.com/2016/05/17/farewell-project-json-hello-
msbuild-and-csproj)

------
pjmlp
.NET of course.

I don't see a use for JavaScript outside the browser, unless forced to do so.

------
akerro
.NET. Also take a look at Spring-Boot, recent releases made me feel like whole
new Java came out.

~~~
mobiuscog
Spring-Boot as long as you don't mind the required voodoo necessary for stack
traces for when things go wrong ;)

------
kodfodrasz
I'm working on a .Net Core project currently. I'd definitely go with .Net
Core, but it has quite some problems currently.

We do integration tests with mocha/chai on node and that is just about as much
untyped js as a project can take imho. For node there are a gazillion of
libraries (i mean frameworks ) but so many are lacking in quality for so
simple stuff what you take for granted in the .net world that choosing the
right one slows us down.

On the other hand for .net core many libraries simply do not exist (yet).
Regular .net stuff wasn't ported, and imho it won't be done until the next
tooling arrives. The tooling is the second con, and will be until 2017q2. The
project.json is a terrible format, the visual studio tooling is lacking,
incompatible, and is slowing ua down. The tooling has some nice ideas but is
too rough around the edges. Debuggning has some inconveniences sometimes, but
generally works. Clean does not clean the solution properly. No complaints
when a file was open and could not be replaced, shows build as success, then
you hunt phantom bugs because of this... Not as mature development experience
as with java/full .net 4.5

We have bet on core getting there, but expect inconveniences until then.

~~~
olalonde
> many are lacking in quality for so simple stuff what you take for granted in
> the .net world that choosing the right one slows us down

Do you have some examples? I was under the impression that the
JavaScript/Node.js ecosystem was bigger, but maybe that's the HN bubble.

~~~
kodfodrasz
The ecosystem is big. Too big, you spend almost as much time trying to find
the right tool as it takes to do it from ground up.

My example: I needed to work with dates. Under .Net the DateTime and TimeSpan
types do this pretty well, and under Java 8 it is also well solved.

Under JavaScript this is not so clean. I found the moments library to work
well, but had some tries before. With one when I tried the example code from
the homepage I received Nan/NaN/NaN NaN:NaN:NaN as a string representation for
a valid date :D This is a thing which is "trivial" (you expect it to be there,
and be solved) and you expect it to just work if not socialized in the JS
world. Surely I'll encounter other such things, even as we use JS only for
integration tests.

Also the Java/.Net ecosystem is also big, but does not completely overlap with
the JS world, and stuff doesn't get reimplemented so often. (JS attiute in the
HN bubble: This library had no release and no tweets in 2 weeks. The project
is dead! have to rewrite from ground up!)

------
douche
Given the option, I would pick .NET in a heartbeat. Of course, I am a .NET guy
anyway, and generally loathe JavaScript and the whole Node clusterfuck to
start with.

I really like having a static type system, that assists my static analysis and
refactoring tools like those built into VS or ReSharper's. Even better when I
can use F#, so I have access to an even stronger type system. I get so
irritated when a stupid typo that would be caught by the compiler, results, in
JS, in trying to access something undefined and crashing. Consequently, I am
much more productive and faster working in C# than JS.

In general, I find the situation with NuGet packages vs Node packages far more
sane. .NET has a workable standard library built in, and has not really
embraced the idea of micro-assemblies containing a single type or function,
and so typically .NET assemblies encompass a larger scope, and have less
version churn, and more backwards compatibility. In a typical .NET project, I
might reference a dozen NuGet packages. In a typical Node project, NPM pulls
down hundreds of megabytes of slightly different versions of 100 different
micro-libraries, nested dozens of layers deep in the filesystem - usually I'll
have four or five different point releases of lodash or underscore as
dependencies of dependencies of dependencies. Not to mention all of the things
on the order of left-pad.

~~~
h_r
I'm mainly a Java programmer here but I like F# a lot. Are there any problems
using only F# with .NET Core apps? Do you really _need_ to use C#?

------
meira
Why do .NET Core seems to be a game changer? M$ is nowhere near to be a game
changer in anything, imo.

EDIT: no reply, a lot of downvotes. A lot of people love it, nobody use?

~~~
vorotato
I think nobody replied because it was a low content critique without any
explanation. Keep in mind your assumptions aren't other people's, so you might
need to explain why you think M$ is nowhere near to being a game changer in
anything. If you don't explain yourself I don't see why anyone should try to
explain why they think .NET Core seems to be a game changer.

------
throwbsidbdk
Node is for hipsters and JavaScript is a terrible language even now. Exception
handling, threading, build tooling, modularity, debugging, profiling, standard
library support.... Almost every metric I can think of is awful in js compared
to .NET and Java world. Most of the devs saying how great js is don't know
many other languages.

Rant aside, if you have any computational demand stay far away from js. Lack
of threading support absolutely kills performance. The hacky alternatives are
terribly slow, like using redis to share state between processes. Js is also
still about ~10x slower than .Net or Java (and runs a single thread) which
matters in hardware cost at scale. The only strength of node is the ability to
run pages on the server. Great for server side rendering and testing, a step
backwards for everything else.

That said, I would avoid .net core for now as well. We tried using it but it
required us to abandon too many of our mainstay libraries and tools to be
productive. Many parts of the standard libraries that you and other libraries
rely on no longer exist. MS is working on this but for now I would definitely
stick with regular .net.

Arguably best stacks for most use cases are Java (Spring boot or Jersey) and
.net MVC using WebAPI. Plus Angular or whatever crazy shit you want for the
frontend. Not exciting but extremely practical, well tested, well understood.

