tree d233eedf489381adea1ee870026e5e87cbd05ce0
parent 1fadc01a78f67f0599e98d91d36b1472b8b7f2c1
author mjtalbot <hello@rive.app> 1715180963 +0000
committer mjtalbot <hello@rive.app> 1715180963 +0000

Wasm fallback and min safari version

### This PR
- fixes WASM not loading on older Apple devices/browsers
- adds a fallback mechanism

#### Fix for older devices
The addition of `MIN_SAFARI_VERSION` is the only flag that resolved the issue on the affected devices (see discussion: https://2dimensions.slack.com/archives/CLLCU09T6/p1714494911457529)

#### Fallback
This PR is meant to showcase a way to introduce a fallback mechanism quickly. Can it be merged? Yes. But we need to consider the impact and alternatives (see below). _Also note that this PR makes an assumption about the best way to handle our single packages, which needs to be discussed before merging (see below)._

#### Problem with this fallback
We'll increase the NPM package size by having two WASM files: `rive.wasm` and `rive_fallback.wasm`. To alleviate any concern, this can be resolved with proper documentation. The packages that load the WASM remotely do so through `unpkg` or `jsdelvr` (or overridden manually). It would not have an impact on the actual end client (to my knowledge), but maybe the perception of the "increased" NPM package size is something we want to avoid.

#### Benefit of this approach
Quick, with minimal change. We continue to use `unpkg` and `jsdelvr` to host.

#### TODO
Adaptive Loading: Implement more sophisticated loading strategies, such as loading different WASM modules based on the user's browser capabilities or preferences. This draft PR only loads the fallback if the current one failed. This does not need to be part of this PR and can be a future enhancement.

### Single vs Non-Single versions
**This fallback mechanism will only work for the non-single packages where we load the WASM bundle separately**. Not the **-single versions, where WASM is bundled with the JS. In my testing during the call to `loadRuntime` the callback for `locateFile` will not be called if Emscripten is built with `-sSINGLE_FILE=1`.

At the time of making the draft PR I've not come up with a solution for this. It might not be possible.

TODO: This needs to be investigated more. Or we should reach out to Emscripten.

#### What this means
If we can't create a fallback for these, then we should make a decision around our single libraries:
- Should they prefer to support older architecture and we recommend that people use the non-single packages to benefit from the fallback mechanism.
- Or the alternative and we still recommend using the non-single packages to benefit from a fallback.

**There are other benefits to using the non-single:**
- Streaming Compilation: Newer browsers can start compiling the WASM file as soon as it starts downloading, which could lead to faster execution start times.
- Better Cache Control: JavaScript and WASM can be cached separately. If you update one, users may not need to re-download the other. With the single version, I can see how people may end up using it in a way where any update to their site might then be bundling everything again.

### Alternative One
_Most of the above still apply._

Instead of adding `rive_fallback.wasm` to the current packages, we create another NPM package called `rive_fallback` or something. And all this package is responsible for is to distribute the fallback WASM files, for example, `rive_canvas_fallback.wasm` and `rive_webgl_fallback.wasm`.

**Benefit**
We do not increase the perceived NPM package size for our published packages. And we can continue to use `unpkg` and `jsdelivr` for hosting.

### Alternative Two
_Most of the above still apply._
We build our own hosting with versioning, etc.

Diffs=
4342a3f04 Wasm fallback and min safari version (#7214)

Co-authored-by: Gordon <pggordonhayes@gmail.com>
Co-authored-by: Maxwell Talbot <talbot.maxwell@gmail.com>