I'm wondering if I could find somewhere a complete list of modules/features that are not supported for the JS backend. (I'm not talking about NodeJS, just plain JavaScript).
I've read this, but it seems to me like every time "I know" what will work, in the end I discover something else is missing.
So, is there some list like that?
Here is a test for which modules can be imported in JS, though there are some missing new modules. So they compile, but not necessarily work (for example, initOptParser in parseopt is essential for use of the module, but was specifically the only proc not available for JS & nimscript). Some amount of modules will compile, but shouldn't, due to importc having a use in JavaScript and a routine that doesn't exist in JavaScript being imported, and some will use cstring in a way that JS does not support.
It's not hard to go through the module yourself and see if it will work in JS, if it uses ptr``s or ``cast``s or ``importc``s a C function or utilizes the pointer behavior of ``cstring, then it's likely going to fail. For example, httpclient imports nativesockets, which, as you can tell from the name, uses native OS socket functions, so it's not supported in JS.
It would definitely be great if we had compile time errors for modules that we won't work for backends like JavaScript, but this takes work to add to every single module, and there's no single agreed upon way to do it. For example, in the os module, paramStr and paramCount for Nintendo Switch (and inadvertently JS) give a runtime error instead of a compile time one. Perhaps runtime errors are less restrictive, but should they be? Wouldn't it get rid of pointless overhead if we accounted for these at compile time?
Basically, you can get some ideas of which modules will work in what backend, but it might take some effort to, and you should know that this is being considered as an issue and could be made easier in the future.