Ah, if it's blank, then it blew up really early. It sounds like it's complaining about the use of ES modules. This script is loaded with `<script type="module"

Ah, if it's blank, then it blew up really early. 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://birchlabs.co.uk/box2d-wasm-liquidfun/liquidfun.gif https://birchlabs.co.uk/box2d-wasm-liquidfun/liquidfun.gif