Aspnetcore: Service Side vs Client Side

[vertonghenb]

First of all, what you guys(the Blazor and the Mono team) are doing is amazing, keep it up!

I do believe we should weigh out the pro's vs cons on short- and long term. Since we can use .NET Core on the server side now -which is proven to be performant and stable- we don't have to worry about the bugs, feature requests and release pace of the Mono team. Therefore we might want to consider to first focus on the server side and once Mono to .WASM is stable enough we should take on the client-side, since we can focus on Blazor itself and be less dependent on the release pace of Mono.

As a final note, there are use cases for both implementations but let's use something that is stable and move Blazor itself forward without having to worry about some core dependencies.

Additional:
Is there a template we can play with for the Server Side?
Any idea when the 'experimental' phase could be over? 2-3 months, a year, two years?

Based on the stand-up episode.

[RemiBou]

I don't understand : is asp.net core not enough for server side ? the whole point of blazor is client side isn't it ?

[chassq]

Given you could run the Blazor process both client side (browser) and server side both have some advantages as pointed out in recent asp net live community video (see: https://youtu.be/CWuIz9khK-o?list=PL1rZQsJPBU2StolNg0aqvQswETPcYnNKL&t=3134 ). I really like the notion that you have a choice. I cannot say I have a preference other than I would like to be able to do both in a single app. For example there are some pages where I might want to protect the presentation code from prying eyes (render them server side) but other cases where is does not matter and I want the pages to render super fast or be available offline. I guess if I had to pick I would choose client side first because server side is already available for C# and I really want the client side programming xp (e.g. Offline PWA). My $.02...

[RyoukoKonpaku]

As @chassq said, I could see a hybrid solution to be a good selling point that a Blazor feature could do that no other SPA could do without some more configuration.

Though that hybrid solution hangs on the how easy it is to setup seamlessly without much setup. Maybe through the router or so where you can set whether you want to render this particular route on the server only or not.

The default should be client however, but there are some cases that server side rendering can be good. Sensitive pages like a payment page wherein you don't want your validation logic being sent to the client or not want to duplicate validation for client and server, while still keeping most of the site client-side would be a good candidate.

[humbersoft]

I am sorry, but I can't see vision for a server side Blazor. I have a couple of problems with it.

1. It feels wrong
   The whole point of a SPA is to avoid server side rendering. It feels wrong to build a SPA that is doing just SSR when we have very capable frameworks from others and Microsoft than can do that.

2. Latency issues
   Anything that will go through the network stack will be super slow already. Then add to that the distance between client and server. Doesn't matter how fast your connection is. It will not be fast enough. Imaging sending every click and scroll event to the server for processing? Only good for Intranet apps.

3. Chattiness
   It is not unusual for one person to have 20-30 browser tabs open at any given time. Imaging all of those connections to a Blazor server, then multiply that be 100 people. IT departments would be banning Blazor apps left right and center for killing bandwidth.

4. Maintain client state on server doesn't scale well.
   What are we going to do? pass around the viewstate? We tried that already (webforms) and the approach was discredited.

5. Forced to use a Microsoft back-end
   This is in Microsoft's interest and I understand this, but most people would be hesitant just because of lock-in fear. Not everyone will want to use a .NET Core back-end.

6. Dog fooding
   I think the effort would be better spent trying to get mono wasm up to par rather than going SSR for .net core.

The team is doing a great job btw. This is not a knock on the work you are doing. You asked for our feedback, so we are giving.

[vertonghenb]

@humbersoft Some very interesting thoughts!

[stavroskasidis]

@humbersoft I totally agree, especially with point 6

[davidbmasterson]

@humbersoft

It feels wrong
The whole point of a SPA is to avoid server side rendering. It feels wrong to build a SPA that is doing just SSR when we have very capable frameworks from others and Microsoft than can do that.
_The point of spa is to not have full page refresh, this in not that_

Latency issues
Anything that will go through the network stack will be super slow already. Then add to that the distance between client and server. Doesn't matter how fast your connection is. It will not be fast enough. Imaging sending every click and scroll event to the server for processing? Only good for Intranet apps.
_If I sent a message that says I clicked this and then the server works out what would change and then send just a change payload for the blazor.js client to render_

Chattiness
It is not unusual for one person to have 20-30 browser tabs open at any given time. Imaging all of those connections to a Blazor server, then multiply that be 100 people. IT departments would be banning Blazor apps left right and center for killing bandwidth.
If I have 20/30 tabs open I am only interaction with one of them at a time as I have only one mouse_

Maintain client state on server doesn't scale well.
What are we going to do? pass around the viewstate? We tried that already (webforms) and the approach was discredited.
_Did you watch the video or just jump on this tread and say this? this is a sockets thin client approach so no viewstate , no postback, just a message send to server side Blazor to say x clicked and then a change diff returned to blazor.js to render_

Forced to use a Microsoft back-end
This is in Microsoft's interest and I understand this, but most people would be hesitant just because of lock-in fear. Not everyone will want to use a .NET Core back-end.
_I appreciate this but if I am writing my code in c# I am not bothered about a Microsoft lock-in even if this was true, but this runs with asp.net core which is not limited to Microsoft platform_

Dog fooding
I think the effort would be better spent trying to get mono wasm up to par rather than going SSR for .net core. _Why?_

[Terricide]

I love the idea of having both and would love to have the ability to run on the server, installed as a desktop app or running client side.

Having the server-side option first as mono-wasm matures sounds great to me.

[Terricide]

Also I'm not sure if people are grasping the concept of how server Blazor would work. It is vastly different then asp.net mvc or webforms. It is a lot more like Wisej or Ooui (without wasm) or like vaadin in the java world.

[danroth27]

Thanks for the feedback on this everyone! Our focus continues to be on building a client-side .NET web UI framework, but this feedback helps us understand how useful it would be if Blazor also supported running server-side.

Since this issue is more of a discussion then a concrete work item for the product I'm going to go ahead and close it. Feel free to post more comments if you have additional feedback to share.

[chassq]

I think it very useful to have server-side eventually! Again to render html that maybe needs more privacy (e.g. protecting source code IP) may be one good scenario. Could be very valuable in making the overall product appealing to a wider developer community. Bottom-line for me is I like having the choice!

[chassq]

Hey @danroth27 , Was wondering if when we have discussion threads like this if you might consider not closing the issue but instead tag it as maybe "discussion" so that it stays open but people know it is now just a running discussion than a "real" issue? It would keep the issue on the default list for a longer time and may get more activity. Thanks!

[GoranHalvarsson]

Yes, I have to take back what I said about server-side. I thought 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!!

[Terricide]

Just FYI my company is using Wisej which is similar to how server-side Blazor works as far as passing messages over websocket. I'm currently sitting in utah and the website is running in the Australia azure data center and it feels plenty responsive.

[DNF-SaS]

IMO, the most important point of the server-side option is the ability to fully use the debugger during development.