Get Functional

Published in

Daftcode Blog

4 min readMar 1, 2017

Functional programming is getting more and more popular in front-end development. But what is it, actually?

If you did some front-end development, you’re probably familiar with Object-Oriented Programming, even if you don’t know it. Many JS libraries are exposing classes, which can be instantiated to describe the desired effect, like this:

const waypoint = new Waypoint({
  element: document.getElementById('thing'),
  handler: () => console.log('You have scrolled to a thing')
})

JavaScript is mostly used in an OO way, but nothing prevents us from using it in a functional way. Let’s see how the two would differ.

But first, a disclaimer: I know FP vs. OOP is a broad, nuanced, and sometimes fuzzy subject. What follows is a slight simplification of a perhaps false dichotomy. Nevertheless, I think that front-end development can benefit greatly from FP influences.

Functional vs. Object-Oriented

Let’s start with a lightweight argument in favour of functional programming:

I wanted to introduce some balance here, but the argument against functional programming seems to be that it’s just… hard. However that’s understandable — even the terms themselves sound cryptic: Monads, Functors, Monoids, and all other mathematical jargon may turn a lot of people away. Haskell, a purely functional language, is famous for being hard to grasp.

But you don’t have to switch to a purely functional language to write functional code. A “functional” language just means that the language was designed with functional paradigm in mind. JavaScript can be functional if you want it to.

First, let’s try to get the bigger picture here. For me at least, the difference roughly boils down to this:

Object-Oriented Programming is easy to grasp, because it mimics the way humans think about the world around them.
Functional Programming has a steeper learning curve and requires a bit of brain-rewiring, because it forces you to think differently than in everyday life.

So why should anyone rewire their brain, when OOP feels so intuitive and familiar? Is it just for the bragging rights? Or maybe some people just like to make their (and their teams) jobs harder by introducing a lot of math? Well, no. FP might be hard to learn, but the benefits are well worth it.

Let’s see how a functional code would differ from an object-oriented code in practice.

How to Close a Door

Imagine you’re creating a world and there is this great new feature called doors. They can be closed or opened, restricting or enabling access to a room. How exciting! But we need some code to make it work— first, in a functional way:

And now, object-oriented:

So, what FP benefits can we see here?

Reusability. In functional version, the open function can open anything that has a boolean locked property. In the future, we may introduce a chest, and use that same function to open it. FP encourages writing small, pure functions that follow Unix philosophy’s Do One Thing and Do It Well™ concept.
Immutability. As the codebase grows, it will become harder to keep track of myDoor object in OO version (has it already been opened on line X?). It’s just safer in the long run to use immutable data structures, which FP encourages.
Data. In FP version, myDoor is pure data — it could be imported from a JSON file or received from a REST API. In OOP version, myDoor is an object that stores some data as well as methods to manipulate that data.
Brevity. As a codebase grows, bloat makes it very hard to maintain, and functional code tends to be very concise.

The point here is not that OOP is bad, the problem is that it’s very easy to mess up. In functional languages, on the other hand, it’s simply harder to write bad code.

In Elm language for example, the compiler will warn you if you forget about a case in a switch statement. Functional style conveys more information about programmer’s intentions, so the development environment can work with you, almost like a pair programming partner.

Functional Programming in Front-end Development

The front-end development community took interest in functional programming in 2016. Here are some interesting projects that embrace the FP paradigm:

TypeScript and Flow are ways to enforce strong typing in JavaScript. TypeScript is a superset of JS, while Flow is a type annotation system that will just warn you if, say, a number is passed where a string should go.
Ramda is “a practical functional library for JavaScript programmers“ — basically a powerful functional toolbelt. Like lodash or underscore, but with FP baked in.
Redux is a library for state management which embraces functional style with the idea of pure functions at it’s core.
Elm, ClojureScript, PureScript —are functional languages that compile to JavaScript. The learning curve is much steeper than with the aforementioned projects.