I was interested in the topic of functional programming, I saw
an article
here , and decided to translate, the article came out small, but interesting.
Link to the original. Next, the translation itself.
Functional programming is becoming more and more popular in front-end development. But what is it, really?
If you're a frontend developer, you're probably familiar with object-oriented programming, even if you don't know it. Many JS libraries use classes that can be created to describe the desired effect, for example:
const waypoint = new Waypoint({ element: document.getElementById('thing'), handler: () => console.log('You have scrolled to a thing') })
JavaScript is commonly used in OOP, but nothing prevents us from using it in functional programming. Let's take a look at how they will be different from each other.
')
But first, disclaimer, I know that OP against OOP is a broad, nuanced, and sometimes fuzzy subject. The following is a slight simplification, perhaps a false dichotomy. However, I think that frontend development can greatly benefit from the influence of the OP.
Functional versus Object Oriented
Let's start with a small argument in the direction of functional programming.
(pun: fun - fun, poop - shit)
I would like to make some balance here, but the argument against functional programming is that it is ... difficult. This is understandable, even the terms sound mysterious: monads, functors, monoids, and all other mathematical words can repel many people. Haskell, a purely functional language, is known for being difficult to understand.
But you do not need to switch to a purely functional language to write functional code. “Functional” language means that the language was developed taking into account the functional paradigm. JavaScript can be functional if you want it.
First, let's try to get a more complete picture. For me, at least, the difference is roughly as follows:
- Object-oriented programming is easy to understand, because it mimics how people think about the world around them.
- Functional programming is more difficult to learn and requires a small reorganization of the brain, because it makes you think differently than in everyday life.
So why should someone rebuild their thinking when the OOP is intuitive and familiar? Just for bragging? Or maybe some people want to make their work (and their teams) harder by typing a lot of math? Not. The AF may be difficult to learn, but the benefits are worth it.
Let's take a look at how the functional code will differ from the object-oriented in practice.
How to close the door
Imagine that you are creating a
world , and creating a new function - the door. They can be closed or open, restrict or open access to the room. Cool! But we need code to work, first, in a functional way:
And now, object-oriented:
So, what are the benefits of FP we can see here?
- Reuse . In the functional version, the open function can open everything that has a boolean locked property. In the future, we can make a chest and use the same function to open it. FP allows you to write small, clean functions that follow Unix concepts: Do One Thing and Do It Well.
- Unchanged . As the code grows, it will be more and more difficult to track the myDoor object in the OO version (was it already open on line x?). In the long run, it is simply safer to use immutable data structures that the FI encourages.
- The data . In the FP version, myDoor is pure data that can be imported from a JSON file or obtained from the REST API. In the OOP version, myDoor is an object that stores data, as well as methods, to manage this data.
- Brevity . As the code grows, it is harder to maintain, and the functional code is more concise.
The point is not that the PLO is bad, the problem is that it is very easy to spoil it. On the other hand, in functional languages ​​it is just harder to write bad code.
For example, in the Elm language, the
compiler will warn you if you forget about the case in the switch statement. The functional style conveys more information about the programmer’s goal, so the development environment can work with you, almost like a programmer’s partner.
Functional programming in front-end development
The front-end community of developers became interested in functional programming in 2016. Here are some interesting projects where you can find examples of FP:
- TypeScript and Flow provide strong typing in JavaScript. TypeScript is an add-on for JS, while Flow is a warning system that will alert you if, for example, the number is passed where there should be a string.
- Ramda is “a practical, functional library for JavaScript programmers.” Is generally a powerful functional tool. Like lodash or underscore, but with FP.
- Redux is a state control library that includes an FP with the idea of ​​pure functions in its core.
- Elm , ClojureScript , PureScript are functional languages ​​that are compiled into JavaScript. The learning curve is much steeper than in the above projects.
What's next?
If you want to plunge into functional programming, I would advise the following:
- Exhaustive, but very affordable introduction to AF
- Professor Frisbee's Functional Programming Guide (free e-book)
- Functional programming language - these mysterious terms
And if you're from the world of javascript:
- Thoughts in Ramda - an introduction to Ramda
- Awesome OP JS - Functional Oriented Resources for JS
- What is the functional programming of Eric Elliot
Thank you for reading!
If you find any typos or have suggestions for translation - please write in private messages.