Fork me on GitHub
#clojurescript
<
2020-10-26
>
leif01:10:31

Hey, I noticed the clojurescript compiler seems to compile to uses of document.write. Is there any particular reason it does that over something like appendChild?

leif01:10:53

Oh wiat, never mind, that was absolutely introduced by figwheel. Sorry about that.

p-himik07:10:17

The code that does it is in cljs.closure/output-main-file, so it has nothing to do with Figwheel, I think.

thheller08:10:58

yeah its CLJS but its only in development builds. optimized builds don't do that.

thheller09:10:46

well technically its not even CLJS. it is the debug load mechanism of the closure library. CLJS just adopted that.

leif16:10:57

Ah, okay, taht makes sense, thanks.

leif16:10:44

Is there any way to have a non-development, non-optimized build?

leif16:10:58

(When the build is optimized, I'm getting an error saying a.aZa is not a function, which I suspect means something that should be an extern is getting optimized, but obviously I have no idea what a.aZa is so its kind of hard to debug that without figuring that out first...

thheller17:10:28

you can set :pseudo-names true in your compiler options. that will make the name recognizable

thheller17:10:50

:optimizations :simple also works if you don't care about file size

leif18:10:55

@thheller Oh cool, thanks.

leif18:10:47

Also the advanced optimizations compile size is 7 MB, while the simple one is 10 MB, so ya. :)

leif19:10:47

Ah, the problem seems to be with identifiers with a . in it.

leif19:10:58

In this case, react bootstraps Modal.Header.

leif19:10:34

Which Makes sense. It looks like Object.Modal is making it into the inferred_exports.js file, but not Object.Modal.Header

Karol Wójcik08:10:42

Hi. Could somebody please point me to benchmark json vs transit-cljs? I’m trying to find it without any success

thheller10:10:33

what would you want to benchmark? it is always going to be slower given that it is built on top of json and uses persistent collections

mkvlr12:10:53

@karol.wojcik there’s https://swannodette.github.io/2014/07/23/a-closer-look-at-transit/ and it links to http://jsperf.com/json-vs-transit/2 (archive link https://web.archive.org/web/20160310101542/http://jsperf.com/json-vs-transit/2 doens’t seem to useful?). @thheller I do remember @dnolen talking about it being faster than json in some cases due to compression.

dnolen13:10:09

there were some interesting moments in the past where I think it was faster on V8 or something, but not generally true

dnolen13:10:45

overall it's a reasonably small performance hit over JSON

dnolen13:10:31

at the bottom it has very simple benchmarks

thheller14:10:27

yeah comparing to JSON is not very interesting since we don't want to work with JS objects/strings. when we actually want CLJS datastructures then the transit overhead is very minimal and well worth it. also a whole lot faster than cljs.reader. the compression is nice too. overall I don't see an argument against transit 😉

✔️ 3
theeternalpulse15:10:39

Anyone have a link to some good example projects that use datascript for the application state?

6
afhammad19:10:35

Can anyone point me to any docs on Clojurescript's core.async support (given its a subset of Clojure's)?

uosl20:10:03

I think the only difference is you can't use blocking calls (double exclamation mark) due to JS event loop. https://cljdoc.org/d/org.clojure/core.async/0.7.559/api/cljs.core.async

uosl20:10:59

So everything has to be done inside a Go block and returned asynchronously (similarly to JS promises).

afhammad20:10:04

Thanks, the link is helpful.