4 ms·
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
by 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 agoYes, 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. ...)