As someone who likes .NET I have never once seen a Blazor website that works well.
Just try dragging and dropping: https://blazordragdrop.azurewebsites.net/
The "best" I've seen has been like 100ms of latency.
Just try dragging and dropping: https://blazordragdrop.azurewebsites.net/
The "best" I've seen has been like 100ms of latency.
As others have pointed out, it is using the least efficient mode possible (HTTP 1.1 polling instead of WebSockets or WASM), so it is maximally sensitive to network latency. Unless you're physically near that particular Azure region, you'll have a bad experience.
Real-world usage of Blazor for Internet apps would typically use client-side WASM. Similarly, corporations might opt to use WebSockets over their private LAN, which is likely to provide very low latency and high bandwidth.
This demo app was accidentally deployed with the incorrect/default settings. It doesn't even have HTTP/2 enabled, let alone WebSockets, which are off by default: https://learn.microsoft.com/en-us/aspnet/core/signalr/publis...
Microsoft themselves mention that performance is expected to be bad with WebSockets off: https://learn.microsoft.com/en-us/aspnet/core/blazor/host-an...
When WebSockets are disabled, Azure App Service simulates a
real-time connection using HTTP Long Polling. HTTP Long Polling
is noticeably slower than running with WebSockets enabled, which
doesn't use polling to simulate a client-server connection.Edit: And the most important advantage, next to productivity, is maintainability, without the entire JS/TS/Node toolkit.
You can also just use Blazor WASM, but I've had trouble setting up Windows Authentication when in Blazor Server it works out of the box.
Honestly, it's one of the issues I see with WASM as a whole. The JavaScript ecosystem is almost implicitly supportive of open source, since that's essentially what gets delivered to the browser. WASM feels like it take us back towards walled gardens where you have to buy Telerik or Dundas libraries to get the widget you want to use, and then find out they don't play nicely with some other part of your stack. For all but the must graphically intensive use cases, or companies that can afford to own their stack from the ground up, I see little reason to adopt it.
The thing my enterprise customers wanted to avoid was deploying software on their desktops. They didn't even like rolling out Office. Presumably Blazor eliminates that problem because the whole thing is delivered over http.
JS is basically a compilation target nowadays. Don’t tell me that a minified, tree-shaken JS file somehow helps open-source. Sure, .NET is definitely not the panacea of open-source, but that is not inherent in the technology, but the politics around.
When building internal applications, you can make many assumptions - where are your users and how good is their network connection, how many of them do you have - dozens? hundreds? maybe even thousands, but not millions, so scalability is not a problem. Whether the app will be used on a mobile phones or not. Will it be a problem if your application takes 20 seconds to open? :) If the employee will use it half of the day, then probably no.
My org does none of these so Blazor was a great option for us.
The same is not true for Blazor Webassembly, which operates as combination of client and server projects, typically communicating via standard REST calls.
For me the problem with TypeScript is not the language, JS/TS are fine for me, the problem is the entire toolchain - NodeJS, all the node_modules, configuration files, the need to compile.
Maybe Svelte, where they got rid of TypeScript and the types are now in JSDoc, could be a compromise.
I work on a startup that is on WASM (primarily desktop; little to no mobile usage, which limits the negatives of blazor wasm) and it's quite good. We were concerned about load time initially and asked users about the load time.
The response was "what load time". Blazor is good for the "right" kind of application, but like many see poor implementation due to limited documentation guidance or worked examples can severely degrade practical implementation.
DOMContentLoaded: 4.61s
Finish: 19.48s
https://pagespeed.web.dev/analysis?url=https%3A%2F%2Fwww.mud...