Regression: Syntax highlighting depends on WebAssembly

[L3P3]

• Web Browser: Mypal 29.0.1 (Pale Moon/Firefox)
• Local OS: Windows XP SP3
• Remote OS: Debian 10
• Remote Architecture: x86-64
• code-server --version: 3.9.0 fc6d123

With the previous code-server version, I was very productive with my favorite IDE on my favorite device which is still my daily driver for most things.
Now, syntax highlighting does not work anymore when wasm is not available.
In my opinion, we should make it possible to run code-server without wasm but with pure JS. There is a wasm-to-js polyfill available but I think it is better to just keep the JS version of things. I don't know how that wasm is generated by but usually, all wasm compilers also output asm.js which should work flawless too. Fixing this issue might be as easy as enabling asm.js fallback in compilation settings, which causes no overhead for wasm-enabled browsers but would also enable the others.
Hightlighting worked perfectly before, even with files with 10k of lines and I see no good reason for using wasm without fallbacks, it feels like cheating on the last steps to me, like using adobe flash or java applet just for one part of the app while 99% is done in JS. Then why not using java in the first place...
And I am honestly ready to pay for you to keep supporting bare JS environments.

I just found out that Mypal does in fact experimentally support wasm, using about:config. Syntax highlighting works again. Phew! But it still scares me that it is required... Consider this issue as a theoretical debate or flexing with Windows XP.

Full console history:

register.js:14:404: [Service Worker] registered 
workbench.web.api.js:4801:76: The web worker extension host is started without an iframe sandbox!
main.js:1:6795: no native wasm support detected

  ERR WebAssembly is not defined: r</<@node_modules/vscode-oniguruma/release/main.js:1:6836
t.loadWASM/<@node_modules/vscode-oniguruma/release/main.js:1:5293
t.loadWASM@node_modules/vscode-oniguruma/release/main.js:1:5275
_doGetVSCodeOniguruma@out/vs/workbench/workbench.web.api.js:5724:882

[jsjoeio]

WOW! I have not seen the Windows XP UI in a long time.

Not sure what could have changed in 3.9.0 that would cause this but will keep that in mind.

Syntax highlighting works again

Glad to hear that it's working again. Going to close this for now.

Consider this issue as a theoretical debate or flexing with Windows XP.

HA! Let's go with flexing with Windows XP 💪

[mmdjiji]

I met this problem yesterday, when I use Kiwi browser, it may not support WebAssembly so the syntax highlight cannot be display normally.

[L3P3]

I see no good reason for using wasm without fallbacks

I think this is still a valid point. It may be just one flag to set in the toolchain to also generate asm.js fallback in case wasm is not supported, which may be the case even in modern browsers on some machines.

[mmdjiji]

I see no good reason for using wasm without fallbacks

I think this is still a valid point. It may be just one flag to set in the toolchain to also generate asm.js fallback in case wasm is not supported, which may be the case even in modern browsers on some machines.

Did you mean, if the browser do not supply WebAssembly, use asm.js instead? It is a good idea because although in many situations WebAssembly is faster than asm.js, the compatibility of asm.js is higher than WebAssembly.

[L3P3]

Yes exactly. As stated above, most tools generating wasm can also output asm.js. The wasm loader then detects if wasm is supported and if not, it falls back to asm.js. asm.js does even work on pre-asm.js browsers but that is not important here since they will not support a lot of other crucial stuff.
Edit: If the tool cannot output asm.js by itself, there are multiple tools that convert wasm to asm.js!

[mmdjiji]

Cool, maybe you can put an issue then.

[L3P3]

I think this already is the proper issue. I could also try to make it work by myself but I had to get into this project and it would take much time I think.

[mmdjiji]

That's great! It is cool to make it work and merge to master.

[code-asher]

This is definitely interesting; I took a peek at the code and it looks like it's always relied on wasm without fallbacks but if it worked before there must be something I'm missing. Assuming this can be replicated in Codespaces it'd probably make more sense to raise this upstream rather than trying to patch it here.