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