wasm improvements

project.cpp

@@ -192,7 +192,31 @@ extern "C" Configuration CrafterBuildProject(std::span<const std::string_view> a
         // JS glue shipped alongside the .wasm so the loader has the
         // env-import surface the Window/Dom bindings expect.
         cfg.files.emplace_back(fs::path("additional/dom-env.js"));
-        cfg.files.emplace_back(fs::path("additional/dom-webgpu.js"));
+
+        // dom-webgpu.js is opt-out via --no-webgpu, for apps that only use
+        // the Dom/Router partitions and never touch Device/RTPass/UIRenderer.
+        //
+        // Three reasons a DOM-only app wants it gone, in increasing order of
+        // severity:
+        //   1. It is ~182 KB (47 KB gzip) of dead weight.
+        //   2. Its init is an async IIFE that runtime.js awaits before
+        //      _start(), and that init does `await navigator.gpu
+        //      .requestAdapter()` — so every page load blocks wasm startup on
+        //      a GPU adapter request, including on machines with no GPU.
+        //   3. Worst: when navigator.gpu is absent it REPLACES
+        //      document.body.innerHTML with an error message and throws, so
+        //      _start() never runs. For a server-rendered page that means the
+        //      real content is destroyed and replaced with a WebGPU warning on
+        //      any browser without WebGPU support.
+        //
+        // Safety: with --gc-sections an app that never calls into the WebGPU
+        // partitions emits no wgpu* env imports, so omitting the bridge links
+        // and instantiates cleanly. An app that DOES use WebGPU and passes
+        // --no-webgpu anyway fails at instantiate with a missing-import error
+        // naming the specific wgpu* symbol.
+        if (!opts.Has("--no-webgpu")) {
+            cfg.files.emplace_back(fs::path("additional/dom-webgpu.js"));
+        }
     } else {
         std::array<fs::path, 14> impls = {
             "implementations/Crafter.Graphics-Clipboard",