Ask HN: Node vs. .NET Core (2024 edition)
This same question was asked back when .NET Core was released in 2016.
https://news.ycombinator.com/item?id=13034904
How are things looking now after 8 years?
https://news.ycombinator.com/item?id=13034904
How are things looking now after 8 years?
When I was starting a new project a couple of years back, I went with .NET 6 and never looked back. The Core branch (and subsequent versions) fixed a lot of the issues I had with the original .NET Framework. Happily developing with VSCode on a Mac and deploying to ARM-based Linux instances in AWS. To the original question, the only right answer is you should pick what you know unless there is some overriding reason (e.g. performance). When building a backend API, I'd personally pick C# over JS all day.
The developer experience is a lot better for .net, in my opinion, but it’s also expensive and usually requires windows (yes, Linux .net is completely possible). Microsoft invests heavily into building better, easier tooling from end to end. If you are an azure shop, it’s very easy to deploy.
I haven’t looked at the latest benchmarks, but when I did, c# was a clear winner in performance, multithreading, etc. nodejs isn’t slow by any means, either.
Nodejs excels at speed of development and in BFF patterns like next or other SSG. .net will steer you into better design patterns for maintainability in the future. There are also more gotchas around nodejs which is mostly due to the funkiness of JavaScript.
It’s quite nice if you use nodejs backend and frontend. It’s one language and if you use typescript you can share types!
Bottom line, there are tradeoffs to both. I would be more concerned about your team composition, skill set, and project type when picking between them.
If you held a hun to my head, I’d pick .net
Can you please clarify what exactly is expensive and requires windows as far as .net is concerned?
Compared to 2016 the development and hosting experience for at least Linux (can't speak to Macs) has gone forward by a country mile. You can develop practically for free (no need to visual studio license since vs code exists) and target Linux environments during build so no need for windows server either.
The experience isn’t as good in vscode (I haven’t used rider, but it costs money anyway, so still expensive) as it is in full fat visual studio.
At work, I use windows and full visual studio. At home, I use Linux and vscode.
Also, Rider is free if you apply for an OSS license (if you use it for FOSS), or have your company pay for it if you use it professionally.
While the former may be missed by some, I long ago adapted and prefer to normal folder and file navigation, and for the latter there are other extensions to browser the tests. The ability to run/debug specific tests is already included in the base C# extension, while project management is actually easier via CLI the same way you do it with Rust's cargo (dotnet new {templateName}, dotnet new sln, dotnet sln add/remove, etc.).
[0] https://marketplace.visualstudio.com/items?itemName=ms-dotne...
The OP states this is intended as an update to a 2016 question, but the responses are largely stuck pre-2016, full of nonsense complaints that haven't been true for the better part of a decade (including imagined OS dependent lock-in, imagined lack of CLI based tools, and etc).
The .NET Core variant doesn't even exist anymore, and hasn't since 2020. It's just .NET, after a difficult planned multi-year effort that .NET core was a part of, to unify into a single cross platform .NET
That's a good point and sorry for the mistake.
In my defense I copied and pasted the title from the previous question and I don't know much about .NET in general.
You were asking the original question. It's reasonable to ask a question and not know the answer. We can, however, expect better of those who write in with answers.
Examples of major considerations are security vulnerabilities and dependency hell (both solved long ago in .NET), performance and memory footprint (the average expected difference in application code performance is >10x), and ability to reach performance ceiling with additional optimization, supported deployment targets, the quality of the languages themselves (C# and F#), interop with C/C++/Rust, IDE support, static typing, quality of the libraries in the ecosystem (fewer but much better), etc.
In 2024, if you use TypeScript (strict mode) with Bun, Biome, and tRPC, you can get excellent types, a great toolchain, and all configurations become straightforward. Dependency installation is very fast, and you no longer need to worry about package managers; packaging and compilation are also simplified. Moreover, in the software industry downturn of 2024, we're most likely all full-stack developers. We can't escape the fact that JavaScript runs in the browser, and with the above setup, you can effectively share types between the front and back end.
Regarding database types, there's also Prisma or Drizzle (yes, the JavaScript world is always full of wonderful new things). They allow for the convenient creation of fully typed models, and we can easily use 'import type' to share types with the frontend.
I would only use something like Golang or Rust in a self contained service where it solves a single specific problem and my primary apis would be in typescript.
That's how people make millions in profit even running just PHP ;)
I admit, it's probably a skill issue. I've been using Linux distros for the last ~10 years, and am now working with .net codebases.
It works well enough most of the time, but it also eliminates the need to think, so when something doesn't work as expected, ClickOps engineers are lost.
Okay. How about ...
* dotnet new mvc
* dotnet new api
* dotnet new blazor
* dotnet new grpc
I like (and use) Node, but modern DotNet can easily hold it's own.
I see Linux users copy and paste commands into their terminals all the time, sometimes without understanding what they’re doing. How is that different from clicking “next, next, next” in a GUI?
Interacting with a computer using ZSH instead of a GUI isn’t inherently better. It’s just different. Knowing how to run basic shell commands doesn’t tell you anything about a person’s understanding of how computers work.
Plenty of non-technical people can run basic shell commands. It doesn’t mean they understand how virtual memory works, or what DNS is, or how computers store files on disk.
C# is a lower level language that is very accessible but advanced scenarios need the same required reading as e.g. Go which is often misused in systems programming domains.
Front end tooling like Vite does have it but with a Node server you're forced to restart the whole thing (usually with nodemon).
Yeah it's fast too. faster than node. typed etc. but C# is a complicated language. and it keeps adding features. the have awesome tooling in .net world etc.
but you know why javascript / node.js shines. JS is a simple language. of course lisps are simple i.e clojure. but only one other language comes close to the simplicity of javascript -- golang.
but is golang malleable as javascript ?
the only thing that might suck in the js world is tooling. but in terms of server things i.e consume json / transform json which is what informational based applications -- i.e the majority of the apps most of us work in. node.js is unmatched in terms of productivity
so yeah node.js gets you 80% of the results with 20% of the work.
That's the reason almost everyone has switched to TS and then you lose the malleability and simplicity of JS. At which point why not just use C#?
types are good ? yeah ... but to a limit. Tests make for better programs than types.
Using values too instead of mutations etc.
Rich Hickey - makes a good point in his the Value of Values talk.
and another point -- someone is gonna mention about node.js libraries being abandoned etc -- I don't know which exactly -- but if you stay in the express ecosystem and create your own middleware instead of just importing everything willy nilly you will go far.
and the major libraries for databases, redis and api stuff have been stable for a long time. Express is still version 4 and has been for a long time.
Countless frameworks in the other language ecosystems have changed a lot since then .net, rails, django etc. new features -- deprecations etc. and you know what has stayed with the same simple API ? Express
Performance is bad. Bad as in all the other frameworks use it as a baseline for their benchmarks lol.
Otherwise, JS is an immediate productivity loss as you cannot trivially refactor the code, a lot of features exist to mimic strong typing (or you just use TypeScript instead), it cannot be directly compared. You use JS when it makes sense, when you have to. Pure back-end is not that situation.
I used to be pretty excited about node. It’s stupidly cheap to get started and deploy anywhere, using one language for front and backend can be a boon for teams that mix junior talent or folks that just want to reduce complexity and maximize reuse, has a low barrier to entry and wide open community, and was surprisingly scrappy in concurrency, pound for pound.
Coming back to node, I’m fucking miserable, to be honest. The headless community has actually become a liability, where the lack of built-in solutions for essential tasks–particularly the toolchain– has led to something worse than design-by-committee, more akin to design-by-vibes or meme, because the core group is painfully behind the needs of the community and tends to fracture (see bun, demo, etc) rather than evolve. We can’t even decide on a god damned package manager, and all of them are a dumpster fire. Meanwhile your project’s dependency tree is a katamari ball of potential supply chain vectors or abandonware, and all you’ve done is fucking boilerplate a project! Which by the way, will break sometime in the near future and require you to painfully hand roll it back up or go through the expensive and arduous task of replacing.
So, about dotnet. I think the toolchain is good. The core libraries get you most of the way there. You can run it inexpensively almost anywhere these days. C# isn’t perfect but it’s a damned good OOP language. You can squeeze a lot of performance out of it, but even the default, basic approaches will get you far. I worry about the ecosystem as I’m not sure it’s as competitive or desirable as the competition, and I don’t feel great about Microsoft either. But my team expressed interest in dumping node for it and I would take it in a heartbeat.
I use Go, Node, and C# (also Python, Ruby, and PHP currently) and the correct answer is there is no correct answer.
The closest you can get is to use what you know.
If what you know can't do the job, then presumably having reached that conclusion you're armed with the knowledge of the missing functionality that lets you do a proper technical assessment of the alternatives with your specific use case in mind.
If you’re just building services and you want something that gives you solid computational performance and also runs anywhere you can just use go and solve your customer problems.
Leave the rest to boot camp devs or enterprise sales trapped companies.
What matters is quality and maintainability of code, not brevity of code.
I prefer the expressiveness of C# or Ruby, for example, but do a lot of stuff in Go for the clarity/obviousness of the code and the power of the tooling/libraries/ecosystem.
Basically I agree with everything you said there, but with just one amendment - the baggage in .Net was sort of reset not too many years ago with the introduction of Core, and how much you bring into your codebase/tooling is often a personal choice now (depending upon your project) rather than it being forced on you. For example a .Net API can be very clean, fast, free of cruft, and run anywhere from a single binary. A .Net MVC website less so unless you're careful (though I still prefer Razor over Go's default templating).