More by Joseph Callaars
February 2020

On using Ramda less often

For those who are not familiar with Ramda, it is a vast functional library for JavaScript and has been a personal favourite for quite some time now. Lately, however, I'm going off it.

I've been in projects where a fully functional style of programming was great, but I found that it becomes hard to maintain because it's not easy to read.

If I read the following code in JavaScript;

const getRow = data => {
  if (!data || data.length === 0) return [templateRow];

  const filteredData = data.map(extractMinimumData)
                           .sort(row => row.name.toLowerCase());

  return filteredData[0];  
}

Versus this in Ramda;

const isEmptyOrNil = R.either(R.isNil, R.isEmpty);
const sortLowercaseName = R.compose(R.toLower, R.prop('name'));
const getTemplate = R.always([templateRow]);
const extractRow = R.compose(
  R.head, 
  R.sortBy(sortLowercaseName), 
  R.map(extractMinimumData)
);

const getRow = R.ifElse(isEmptyOrNil, getTemplate, extractRow);

Then I cannot - in good conscious - choose for Ramda. It's just too obfuscated and makes me look like some evil genius programmer, while in fact, it could've been much easier to maintain if I would've just written it out in plain JS.

I'm not saying Ramda doesn't have its place though, because the isEmptyOrNil function in Ramda feels cleaner, and that's because I'm not too fond of multiple conditions in an if-statement. But doing everything in Ramda, that's where it becomes unmaintainable.

And, in the end, it's going to end up more bytes as well if we do it in Ramda, instead of JS. I suppose it comes down to sensibility after all. Your co-workers are going to thank you later if your code is readable (and maintainable), but you will also if you read it in a few months again.

I'm on GitHubKeybase