Proposal: netscript apphosts should enable the Aspire browser-logs devtools integration by default (https://aspire.dev/integrations/devtools/browser-logs/?aspire-lang=typescript) so a Vite/Fresh app resource forwards its BROWSER console logs into the Aspire dashboard automatically.
Why: debugging a client-side failure in a durable-streams island (an ElectricSQL StreamDB consumer throwing TypeError: Decoding failed) was invisible from the server logs and OTEL — the only signal lived in the browser console. We had to hand-instrument the island with console.info/.catch to surface it. With browser-logs wired by default, the Aspire dashboard would have shown the client error immediately.
Also worth surfacing in the streams docs: the durable-streams runtime warns Using HTTP (not HTTPS) limits browsers to ~6 concurrent connections per origin under HTTP/1.1 ... Use HTTPS for HTTP/2 (electric-http2) — the local apphost serves the app over http, so multi-stream islands can starve connections.
Proposal: netscript apphosts should enable the Aspire browser-logs devtools integration by default (https://aspire.dev/integrations/devtools/browser-logs/?aspire-lang=typescript) so a Vite/Fresh app resource forwards its BROWSER console logs into the Aspire dashboard automatically.
Why: debugging a client-side failure in a durable-streams island (an ElectricSQL StreamDB consumer throwing
TypeError: Decoding failed) was invisible from the server logs and OTEL — the only signal lived in the browser console. We had to hand-instrument the island withconsole.info/.catchto surface it. With browser-logs wired by default, the Aspire dashboard would have shown the client error immediately.Also worth surfacing in the streams docs: the durable-streams runtime warns
Using HTTP (not HTTPS) limits browsers to ~6 concurrent connections per origin under HTTP/1.1 ... Use HTTPS for HTTP/2(electric-http2) — the local apphost serves the app over http, so multi-stream islands can starve connections.