nbb is intended to be used as bb but by leveraging the Node.JS ecosystem in mind. There are JS libraries for about anything (reading excel files, or whatever) and that may not always be the case for bb. It's just another way to increase the reach of Clojure via scripting

you can run nbb anywhere you can run node, indeed:

npx nbb

The other day you mentioned that SCI works in cljs, which I hadn't realized. I'm hoping that making cljs builds of ys might allow it to get to more platforms. But the ability to also leverage JS npm libs is exciting too.

yep, that is supported by SCI (given enough configuration ;))

nbb is one such project, #C034FQN490E is another one that uses SCI+JS, and #C03DPCLCV9N (VSCode scripting) another one

given that bb can't dynamically use java libs, are there things that bb can do that nbb can't?

bb is just closer to JVM semantics, so it's easier to share code between Clojure (JVM) and bb. ClojureScript is less popular than Clojure

The thing that bb can that nbb can't mostly has to do with the target platform (multi-threading etc) (and vice versa)

the stuff that makes nbb more complicated is that JS needs async to load libs (if you want to load ES modules). This is why sci.async (https://github.com/babashka/sci/blob/master/doc/async.md) was written

I'm also working on an alternative CLJS compiler which can be integrated in a (normal) CLJS app for dynamic evaluation: https://squint-cljs.github.io/cherry/ (playground takes a while to load due to import-maps / CDN stuff) This performs better than SCI (interpretation vs compilation)

The thing that the cherry compiler simplifies is that you can just compile to import .. from "whatever" and don't worry about async loading of JS libraries yourself

$ time bb -e nil

real	0m0.033s
user	0m0.010s
sys	0m0.024s
$ time nbb -e nil

real	0m0.174s
user	0m0.150s
sys	0m0.029s

yeah, you can speed up the node bit a bit btw

depending on how you installed it

if you run node_modules/.bin/nbb directly it's much faster

or wait, maybe that's not true, it was npx which is slow

with npm install -g nbb@latest I get:

$ time nbb -e '(+ 1 2 3)'
6
nbb -e '(+ 1 2 3)'   0.10s  user 0.02s system 95% cpu 0.119 total

yeah that's another benefit of bb over nbb, graalvm is just snappier to start up

$ which nbb
/home/ingy/.nvm/versions/node/v16.13.1/bin/nbb

try a newer node version (21 is LTS now), it might be somewhat faster

$ time node -e 1

real	0m0.041s

glad they fixed it 🙂

node also supports building images like graalvm, this might fix the startup issue even more, but that's another rabbit hole to get into

bun does too

$ time bun -e '1'
bun -e '1'   0.01s  user 0.01s system 89% cpu 0.019 total

but paradoxically bun takes longer to run nbb since it first checks if there is stuff to transpile I believe

anyway, good luck making trade-offs :)

>

$ which nbb
> /home/ingy/.nvm/versions/node/v16.13.1/bin/nbb

what I'm wondering most for YS is that I need to compile to a shared lib to bind to every language. if I could build a shared lib with nodejs that would be pretty rad. (target platform wise)

I don't know about creating a shared library, but bun lets you use shared libraries pretty easily

note that bun is kind of experimental, it's kind of changing at a fast pace

@U3X7174KS

$ time /home/ingy/.nvm/versions/node/v16.13.1/bin/node -e 1

real	0m0.049s

and node 21?

nvm use 21

$ time /home/ingy/.nvm/versions/node/v21.6.0/bin/node -e 1

real	0m0.029s

Forgot about this one:

time deno run -A npm:nbb -e '(+ 1 2 3)'
6
deno run -A npm:nbb -e '(+ 1 2 3)'   0.06s  user 0.01s system 62% cpu 0.115 total

$ time deno run -A npm:squint-cljs -e '(js/console.log (+ 1 2 3))'
6
deno run -A npm:squint-cljs -e '(js/console.log (+ 1 2 3))'   0.05s  user 0.01s system 94% cpu 0.059 total

with deno.json being:

{
  "imports": {
    "squint-cljs": "npm:squint-cljs",
    "squint-cljs/core.js": "npm:squint-cljs/core.js"
  }
}