How to become a web developer. Part 4 : Functional Programming

In the previous installment of this series on becoming a web developer we looked at the core Object Oriented Design principles you need to understand. Today we delve into some Functional Programming.

If you haven’t seen the previous posts in this series you can find them here:

Why you need to understand Functional Programming.

No, it’s not because Functional Programming will solve all your coding problems.

Functional Programming is just another tool in your arsenal. Some problems are easier to solve using Functional Programming techniques. Others are more suited to logical programming. Others are best done using OO.

The more tools you have the better programmer you will become.

Having said that there has been a tremendous resurgence in Functional Programming over the last few years. Many programming languages are a hybrid of OO/FP (Like JavaScript and C#) so understanding functional programming will make you a better programmer in those languages.

In addition a number of languages with a stronger functional programming ethos have become popular over the last few years.

Languages like:

Some core Functional Programming concepts you need to understand

Just like OO there are a few core concepts you need to wrap your head around. I have deliberately left out some of the more advanced concepts from this post (Monads, Homoiconicity, Lazy Evaluation, Currying, etc).

If you are serious about your functional programming journey it really is worth spending the time to understand all of these.

Although it’s probably the least practical of the languages mentioned above Haskell is the purist functional language in the group. If you are serious about getting to grips with functional programming then check out the fantastic “Learn you a Haskell for Great Good!” guide.

For now I am going to focus on the easier to grasp concepts that are found in most hybrid languages like JavaScript. The aim is to get you the most bang for your buck.


A closure is a function called in one context that remembers the variables from the environment in which it was defined. Multiple closures defined within the same context remember that same context, so changes they make are shared between them. Every time a function is called that creates closures, a new, shared context is created for the new closures.

In essence you can think of it as a pairing between a piece of code (the function) and a scope (the scope available at the point of definition). When you pass the function along to other parts of your program, the scope travels along with it.

For an in depth explanation of closures using JavaScript examples check out this post.

Higher order functions

Higher order functions are functions that do one of two things.

They either:

  • Take a function as input
  • Return a function as output

If you come from a language without functional programming features this can seem a little strange at first. It is one of the most useful concepts to wrap your head around though.

If you are familiar with the command pattern in the OO world you already have a taste of what this allows you to do. Often the command pattern is just a workaround for not being able to take a function as an input parameter.

Returning a function is slightly less common but no less useful. For an excellent example of this in use have a look at how scales are implemented in d3.js.

Function composition

Function composition is the act of composing multiple simple functions to create a more complex result. You can compare it to the way the unix command line works. Lots of small simple programs can be combined using the | command to feed the output from one application to the input of another.

Some functional languages have first class support for function composition (with . in Haskell and >> in F# for example) other languages like Javascript don’t have first class support but have libraries that add it (underscore.js chaining).

Side effects

A function can be considered to have a side effect when in addition to returning a value it also get’s input from or modifies another part of the program or the outside world.

Some examples of side effects include:

  • modifying a global variable or static variable
  • modifying one of the functions arguments
  • raising an exception
  • writing data to a display or file
  • reading data from a file or database
  • calling other side-effecting functions

You should be very aware of when your functions produce side effects. Side effects make the behavior of your application harder to predict and control. The same function called twice might produce wildly different results.

Pure functional languages don’t allow any side effects in functions, instead all side effects are pushed into a monad. Don’t worry you don’t need to understand monads just yet, but they aren’t that scary. If you are interested there is a great talk by Brian Beckman that does a good job of explaining monads:

For now just be aware of side effects and try limit side effects to as few areas of your code as possible.

Functional programming in JavaScript

Now that we have covered the basics lets look at how best to start using these concepts in Javascript. I am picking Javascript as it’s a language you have to know as a web developer regardless of which backend framework or language you use.

My go to library for making functional programming easier in javascript is underscore.js, there are other options and underscore has it’s quirks but it is widely supported, easy to get to grips with and has excellent documentation.

The documentation at is a good place to start but if you prefer a tutorial have a look at “Getting cozy with underscore.js“.


Functional programming is a large topic and learning it can feel like a brain melting task at times. Especially if you come from an imperative/OO background. Just bear in mind that learning OO in the beginning was just as hard, it seems easy and logical once you have spent thousands of hours practicing it. The same goes for functional programming.

Keep at it, it’s worth it in the long run.

Leave a Reply

Your email address will not be published. Required fields are marked *