by Mindstormy on 8/4/23, 7:21 PM
I view Ramda as a redflag in most any code base I see it in. Anecdotally, every large codebase I have worked with that heavily used Ramda is generally held together by one very smart engineer. Once that engineer leaves the company, the code base falls apart because no one else can understand it very well and it takes ages to fix bugs or ship new features. So these days I champion against Ramda simply because I think it just takes to much effort for a typical engineer to understand and it is usually at odds with the rest of the companies code.
by solardev on 8/4/23, 9:45 PM
Ramda was a hellhole I hope never to use again. We spent a year trying to learn it, finding it unreadable every time we went back to it (originally added by an outside contractor). Eventually we decided to give up, ripped it all out in a week and went back to lodash and never had an issue again.
Ramda code was just impossible to read and made every 5-min job take hours or days... not worth it, no matter the ideology.
by tengbretson on 8/4/23, 6:45 PM
I've gone pretty deep down this particular FP rabbit hole in JS before. I'm not saying that it shouldn't be in your toolbox, but in my experience currying should not be something you regularly reach for.
by jauntywundrkind on 8/4/23, 7:43 PM
Ramda putting the options first, data last in the args is a killer move. It means it's easier to bind functions. And many functions can be made variadic, accept all much data as you want to feed, which is a huge boost.
Ramda & fp libraries in general seen to have faded a bit. The utility library everyone knew, lodash, hasn't shipped an update in 2 years. Weird to see this kind of stuff falling away a bit.
by rpowers on 8/4/23, 7:30 PM
I used Ramda for 3+ years. I like somethings but overall wouldn't pick it up again. FP in general makes it really easy for people to write inefficient passes over data. In addition, debugging or code reviewing ramdajs code can be painful as you often have several layers of call stack with meaningless (curryN, pipe, map, pick) functions. I say meaningless because when your whole app uses ramda, you find it very difficult to know what is being map'd or curry'd.
by JasonSage on 8/4/23, 7:01 PM
In the late 10s I worked at a startup that was not adopting Flow or TypeScript, and pushing FP using Ramda/lodash-fp seemed like a way to encourage devs to separate out data from dataflow and make things into reusable pieces. Instead of some spaghetti imperative code, we could write a bunch of small functions that work on well-known entities, and compose them up to make a procedure. In theory it was better.
When the company finally came around to using TypeScript, devs could once again reason about code and data and relationships between functions without resorting to abstraction, and the FP stuff died a quick death.
by mirekrusin on 8/5/23, 12:51 AM
I find straight forward, dedicated, precisely typed combinators much more readable and practical to use ie. for iterables (context where it makes a lot of sense) [0] example [1], runtime assertions (through refutations, which are much faster than combinators over assertions) [2], parser combinators for smallish grammars [3] etc.
In many cases vanilla/imperative js is more readable and terse, no need to bring functional fanaticism everywhere, just in places where it gives true benefits and in form that can be understood by peers.
Functional code can be beautiful and can also be unreadable/undebugable. Same with imperative code. It's great in js/ts you can pick approach where the problem is expressed more naturally and mix those paradigms at will.
[0] https://github.com/preludejs/generator
[1] https://observablehq.com/@mirek/project-euler
[2] https://github.com/preludejs/refute
[3] https://github.com/preludejs/parser
by SirensOfTitan on 8/4/23, 10:30 PM
I considered Ramda at my last company for a hot minute, but ultimately decided it was too opaque to be a reasonable decision. We ended up using lodash for a little while, but in reality used like 2% of lodash, so I ripped it entirely out in favor of our own small utility collection with really sound typescript typing.
I think, in any project, it’s best to repeat yourself more, and patiently watch to see which abstractions actually emerge.
by ARussell on 8/5/23, 5:24 PM
Personally I just don't think Ramda fits really well with JavaScript's mutable and often object-oriented nature. It goes against the grain too much for my taste, and it doesn't work very well with Typescript.
In a professional setting I will probably always reach for Lodash due to it's maturity and mindshare. Personally, though, I really prefer Remeda (https://github.com/remeda/remeda) as a pragmatic and flexible API.
by tekkk on 8/4/23, 7:41 PM
It's a cool library but rarely I get to write something so convoluted in JS/TS that Ramda would make it appear simpler. Rather, it often makes it more convoluted since you can't look directly from the code what a function is doing but have to look up Ramda documentation first. Even that might not help.
by brodo on 8/4/23, 11:28 PM
Instead of using a library like Ramda or lowdash, I would suggest using modern standard Javascript functions. These kinds of libraries tend to go everywhere (like sand on Tatooine) and you end up writing some hybrid of ‘normal’ Javascript and some pure functional language. If you want to go functional, use Haskell or Purescript. Don’t bend Javascript into something it is not.
by Vanit on 8/5/23, 1:25 PM
Please don't use this. I see a lot of engineers, particularly stubborn seniors, who are dabbling in JS want to bring their functional programming gifts from heaven to us lowly JS peasants. In reality it makes the project inscrutable and also makes it might impossible to onboard any JS specialists to the JS project.
by smrtinsert on 8/4/23, 7:13 PM
Long time ago we already had a large lodash codebase, but I remember liking ramdas api design more. Did a few pocs but we never needed it. We did need a lot of fp though. We were on es6 and constantly merging observables. Lodash was a good supporting library for that, but I think the Ramda version would have been a little cleaner.
by tjasdfw2342 on 8/5/23, 12:03 PM
As an FP purist. These third party libs for JS are a mistake.
stick to stdlib and native lang constructs.