Ten years ago I stepped away from the Microsoft ecosystem, in large part due to said ecosystem drifting away from industry best practices at the time, and also a conservative development culture formed around this ecosystem that did not want to acknowledge the outside world. So if I were starting a new project eight years ago, .NET would've been one of the last technologies I would've picked, despite big love for C#.
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.
> but it’s also expensive and usually requires windows
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.
Yes, you can use vscode and rider. Rider isn’t free for companies and vscode has some free stuff, but Microsoft came out with a new extension for c# that requires a visual studio subscription. To me, this signals they will be directing the majority of their investment into this, rather than a free extension.
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.
The description is somewhat misleading but it comes down to 1. Visual Studio style solution explorer and 2. Visual Studio style tests explorer [0]
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.).
It's amazing how uninformed the comments are on the .NET ecosystem as of the time of this comment.
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
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.
Unless you use server-side rendering or JS-only dependency, in which case you do need Node.js, its usage cannot be justified as it is a massive downgrade in every way vs .NET (ASP.NET Core + EF Core/Dapper combo).
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.
A lot of people still have a negative opinion on .NET and C# where in fact it's probably the most productive combo and bang for your buck ever made when it comes to the quality of the actual framework, capabilities of the C# language (and to extent the other CLR languages like F#) and tooling. It checks all three boxes. There have been massive improvements in both support and new features after .NET Core came into being. Some people even say that they've been adding too much too fast recently. I don't know how it compares to Java and Go which seem to be the main competitors in that niche (not taking JS/Python/Ruby/PHP etc. into account), but I'd probably pick Go rather than Java myself if I had to abandon C#.
Just like the bias against C# we all share, in 2024 we should talk about something new when discussing Node.js. I think Bun should also be part of this conversation. Bun is designed to improve the Developer Experience (DX) in the JavaScript world.
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.
Addition: Learning a language is simple, but becoming skilled in using it and understanding its common ecosystem takes a long time, usually between 6 to 18 months for most people. The ecosystem of front-end applications overlaps significantly with Node.js, which is undeniable. No matter how much you like C#, you can't avoid initiating a front-end project that includes Node.js. Therefore, you end up managing both Node.js and C# ecosystems. Don't mention Blazor to me; in reality, most applications still use React, Angular, or Vue.
I use typescript because every single service that exists releases a first-party typescript or python library. I don't use python because the type system is just not nearly as well supported as typescript. The major problem I have with typescript is that the tooling is terrible but python has the same exact problem. For example, the entire node esm / commonjs disaster makes configuring projects extremely painful. Then throw in frameworks like Next.js that have their own custom workarounds to these problems and it's even more fragmented.
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.
I know you're not asking about the personality behind the skills, but I'd sooner take a JS dev than a .NET one (even (and maybe especially) that Core runs on Linux), I'd even switch the entire stack to avoid having to deal with Windows talent. The ClickOps mentality in Microsoft-based ecosystems is astounding.
ClickOps? I'm sorry. Node.js tooling, all of it, is worse than CLI experience (arguably you don’t need that much) you get out of .NET save for certain hot-reload edge cases (which is supported, but is subject to constraints expected from a compiled language).
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.
I'm a full stack Microsoft tech stack web dev since the days of asp classic. It's cool that the tech industry is big enough for all of us. I am not sure what the ClickOps mentality is, but I'm pretty sure I have it. Peace.
I think he's referring to all of the clicking required on Windows. For example, on Linux, I can create a project folder, files, etc. and open the project all from the terminal. On windows, I have to click into the file explorer, find the project folder, double click it to open it within the browser. So much clicking.
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.
I took it more as a dig at the way Microsoft offers its products. You want to spin up a new VM and deploy an app? Mindlessly click through these menus until you see a green checkmark.
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.
Precisely. The abstraction of knowledge is a cultural staple of that ecosystem. It's great and all, but you end up with developers who have no understanding of what is happening when they click "next next next next yes finish". On Linux, that understanding is a core pillar of the culture. Stark contrasts.
I'm having fun jumping into this conflict. Since I'm unabashedly on one side of the argument, I feel equipped and compelled to weigh in. The work my small team does is well documented, and when we execute our plans, we can click "next next etc." and everything works quite nicely. You're absolutely correct that I do not want to have an understanding of what is happening when I click next. I have a lot of other things that I need to understand. Humans for example do not have any "next" button so I spend a lot of time wrangling us. When the computer does what I think it out to do, then you're right I am not going to dig in. That's true. Inevitably I'm sometimes surprised when the computer doesn't do what I think it ought to, and I do have to dig in. Then I am perfectly happy to debug the situation. We figure out what's going on, fix it in the near term, update the documentation to address this in the long term, and then go back to clicking "next next etc." I call this productivity. I guess you could look down on me for not wanting to know things I am not getting paid to know. I look at it as saving my limited brain cells and attention for things I am getting paid to deal with.
I’m a macOS/Linux person, but I feel this is a bit of a hot take.
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.
Node.js runs everywhere and has the most popular frameworks, which are still maintained by thousands of developers. You also get serverless functions and NPM with millions of public packages.
.net core is pretty cool. they even adopted a similar api to express if I remember well.
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.
The API adoption is in many ways the other way around - for example, a lot of JS frameworks are now mimicking HttpContext that ASP.NET and ASP.NET Core had for more than a decade. Ultimately, registering and routing endpoint is usually a smaller part of the project, but yes, the introduction of minimal API especially in combination with top-level statements is welcome
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.
and why are you using TS to begin with ? and yes I agree if you're gonna jump on the typescript wagon, why not use C# etc.
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
That's because Express has been seriously neglected for the past 10 years. That's why it's still version 4. I think you still have to hack in basic support for async handlers.
Performance is bad. Bad as in all the other frameworks use it as a baseline for their benchmarks lol.
I was a long time net dev (going back to 2001) who has since moved onto a lot of other things, including nodejs. However, I did take a long break from nodejs for about 2 years, and in my new position it is used heavily.
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.
It was tongue in cheek. Both .net and node bring a ton of baggage.
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.
Fair enough. I always consider Go first, but I do differ in that I'm happy to take .Net second.
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).
It often does require more LOC, but unless the difference is extreme (and whilst it's there it isn't extreme) then I'm not sure why LOC would even be relevant.
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.
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.