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