Comment by wokwokwok | Hacker News Reader

Comment by wokwokwok | Hacker News Reader

> Blazor code executing on the server has the flexibility to do anything you would normally do on the server, such as connecting directly to a database.

Frustrating to see even the splash page off in lalala land.

Write once, deploy no where because surprise, the 3rd party package you were using requires a database connection, or some other server side feature.

This kind of messaging is why Blazor code is a mess; its not a seamless change to run on WASM when its ready, its server side lock-in, making db calls from your code behind file.

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

> If you are a Web Forms developer and want to build a new application on .NET Core, we would recommend Blazor which provides the closest programming model. [1]

The sad thing is, the WASM c# end-to-end, using real full dlls in the browser is actually really cool.

...but somehow that got lost along the way.

[1] https://devblogs.microsoft.com/dotnet/net-core-is-the-future...

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 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

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.

Reply on news.ycombinator.com