.NET Blazor

It's not about learning Blazor per say.

It's about learning C# .NET and working at the many, many companies who use .NET in some capacity for their various needs like desktop apps, data processing services, etc, and of course web with Blazor. I can take my existing skillset in C# .NET and apply it to many different things.

I find no lack of companies hiring C# .NET devs in the midwest.

This article is really odd. The long lists of disadvantages feel a lot like the lists of disadvantages that ChatGPT produce, where relevant disadvantages will be placed right next to things that are wildly inapplicable to whatever I'm doing. And the whole list is extremely impersonal - there isn't a single reference to the product(s) that the author worked on, so it's impossible to tell if the downsides are even real downsides or not.

Yea, I've been using Blazor in .NET 8 through the previews and it's really nice.

The Server Side Rendering is fast like any server-rendered stuff. Enhanced Navigation means that pages load even faster since they're just using `fetch` to get the next page and swapping the content (like Turbo in Rails). When I need some interactivity, the page still renders from the server and then the browser downloads the WASM in the background.

With .NET 8, Blazor is really ready. It isn't perfect, but it's so productive for me and the downsides are really minimal. Plus, it'll likely get a lot better with .NET 9 in a year because of WASM-GC (and post-MVP improvements to WASM-GC). With WASM-GC, .NET won't need to ship a garbage collector and WASM-based stuff won't need to copy between WASM and JS for DOM manipulations.

Since people might want the "minimal" downsides, I'll put them here. If you're using Blazor SSR with WASM, after the first interactive page renders for the first time, there's a second or two before the interactivity is actually available while it downloads the WASM (on interactive components, not links or anything). If you were making a Facebook clone, it'd mean that the "like" button on posts wouldn't work for a second or two. This is pretty minimal for two reasons. First, it's just the first page load of the first interactive page. After that, the WASM is cached in the browser. Second, most of the time people need a few seconds to read the content before using an interactive bit. All of the navigation and such works instantly, but an interactive bit like a "like" button takes a second or two.

If you want to get rid of that, you can use interactive-auto. This means that the first interactive page load will use a web socket and the interactive bits will be done with Blazor Server. It'll download the WASM in the background and switch to WASM for future page loads so you don't need the web socket for the vast majority of your stuff. However, web sockets do create a certain amount of hassle since you need to make sure that any proxies in-between handle web sockets and that you consistently route the user to the correct backend if you're load balancing.

To me, those downsides are minimal and don't have a lot of user impact for me. This is in contrast with Blazor in .NET 7 where I'd have to choose using a web socket all the time or having a big WASM payload that meant the page didn't render for a few seconds and gave users a crappy experience.

If you're primarily creating something that would be server-rendered (like Rails or Django), Blazor offers that with the additional nicety that you can add interactive elements without needing to deal with JS. That isn't meant as a "JS is crappy" comment, but to note that having to deal with another ecosystem where you need to duplicate your models and keep them in sync, having to deal with another build system or glue things together yourself, etc. is a pain when it isn't your main focus. So many sites end up with a full front-end stack and all the hassle involved because they need a couple pages or want to keep a consistent component system. Blazor means that you don't have to go that route.

Let's say it does: It leaves behind a WebAPI backend that [new hotness] can utilize. WebAPI is an agnostic protocol.

What does Blazor leave behind? Nothing reusable at all. It is a proprietary server hosting proprietary connections via proprietary pipeline. Plus sometimes inscrutable WebAssembly. Just go ask all the companies STILL stuck on Web Forms or Silverlight how that worked out for them the last times? Exactly.

Friends don't let friends buy into proprietary backends that muddy the water between UI/API layers. Stick to WebAPI and put whatever you want in front. That way you can migrate either front OR back independently of one another (and or do piecemeal migrations).

PS - This has nothing to do with "Microsoft bad." This has to do with standard protocols between front/back Vs bespoke stuff. I'd also criticize the short-sightedness if another company offered the same thing.

I think sometimes there's often gaps where you have to fill in for the designer.