4 ms·

1. use .Net that work with open standard like ASP.net (html/css/javascript) never buy into Microsoft's own technology like Silverlight. Blazor look promising si

1. use .Net that work with open standard like ASP.net (html/css/javascript) never buy into Microsoft's own technology like Silverlight. Blazor look promising since its based on webassembly 2. Microsoft fat client is a mess. winform? wpf? uwp? which one to use? don't forget winRT

electroly 5y ago
Mess is subjective. I've been using the same stable UI framework for 20 years. Today's junior frontend devs were in diapers when I started using Windows Forms and it hasn't ever been broken or required rewrites. I don't think web developers even realize this is possible. The biggest choice is deciding how much you like technologies from the Windows team. Personally, I stay away from them. With the exception of the very oldest technologies (Win32 and COM), tech from the Windows team has less longevity than technologies from DevDiv. That means yes to Blazor, WinForms, and WPF, and no to UWP and WinRT. Note that Blazor has a server-side edition. Most production Blazor usage is not WebAssembly-based at this point in time.
- mpmpmpmp 5y ago
  That's interesting because the 3 blazor projects that I have done client work for are all WASM not server. Do you have a source for the stats on server vs wasm deployments or just what you've experienced so far?
  - electroly 5y ago
    It's just personal experience and what I've heard from other enterprises. Inside corporate networks the latency from Blazor Server isn't a showstopper, and Blazor Server has been production-ready for much longer than Blazor/WASM.
    - hackerfromthefu 5y ago
      And sadly Blazor WASM even in .NET 6 has runtime performance slower than React, with 5 Mb hello world download. The other big advantage of Blazor server is you can remove the separate service layer project and deployment target entirely, reducing total code and total infrastructure significantly.

electroly 5y ago

Mess is subjective. I've been using the same stable UI framework for 20 years. Today's junior frontend devs were in diapers when I started using Windows Forms and it hasn't ever been broken or required rewrites. I don't think web developers even realize this is possible. The biggest choice is deciding how much you like technologies from the Windows team. Personally, I stay away from them. With the exception of the very oldest technologies (Win32 and COM), tech from the Windows team has less longevity than technologies from DevDiv. That means yes to Blazor, WinForms, and WPF, and no to UWP and WinRT. Note that Blazor has a server-side edition. Most production Blazor usage is not WebAssembly-based at this point in time.

mpmpmpmp 5y ago
That's interesting because the 3 blazor projects that I have done client work for are all WASM not server. Do you have a source for the stats on server vs wasm deployments or just what you've experienced so far?
- electroly 5y ago
  It's just personal experience and what I've heard from other enterprises. Inside corporate networks the latency from Blazor Server isn't a showstopper, and Blazor Server has been production-ready for much longer than Blazor/WASM.
  - hackerfromthefu 5y ago
    And sadly Blazor WASM even in .NET 6 has runtime performance slower than React, with 5 Mb hello world download. The other big advantage of Blazor server is you can remove the separate service layer project and deployment target entirely, reducing total code and total infrastructure significantly.