Clojurians Log v2

@chris358 has joined the channel

I think we could make ES6 output vs .cjs or whatever else output configurable, so the compiler API gives you some options, for e.g. when you want to integrate the compiler in a REPL, browser, etc. Reloading ES6 modules is a bit painful so having some "dev" mode or "playground" mode vs "optimized build" mode could be a good idea.

would love it if cherry wouldn’t inherit the closed world assumption of closure

Well, es6 modules are closed for a reason, I think. It makes analyzing / caching / tree-shaking / etc a lot easier. So having the es6 module is good, but in some scenarios you might just want to get a JS snippet and js/eval that inside a browser, while not having the import and export stuff. There's also this: https://github.com/borkdude/cherry/issues/24

I opened an issue for the configurable output: https://github.com/borkdude/cherry/issues/23

I believe @jackrusher has some ideas about how it can be done with es6 modules.

OK, opened an issue to discuss the reloading aspect: https://github.com/borkdude/cherry/issues/25

Also opened an issue about the macro approach: https://github.com/borkdude/cherry/issues/4 I see two possible scenarios: • Macros are ran in SCI during compilation, no emission to .mjs for macros • Macro namespaces are transpiled first, then dynamically loaded in the compiler and then ran during compilation

The first option would also allow cherry to be ran inside JVM / bb, etc. since macros aren't loaded from .js files in that case. But it would also force you to keep the macro sources around when you distribute a library

So until google closure figures out how to produce ES6 module output, I think we're left with 300kb apps at minimum for cherry. See https://github.com/borkdude/cherry/issues/24

Maybe not too bad and for multiple libs written with cherry, they'll still be able to interop with each other and other JS libs, so no extra kbs for those use cases

Or... until cherry can transpile cljs.core itself to ES6 ;) loading

I'm figuring out if google closure can do a pass over a cherry-compiled file which uses the (already advanced compiled) cherry module.

npx google-closure-compiler --js=index.mjs

Alright, this worked!

npx google-closure-compiler --module_resolution NODE --compilation_level ADVANCED  --js=node_modules/cherry-cljs/lib/cljs_core.js --js=node_modules/cherry-cljs/cljs.core.js --js=index.mjs  --js_output_file=dist/out.js --language_in ECMASCRIPT_2020

160kb

And when adding a core function, like prn and assoc etc, it gets slightly bigger, like 10kb extra. But this seems to work :)

This is the output for:

(ns index)

(prn (assoc {:a (+ 1 2 3)} :b 1)
     (range 20))

Seems to work in browser as well

what's your dev workflow like? In js land https://vitejs.dev/guide/why.html and https://vitest.dev/guide/why.html seem to be the choices du jour for es6 modules. I guess cherry should work well with those?

cherry + vite.js https://twitter.com/borkdude/status/1552308825310494721 😎

Pushed the vite code example so you can play around locally: https://github.com/borkdude/cherry/blob/main/examples/vite/README.md

vitest: https://twitter.com/borkdude/status/1552369264866230275 (cc @mkvlr)

@borkdude nice, looks pretty snappy as well

could become even snappier when cherry exposes an API to be used in Node, currently I'm launching node on every change to recompile .cljs

and with source map support, perhaps this tool will also show the right .cljs location

could the compilation also run in the browser without node?

it could yes, the compiler is pretty simple, just a string -> string translation

and wondering if this could be useful for self-hosted tests

right now it's coupled with node.js fs to read files but that has to be split out from the compiler core thing to make it work with browsers