4 ms·

There's a problem with Blazor, and that is that its not ready. Which is why they're shipping server side Blazor [0], which is all the stupid parts of Blazor wi

There's a problem with Blazor, and that is that its not ready. Which is why they're shipping server side Blazor [0], which is all the stupid parts of Blazor with none of the benefits. Don't get me wrong, the idea of running .Net in WASM is very appealing to me... but server side Blazor is a daft idea, and it's a mistake. Here's the model: - Your component view state is rendered on the server. - A delta is sent to the front-end. - The frontend updates the DOM in the browser. - Any DOM event is sent to the server. - repeat. Seems ok? However, the problems here to understand are: 1) Every UI interaction, from mouse focus, to mouse drag, to click to button down, is sent down the wire to the server to be processed. For high latency situations, this will feel terrible. 2) Every client shares the same server cluster. As such, it scales badly; your application may perform well with 10 users, but for 100 users, you have 10x as much server work happening. Not business logic... UI logic. Will it scale? No one knows, but the money is on 'no'. The server scale-out demands will scale with people viewing the website; effectively this means the UI will lag out under load when the server is busy, the exact opposite of modern SPA applications and apps that remain superficially responsive under server load, and compounding issues generated from (1). 3) As many of the examples show, server side Blazor shows how you can execute arbitrary code on the server as part of your components (eg. fetch DB records). However, no vague consideration has been given to the authentication model for this. In fact, the stated high level goal is that razor components will 'with one click' work seamlessly on both WASM-mono and razor-components; ie. They are are naive of user roles and permission groups on the server, and expect to interact with an arbitrary backend 'service' with its own permission roles. (But that isnt what the examples show). These are not trivial problems, they are, unfortunately, insurmountable architectural issues with server-side Blazor. ...and the work around is a compromise. ie. You use javascript. Which... kind of makes it rather pointless. This is being shipped early for business reasons, not technical reasons. They should just wait for the WASM target to be ready; this will be a disaster, in my opinion. [0] - https://blogs.msdn.microsoft.com/webdev/2018/10/02/blazor-0-6-0-experimental-release-now-available/ https://blogs.msdn.microsoft.com/webdev/2018/10/02/blazor-0-...

martijn_himself 8y ago
This is quite enlightening in that I'm very excited by the prospect of using C# in the browser without the downsides that came with Silverlight, but especially 1) seems to be a big negative! (I'm not sure I completely understand 2) and 3), does 2) only apply to server-side Blazor? Is 3) not inherent to all web development in that authentication on the client is 'disconnected' from users/ permissions on the server anyway?). As someone who is trying to wrap his head around all this, did they go with server side Blazor because browsers do not support all required WASM features yet? What is even the point of server side rendering?
- judah 8y ago
  Yes, 2 only applies to server-side Blazor. "Server-side Blazor" itself will be renamed[0] to Razor Components so as to disambiguate it with WASM-in-the-browser, which will still be called Blazor. Razor Components seems to be a blend of different kinds of web programming models, as described by the parent poster: - Traditional: POST + Redirect + GET - Single Page App: Thick client in JS - Razor Components: Traditional, but instead of POST+Redirect, it uses Web Sockets to asynchronously update state. Razor Components are being shipped because it's building off well-known, mature technologies. OTOH, Blazor (WASM in browser) is still baking. For example, there is no tree-shaking to minimize the minimize the size of components needed to run your Blazor app. (IIRC, the average size of a basic nav app is ~2MB.) [0]: https://blogs.msdn.microsoft.com/webdev/2018/10/02/blazor-0-6-0-experimental-release-now-available/ https://blogs.msdn.microsoft.com/webdev/2018/10/02/blazor-0-...
- shadowmint 8y ago
  > Is 3) not inherent to all web development in that authentication on the client is 'disconnected' from users/ permissions on the server anyway? Server side components directly call server code, unlike client components, which use an HttpService. Compare for example https://dzone.com/articles/understanding-server-side-blazor https://dzone.com/articles/understanding-server-side-blazor, where: > The Blazor app is hosted by an ASP.NET Core app, which also sets up the SignalR endpoint. Since the Blazor app is running on the server, the event handling logic can directly access the server resources and services. Vs. the actual official samples, where an HttpService is used to access data from a controller: https://github.com/aspnet/samples/blob/master/samples/aspnetcore/blazor/FlightFinder/FlightFinder.Client/Services/AppState.cs#L35 https://github.com/aspnet/samples/blob/master/samples/aspnet... ie. Blazor server side components are indeed disconnected from users/permissions, by design... it just happens that they can also call arbitrary server side code, which is obviously a) not portable, and b) hugely unsafe. There's an issue in the issue tracker for this, but basically, the tldr; is, no, you shouldn't call arbitrary server side code... but, you can, and so people are doing it. ... shakes head ... (edit: Oh look, another great one, https://social.technet.microsoft.com/wiki/contents/articles/51872.blazor-single-page-application-using-server-side-blazor.aspx#Creating_the_Service_class https://social.technet.microsoft.com/wiki/contents/articles/... > We will invoke the methods of EmployeeDataAccessLayer class from our service. The service will be injected into our components and the components will call the service methods to access the database. ...)
caleblloyd 8y ago
Server Side Blazor performance should be similar to Server Side generated web pages, except the framework allows for SPA-style interactions instead of full page reloads. There is added resource utilization from tracking session state on the server, but if done properly it could be as little as 1MB or so per active client connection. With the rise of serverless and edge computing (think cloudflare workers), I wouldn't be surprised if patterns emerge to running this at the edge. I agree I wouldn't put any high traffic apps on Server Side Blazor from the get-go. But for Enterprise apps with high complexity and a small user base, I think it would greatly streamline development.
- shadowmint 8y ago
  > There is added resource utilization from tracking session state on the server, but if done properly it could be as little as 1MB or so per active client connection. Just curious, where did you pull this number out of? I've never seen a SignalR connection use that little memory for anything.
  - caleblloyd 8y ago
    Server Side Blazor will have to store the current Virtual DOM Representation in memory for each client, so that it can do diffing on it if a request comes in for that client and return the diffs. 1MB is my estimate for the Virtual DOM and associated independent state for each client. I was not factoring in the SignalR per-connection memory footprint, I imagine that would already be pretty optimized?

martijn_himself 8y ago

This is quite enlightening in that I'm very excited by the prospect of using C# in the browser without the downsides that came with Silverlight, but especially 1) seems to be a big negative! (I'm not sure I completely understand 2) and 3), does 2) only apply to server-side Blazor? Is 3) not inherent to all web development in that authentication on the client is 'disconnected' from users/ permissions on the server anyway?). As someone who is trying to wrap his head around all this, did they go with server side Blazor because browsers do not support all required WASM features yet? What is even the point of server side rendering?

judah 8y ago
Yes, 2 only applies to server-side Blazor. "Server-side Blazor" itself will be renamed[0] to Razor Components so as to disambiguate it with WASM-in-the-browser, which will still be called Blazor. Razor Components seems to be a blend of different kinds of web programming models, as described by the parent poster: - Traditional: POST + Redirect + GET - Single Page App: Thick client in JS - Razor Components: Traditional, but instead of POST+Redirect, it uses Web Sockets to asynchronously update state. Razor Components are being shipped because it's building off well-known, mature technologies. OTOH, Blazor (WASM in browser) is still baking. For example, there is no tree-shaking to minimize the minimize the size of components needed to run your Blazor app. (IIRC, the average size of a basic nav app is ~2MB.) [0]: https://blogs.msdn.microsoft.com/webdev/2018/10/02/blazor-0-6-0-experimental-release-now-available/ https://blogs.msdn.microsoft.com/webdev/2018/10/02/blazor-0-...
shadowmint 8y ago
> Is 3) not inherent to all web development in that authentication on the client is 'disconnected' from users/ permissions on the server anyway? Server side components directly call server code, unlike client components, which use an HttpService. Compare for example https://dzone.com/articles/understanding-server-side-blazor https://dzone.com/articles/understanding-server-side-blazor, where: > The Blazor app is hosted by an ASP.NET Core app, which also sets up the SignalR endpoint. Since the Blazor app is running on the server, the event handling logic can directly access the server resources and services. Vs. the actual official samples, where an HttpService is used to access data from a controller: https://github.com/aspnet/samples/blob/master/samples/aspnetcore/blazor/FlightFinder/FlightFinder.Client/Services/AppState.cs#L35 https://github.com/aspnet/samples/blob/master/samples/aspnet... ie. Blazor server side components are indeed disconnected from users/permissions, by design... it just happens that they can also call arbitrary server side code, which is obviously a) not portable, and b) hugely unsafe. There's an issue in the issue tracker for this, but basically, the tldr; is, no, you shouldn't call arbitrary server side code... but, you can, and so people are doing it. ... shakes head ... (edit: Oh look, another great one, https://social.technet.microsoft.com/wiki/contents/articles/51872.blazor-single-page-application-using-server-side-blazor.aspx#Creating_the_Service_class https://social.technet.microsoft.com/wiki/contents/articles/... > We will invoke the methods of EmployeeDataAccessLayer class from our service. The service will be injected into our components and the components will call the service methods to access the database. ...)

caleblloyd 8y ago

Server Side Blazor performance should be similar to Server Side generated web pages, except the framework allows for SPA-style interactions instead of full page reloads. There is added resource utilization from tracking session state on the server, but if done properly it could be as little as 1MB or so per active client connection. With the rise of serverless and edge computing (think cloudflare workers), I wouldn't be surprised if patterns emerge to running this at the edge. I agree I wouldn't put any high traffic apps on Server Side Blazor from the get-go. But for Enterprise apps with high complexity and a small user base, I think it would greatly streamline development.

shadowmint 8y ago
> There is added resource utilization from tracking session state on the server, but if done properly it could be as little as 1MB or so per active client connection. Just curious, where did you pull this number out of? I've never seen a SignalR connection use that little memory for anything.
- caleblloyd 8y ago
  Server Side Blazor will have to store the current Virtual DOM Representation in memory for each client, so that it can do diffing on it if a request comes in for that client and return the diffs. 1MB is my estimate for the Virtual DOM and associated independent state for each client. I was not factoring in the SignalR per-connection memory footprint, I imagine that would already be pretty optimized?