Fork me on GitHub

So maybe not the direction most folks would go, but what's it like to call a function in a clojurescript library from JavaScript? I'm really excited about the odoyle-rules lib and see a ton of value in it, but not sure how I'd go about passing data to it and stuff and calling it from JavaScript.


Here's an example: I specifically wrote the library to be callable from both. Not sure if the one you're looking at was so kind.


You can call cljs.core.js-GTclj from the js side to convert js structures to cljs if the library won't accept them as is


Thank you very much! Given I can't even figure out how to compile the js bundle I have road ahead of me it appears!


what's the relationship between closure compilation and runtime introspection? eg. the renaming it does, is that just to reduce bundle size or does it significantly speed up javascript interpretation? one could imagine using some sort of map to make clojurescript REPLs work post advanced optimization? ( [clojurescript form]) -use rename-map-> ([clojurescript form with munged names]) -> engine, are there other optimizations that it's doing which make the post-advanced-compilation runtime significantly different? Like advanced tree shaking, inlining etc? Very broad question so I'd appreciate a link to the right place to read about this


Yes, there's DCE, there's code inlining, there's name reuse. All make it harder for a REPL to work in production.


does anyone do it? it seems like bootstrapped clojurescript might make it a bit easier


Yeah, as far as I'm aware people just go with the bootstrapped option. That's how e.g. online CLJS REPLs are made.


as in, they don't use advanced compilation they push everything through a bootstrapped interpreter?


I'd say "yes" but I wouldn't trust me too much on the matter - I myself have only done that once, and without a full understanding of the whole process and how exactly it works.


you could almost imagine specifying what to compile and what not to, or if bundle size weren't an issue, 'decompiling', as in either bootstrap-interpreting or switching over to a pre-shipped less-compiled version of the code on demand. You'd need to like re-point variables somewhere underneath, but clojurescript doesn't have 'real' vars in a way I've never fully understood


typically people who make online REPLs compile their application using simple optimizations (i.e. local variable & function parameter renaming, whitespace removal, and comment removal) and ship the self-hosted clojurescript compiler along with their application


AFAIK the self-hosted ClojureScript compiler does not work with advanced optimizations


another option these days is to use sci, which is lighter weight than the ClojureScript compiler and can work with advanced optimizations, but isn't as fast since it's fully interpreted. if I were building a REPL that didn't necessarily need full CLJS compatibility, I would probably choose sci


Self-hosted Clojurescript is not interpreted. It's basically the Clojurescript compiler all in Clojurescript with the Java dependencies replaced by the Google JS Closure compiler.


That allows a Clojurescript REPL to read and compile the text forms sent to it to JavaScript at runtime without needing Java/Clojure to be available.


You could probably still have a REPL in an advanced optimized app, assuming Self-hosted Clojurescript could be compiled as such as well, but it be missing a lot of functions that were explicitly removed during compilation, some functions would have been inlined and so won't exist in the shape you expect, and the names of everything will be garbage, so it's quite pointless I think. You're right that technically you might be able to reverse map things back, but since it's Google Closure that does all the optimization, you'd probably have to modify it so it also produces some kind of reverse map of the transforms.