Cherry: ClojureScript to ES6 Compiler | Hacker News Reader

Cherry: ClojureScript to ES6 Compiler

github.com

75 pointstosh18 comments

Genuine question: Why ES6?

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.

> 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.

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.

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.

The LTS version of node is now 18, which supports its special flavor of ESM.

ClojureScript already compiles to CommonJS with the built-in :target :bundle option.

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

I don't quite get how this differs from existing tooling such as shadow-cljs... is it the non-dependence on Google Closure?

There’s no runtime. Also shadow-cljs is not a compiler, it uses the main ClojureScript compiler.

There's a core library like with current ClojureScript, no?

> Compiled JS files are linked to one shared NPM module "cherry-cljs" which contains cljs.core.js, cljs.string

Is anyone doing Clojure to Wasm?

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.

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.

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!

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.

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.

Reply on news.ycombinator.com