>UPDATE
> An earlier post described performance problems on Firefox and Safari, which were related to the Proxy object. This feature is used to read values from WebAssembly into JavaScript.
> After changing to Object.defineProperty() all browsers are equally fast on WebAssembly, beating JavaScript in all cases.
The update at the bottom is kind of interesting. All browsers are equally fast, which makes sense because wasm should speak directly to the hardware more easily than javascript.
This is also just because APIs like Object.defineProperty are old and well-optimized, while Proxy (in comparison - it's not THAT new) is relatively new and not optimized because it is rarely used. Part of the reason it's rarely used is that it's very slow :-)
That is generally how web platform optimization goes, yes. Browser vendors optimize the stuff that gets used most, which means new APIs tend not to get used much unless they fill a gaping hole.
A word about my C64 emulator: this is very CPU hungry, partly because the 6502 emulation uses a cycle-stepped model (https://floooh.github.io/2019/12/13/cycle-stepped-6502.html), this causes the 6502 emulation to store and load context in each cycle which pretty much eliminates the opportunity that emulator state can be kept in registers across cycles, it also does an indirect jump for each cycle instead of just once per instruction. More importantly though, the VIC-II emulation isn't very optimised, every cycle updates the entire chip state, sprite units and all (the VIC-II emulation dominates the per-frame budget much more than the CPU) - in general the implementation of the entire emulator is fairly straightforward, but also fairly brute-force.
When looking at emulator benchmarks it's always important to also look at how the emulator has been implemented, and what compromises an emulator might make to balance between performance, accuracy and "design purity" (e.g. the cycle-stepping CPU model isn't all that useful in practice, except that it is 'more pure' and interesting from an emulator-design point-of-view). In comparison to those implementation differences, the performance difference between WASM and JS should be mostly negligible.
The update at the bottom is kind of interesting. All browsers are equally fast, which makes sense because wasm should speak directly to the hardware more easily than javascript.