But presumably if that was the eventually standardized format the compiler could ship with browsers, though, right? It just seems weird to compare against another format that hasn't been agreed to either but they shipped the compiler with the browser preview so people can test it.
It should either be comparing sources or comparing (source + compiler to get it working in a shipping stable browser), not mixing the two.
The proposal from SPIR-V advocates is to not ship any high level language compiler with the browser. That could change, but currently no one is excited about accepting both a binary language and a text-based language.
Why would you expect people to ship a compiler though? Like: when I want to do runtime code generation on .NET, I don't concatenate strings containing C# and run them through a C# compiler... that would be madness!!... instead I use the APIs provided to do IL generation, which have been extremely amazing essentially since day one and provide unbounded flexibility over working with any specific textual language. If I really really wanted a compiler at runtime, maybe I want a different one, and I can then use differently models like F# or a Lisp variant... things that are much harder if someone insists I translate everything into some silly specific language :/.
Shipping support for both a text format and a binary format directly in the browser is in some ways the worst of both worlds. If both are implemented natively, you get double the attack surface at the ingestion layer. If the text format is supported by compiling to the binary format (or vice versa) using WASM that happens to ship with the browser, it will probably be slow (whereas ingesting a text format directly seems pretty fast).
It should either be comparing sources or comparing (source + compiler to get it working in a shipping stable browser), not mixing the two.