This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-01-23
Channels
- # announcements (1)
- # babashka (13)
- # cherry (12)
- # cider (6)
- # clj-kondo (3)
- # cljs-dev (28)
- # clojure (77)
- # clojure-europe (25)
- # clojure-nl (1)
- # clojure-norway (35)
- # clojure-uk (5)
- # clojurescript (31)
- # conjure (7)
- # cursive (12)
- # data-science (9)
- # datalevin (5)
- # datomic (8)
- # hyperfiddle (21)
- # jobs (7)
- # kaocha (19)
- # malli (26)
- # matrix (3)
- # releases (1)
- # shadow-cljs (42)
- # squint (95)
- # testing (2)
- # vim (14)
- # wasm (1)
thank you @thheller for shadow-cljs, I managed to compiel ClojureScript to Wasm with it and cherry 🙂
platform independent apps. simplified deployments (drop docker), improved security , because I can
hehe. did you do some comparison benchmarks? I'd be curious how it compares to just directly running the JS
no, I just tried it this morning and was very excited about being able to compile cljs to wasm
I would like to do a cli app, a web service and see how I could implement wasm plugins for something
WASM allows you to run LibreOffice in a browser ! among other things - it's the next BIG thing
Yeah, I know roughly what it is, just not on a level where I can ask interesting questions. But always cool exploring new areas, will be interesting to see what you do with this 😊
is there a js -> wasm compiler? I've been wanting to write a compiler for a subset of cljs through binaryen just for shared memory maps, seems like a pretty doable project
I want to be able to compile/load/eval wasm modules from the cljs repl, need to find a few weeks though
this is trivial? if talking about actual WASM files ONLY, as in not those that come with some extra glue JS code
I mean wasm modules that are written in some subset of cljs, that exports persistent data sturctures which interop with cljs
I looked a little and I don't think it's that bad 😛 wasm gc is pretty high level and binaryen even higher
my expectation is that CLJS via wasm is at least an order of magnitude slower than just running the JS, but I'd love to be proven wrong
Is there a way to provide a build variable from shadow-cljs.edn to a clojure defmacro? I have a defn* macro that traces execution of defined via it functions, atm I'm looking for how to enable it depending on whether it's a :dev or :release build.
by build variable, do you mean closure-defines?
Usually closure-defines are supplied a value from the environment using the #shadow/env reader fn like #shadow/env "API_HOST"
. So if your variable lives in the environment, you could just use something like ~(System/getenv "env")
in your macro to get the functionality you want since all macros live in Clojure land.
the macro env has a (:shadow.build/mode &env)
, it'll be :release
for release builds, otherwise :dev

obviously shadow-cljs only though, for others you might want to go with :closure-defines
route
Ty, folks!
Is there a way to do this - I have a module called "dev-tools" in which I require a few dependencies and give users a set of tools for bug reporting and testing my app. I am looking for a way to make this available on staging server only, while the production server bundle should not contain any of it, neither the module nor any of the dependencies the module pulls in. Can it be done?
I'm assuming you meant setting that up under :builds
in shadow-cljs.edn, staging build with the dev module included and production one without. I'm trying to set it up like that but running into issue, this module is supposed to be lazy loaded so when not present shadow.lazy/loadable is complaining about it: "`Encountered error when macroexpanding shadow.lazy/loadable.`
Could not find module for ns ...
". I don't know how to get around that issue for the production version where dev tools module is not meant to be included.
yeah I'm not exactly sure what you are after. you can just not use shadow.lazy to load the optional thing
did you check a build report https://shadow-cljs.github.io/docs/UsersGuide.html#build-report
maybe all the extra code you worried about is in that extra module and not a problem?
You are absolutely right! Turns out I referenced some of the dependencies from that module in the main app module which is why they ended up in the main app module and not in the lazily loaded dev-tools module. Once I removed those references, all the code I was worried about went to dev-tools module, which is exactly where it should be. Considering it's lazy loaded, the solution could be as simple as not displaying the link to it on production server and it won't get loaded. Thanks!