Hacker News new | ask | show | jobs
by DANmode 981 days ago
But...back to the original topic, is drag and drop laggy for those use cases?
3 comments

In Blazor Server, for things like drag and drop or any mouse movement events, you should avoid tying them to server-side handlers, but you can also just write JavaScript code. The backend needs to know what to render, not necessarily where, you can keep it on the frontend.

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.

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.
Also, internal-use apps are typically accessed over the LAN with much lower latencies than random Internet users.
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.
It's possible to enable compression for WebSockets, but the real problem is latency, not bandwidth. You can't fix the speed of light.
Blazor on Webassembly is not really slower than react or angular. Just the initial load (which is very cacheable) is the problem.