It isn't just about scratching an itch. It results in fewer bugs, faster development, more features etc. which are useful to end users.

My experience of tools/languages that sit on top of the actual native implementations (e.g. React Native or Xamarin on mobile) is that they often lead to much slower development, since when you're Googling around trying to find answers to an issue you're looking in a much smaller community for answers. Eventually the answer usually ends up being "just do it the native way".

Hopefully Blazor will avoid such issues. In any case I'm probably speaking out of turn... it clearly isn't designed for wide-scale deployments - in house/intranet tools are a different beast anyway.

I use Xamarin Android and while you are right about the ton of googling needed, it was always to search for Android API and almost never because of Xamarin itself. Once found, it’s straightforward to convert from Java code to C# except a few cases (layout parameters for instance). The other issue is coming from a nicely design framework (WPF, Silverlight or WP7/8) the Android APIs feel ugly at times (gesture handlers for example).

Assuming you are doing Xamarin.Native and not Xamarin.Forms, you can just tab-complete your way through it if you know the native side. The apis are almost 1-to-1, only making things more dotnet-y when it makes sense.

That's such nonsensical marketing spin.

I don't see how easier development does not result in better outcomes. Imagine how bad things would be if everyone had to code in Assembly.

But the "easier development" part is very debatable. What do I see in the browser developer console when debugging a Blazor app? Can I insert breakpoints, trace what is running and how? etc. etc.

I get disliking JavaScript, but there is a strong argument to be made for using the tried and tested technologies that developers have been using for a very long time, rather than shoehorning whole new tech in just because it's in a language you prefer.

The answer to your break point question is yes. You can debug your C# code on the front end with breakpoints. The biggest benefit is applications with a lot of domain business logic tend to have that logic copied to the front end and copied to the backend. If a object can no longer be updated if it has an expired date then you would have logic on your server to prevent that. You would also have logic on your front end to display to the user that this can not happen before even going to the server. The server would act as a backup and ensure it never happens.

With Blazor, this logic only exists in one place which helps follow DRY.Logic that is duplicated tends to get missed in testing often. This provides business value.

The process of developing better tools for more effective software design is not just about making developers feel better.

It's about prodding development teams towards the pit of success, to use a common cliche, instead of the pit of despair. Less mental overhead, less need for expertise in specific flavor-of-the-month frameworks, less churn, easier hiring (you just need to know C#), more reliance on compiler tools to prevent dumb mistakes.

Stuff like that easily make the difference between success and total failure. The business stakes are actually quite high.