5 ms·

what is the appeal of Blazor (as for that matter yew), when now there's a healthy ecosystem based on Typescript for the front-end? Is it just the ability to nev

what is the appeal of Blazor (as for that matter yew), when now there's a healthy ecosystem based on Typescript for the front-end? Is it just the ability to never leave C# (or rust)?

gameswithgo 6y ago
Yes, there is always some value in having the same language client and server. Both in terms of being able to have shared types and functions, and less cognitive overheard when switching from client to server.
bob1029 6y ago
Productivity is the biggest appeal. 99% of our experience with Blazor involves writing some Razor-blessed HTML, taking dependency on state services and plugging things into DI. Our existing business services are simply consumed by the UI state services, so there isn't even any code involved for wiring this part up aside from some AddScoped<T>() calls in your bootstrapping code. Things that we do not worry about anymore: Javascript, controllers, CORS, JSON, HTTP status codes, API documentation, 3rd party dependencies. I say we don't worry about javascript and that is true, but I want to be clear that there is still a tiny amount of javascript involved. We do maintain a single "BlazorExtensions.js" file which covers all js interop needs across the entire solution. This file is currently only 120 lines long. So, while we do have javascript, we absolutely do not lose sleep over it anymore.
- stuartd 6y ago
  > Things that we do not worry about anymore: Javascript, controllers, CORS, JSON, HTTP status codes, API documentation, 3rd party dependencies. That's a good looking list of things not to worry about. Especially CORS, the bane of my life.. the fact it's pre-flight has caused me so many problems in my (tiny) UI responsibility.
  - bob1029 6y ago
    I've lost approximately a week of my life to it. Never again.
  - nicoburns 6y ago
    How does Blazor avoid CORS issues? It's still running client-side, right? And thus would be subject to the same CORS restrictions as JavaScript.
- Nelkins 6y ago
  How is the performance? Is this for an internal application, or a public facing one?
  - bob1029 6y ago
    Performance is good, but I would only use it on well-bounded target audiences. Anything over 10000 simultaneous users on a single instance would probably start to concern me. It is perfect for any internal or B2B UI you might want to build. That said, combine Blazor with other Microsoft magic like Orleans, and you can start to horizontally scale. Might even be possible to make Server-Side Blazor viable for mass public consumption using this approach. Edit: It does appear this would be fairly easy to rig a test for as of latest versions of everything. Should be able to throw Blazor and Orleans on top of the same IWebHost instance. https://devblogs.microsoft.com/dotnet/orleans-3-0/#co-hosting-via-the-generic-host https://devblogs.microsoft.com/dotnet/orleans-3-0/#co-hostin...

what is the appeal of Blazor (as for that matter yew), when now there's a healthy ecosystem based on Typescript for the front-end? Is it just the ability to never leave C# (or rust)?

gameswithgo 6y ago

Yes, there is always some value in having the same language client and server. Both in terms of being able to have shared types and functions, and less cognitive overheard when switching from client to server.

bob1029 6y ago

Productivity is the biggest appeal. 99% of our experience with Blazor involves writing some Razor-blessed HTML, taking dependency on state services and plugging things into DI. Our existing business services are simply consumed by the UI state services, so there isn't even any code involved for wiring this part up aside from some AddScoped<T>() calls in your bootstrapping code. Things that we do not worry about anymore: Javascript, controllers, CORS, JSON, HTTP status codes, API documentation, 3rd party dependencies. I say we don't worry about javascript and that is true, but I want to be clear that there is still a tiny amount of javascript involved. We do maintain a single "BlazorExtensions.js" file which covers all js interop needs across the entire solution. This file is currently only 120 lines long. So, while we do have javascript, we absolutely do not lose sleep over it anymore.

stuartd 6y ago
> Things that we do not worry about anymore: Javascript, controllers, CORS, JSON, HTTP status codes, API documentation, 3rd party dependencies. That's a good looking list of things not to worry about. Especially CORS, the bane of my life.. the fact it's pre-flight has caused me so many problems in my (tiny) UI responsibility.
- bob1029 6y ago
  I've lost approximately a week of my life to it. Never again.
- nicoburns 6y ago
  How does Blazor avoid CORS issues? It's still running client-side, right? And thus would be subject to the same CORS restrictions as JavaScript.
Nelkins 6y ago
How is the performance? Is this for an internal application, or a public facing one?
- bob1029 6y ago
  Performance is good, but I would only use it on well-bounded target audiences. Anything over 10000 simultaneous users on a single instance would probably start to concern me. It is perfect for any internal or B2B UI you might want to build. That said, combine Blazor with other Microsoft magic like Orleans, and you can start to horizontally scale. Might even be possible to make Server-Side Blazor viable for mass public consumption using this approach. Edit: It does appear this would be fairly easy to rig a test for as of latest versions of everything. Should be able to throw Blazor and Orleans on top of the same IWebHost instance. https://devblogs.microsoft.com/dotnet/orleans-3-0/#co-hosting-via-the-generic-host https://devblogs.microsoft.com/dotnet/orleans-3-0/#co-hostin...