2 ms·

One fundamental difference is that if you are building a React or Vue static app, you're going to need a backend anyways. If you're building a React or Vue SSR

One fundamental difference is that if you are building a React or Vue static app, you're going to need a backend anyways. If you're building a React or Vue SSR app (Next.js, Nuxt.js), you'll probably want a separate backend anyways. If you're going to have a separate backend, .NET has some advantages compared to Node that's worth considering. It's higher throughput than Node for the same compute resources, it's multi-threaded and you can run background workers in-process, it has some nice built-ins for concurrent processing (Task Parallel Library, System.Threading.Channels), the nuget ecosystem is less prone to security risks compared to NPM [0], EF Core is a really mature ORM and possibly one of the best ones out there for productivity, it has serviceable hot reload for productivity, and modern C# is really, really close to JS and TS in syntax [1]. One often overlooked advantage for high security contexts is that .NET has a large standard library that's maintained by Microsoft for really core things like encryption, hashing, database drivers, network code, etc. You get the benefit of having an army of professional engineers maintaining that core code and patching it when security issues arise versus the Node/NPM ecosystem's strong dependency on the community. C# and .NET are the backend runtime that most teams probably want when they think of moving on from Node to Elixir, Go, or Rust because of how close it is to TypeScript now. And if you're going to use .NET on the backend, then why not consider Blazor for SSR and static HTML? (Disclaimer, I'm not a big fan of Blazor, but I can see why teams would choose it). [0] GitHub State of the Octoverse 2020: https://octoverse.github.com/2020/static/github-octoverse-2020-security-report.pdf https://octoverse.github.com/2020/static/github-octoverse-20... [1] https://github.com/CharlieDigital/js-ts-csharp https://github.com/CharlieDigital/js-ts-csharp

adamgordonbell 3y ago
C# and .NET are the backend runtime that most teams probably want when they think of moving on from Node to Elixir, Go, or Rust because of how close it is to TypeScript now. Bold statement. Looking like typescript doesn't seem like it should be the most important concern in a backend lang.
- CharlieDigital 3y ago
  I don't think it's that bold. It's like saying learning Spanish is easier than learning Japanese if you're a native English speaker. The basis in the shared Latin characterset certainly makes it easier to learn Spanish, no? Similar syntax equates to similar constructs and concepts. The way async/await works -- from a dev perspective -- is the same. Exception handling is more or less the same with try-catch-finally. Lambda closures work largely the same (some differences due to how JS binds `this`). TypeScript object hierarchies like interfaces and abstract classes are more or less identical in function (obvious differences, though in underlying implementation and capabilities). Same null coalescing, same nullability constructs. Array methods like `map`, `filter`, and so on are subset of System.Collections.Linq operations like `Select`, `Where`. Certainly having similar syntactic language constructs makes it easier to adopt if you are already comfortable with try-catch-finally and async/await versus entirely switching paradigms in Go or Rust, for example. Tooling is very similar from a CLI perspective and DX isn't that different. Hot reload, .csproj = package.json, main.ts or index.ts = Program.cs
  - adamgordonbell 3y ago
    I'm questioning whether learning the syntax of a language is the main difficulty in backend development and should be the main decision point.

adamgordonbell 3y ago

C# and .NET are the backend runtime that most teams probably want when they think of moving on from Node to Elixir, Go, or Rust because of how close it is to TypeScript now. Bold statement. Looking like typescript doesn't seem like it should be the most important concern in a backend lang.

CharlieDigital 3y ago
I don't think it's that bold. It's like saying learning Spanish is easier than learning Japanese if you're a native English speaker. The basis in the shared Latin characterset certainly makes it easier to learn Spanish, no? Similar syntax equates to similar constructs and concepts. The way async/await works -- from a dev perspective -- is the same. Exception handling is more or less the same with try-catch-finally. Lambda closures work largely the same (some differences due to how JS binds `this`). TypeScript object hierarchies like interfaces and abstract classes are more or less identical in function (obvious differences, though in underlying implementation and capabilities). Same null coalescing, same nullability constructs. Array methods like `map`, `filter`, and so on are subset of System.Collections.Linq operations like `Select`, `Where`. Certainly having similar syntactic language constructs makes it easier to adopt if you are already comfortable with try-catch-finally and async/await versus entirely switching paradigms in Go or Rust, for example. Tooling is very similar from a CLI perspective and DX isn't that different. Hot reload, .csproj = package.json, main.ts or index.ts = Program.cs
- adamgordonbell 3y ago
  I'm questioning whether learning the syntax of a language is the main difficulty in backend development and should be the main decision point.