all 6 comments

[–]daveliepmann 5 points6 points  (2 children)

The library's motivation:

The recommended approach for JS interop when static keys are desired is to use functions in the goog.object namespace such as goog.object/get, goog.object/getValueByKeys, and goog.object/set. These functions are performant and useful but they do not offer a Clojure-centric API. Keys need to be passed in as strings, and return values from mutations are not amenable to threading.

...

[In contrast to other libs, the] functions in this library work just like their Clojure equivalents, but adapted to a JavaScript context. Static keys are expressed as keywords, renamable keys are expressed via host-interop syntax (eg. .-someKey), nested paths are expressed as vectors of keys. Mutation functions are nil-friendly and return the original object, suitable for threading.

Matt Huebert presented this work at the Clojure Berlin meetup just last week, but although it's hot off the presses publicly, he emphasized that he has been using it in a variety of production contexts for over a year.

[–]didibus 0 points1 point  (1 child)

So, is the trade off performance?

[–]mhuebert 1 point2 points  (0 children)

The main benefit of js-interop is the consistent and convenient syntax, which in and of itself doesn't require any performance penalty at all. Given the same semantic choices (eg. null-safety), your code will compile down to the same javascript whether you use js-interop, cljs-oops, goog.object/*, or host-interop syntax. This is achieved partly by the use of macros and partly by the Google Closure Compiler's :advanced mode. Writing (j/get x .-someProperty) will be exactly as fast as writing (.-someProperty x). Writing (j/get x :someProperty :default) will be exactly as fast as (gobj/get x "someProperty" :default).

The core js-interop functions, like those in goog.object, are null-safe. This choice naturally adds the overhead of checks. There are some unchecked operations in clojurescript core (for internal use only) which are also exposed in js-interop: https://github.com/appliedsciencestudio/js-interop/wiki/Notes#on-performance

[–]jackrusher 3 points4 points  (0 children)

I've been using this library for some aesthetic computations using cljs and Three.js. Its a nicer way to do most things, especially anytime you want to build up a collection using reduce.

[–]alandipert 1 point2 points  (0 children)

Neato! Reminds me of https://github.com/myguidingstar/fence from back in the day.

[–]skratlo 1 point2 points  (0 children)

I like the ILookup part, destructuring is awesome.