Ask HN: Node vs. .NET Core | Hacker News Reader

Ask HN: Node vs. .NET Core

56 pointsprmph60 comments

For a medium-size web SaaS project with a roughly equal mix of computation and IO demands, which of these would you recommend?

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.

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

View on HN

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

Some people would argue that optional static typing (flow/typescript over js style) can be superior because you get the best of both worlds - typing when you need it and no typing where it's not necessary / you need to prototype it quickly.

There is some merit behind it because more often than not, you don't know in advance what class hierarchy you're going to end up with. No typing means faster prototyping and you have flexibility to add it at your own paste.

On the other hand, C# does now have the dynamic keyword.

I agree that discoverability and selection of well-maintained packages is problematic in node (I couldn't compare with .NET core though). But I disagree with you on picking Express as an example of this. I see Express as stable and very well maintained. If by "rotting" you mean "no new feature added", then sure, but I'd consider it a good thing: it is mature and stable, and is used by a lot of people around the world to power pretty demanding apps.

> The JS ecosystem is nowhere near .NET's. And C# is way more enjoyable

Really? This reply looks like a sponsored one. M$ is investing high in content marketing.

Please don't post baseless accusations of shillage. If you don't start posting civilly and substantively we'll have to ban the account again.

Dude, don't get too personal.

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.

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$?

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.

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

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.

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

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.

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.

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.

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.

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.

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

Or Haskell.

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 :-) )

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.

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.

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.

I'm guessing they're referring to the fact that .NET Core is open source and cross platform.

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

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

The code is, but the infra around it was, until recently, pretty slow (and scaled poorly). They can also take advantage of the optimisations in the tcp/ip stack that you get on the linuxes now that it's cross platform :)

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!

technically node and v8 JIT compile JS so the JS is also 'compiled'

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

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.

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 [1] https://www.jetbrains.com/rider/

The public version of Rider is really good.

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.

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

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)

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)

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

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.

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.

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.

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.

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 [1]: https://www.techempower.com/blog/2016/11/16/framework-benchm... [2]: https://github.com/aspnet/KestrelHttpServer/pull/1138 [3]: https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-t... [4]: http://ivanz.com/2016/05/17/farewell-project-json-hello-msbu...

.NET of course.

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

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

Jersey is semi fun to use as well and can run on grizzly and netty, two of the fastest http servers in existence

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

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.

> The project.json is a terrible format

The latest asp.net core templates(shipping with VS 2017 RC) use .csproj files, so you can test them out already.

> On the other hand for .net core many libraries simply do not exist (yet).

This is partly due to MS making such a huge mess out of the ecosystem, going through dnx to dotnet and switching around targets to settle on netstandard. Hopefully things have settled by now and library authors can catch up. There's still one more compatibility snafu to get through with the transition from netstandard 1.6 -> 2.0 and .NET framework versions 4.6.1/4.6.2.

If you suffer from "javascript fatigue", it's best to stay away from .NET Core right now - it is going through the same churn of rapid reinvention. We're using it for some smaller projects and are really happy with where it's going, but it's not been an easy ride.

We know that the new tooling is supposed to solve many problems, but until then we stick to the stable versions as we have no problems with the runtime so far, and got other stuff to work on until then. :)

I saw this thread and searched for ".net core" to read up on it. When I opened one of the results, the first thing I saw after being redirected was a full screen modal asking me to take a survey [0]. It's unlikely you're one of the people maintaining the website, but maybe you know someone or can pass on the message that it's pretty tasteless to show that kind of modal on the first visit. Heck, why would you even ask for someone to complete a survey before they have a chance to try the experience?

[0] https://i.imgur.com/8sDrr6A.png

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

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!)

I keep focused on Java/.NET world (occasionally C++), only using JavaScript on the browser.

Being bigger doesn't mean better quality, in tooling, performance or libraries.

I had a laugh at a Code:dive lighting talk about the amount libraries in npm to create a directory!

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.

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#?

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?

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.

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.

Reply on news.ycombinator.com