3 ms·

Zaphod: Clojure's API for JavaScript's Data Structures

68 points by codecurve 10y ago

codecurve 10y ago
tl;dr I wanted Clojure's simplicity with Lodash's flexibility, something easier to integrate into existing projects than ImmutableJS or Mori. Function bind syntax will be controversial, so I've also included a compatibility interface, so you can use Zaphod from Babel-free JavaScript (https://zaphod.surge.sh/compat/ https://zaphod.surge.sh/compat/)
- k__ 10y ago
  Doesn't Ramda create new entities instead of modifying existing ones?
  - codecurve 10y ago
    Yeah, so do lodash/fp and a handful of other solid libraries. The difference is that this sticks as close as possible to Clojure's API _for data_, rather than trying to be a functional programming utility belt.
    - k__ 10y ago
      Really? I had a few problems using lodash with Redux, because it mutated my objects.
      - codecurve 10y ago
        Ah, lodash and lodash/fp are slightly different packages. https://github.com/lodash/lodash/wiki/FP-Guide https://github.com/lodash/lodash/wiki/FP-Guide
        k__ 10y ago
        I see, thanks for the info :)
  - jdd 10y ago
    You might dig lodash-bound – Enables chained lodash functions with ES bind (::) syntax https://github.com/elado/lodash-bound https://github.com/elado/lodash-bound
    - k__ 10y ago
      Yes, the whole :: syntax sounded nice and I used it quite a while last year, but it don't believe it gets approved anymore. It's stage 0 for over a year now and nothing happend.
- zaphar 10y ago
  As some feedback on the site's wording. It wasn't immediately clear to me that this was a javascript library that ported Clojures immutable API's. I initially thought it was support in Clojure for Javascript data structures. I had to see the code samples before I realized.
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
Sonata 10y ago
I'm really not a fan of the function bind operator. It adds extra complexity to the meaning of "this" in JS, which is already one of the most confusing aspects of the language. I do understand that it is nice to be able to write those chained method call pipelines, without having to monkey patch anything. I think the |> operator from Elixer is a much simpler solution to this problem through, as it allows you to use normal functions, rather than having to write special versions that use 'this' for their primary data.
- codecurve 10y ago
  Totally hear what you're saying and I think JS would be better off without `this` in the first place. Clojure's threading macros are another great solution to the chaining problem. That said, `this` is here to stay and to me, function bind feels like a pretty great way to write code that feels natural, without the danger of extending the prototypes for Array and Object.

68 points by codecurve 10y ago

tl;dr I wanted Clojure's simplicity with Lodash's flexibility, something easier to integrate into existing projects than ImmutableJS or Mori. Function bind syntax will be controversial, so I've also included a compatibility interface, so you can use Zaphod from Babel-free JavaScript (https://zaphod.surge.sh/compat/ https://zaphod.surge.sh/compat/)

k__ 10y ago
Doesn't Ramda create new entities instead of modifying existing ones?
- codecurve 10y ago
  Yeah, so do lodash/fp and a handful of other solid libraries. The difference is that this sticks as close as possible to Clojure's API _for data_, rather than trying to be a functional programming utility belt.
  - k__ 10y ago
    Really? I had a few problems using lodash with Redux, because it mutated my objects.
    - codecurve 10y ago
      Ah, lodash and lodash/fp are slightly different packages. https://github.com/lodash/lodash/wiki/FP-Guide https://github.com/lodash/lodash/wiki/FP-Guide
      - k__ 10y ago
        I see, thanks for the info :)
- jdd 10y ago
  You might dig lodash-bound – Enables chained lodash functions with ES bind (::) syntax https://github.com/elado/lodash-bound https://github.com/elado/lodash-bound
  - k__ 10y ago
    Yes, the whole :: syntax sounded nice and I used it quite a while last year, but it don't believe it gets approved anymore. It's stage 0 for over a year now and nothing happend.
zaphar 10y ago
As some feedback on the site's wording. It wasn't immediately clear to me that this was a javascript library that ported Clojures immutable API's. I initially thought it was support in Clojure for Javascript data structures. I had to see the code samples before I realized.

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]

Sonata 10y ago

I'm really not a fan of the function bind operator. It adds extra complexity to the meaning of "this" in JS, which is already one of the most confusing aspects of the language. I do understand that it is nice to be able to write those chained method call pipelines, without having to monkey patch anything. I think the |> operator from Elixer is a much simpler solution to this problem through, as it allows you to use normal functions, rather than having to write special versions that use 'this' for their primary data.

codecurve 10y ago
Totally hear what you're saying and I think JS would be better off without `this` in the first place. Clojure's threading macros are another great solution to the chaining problem. That said, `this` is here to stay and to me, function bind feels like a pretty great way to write code that feels natural, without the danger of extending the prototypes for Array and Object.