4 ms·

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 leav

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.

Mikeb85 4y ago
> 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.
- leidenfrost 4y ago
  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.
  - askonomm 4y ago
    You can already develop with ClojureScript on the back-end. A popular ClojureScript compiler, Shadow-CLJS (https://github.com/thheller/shadow-cljs https://github.com/thheller/shadow-cljs) has a target for Node among many others.
  - wiredearp 4y ago
    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.
  - kitten_mittens_ 4y ago
    The LTS version of node is now 18, which supports its special flavor of ESM.
- user5678 4y ago
cgdub 4y ago
ClojureScript already compiles to CommonJS with the built-in :target :bundle option.
brundolf 4y ago
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

Mikeb85 4y ago

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

leidenfrost 4y ago
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.
- askonomm 4y ago
  You can already develop with ClojureScript on the back-end. A popular ClojureScript compiler, Shadow-CLJS (https://github.com/thheller/shadow-cljs https://github.com/thheller/shadow-cljs) has a target for Node among many others.
- wiredearp 4y ago
  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.
- kitten_mittens_ 4y ago
  The LTS version of node is now 18, which supports its special flavor of ESM.
user5678 4y ago

cgdub 4y ago

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

brundolf 4y ago

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