Use of a dynamically typed language as runtime for a typed compiled language is a good design choice, and it has been done before this. A long time ago Axiom computer algebra system was implemented on top of Lisp.
This does not answer your question in full, but it will spare other people from telling this. I’d love if you get a great answer. I’m interested about this too.
You can also use other backends of the PureScript compiler. Then PureScript will produce a different output language (e.g. C) that can then use the specific module/import format of this language. It is also being discussed to use ES modules as an output format of the JS backend as module bundlers and Node.js now support ES modules as well.
The PureScript compiler does not need Node.js as it is written in Haskell. But the REPL compiles your expressions into JS and evaluates them in Node.js. Not all expressions are turned into JS code, e.g. the type system is obviously not part of the output. I am not sure if the backend of the REPL can be changed or if it simply uses the one your PS compiler uses.
Another thing to consider is the FFI. If a library makes use of the FFI, the FFI code obviously needs to be written in the compiler target language. And not only that, the FFI might make use of global variables that are only available in a specific runtime. The PureScript browser libraries bridge to JS code that uses DOM functions that are only available in the browser. Similarly a http server library might make use of the http module from Node.js and can only be used inside of Node.
Now there are a few use-cases where you might not need Node.js in your toolchain to create (and run) your build. E.g. when you are targeting a non-JS backend or when you just want to produce output files in CI (or a Docker multistage build).
Deno is not a JS runtime but a TypeScript runtime. While they recently made the decision to write internal modules in JS, I think the compiler would still have to output TS. All JS should be valid TS but there might still be type errors because the TS compiler is not able to correctly infer all types. So making PureScript run on deno might not be a simple task for this reason and all the reasons mentioned above.
First of all, thank you for the thorough write-up!
This paragraph entirely answers my question but other info you provided already takes care of my follow-up questions I had in mind.
Yes, this is what threw me off when I encountered the REPL error. Learning PureScript to also be able to try out purerl but I know that there are many other alternative backends so if PureScript would so tightly coupled with Node, it would certainly be a pain to port it to other languages.
Thanks for mentioning this! Just found the relevant discussions:
According to their website, it is both. (Not trying to put up an argument; will have to do a lot more research.) The work currently being done on ES modules will definitely make it easier to use it with deno though.