Cherry: ClojureScript to ES6 Compiler(github.com)
github.com
Cherry: ClojureScript to ES6 Compiler
https://github.com/squint-cljs/cherry
20 comments
> Genuine question: Why ES6?
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.
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.
That's true.
Maybe not CommonJS but a version of JS compatible with LTS Node. That way you can develop with ClojureJS also on the Back End.
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 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.
ES6 is compatible with Node out of the box.
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.
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.
The LTS version of node is now 18, which supports its special flavor of ESM.
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
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
ClojureScript already compiles to CommonJS with the built-in :target :bundle option.
I don't quite get how this differs from existing tooling such as shadow-cljs... is it the non-dependence on Google Closure?
Is anyone doing Clojure to Wasm?
Everyone is waiting for WASM to support garbage-collection (GC) officially. =)
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!
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!
Not everyone, anyone that cares is shipping their own GC implementation just as they have to in regular CPUs.
GC is "coming" since WebAssembly was announced.
GC is "coming" since WebAssembly was announced.
I'd love a Clojure(Script) that ran on Wasm, even if it bundled its own GC. One path through this would be the Gambit Scheme ClojureScript compiler.
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.
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.
How would you do that? Compile a JVM to WASM? A GraalVM to WASM image? Seems like it'd be too heavy for the web.
Clojure always builds on their host platform, that is why even its reader has conditionals for each platform.
A WebAssembly implementation would target the WebAssembly bytecode, and everything beyond the core forms would be based on WebAssembly ecosystem.
A WebAssembly implementation would target the WebAssembly bytecode, and everything beyond the core forms would be based on WebAssembly ecosystem.
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.