[HN Gopher] Create ad-hoc ClojureScript scripts on Node.js with nbb
       ___________________________________________________________________
        
       Create ad-hoc ClojureScript scripts on Node.js with nbb
        
       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
        
       Author : Borkdude
       Score  : 107 points
       Date   : 2021-09-19 15:45 UTC (1 days ago)
        
       | brundolf wrote:
       | 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?
        
         | Borkdude wrote:
         | 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).
        
           | brundolf wrote:
           | 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 :)
        
             | Borkdude wrote:
             | 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.
        
       | ithrow wrote:
       | 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!"
        
         | harperlee wrote:
         | As a datapoint, I don't know javascript but I do know
         | clojurescript.
        
           | Scarbutt wrote:
           | Yeah, good luck with that.
        
             | harperlee wrote:
             | 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.
        
               | Scarbutt wrote:
               | Not about employability. You can't really leverage cljs
               | well without knowing JS but I'm sure you would disagree.
        
               | harperlee wrote:
               | 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.
        
               | piercebot wrote:
               | This is like saying "you can't really leverage Java well
               | without knowing JVM bytecode." Which is to say: I also
               | disagree with you :)
        
               | ithrow wrote:
               | 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.
        
               | iLemming wrote:
               | 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.
        
               | iLemming wrote:
               | > 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.
        
               | jetti wrote:
               | 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.
        
         | iLemming wrote:
         | > 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.
        
         | Borkdude wrote:
         | These are just small examples by nature.
         | 
         | See e.g. https://github.com/chr15m/c64core for a non-trivial
         | project in nbb.
        
           | ithrow wrote:
           | Equally bad, I don't see where are you getting any value from
           | cljs there.
        
             | Borkdude wrote:
             | 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.
        
               | ithrow wrote:
               | you are not really writing cljs... but whatever floats
               | your boat.
        
         | piercebot wrote:
         | 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.
        
         | brundolf wrote:
         | People can enjoy and/or get utility out of different things.
        
         | aaron-santos wrote:
         | Why would I want nodejs? All of that to avoid writing C for
         | simple things?
        
       | CraigJPerry wrote:
       | 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
        
         | Borkdude wrote:
         | 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
        
           | brundolf wrote:
           | Does it add startup time after the first run (where it
           | downloads and caches the dependency)?
        
             | Borkdude wrote:
             | When I tested this, it did.
        
               | brundolf wrote:
               | Interesting! Maybe it has to look for node_modules in
               | your current directory and each ancestor directory before
               | falling back to the global install
        
       ___________________________________________________________________
       (page generated 2021-09-20 23:02 UTC)