|
Do you think that the 20% productivity boost might be solely because you now just have one language to work with? That's what I'm thinking, and that's why I'm personally keen to learn and use Blazor instead of the usual JS frontend. After looking around at the current popular solutions, I've yet to find something that is as ergonomic and productive as the .NET stack in regards to creating a web-based product. You have one of the most solid backend frameworks (ASP.NET) with lots of great tools like EF Core for ORM, SignalR for real-time, now Blazor for frontend, easy authentication and authorization, etc. That just makes everything so performant. However, that is a very high level focused development path, while I feel Go is slightly lower level where you still have pointers and such. I see it as great for CLI apps and very specific server needs where you'd want great performance and CSP threading in combination with a very easy syntax for new developers, but I don't think that's a very common use case to be honest. Even though I love Go for its focus on simplicity, it just isn't the most suitable lang for high-level work, nor is it very suitable for low-level work at the same time. Regarding your switch from C# to TS, I understand it made sense in the last couple of years. It simplified the stack via reducing language context switching, which can be a good productivity boost depending on your team and team size. However, if you would've tested Blazor today and found it would have satisfied your frontend needs, I actually think a full C# stack will be better than TypeScript to be honest, due to the better tooling and better runtime that exists for C# compared to Node.js/Bun/Deno. I still think TS is better in the frontend department than Blazor, but that's simply because JS/TS has been the only language for frontend in a long time. I hope Blazor will gain traction as a real alternative. |
The productivity gains come somewhat in spite of using a single language and sharing resources. On one had this will play out nicely over time, but on the other hand we had to transition a lot of developers and tax others to help the process along. I can’t tell you exactly why we’re seeing it. The general consensus is that it’s just “nicer to work with Typescript” but I suspect it’s also because our internal developer tools are just better for Typescript. Not so much because we couldn’t have made them for C# but because we, had, to make them for Typescript.