Suppose you learn some functional JavaScript, and it’s wonderful. But, for some reason, your team doesn’t get it? What do you do? To understand what’s going on, we need to step back and get a little perspective…

Property-based tests give us more confidence in our code. They’re great at catching edge-cases we may not have thought of otherwise. But this confidence comes at a cost. Property tests take more effort to write. They force you to think hard about what the code is doing, and what its expected behaviour should be. It’s hard work. And on top of that, running 100+ tests is always going to take longer than running 3–5 example-based tests. This cost is real, and it raises the question:

How do we keep ourselves from over-specifying or writing unnecessary tests?

Property-based testing helps us write better tests, with less code, and greater coverage. This leads to more confidence in our code, and fewer bugs in our applications. But, as always, there’s a price. Property tests take more effort to write, and they take longer to run. But they’re worth it.

The JavaScript ternary operator is more than just a ‘clever’ hack used by people who prefer brevity to clarity.

JavaScript cops a lot of sneers and snide remarks. Some of them are deserved. Others, not so much. One that often comes up is floating point numbers. And in days past, it was a legitimate criticism.

It’s not that JavaScript did floating point numbers any worse than other languages. It uses the same IEEE standard that most of them do. The trouble is that floating point numbers were the only option. There was no other number type in JavaScript.

That’s no longer the case.

For over a year now, BigInt has officially been part of the TC39 ECMAScript standard. So we have another option for number types, besides floating point.

How does that help though?

Well, BigInt values are not restricted to 64 bits. They can be arbitrarily long. With a little mathematical care, we can use them to make very high precision calculations. And it’s not terribly hard either. You can write your own library from scratch with the power of BigInt.

“Higher-order function” is one of those phrases people throw around a lot. But it’s rare for anyone to stop to explain what that means. Perhaps you already know what a higher-order function is. But how do we use them in the real world? What are some practical examples of when and how they’re useful? Can we use them for manipulating the DOM? Or, are people who use higher-order functions showing off? Are they over-complicating code for no good reason?

A fascinating read on how transducers work, building them up from scratch from reducers using JavaScript, then showing how to uses built-in transducers from Ramda. And if all that sounds like gobbledygook, you’re not alone - but read this article and it will start to make sense. :)

Author James Sinclair on why bother learning this challenging concept:

A solution that would give us the elegance of using small, simple functions. But also the efficiency of doing our processing in a single pass through the array. What is this magical solution? It’s a concept called a transducer.

I’m blown away by the clarity of explanation in this post, and came away with it excited to start using Reduce way more. Definitely worth a read to level up your game.

Reduce is the Swiss-army knife of array iterators. It’s really powerful. So powerful, you can build most of the other array iterator methods with it, like .map(), .filter() and .flatMap(). And in this article we’ll look at some more amazing things you can do with it. But, if you’re new to array iterator methods, .reduce() can be confusing at first.