Aspnetcore: Blazor potentially no longer client-side technology?

[daniel007]

Hi,

I watched today's ASP.NET Community Standup stream, and although the Electron demo was impressive, I'm somewhat surprised that the team is now seriously considering changing direction and running Blazor on the server. While there are some valid scenarios (and I think this should definitely be an option in the future), what got me (and others) so excited about this technology was the fact that it is purely client-side framework (webserver serving only static files).

To be honest, I was hoping that by this time (has it been a year since the first Blazor demo?) I would already be writing production apps in what I think is the best UI framework that Microsoft has been working on for quite some time. Wasn't this project supposed to be given a go/no go in May?

Thanks and keep up the great work! Very impressive what such a small team has been able to accomplish so far!

[SIkebe]

@daniel007 @danroth27 said in gitter channel

I think of server-side blazor as a stepping stone to the client-side solution
We can make progress on a production runtime and then move to the client as .NET on WebAssemlby matures

[humbersoft]

I watched the standup too and I do not like the server side direction/exploration. It reminds me too much of web forms. I think developers need to know that they are writing client-side code. When the lines start to blur between what is client and what is server, then that is when the problems come. Blazor needs to stay client side. We already have viable server-side frameworks with asp.net and asp.net core.
$0.02

[Amine-Smahi]

Please keep it client side and make it better 😢

[mindyourservice]

Awesome work! Really excited to use this in production.

To answer Steve’s question.

Client Side would work for our large scale business app. Mainly because of heavy UI components that would be too slow due to latency. Saving time on Web API would be good, but we need these regardless due to mobile apps and business API’s.

[danroth27]

Blazor is and will continue to be a client-side framework. There are no plans to change that. However, Blazor's architecture is flexible such that it can be used in a variety of scenarios including out of process scenarios like Web Workers, Electron apps, and server-side apps. These scenarios are being investigated in addition to running Blazor client-side in the browser.

[Terricide]

I was just watching the presentation and Steve missed out on a big feature of having Blazor running on the server and just rendering on the browser.

That is security. By having everything running on the server you are not exposing and of the business logic or code in the browser.

I use a product called Visual WebGUI and I am currently using Wisej and we had a security audit that we passed with flying colors in part to the fact that browser is dumb and is essentially rendering what the server told it to.

https://news.ycombinator.com/item?id=484514

[Terricide]

For more info
https://wisej.com/docs/html/Security.htm

[GoranHalvarsson]

Server-side, we have that already - ASP.Net Mvc. I think it will confuse developers if BLAZOR also does server-side stuff...
Let BLAZOR be the client-side option for us that are tired of big messy javascript frameworks.

[daniel007]

I'm not sure to what extent security concern is a valid argument. Client applications (whether hosted in the browser or desktop) should not keep any confidential information (besides what is needed for authentication/authorization), service layer (Web API) takes care of that.

I briefly scrolled through the Gitter feed and it appears that @danroth27 is trying to sell the server option as a higher priority project. Can you share the main reasons?

In my experience, server applications are more difficult (and costly) to maintain. Modern computers have plenty of processing power to distribute the workload evenly, if I remember one of the early Blazor videos starring @SteveSandersonMS , he mentioned something similar.

Blazor will be a tough sell to the management when there are other viable server solutions. Modern (web) development is clearly shifting towards exclusive client-side development (where I think it should be), if Blazor can run in the browser and maybe as a PWA, it is a winner.

Someone mentioned startup time, I guess that depends on how long it is. If on a typical setup, an application can load the bare minimum within one or two seconds, that would be perfectly fine in my case (mostly enterprise applications). Then the program can start loading other modules/areas/assemblies on demand as needed (I believe this is being addressed under Lazy Loading elsewhere).

Thanks for taking my feedback into considerations.

[danroth27]

I briefly scrolled through the Gitter feed and it appears that @danroth27 is trying to sell the server option as a higher priority project. Can you share the main reasons?

That was certainly not my intention! Blazor as a client-side web UI framework is still our top priority. Pragmatically, Blazor on the server may be easier to deliver initially as it has no dependency on delivering .NET on WebAssembly. But the long-term goal is still to deliver Blazor on the client.

[vertonghenb]

I do believe that the Server side option is currently more approachable since it's backed by .NET Core and not bound to the mono compilation to WASM which is currently 'holding us back' (perf. issues etc), let me be clear though the mono team is doing an amazing job! Maybe consider the server side option for now and later on when mono to wasm has more feature move to the client side?

[GoranHalvarsson]

Yes, I have to take back what I said about server-side. I was thinking about server-side in the "old way", you know do action on each web request and all that. But this is an entirely "new" way using server-side, no need to wait for each request. Do everything via websockets, this is wonderful. I think you are on to something here. Keep up with the good work Blazor people!!