This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-12-20
Channels
- # adventofcode (38)
- # announcements (8)
- # aws (4)
- # babashka (131)
- # beginners (263)
- # calva (2)
- # clj-kondo (12)
- # cljdoc (12)
- # cljsrn (3)
- # clojure (122)
- # clojure-europe (3)
- # clojure-finland (2)
- # clojure-nl (13)
- # clojure-uk (80)
- # clojured (1)
- # clojuredesign-podcast (3)
- # clojurescript (78)
- # core-async (19)
- # cursive (19)
- # datomic (7)
- # duct (10)
- # events (1)
- # fulcro (7)
- # graalvm (12)
- # graphql (3)
- # juxt (4)
- # malli (10)
- # music (3)
- # nrepl (4)
- # off-topic (25)
- # pathom (4)
- # pedestal (1)
- # re-frame (78)
- # reagent (8)
- # shadow-cljs (91)
- # sql (8)
- # vim (3)
- # xtdb (2)
Im trying to specify a private npm pkg named something like @org/some-pkg in my shadow-cljs.edn but its complaining about the @ character. Ive tried googling but to no avail
@nicdaoraf why would you specify that in shadow-cljs.edn? where?
["@org/some-pkg" ...]
oh, inside :dependencies
hmm quoting didnt work, just complained that: Doesnt support "@org/some-pkg"
oh right
Yeah, I misread the question and thought you were just trying to require it.
i thought id have to go yarn add @org/some-pkg and put it into :dependencies
I'm looking at https://shadow-cljs.github.io/docs/UsersGuide.html
> Example 1. Specify dependencies
> {:dependencies [[lib "1.0"]]}
What dependencies do they mean here?
oh and those are different from "js" deps?
> Or a `.jar` file, representing Clojure(Script) or JVM libraries. These are compressed archives containing many files (basically just a `.zip` file). These are added by your `:dependencies`.
Also, I just realized that you're the author of shadow-cljs 🤯
thanks a lot
I've been looking at lighthouse performance on clojurescript apps, well, re-frame in particular. And I was really surprised to see they score pretty low. Is that just a re-frame thing? Reagent perhaps? Any tricks to improving run time performance people know of?
@cam.asoftware did you measure a release build or a development build?
well how large is it? lighthouse really only measures load times and they are horrific unless you used :optimizations :advanced
to build it
I see, do you think the projects measured here are not using those optimisations? https://www.google.com/amp/s/www.freecodecamp.org/news/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075/amp/
I only ask because I'm seriously fed up with JavaScript. I looked at elm which looks great, but there is some really interesting things about clojurescript
it is pretty easy to get 100/100 in lighthouse with any CLJS if that is your concern
Cool! As long as it's possible, and I understand it's not the only thing to consider, then awesome! Right now I'm trying to figure out what I should use as my toolchain (that makes performance optimisation a possibility if needed) so far I see figwheel, devcards, shadow cljs.... Lol, hard to know where to begin!
And don't start me on editor's.... That's another story. But repl type dev looks very attractive.
Although, from what I can tell, devcards is not really about builds.... More of a helper? Not sure
@cam To reduce choice, re-frame-template
might be a good place to start?
By default, a shim should be used instead of it: https://github.com/clojure/clojurescript-site/blob/master/content/reference/compiler-options.adoc#process-shim
Wrong: https://github.com/dm3/manifold-cljs/blob/master/src/manifold_cljs/executor.cljs#L20
No. The *target*
dynamic variable has been removed quite some time ago: https://github.com/clojure/clojurescript/blob/master/changes.md#changes-26
Actually, I may be wrong - the variable is defined differently, but it's used in the old way. I'll try to check it.
Yep, it seems to work just fine. Can you print the value of cljs.core/*target*
in some code that gets executed?
Uhm. OK. At this point, I would start debugging CLJS in the browser.
If debugging doesn't work, I would copy the relevant manifold-cljs file to my project files under the correct manifold-cljs namespace, and add a bunch of js/console.log
statements in there to see what's going on.
Is there such a thing as "boxed math" in js/cljs, in the same performance-harmful way that exists in JVM clj?
there are tricky things with JS math but it doesn’t manifest as a boxed/unboxed distinction
when I deref an atom does it create full copy of the atom I have some big atoms in ref-frame app when I deref them do I cause the app use more ram or is it just a link to an immutable element?
N.B.: Only if it's really an atom, and a bunch of other types defined by CLJS. deref
just calls the -deref
method of the IDeref
protocol. In the general case, you cannot guarantee what it will do. E.g. delay
computes some function, reagent.ratom/atom
notifies some watchers, etc.
That's a Reagent's reaction
. It does a lot of stuff. But if the underlying values didn't change, deref
ing it will just return a value that has been computed during the previous deref
.
Don't worry about "overheating" anything before you actually see any symptoms. Unless you're sure that something is a problem, that is. Like writing a O(2^n)
algorithm where a O(n)
would suffice.
My app crashes for some people in Chrome because it creates an object called XR
. This name was blacklisted for renaming in the Google Closure Compiler 10 months ago, but cljs is using an older version: https://github.com/google/closure-compiler/blame/5c84f3cc92dc5369d50f0398505fa45573be125f/src/com/google/javascript/jscomp/parsing/ParserConfig.properties#L227
Is there an easy way to use a newer version of the GCC or is that usually tricky? Or can this setting be configured for cljs builds?
I think, the latest version of shadow-cljs uses one of the latest GCC releases for compilation.
meaning this shows that I can exclude gcc from cljs and specify my own version or I should switch to shadow-cljs?
I tried upgrading to the shadow-cljs version, which didn't work, but a version in between seems to work fine. cheers!