This isn't all JS-specific (in fact, most of it isn't), though I used JS for familiarity. I haven't tested or benchmarked this (part of why it's a draft PR), but I created the PR anyways just to help explain.

The long 104-line comment explains most of it, but there's a few key insights into this:

• Every object allocated in JS is allocated on the heap. (Even stacks are commonly heap-allocated.) In performance-critical code, it's common to avoid object allocation entirely. Temporaries that are immediately read from and dropped are typically optimized for and usually are only allocated in the really fast nursery, so the allocation cost here is relatively low (though still non-negligible in hot loops).
• CPUs do better if you can do everything in a row, and memory loads outside L1 cache tend to be significantly costlier than the computation. This is why I flattened the roots: to ensure that the inner loop is dealing with exactly one contiguous array. (I'm using a typed array to match idioms, but normal arrays are more idiomatic.)
• You should prefer a * sqrt(1 + (a/b)^2) for computing the two-dimensional Euclidean norm, as it's more numerically stable. (JS has a Math.hypot(...components) for this reason.) This happens to require an extra floating point division, but you can reclaim with a floating-point fma where available. (This applies across the board, though I see you're already using the WebGL distance function, so that's not an issue in the GPU code.)
• You can do a little math and take advantage of both sides being positive to only do one comparison in the inner loop - this may yield a moderate performance boost as you wouldn't need to do the 2 absolute values + 2 floating-point comparisons, but only one single comparison with an already-calculated result. I explain the math in the big comment as well. This holds for all variants, and would also simplify your SIMD condition substantially.

Also, separately, I have a couple larger nits:

• In the TypeScript stuff, using type Root = [number, number] and root: Root[] would be more idiomatic of a type for your roots. (You can also label them as [x: number, y: number] for added clarity.) Likewise, type Color = [number, number, number, number] + colors: Color[] would be clearer and more idiomatic. This would also cause the array's length to get checked for, so you wouldn't be as likely to accidentally forget an entry or add one too many entries.
• You're using 32-bit floating point arithmetic for WebAssembly, while JS uses 64-bit floating point arithmetic natively, so it's not really an apples-to-apples comparison. This should be made clear in the demo.
• In your SIMD calculation, {i,u}8x16_swizzle(a) may yield slightly faster code for the lane shifting than *_shuffle(a, a) due to better instruction selection, though that will need benchmarked.
• In your SIMD calculation, I would suggest loading chunks of 4 and doing let real = f32x4_shuffle::<0, 2, 4, 6>(a, b); let imag = f32x4_shuffle::<0, 2, 4, 6>(a, b); so you can do it in full batches of 4 using a similar algorithm to the scalar variant. This would require slightly more registers of course and it'd also complicate finding the matching lane (TL;DR: let lane_idx = i32x4_bitmask(f32x4_lt(square_norm, f32x4_splat(0.000002))).trailing_zeros(), lane found if lane_idx < 4), but you might derive a full 1.5x speedup from that if not more as you're doing even the expensive operations like sqrt fully parallel.