Functional programming in Javascript is an antipattern
Alex Dixon

Our architecture is React/Redux/Ramda in TypeScript; we ripped ImmutableJS out shortly after starting down the path of using it. Like you, we found the overhead of its function space cognitively unbearable, and like other responses, we found that its touted performance gains really didn’t apply even in our size app; we needed to deal with mutability where we had large data because it was constantly changing, while ImmutableJS just was not feasible.

Instead, we use Object.freeze while developing to the point that we hardly even notice that we’re working with immutable structures anymore. In some places with a high number of mutations, such as tracking mouse movements, we started adopting RxJS; while the function space there is large, Observables gave us such an additional benefit that it was worth it.

We’ve used the benefits of the TypeScript typing system to our benefit, too; we can tell very quickly what kind of object we’re working with and know immediately what functions are available and which won’t work. TypeScript is no-where near as terse as ClojureScript, so it is more code to write… but we run into a lot less of the grammar barrier, and we’ve found that point-free programming makes it hard to read in a couple weeks, even if the reader is the one who wrote it!

The final thing I want to add, though, is that we have different software languages for a reason: find the one that works best for you, your team, and your problem set, and use it! There’s no one language to rule them all because each one tackles each problem slightly differently, and only in the scope of a given problem are some better or worse. And, for that reason, JavaScript is definitely worse at functional programming than a language designed for it from the ground up. But… I’d say that ImmutableJS is your anti-pattern here, not FP in JavaScript as a whole.

Show your support

Clapping shows how much you appreciated Matthew DeKrey’s story.