Clojurians Log v2
clojurescript
@p-himik Hmm..it actually looks to be unrelated to fighweel, like the error persists even when I run the compiled JS from an entirely different server.
@p-himik GOT IT...kinda: https://javascript.info/modifying-document
Its because if write is called after a page is loaded the document gets erased.
Which....seems to indicate that as long as the cojurescript compiler uses write it might not be possible, at least not without reconstructing the whole document within clojurescript itself.
Either way though, this seems like an interesting enough question on its own I'm going to ask it in the main thread. Thanks again for your feedback.
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?
Oh wiat, never mind, that was absolutely introduced by figwheel. Sorry about that.
The code that does it is in cljs.closure/output-main-file, so it has nothing to do with Figwheel, I think.
yeah its CLJS but its only in development builds. optimized builds don't do that.
well technically its not even CLJS. it is the debug load mechanism of the closure library. CLJS just adopted that.
Ah, okay, taht makes sense, thanks.
Is there any way to have a non-development, non-optimized build?
(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...
you can set :pseudo-names true in your compiler options. that will make the name recognizable
:optimizations :simple also works if you don't care about file size
@thheller Oh cool, thanks.
Also the advanced optimizations compile size is 7 MB, while the simple one is 10 MB, so ya. :)
Ah, the problem seems to be with identifiers with a . in it.
In this case, react bootstraps Modal.Header.
Which Makes sense. It looks like Object.Modal is making it into the inferred_exports.js file, but not Object.Modal.Header
Hi. Could somebody please point me to benchmark json vs transit-cljs? I’m trying to find it without any success
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
@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.
there were some interesting moments in the past where I think it was faster on V8 or something, but not generally true
overall it's a reasonably small performance hit over JSON
at the bottom it has very simple benchmarks
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 😉
Anyone have a link to some good example projects that use datascript for the application state?
Can anyone point me to any docs on Clojurescript's core.async support (given its a subset of Clojure's)?
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
So everything has to be done inside a Go block and returned asynchronously (similarly to JS promises).
Thanks, the link is helpful.