7 ms·

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/ ht

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/ https://blazordragdrop.azurewebsites.net/ The "best" I've seen has been like 100ms of latency.

debacle 3y ago
Wow that's severely not great.
teh_klev 3y ago
Seem to work for me. What's broken for you and how can I reproduce?
- csjh 3y ago
  It "works", but there is a pretty ridiculous amount of latency.
  - teh_klev 3y ago
    I'm genuinely not seeing any latency. It feels pretty snappy to me. This is Chrome 116 on Windows 10 Pro.
mgh95 3y ago
This is because it's the server version. This is equivalent to liveview websites that have roundtrip latency. Do you know if there is a wasm hosted version of this?
- Anon3941 3y ago
  Not only is it Blazor Server, the web socket connection doesn't appear to work so its fallen back to http polling...
  - mgh95 3y ago
    Yeah, the issues here appear to be developer related. The docs offer less practical guidance than they should on proper deployment of blazor applications. 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.
  - ahoka 3y ago
    It’s deployed on an all-Microsoft stack and despite that it’s not working. Do MS still makes you think you need to pay for an Azure service to have WS in your app? It used to be the case.
ptrwis 3y ago
Blazor is not intended for websites, it is intended for enterprise, intranet CRUD applications with interactive forms, tables, etc. Especially if you already have .Net on the backend. I just finished one such application on Blazor Server and it works great. Programming was easy having previous experience with Angular. Edit: And the most important advantage, next to productivity, is maintainability, without the entire JS/TS/Node toolkit.
- local_crmdgeon 3y ago
  That made sense back in the day, but I can slap some crappy CRUD app together with Next and Formik in a few hours now.
- DANmode 3y ago
  But...back to the original topic, is drag and drop laggy for those use cases?
  - mgh95 3y ago
    No. This website is slow because its a liveview style websocket on each drag and drop action. A wasm implementation would not exhibit these characteristics.
    - jiggawatts 3y ago
      Also, internal-use apps are typically accessed over the LAN with much lower latencies than random Internet users.
      - ptrwis 3y ago
        On the other hand, remote work is very popular today, but if employees want to work remotely, it's their problem to have a good internet. I tested the Blazor server on a poor cellular network where packets could be lost or there were random long delays in packet delivery, and the application was unstable. It was better to set long-polling and enable compression, which is disabled by default. This is also a problem with websockets - messages are not compressed. Long polling again was less resposnsive on good internet connection. I'm curious how this would work in various configurations of quic/http3.
4rt 3y ago
That looks to be some individual dev's dragdrop example made 4 years ago. Just because it's hosted on azure doesn't mean its a microsoft demo.
- taspeotis 3y ago
  I am not under any confusion as to whether it’s Microsoft’s or not. Nothing with Blazor I’ve seen is fast. That’s just the easiest example to show it.
  - 4rt 3y ago
    This one seems ok https://www.mudblazor.com/components/dropzone#basic-usage https://www.mudblazor.com/components/dropzone#basic-usage
    - taspeotis 3y ago
      Uh... DOMContentLoaded: 4.61s Finish: 19.48s So it took 5 seconds to show me a splash screen, and another 15 seconds to actually start? It's 28 megabytes... https://pagespeed.web.dev/analysis?url=https%3A%2F%2Fwww.mudblazor.com%2Fcomponents%2Fdropzone%23basic-usage https://pagespeed.web.dev/analysis?url=https%3A%2F%2Fwww.mud...
      - Jochim 3y ago
        It took a while to start on my phone but the splash screen displayed instantly.
        taspeotis 3y ago
        Damning with a hint of praise.
jiggawatts 3y ago
This is served out of the West Europe region. 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/publish-to-azure-web-app?view=aspnetcore-7.0#configure-the-app-in-azure-app-service 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-and-deploy/server?view=aspnetcore-7.0#azure-signalr-service 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.
deafpolygon 3y ago
This is pretty instant to me.

debacle 3y ago

Wow that's severely not great.

teh_klev 3y ago

Seem to work for me. What's broken for you and how can I reproduce?

csjh 3y ago
It "works", but there is a pretty ridiculous amount of latency.
- teh_klev 3y ago
  I'm genuinely not seeing any latency. It feels pretty snappy to me. This is Chrome 116 on Windows 10 Pro.

mgh95 3y ago

This is because it's the server version. This is equivalent to liveview websites that have roundtrip latency. Do you know if there is a wasm hosted version of this?

Anon3941 3y ago
Not only is it Blazor Server, the web socket connection doesn't appear to work so its fallen back to http polling...
- mgh95 3y ago
  Yeah, the issues here appear to be developer related. The docs offer less practical guidance than they should on proper deployment of blazor applications. 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.
- ahoka 3y ago
  It’s deployed on an all-Microsoft stack and despite that it’s not working. Do MS still makes you think you need to pay for an Azure service to have WS in your app? It used to be the case.

ptrwis 3y ago

Blazor is not intended for websites, it is intended for enterprise, intranet CRUD applications with interactive forms, tables, etc. Especially if you already have .Net on the backend. I just finished one such application on Blazor Server and it works great. Programming was easy having previous experience with Angular. Edit: And the most important advantage, next to productivity, is maintainability, without the entire JS/TS/Node toolkit.

local_crmdgeon 3y ago
That made sense back in the day, but I can slap some crappy CRUD app together with Next and Formik in a few hours now.
DANmode 3y ago
But...back to the original topic, is drag and drop laggy for those use cases?
- mgh95 3y ago
  No. This website is slow because its a liveview style websocket on each drag and drop action. A wasm implementation would not exhibit these characteristics.
  - jiggawatts 3y ago
    Also, internal-use apps are typically accessed over the LAN with much lower latencies than random Internet users.
    - ptrwis 3y ago
      On the other hand, remote work is very popular today, but if employees want to work remotely, it's their problem to have a good internet. I tested the Blazor server on a poor cellular network where packets could be lost or there were random long delays in packet delivery, and the application was unstable. It was better to set long-polling and enable compression, which is disabled by default. This is also a problem with websockets - messages are not compressed. Long polling again was less resposnsive on good internet connection. I'm curious how this would work in various configurations of quic/http3.

4rt 3y ago

That looks to be some individual dev's dragdrop example made 4 years ago. Just because it's hosted on azure doesn't mean its a microsoft demo.

taspeotis 3y ago
I am not under any confusion as to whether it’s Microsoft’s or not. Nothing with Blazor I’ve seen is fast. That’s just the easiest example to show it.
- 4rt 3y ago
  This one seems ok https://www.mudblazor.com/components/dropzone#basic-usage https://www.mudblazor.com/components/dropzone#basic-usage
  - taspeotis 3y ago
    Uh... DOMContentLoaded: 4.61s Finish: 19.48s So it took 5 seconds to show me a splash screen, and another 15 seconds to actually start? It's 28 megabytes... https://pagespeed.web.dev/analysis?url=https%3A%2F%2Fwww.mudblazor.com%2Fcomponents%2Fdropzone%23basic-usage https://pagespeed.web.dev/analysis?url=https%3A%2F%2Fwww.mud...
    - Jochim 3y ago
      It took a while to start on my phone but the splash screen displayed instantly.
      - taspeotis 3y ago
        Damning with a hint of praise.

jiggawatts 3y ago

This is served out of the West Europe region. 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/publish-to-azure-web-app?view=aspnetcore-7.0#configure-the-app-in-azure-app-service 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-and-deploy/server?view=aspnetcore-7.0#azure-signalr-service 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.

deafpolygon 3y ago

This is pretty instant to me.