Fork me on GitHub
#shadow-cljs
<
2024-01-23
>
Eugen11:01:37

thank you @thheller for shadow-cljs, I managed to compiel ClojureScript to Wasm with it and cherry 🙂

🔥 2
thheller11:01:47

why would you do such a thing 😛

Eugen11:01:33

which thing? ClojureScript to WASM ? where do I start 🙂

Eugen11:01:43

platform independent apps. simplified deployments (drop docker), improved security , because I can

thheller12:01:40

hehe. did you do some comparison benchmarks? I'd be curious how it compares to just directly running the JS

Eugen12:01:24

no, I just tried it this morning and was very excited about being able to compile cljs to wasm

Eugen12:01:50

I am going to play around with this more in the future

cjohansen12:01:32

How does the output bundle size compare?

Eugen12:01:37

I would like to do a cli app, a web service and see how I could implement wasm plugins for something

Eugen12:01:00

well, plain cljs gets a 2.1 MB wasm

Eugen12:01:16

adding in cherry (to evalaute cljs from wasm) gets us 6.8 mb

Eugen12:01:33

right now I don't care that much about this

cjohansen12:01:52

I don't know anything about wasm, so I'm probably asking irrelevant questions 😄

Eugen12:01:32

WASM allows you to run LibreOffice in a browser ! among other things - it's the next BIG thing

Eugen12:01:49

and IMO will change a lot how we do things

cjohansen12:01:49

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 😊

nivekuil12:01:14

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

Eugen12:01:48

look at javy / qucikjs

nivekuil12:01:32

oh, you embed the js engine. can't really interop with it then right

nivekuil12:01:23

I want to be able to compile/load/eval wasm modules from the cljs repl, need to find a few weeks though

👍 1
thheller12:01:35

this is trivial? if talking about actual WASM files ONLY, as in not those that come with some extra glue JS code

nivekuil12:01:35

I mean wasm modules that are written in some subset of cljs, that exports persistent data sturctures which interop with cljs

thheller12:01:09

yeah for that you gonna need a few weeks to years 😉

nivekuil12:01:32

I looked a little and I don't think it's that bad 😛 wasm gc is pretty high level and binaryen even higher

nivekuil12:01:47

not trying to port the whole language, just enough to avoid transit

thheller12:01:02

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

nivekuil12:01:46

no idea, I just want shared memory without the serde cost

🤷 1
andrewzhurov17:01:41

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.

Janet A. Carr17:01:00

by build variable, do you mean closure-defines?

Janet A. Carr17:01:49

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.

thheller17:01:39

the macro env has a (:shadow.build/mode &env), it'll be :release for release builds, otherwise :dev

clojure-spin 1
thheller17:01:51

obviously shadow-cljs only though, for others you might want to go with :closure-defines route

ns21:01:09

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?

thheller21:01:05

two separate builds?

ns22:01:31

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.

thheller22:01:51

yeah I'm not exactly sure what you are after. you can just not use shadow.lazy to load the optional thing

thheller22:01:52

maybe all the extra code you worried about is in that extra module and not a problem?

ns22:01:23

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!