It sounds like it's complaining about the use of ES modules. This script is loaded with `<script type="module">` and uses ES imports (`import App from './App.svelte'`).
Yes, Safari is expected to go bang (doesn't support module Workers).
I target Chromium's featureset — I developed on macOS Edge. macOS Chrome and Android's Chrome WebView work for me too.
It needs a few modern features in order to work:
- Web workers
- WebAssembly
- top-level await (on Web, and in Worker)
- ES modules + imports (on Web, and in Worker)
- requestAnimationFrame in Worker
- WebGL2
- OffscreenCanvas
Most of these were chosen for "ease of development". With bundling, it'd be possible to eliminate the ES modules / await usage. WebGL2 isn't strictly necessary either. WASM + workers are widely supported.So the primary blocker to Firefox support is support for OffscreenCanvas, and requestAnimationFrame in Worker. There's other options there: render on the main thread instead. Harder to develop (syncing timing + state between threads). Can probably be done performantly with SharedArrayBuffer.
In truth, I did include error-handling to provide a compatibility explanation if the worker explodes. This displays in Firefox. But I hadn't expected the main thread to explode too.
Here's a GIF of what it's supposed to look like!
https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCa...
nor does it support top level await
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
But I'm not sure using top level await was a good idea at this time. Can't really open it in Firefox mobile either (due to import syntax).