in my experience, you can be very productive with dotnet if you stay on the well-traveled path.
I would not use it for private projects, but i like the opinionated defaults in a small team org setting. If your org is full on Microsoft ecosystem (Azure AD, Windows Server, ..) anyway, it fits in very well.
you don't have to be clever or reinvent the wheel because 90% of standard use cases are well documented in microsoft docs. it has a steep learning curve though (e.g. auth in aspnet).
I would definitely not call serving HTML from Azure Functions next-gen.
You are increasing the response time by 20-30ms just by using HTTP-Functions instead of plain ASP.NET (lots of abstractions and grpc channel to worker processes). Beyond that you will get long cold starts, no response-streaming and slow scaling. The cost of the consumption-based plan will skyrocket after small number of requests compared to serving from dedicated App Service.
What do you think about the author's opinion on focusing on integration tests? I am a relatively young developer and face a lot of backlash at my workplace when I prefer writing integration tests to unit tests. Our components have hundreds of unit tests, but things break because the data quality of connected systems is so poor. I always think, you could make most of these problems visible and communicate them to other teams in advance with just sending masses of data sets through the system using automated integration tests. But instead, we spend our time writing unit tests on our poor assumptions and fighting the mess in production.
I would not use it for private projects, but i like the opinionated defaults in a small team org setting. If your org is full on Microsoft ecosystem (Azure AD, Windows Server, ..) anyway, it fits in very well.
you don't have to be clever or reinvent the wheel because 90% of standard use cases are well documented in microsoft docs. it has a steep learning curve though (e.g. auth in aspnet).