It's the same for a lot of similar things, Deno land, cloudflare workers/pages, etc. Things that reduce the friction to get something running online can be beneficial. They all have practical offsets and negatives too.
It's not a bad decision so much as a decision of where you derive value, and how much.
That doesn't need to be snarky. I know JavaScript and a variety of other languages, but if I'm picking a stack to work on the whole of, it's going to be a whole lot less context switching to use one language throughout, so JavaScript (in fact, TypeScript) it generally is.
I think the biggest "growing pain" is that C# runtime is multi-threaded so devs that are used to single-threaded Node.js environment need to understand object lifetimes. (Of course there are other differences as well, but the biggest IMO is understanding threading and object lifecycles in the underlying runtime.)
Syntactically identical promises/futures; syntactically identical lambdas; largely congruent tuples, classes, interfaces, generics, anonymous objects. C# 13 collection initializers are going to largely feel like JS array initializers.
Minor syntax differences can be picked up quickly. Frameworks like Nest.js are super similar to .NET Web API.
I use an apple computer and prefer to write my code in a simple text editor. Getting C# (or god forbid C++) just running in such a way that I can just focus on the code and not the surrounding environment or build tools took me long enough the last time I tried, that I decided to just not use C#.
Give it another look!
brew install dotnet-sdk
dotnet new console -o ConsoleApp --aot
cd ConsoleApp
dotnet publish -o .
./ConsoleApp
Feel free to comment out `PublishAot` property in .csproj file if you don't want AOT (i.e. using libraries that want JIT), or use dotnet watch and run commands for quick iteration.
Note that for rich editing experience you do not need C# Dev Kit (which requires an account), only a baseline C# extension which has all the good bits. For running and debugging the project out of VS Code - upon first F5 press it will suggest generating config assets for .NET project it managed to find in an opened folder - just agree and it will work on the next F5 press.
You can also write C# with Neovim and csharp-ls.
If that’s the case, your web app is much less complex too, which reduces the need for a product that reduces complexity?
I personally can't stand it, and actively work to excise it from front-end applications though _because_ it's difficult to work with it as a 'part' of your world. Like a lot of dev-experiential products/business models, their moat only exists if they can keep you "in" vercel, the moment they become just nodejs + lambda to a customer, then their value-add ceases; So they make it difficult to "grow up" out of vercel -- for many shops that's fine, it will be all they need from it, so a premium for a polished nodejs+lambda+deployment+cdn experience is worth it.
But if you're a micro-arch with backend services running on your own cloud, vercel will always be the wart in your infrastructure making everything from network policy to authentication and monitoring or tracing more difficult.