JS is a much better compile target. WebAssembly doesn't have GC and it's just not geared towards dynamic languages.
You might attempt the equivalent of a native code compiler for Clojure but just targeting WebAssembly, plus a low level runtime implementing GC and JS interop, but it's a lot of work and there's no guarantee it would be competitive since JS JITs are quite good.
As for the compilation target, It may be better compile to CommonJS as well, so you can base your entire project in Clojure and leave the target as the production build, like Babel does.
You can already develop with ClojureScript on the back-end. A popular ClojureScript compiler, Shadow-CLJS (https://github.com/thheller/shadow-cljs) has a target for Node among many others.
You can `import` and `export` just like in the browser (and in TypeScript) as long as your files come with the `.mjs` extension. Cherry adds this extension by default, so I imagine it comes with the server in mind.
You can also keep the `.js` extension and configure this behavior in the `package.json` to run the same files both client- and serverside.
Some libraries still expect to run as CommonJS, but then you might find an "es" version if you poke around in their repositories.
I'm imagining they don't want to deal with transpiling for maximum browser compatibility, or with bundling; there are existing tools that do those things really well and you can always feed the output of this through those if you want those qualities
Targeting ES6 will yield simpler, more readable compilation output (which is a stated goal of the project). It can also preserve module boundaries while keeping client-side support, which is not something you could do with CommonJS. And they mention other things like async/await support, which would be a huge pain to try and implement yourself instead of leaning on the target language
20 comments
[ 5.5 ms ] story [ 62.4 ms ] threadA WebAssembly implementation would target the WebAssembly bytecode, and everything beyond the core forms would be based on WebAssembly ecosystem.
You might attempt the equivalent of a native code compiler for Clojure but just targeting WebAssembly, plus a low level runtime implementing GC and JS interop, but it's a lot of work and there's no guarantee it would be competitive since JS JITs are quite good.
Clojure has Javascript, JVM, .NET, LLVM, Arduino, GraalVM, etc. targets, so rest assured, a WASM version will come out as soon as it makes sense!
GC is "coming" since WebAssembly was announced.
As for the compilation target, It may be better compile to CommonJS as well, so you can base your entire project in Clojure and leave the target as the production build, like Babel does.
Because CommonJS is dead and only continues to be supported because of all the old NodeJS stuff written in it.
The whole point of ClojureScript is to target the browser since Clojure itself targets the backened; well every browser supports ES6.
Maybe not CommonJS but a version of JS compatible with LTS Node. That way you can develop with ClojureJS also on the Back End.
You can `import` and `export` just like in the browser (and in TypeScript) as long as your files come with the `.mjs` extension. Cherry adds this extension by default, so I imagine it comes with the server in mind.
You can also keep the `.js` extension and configure this behavior in the `package.json` to run the same files both client- and serverside.
Some libraries still expect to run as CommonJS, but then you might find an "es" version if you poke around in their repositories.
Targeting ES6 will yield simpler, more readable compilation output (which is a stated goal of the project). It can also preserve module boundaries while keeping client-side support, which is not something you could do with CommonJS. And they mention other things like async/await support, which would be a huge pain to try and implement yourself instead of leaning on the target language
> Compiled JS files are linked to one shared NPM module "cherry-cljs" which contains cljs.core.js, cljs.string