This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws (1)
- # aws-lambda (1)
- # beginners (34)
- # boot (61)
- # cljs-dev (126)
- # cljsjs (10)
- # cljsrn (4)
- # clojure (27)
- # clojure-russia (7)
- # clojure-spec (1)
- # clojure-uk (26)
- # clojurescript (42)
- # cursive (31)
- # datascript (4)
- # datomic (16)
- # hoplon (51)
- # klipse (1)
- # lein-figwheel (1)
- # lumo (79)
- # off-topic (16)
- # om (7)
- # parinfer (5)
- # planck (2)
- # re-frame (6)
- # reagent (3)
- # ring-swagger (5)
- # untangled (11)
(sorry, invited @logbot so chat can be logged here without breaking the clojurian-wide 10k message limit https://clojurians-log.clojureverse.org/lumo/index.html )
Node + Cljs (via lumo) could be a massive benefit. Cljs is a much better language than JS, so bringing cljs to a much wider audience could be a big win. But only if the extensions story is worked out. And you don't often get the chance to discuss trade offs ahead of time
So I'm really keen to see some views here, especially from those with prior JS experience. I don't have any strong opinions here myself
i’d say it only makes sense to publish es5 to npm, but to keep cljs dependencies on maven
the problem is that tools like planck/lumo have to handle dependencies like this: http://planck-repl.org/dependencies.html
I'd really like guidance on this. I'm keen to publish a cljs version of juxt's aero (config) tag literals (for edn). But should I precompile first? And where to publish?
I'm sure some people who don't know exactly what they're doing might publish ES6 stuff 🙂
@malcolmsparks tagged literals for cljs should be published on maven, do you know how to do that?
these get added to the java classpath so they’re compiled with your clojurescript project
I'm keen not to neutralise all the effort gone into lumo and its superfast startup by throwing my uncompiled stuff to compile
I agree we should have a way to publish "aot" artifacts for Lumo/Planck to consume
When we end up building the whole tower again on lumo, in uncompiled form, aren't we back where we started?
that's what the CLJS compiler needs to consume in order to know which vars are in which namespaces
But I'm happy publishing JS to npm too. (And Mach is getting to be capable enough to automate these chores for me)
Would compiling to js take away any analysis & development (e.g. autocompletion) capabilities from the future away?
the analysis cache is what goes into the ClojureScript compiler environment, it's how it knows that a namespace has certain vars
@anmonteiro what would read the analysis cache? Would new tooling need building around it?
Lumo would consume the analysis cache and dump it into the CLJS compiler environment
the only piece missing is probably just tell Lumo to look for AOTed namespaces in JARs it consumes
@anmonteiro is my understanding correct that the analysis cache is a lossless step that is pre-js and is the bulk of the compilation time to generate?
That sounds perfect for going in then, and completely quenches my concerns about the general concept of aot'ing cljs.
ClojureScript already does that for
cljs.core, if you use the
:classifier "aot" artifact from Maven
Interesting. Do you happen to know if that's a heavy source of compilation time in many projects?
I guess this is also where boot loses in performance for some clojurescript, as it throws away caches regularly.
cached analysis during development means you won't get arity errors, undeclared vars, etc
Interesting, so this is aot’ing the clojure into bytecode and the cljs into js+analysis?
A problem with including AOT artifacts in published JARs is that the artifacts are tied to a compiler version. (The ClojureScript compiler ignores them on a version mismatch.)
Perhaps shipping libs could be built in "release" mode, enabling both options, and the broader issue of version compatibility could be solved in some way.
Maybe this has never mattered much for JVM ClojureScript given Closure is usually used.
Since Lumo and Planck (and any self-hosted implementation) can cache, I suppose the issue isn’t huge—you can take the hit of compilation only on first hit when using a library, and then after that things are fast.