Sounds fine to me. Another term I’ve used for js and Math is pseudo-namespace.

(I’ve seen the term synthetic used for the arbitrary namespaces bestowed to foreign libs.)

Rich used the adjective magic when he introduced it https://github.com/clojure/clojurescript/commit/954e8529b1ec814f40af77d6035f90e93a9126ea#diff-a9cce52f0bf5a7b9afccbec54e4a0e4bR39

Perhaps another good variant might be intrinsic namespace, given the special handling given to them by the compiler.

I'm trying to add a js dependency (https://github.com/lipis/flag-icon-css), I installed it via yarn and required it like this ["flag-icons-css" :as flag], but I'm getting an error "module without entry or suffix flag-icons-css"

maybe the problem is that it's a css thingie? is it possible to include it then?

@shin no, they cannot be included as part of a CLJS build. need to use some other tools to build CSS (eg. node-sass)

@thheller hmm, seems complicated, I was just looking for a quick way to include country flags

including it manually is quick and easy (with no extra tools)

could you tell me how to do that?

https://twitter.com/thheller/status/1158303405691035648

I'm trying to translate javascript code to clojurescript, which with a property value of the Object is a anonymous function. What should I do? For example:

var Navigator = {
    options: ({tintColor, focused}) => {
        <Bar 
          tintColor={tintColor}
          focused={focused}
        />
    }
}

@180338742 JS objects cannot be destructured like this so you'd do (fn [^js obj] (use (.-tintColor obj) (.-focused obj)) or use libs like https://github.com/appliedsciencestudio/js-interop https://github.com/mfikes/cljs-bean

Hello, everyone! Can any one explain the ^js meaning or giving me some links to learn it?

^js is a typehint telling the compiler that the object is a JS object and instructing the compiler to generate externs and prevents the renaming in :advanced builds. see https://clojurescript.org/guides/externs#externs-inference

Has anyone else noticed an unusual amount of "aw snap"s when developing using chrome/chromium 76? Perhaps particularly under (Debian) Linux? I'm working on a re-frame cljs portion of a rather large js web app, and I was hitting "aw snaps" a lot this morning after upgrading chromium (73->76) on Friday. It's not been the only trigger, but the shadow-cljs hot-reloading seemed to cause "aw snap" moments quite often. I've had to downgrade back to version 73 to get any work done. 😕

@mel.collins some people have reported crashes like that in projects with an excessive amount of files (thousands ...). this seems to help to address that https://clojureverse.org/t/improving-initial-load-time-for-browser-builds-during-development/2518

although nobody reported this as happening during hot-reload? only initial load

@thheller To throw in another curveball, is that also applicable to :target :npm-module projects?

no. it is not since it doesn't apply for those

but if you process the code further via say webpack that already does pretty much the same

hm, yeah webpack is indeed in use

yeah that already packages the sources so it doesn't matter

Welp, apparently it hits some kind of "illegal instruction" within Chromium's v8 JS compiler. Reproduction is a real pain though - could happen on first load, could only occur after 30 minutes of interactions and hot-reloading. 😕

Has anyone else run into this difference between clj and cljs?

;; CLJ
(re-seq #"^[a-f]" "aabcded") ;; => ("a")

;; CLJS
(re-seq #"^[a-f]" "aabcded") ;; => ("a" "a" "b" "c" "d" "e" "d")

Is it a difference in regex syntax or in the function proper?

the cljs solution is recursive, which means it ends up running #"^[a-f]" against e.g. "ded" which matches. Seems like a cljs bug to me.

Hello. I'm a node.js/python dev messing around with ClojureScript. I came here because I noticed that using --optimizations advanced deteriorates performance! The Clojure code I'm using:

(ns hello-world.core)

(defn fibo [n]
  (case n
    0 0
    1 0
    2 1
    (+ (fibo (- n 1)) (fibo (- n 2)))))

(defn -main [& args]
  (fibo (int (first args))))

(set! *main-cli-fn* -main)

clj -m cljs.main --target node --optimizations advanced --output-to main.js -c hello-world.core

time node main.js 40

From what I understand, the purpose of the clojurescript optimizations is more to reduce the size of the compiled javascript (not so much to improve performance). It's probably not particularly useful to turn on optimizations when you're running clojurescript on node; your code isn't going over the wire so why bother?

I think shadow-cljs defaults to simple optimizations

for node scripts

@bfay I see. It makes sense now.

@lilactown no it does not

💀

@gabrielblanksm I can't say why the clojurescript compiler is doing this. But is turning your code into this in advanced compilation (before minification).

hello_world.core.fibo = function hello_world$core$fibo(n) {
  var G__526 = n;
  switch (G__526) {
    case 0:
      return 0;

      break;
    case 1:
      return 0;

      break;
    case 2:
      return 1;

      break;
    default:
      return (
        (function() {
          var G__527 = n - 1;
          return hello_world.core.fibo.cljs$core$IFn$_invoke$arity$1
            ? hello_world.core.fibo.cljs$core$IFn$_invoke$arity$1(G__527)
            : hello_world.core.fibo(G__527);
        })() +
        (function() {
          var G__528 = n - 2;
          return hello_world.core.fibo.cljs$core$IFn$_invoke$arity$1
            ? hello_world.core.fibo.cljs$core$IFn$_invoke$arity$1(G__528)
            : hello_world.core.fibo(G__528);
        })()
      );
  }
};

https://clojure.atlassian.net/browse/CLJS-3071

anybody has a good example of how to setup emacs/cider/shadow-cljs properly? I'm not able to get repl working in emacs

it works straight forward to me. come chat in #cider ? and we can diagnose?

@jimmy and @bfay I ran some more tests, here are the results:

optimization level,command arg,execution time (ms)
none,1,690
none,40,2100
simple,1,550
simple,40,2050
advanced,1,470
advanced,40,8600

@dpsutton - thanks, I posted my problem in #cider

@gabrielblanksm yes this is known - but not really all that interesting in practice - code size generally more important than absolute throughput

but also as I'm sure you're aware - performance is a really complicated - and such small tests in isolation generally do more to obscure then provide any light

@dnolen Just to summarize the difference between advanced and none: A reduction of 13% in the code size and a 300% slowdown in execution time. You're totally right tho; profiling such a small script is not a good way to predict the behavior of a real world application. Also, this is the first time I program in clojurescript, so I'm not in a position to criticize anything, I still need to learn a lot.

@lewis FWIW I just run this on my machine and got practically no difference. advanced version is a tiny bit faster given that there is less code to load

@thheller With 40 as the command line argument?

yes

what you described is what I see with 1 as argument, the advanced is ~30% faster because there's less code to load

what is your node --version?

$ time node script.js 40
63245986

real    0m2.003s
user    0m1.766s
sys     0m0.406s

(added a prn to print the result to verify, assuming thats correct :)

node v10.13.0

rather old

hum my node even older, I'll upgrade it asap and check again

@gabrielblanksm If you're curious about :advanced across different engines, the test suite in the compiler might also be of interest. See https://blog.fikesfarm.com/posts/2017-11-18-clojurescript-performance-measurement.html

Measuring code size reduction for such trivial programs isn’t something we care that much about since there’s no benefit for the actual use case

Runtime perf is really important but we don’t test naive fib :) mostly interested in functional patterns and persistent data structures