Ich würde gerne einen SSE (Server-Side-Events) Client in C# für Blazor WASM nutzen (suche grad nach einer fertigen Lib, andernfalls implementiere ich selbst...) und lese mich dazu gerade ein.

Eine ähnliche Frage wurde bereits in einem anderen Thread gestellt.
Damals hatte Abt u.a. kommentiert

Zitat

Client SSE (über Event Source) aus Deinem Code mit C# ist so in der Form nicht 1:1 heute möglich (weils Blazor noch nicht kann, rudimentär eben SignalR);

Ich frage mich nun: Warum ist das so? bzw. warum sollte das so sein? Meinem Verständnis nach kann man doch in Blazor WASM den HttpClient nutzen und damit sollte das doch implementierbar sein. Oder gibt's da ein Problem dass ich grad nicht sehe bezüglich des Streamings der Response?

Hintergrund: Ich bin grad dabei eine Blazor WASM Anwendung zu entwickeln die eine API mit SSE nutzt (Openhab). Ich bekomme das "problemlos" hin, in dem ich JS verwende - aber dafür benötige ich dann JS-Interop in beide Richtungen (daher die Anführungszeichen...). Ich fände es natürlich schon besser, dass dann komplett in C# zu machen - schließlich nutz ich ja (auch) deswegen Blazor

Bart Simpson

Zitat

Ich fände es natürlich schon besser, dass dann komplett in C# zu machen - schließlich nutz ich ja (auch) deswegen Blazor

So ganz stimmt das Verständnis zu Blazor nicht ;-)

Blazor ist kein wirkliches/nur teilweise Replacement für JavaScript, sondern ein WebAssembly-basiertes SPA. Das heisst, dass Blazor mit Angular/React/Rust/Go konkurriert, und nicht mit JavaScript.
Ein WebAssembly SPA hat jedoch bzw. kann JavaScript-Anteile/-Komponenten haben.

Willst Du Blazor machen, dann wirst Du sehr wahrscheinlich auch immer auch JavaScript machen (müssen). Das liegt einfach daran, dass gewisse Dinge entweder von Blazor oder von WebAssembly (als Basis) nicht unterstützt wird oder einfach noch nicht umgesetzt sind, und man dann mit JavaScript arbeiten muss.
"Blazor without JavaScript" funktioniert für die einfachen Fälle, aber ich würde mal behaupten, dass das eher die Marketing-Demos sind als die reellen Projekte. Ich kenn kein Blazor Projekt (selbst einfache Apps) in der realen Welt (zumindest in meiner B2B-Industriekunden-Welt), das ohne JavaScript (Workarounds) auskommt. Die meisten Workarounds hier betreffen aber die UI, einfach weils dafür nichts in WebAssembly gibt.

Schau unter die Haube von Blazor oder vielen Custom Blazor Components, und Du findest Tonnen von JavaScript.

Zitat

Warum ist das so? bzw. warum sollte das so sein?

Auch hier: nicht alle Dinge, die man aus der JavaScript-Welt kennt und standardisiert sind, sind heute in WASM verfügbar. Und nur wenn etwas in WASM verfügbar ist, kann es Blazor auch ohne JavaScript nutzen. Ansonsten ist JS Interop das Fallback.
Bisher gab es insbesondere beim Streaming einfach WebAssembly Limits (WASM in Browser), weshalb der einzige Workaround dann JS Interop war.

Das ist aber nicht nur in Blazor so, sondern gilt für alle WASM "Frameworks", egal ob Rust, Go und Konsorten.

Kann auch sein, dass das mittlerweile geht; Ende letzten Jahres / Anfang diesen Jahres ging das nicht ohne Workarounds.

Hab gerade mal die letzten Issues so angeschaut:
Blazor Support Large File Uploads
Blazor Server & WebAssembly cannot read large file streams from client · Issue #27862 · dotnet/aspnetcore
[Blazor server] Blazor server improvements for 6.0

Im dazugehörigen Pull Request sieht es so aus, dass JS Interop Workarounds bei Streaming weiterhin Alltag sind, aufgrund von WASM Limits.
Blazor WebAssembly & WebView JS to .NET Streaming Interop Support