3 ms·

What's wrong with Ramda?

• dmitriid 4y ago
  Unusable unreadable unnecessary complex abstractions in a language that doesn't need them. Also, extremely non-performant. As you can see even in the blog post: straightforward readable code using built-in functionality is turned into 8-12 imports, a bunch of auxillary functions and multiple function calls that obscure the actual functionality. At 35 times speed penalty and 2 times memory penalty.
• gherkinnn 4y ago
  The library itself is fine. The problem I see is twisting JS/TS in to a language it is not. JS simply does not lend itself to currying, data-last signatures, piping, and pattern matching like an ML family language does. And as you can tell by the Ramda typings, neither does the TS type system. [0] You will forever fight an uphill battle against every single tutorial and piece of documentation and colleague when going down this path. I don't think the effort is worth it. 0 - https://github.com/DefinitelyTyped/DefinitelyTyped/blob/dc9b44bf728c2c49f22055ddf0dec39d74ce2722/types/ramda/index.d.ts#L4021 https://github.com/DefinitelyTyped/DefinitelyTyped/blob/dc9b...
  • tacotacotaco 4y ago
    Pipes and pattern matching have been proposed to JS. https://github.com/tc39/proposal-pipeline-operator https://github.com/tc39/proposal-pipeline-operator https://github.com/tc39/proposal-pattern-matching https://github.com/tc39/proposal-pattern-matching
    • gherkinnn 4y ago
      As much as I like these concepts, I'd be hesitant about adding them to the language. At what point does a language support too many paradigms? In contrast, take the recently stage-3'd Iterator Helpers[0]. These build on top of the language by using methods that already exists in other parts. It feels natural and is more of the same. 0 - https://github.com/tc39/proposal-iterator-helpers#implementations https://github.com/tc39/proposal-iterator-helpers#implementa...