Re: and for anyone who thinks this isn’t webforms back from the dead

For getting smaller and internal projects done quickly and without stack drama, Web Forms does the job just fine. It's not going to win an art contest, but it's usually quicker, cheaper, and simpler than the alternatives. You wanna pay more for art and fashion? Go ahead!

I went to a meetup focusing on Blazor recently and was really surprised when I found out that Blazor is not "run C# in a browser using WASM" like I thought, but was instead "use your browser as a thin client to C# on the backend". The whole time I was thinking "but why??".

The WASM side of it is really interesting for me as a Xamarin proponent, because it has the potential of true single shared-codebase between mobile and web. I'm not sure why I would use Blazor right now though.

> I went to a meetup focusing on Blazor recently and was really surprised when I found out that Blazor is not "run C# in a browser using WASM" like I thought, but was instead "use your browser as a thin client to C# on the backend

That's not true. It can run client-side on a WebAssembly-based .NET runtime or server-side in ASP.NET core.

I find MS has generally been taking a Manhattan-project style approach these days, trying everything at once and keeping what sticks.

https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-...

I'm not saying it can't, but the primary focus (and current release) is the server-side version. I didn't realize (before that meetup) that server-side Blazor was even a thing, everything I heard about it before this was that the client-side version _was_ Blazor.

I don't know if thats a disconnect in marketing, or me not paying attention, but like I said I was really confused.

Yeah, a confusing spate of offerings and terminology is just part of working with the Microsoft stack. It took me like 3 years of professional C# development to finally sort it all out.

But the reason they're pushing server-side Blazor is because loading client-side Blazor just takes too long in production deployments. Right now, you have to wait several seconds before the page loads, which is unacceptable for most users. I feel like server-side has to be the future, though, and they'll address the speed issue soon enough.

what's the difference between server side and just serving everything on the server and jQuery? sounds very similar

Blazor server-side maintains a websocket to a running client and does some Magic to communicate DOM updates to the client.

The team has documented and discussed this several times. They have always recommend using service interfaces or HTTP calls inside your components if you intend on switching to client-side in the future.

Otherwise, for many apps, server-side Blazor works just fine. The component model is like any other frontend framework, not like Webforms at all, and by running server-side gives you a shorter path to the data and backend code you would normally put behind an API interface. This is an incredibly productivity boost.

If you don't need or want it, then don't use it, but it's a major leap forward.

Alternatively, don't use third party packages you don't fully understand.

I'm not sure if I could do much of anything as a developer if I didn't use third-party packages I didn't fully understand.

I suppose I could spend much of my day carefully vetting dependencies... but what about dependencies of dependencies?

So you don't use 3rd party packages? Because the moment you use one you don't fully understand it --that comes with time. You can't magically know every nuance about a package before you start using it. I haven't looked at the code at all for momentjs or the internals of Vue, there's still a lot I don't know about their api's but doesn't mean I still don't get value out of using them.

I take it you don’t use any 3rd party vue/angular/react components?

There’s certainly a place for telerik—only UIs I suppose.

/shrug