Create ad-hoc ClojureScript scripts on Node.js with nbb | Hacker News Reader

Create ad-hoc ClojureScript scripts on Node.js with nbb

116 pointsBorkdude31 comments

Nbb is a scripting environment that aims to make it easier to create ad-hoc scripts on Node.js using ClojureScript. It does not need a JVM for compilation: just use npm and you're good to go. Code is interpreted instead of compiled, which for scripting is usually ok. If your project outgrows the scripting phase, you can migrate to a proper ClojureScript compiler setup. Give it a try if you're curious about ClojureScript.

https://github.com/borkdude/nbb

View on HN

The UX is pretty flawless for getting started, i can just exec random clojurescript instantly on an old 6700k desktop (assuming i have nodejs installed, but nothing else):

      ~/Code/local/clojure ····································· at  15:03:13
     time npx nbb -e "(:doc (meta #'meta))"
    "Returns the metadata of obj, returns nil if there is no metadata."
    0.13s user 0.02s system 114% cpu 0.134 total

Thanks! Note that npx itself adds some startup time to the mix. It's usually faster when ran as a global command (which should be safe since nbb doesn't depend on any other node libraries). Notes on that here:

https://github.com/borkdude/nbb#startup-time

Does it add startup time after the first run (where it downloads and caches the dependency)?

When I tested this, it did.

Interesting! Maybe it has to look for node_modules in your current directory and each ancestor directory before falling back to the global install

This is great, I love batteries-included all-in-one language runners.

Is this a totally custom interpreter? If so, what's the coverage like of ClojureScript's built-in features and functionality? Do third-party libraries generally work in it without issues?

Nbb is to CLJS what babashka is to JVM Clojure. Both scripting environments are implemented using SCI, a Clojure(Script) interpreter which re-uses all the core functions when you call those, the rest (creating vars, functions, namespaces) is interpreted "glue code" and that code isn't compiled (to bytecode or JS); instead it uses interpretation while trying to stay as close as possible to the host language. There are some things that are currently not supported, most notably deftype. For SCI on JS this is just a matter of time, but on JVM the target for SCI is mostly GraalVM images which come with the restriction that you can't implement new types at runtime. SCI originates mostly from the work on babashka, but with nbb, I'm adding better support for CLJS over time.

As for third-party libs: it depends if they are written in the subset that SCI supports. If the library is useful enough for scripting then it can be considered for added as a built-in. The classpath support is still something under development, but it already works for gitlibs. Here is an example of running HoneySQL from source in nbb: https://github.com/borkdude/nbb#classpath.

Just let me know if something doesn't work out (on Slack or Github issues/discussions).

Thanks! I'm not sure I'll use it for anything, I haven't really used ClojureScript, I'm just a language geek who was curious :)

Well yeah, that might be a good use case for nbb too: people who just want to try out a bit of "CLJS" without spending too much time on setup first.

nice, keep up the good work.

clj gives a different way of thinking (imho better), but alas even introducing algebra to geometry had push back, and so will anything that upsets the norm.

Another equally important benefit of clojure is its stability, i.e you can write a script today and it will run weeks/months/years/decades afterwards, the same cannot be said for js.

This is all known to people already using clj and cljs, and now we can keep enjoying our clojure on nodejs also :)

note: there is a misconception aparently that clojure does not support mutability, it does, just does so in a sane way so you dont shoot yourself in the foot. So yes you can mutate in clojure, and yes you can have side affecting stuff, clojure programmers do so every day .

All this just to avoid writing JS in nodejs for simple scripts? why add more complexity to simple things? just to write JS with parenthesis? clojurescript is overkill and definitely tedious to use for this because is not suited for scripts just doing lots of imperative, side-effecting stuff and dealing constantly with mutable APIs.

I love lisp but... https://github.com/borkdude/nbb/blob/main/examples/puppeteer...

"Look how cool I'm, I downloaded this thing just to add parenthesis to my JS script!"

Why would I want nodejs? All of that to avoid writing C for simple things?

Why would I want C? All of that to avoid writing Assembler for simple things?

This feels like a personal attack, bud.

I think the real advantage is scripting with a REPL in your IDE. Whipping up a script becomes trivial because you can test every data transformation (heck, every expression!) with a keystroke. There's no great way to do this in a language without s-expressions.

As a datapoint, I don't know javascript but I do know clojurescript.

Yeah, good luck with that.

Thanks! I’m a hobbyist with limited time and I earn my salary without programming, so I don’t need to cater to any market demand, in case you were condescending on my employability prospects.

Not about employability. You can't really leverage cljs well without knowing JS but I'm sure you would disagree.

Nah, I just disagree with your treating of both “leveraging cljs well” and “knowing JS” as binary things. I’m sure there’s a correlation but I have not found the need of learning neither java nor javascript.

This is like saying "you can't really leverage Java well without knowing JVM bytecode." Which is to say: I also disagree with you :)

dumb analogy, the issue is libraries, you don't need to read bytecode to be able to use a Java library in Java or Clojure but you do need to read Java. Same with Cljs and JS.

I have to say, one has to be some special kind of "dumb" to learn Clojure, but at the same time lose the ability to understand Javascript or Java. One doesn't choose one tool simply because "they don't know the other tool". Sometimes, and quite often, the decision gets made precisely because they gained significant knowledge in both.

I disagree with this. I use Clojure and Clojurescript at my day job and know very little JS and virtually nothing from ES6 and beyond. The only time, that I can think of, that I actually needed to directly reference Javascript was when I was needing to do some downloading of files through an API call. I used some of the Google Closure classes as well as Blob. Other than that everything I need is already in a nice clojurescript wrapper over the javascript libraries.

> without knowing JS

What "knowing JS" even entails here? Reading through ECMAScript's Specification (of over 800 pages long) at least once? Having to deal with browsers since 1998? Knowing your way around numerous "standard libraries"? Understanding perplexing landscape of perpetual changes in JS/TS?

Most full-stack developers (arguably) are not Javascript experts, yet they do sometimes need to write small front-ends or deal with nodejs.

These are just small examples by nature.

See e.g. https://github.com/chr15m/c64core for a non-trivial project in nbb.

Equally bad, I don't see where are you getting any value from cljs there.

You are funny. If you don't see the value that's ok. The value for me is mostly that I enjoy writing CLJS more than JS. Although I don't hate JS, I just enjoy CLJS more.

you are not really writing cljs... but whatever floats your boat.

People can enjoy and/or get utility out of different things.

> why add more complexity to simple things?

I feel you haven't grasp yet, the actual difference between seemingly simple and truly simple things. Path to simplicity quite often is not that straightforward.

Try for example converting the example you're pointing at to javascript, just for comparison.

Reply on news.ycombinator.com