ITNEXT

ITNEXT is a platform for IT developers & software engineers to share knowledge, connect, collaborate, learn and experience next-gen technologies.

Follow publication

Member-only story

Why Functional JS

Michele Riva
ITNEXT
Published in
5 min readMay 26, 2021

--

Some thoughts about the “how would you recommend to begin with FP?” question after my speech at Codemotion 2019 in Milan.

Photo by Samuel Ferrara on Unsplash

On the 24th of October 2019, I made my first speech at the Codemotion conference in Milan, Italy. I talked about functional programming and how it can make our life easier when dealing with complex real-world problems such as maintainability, scalability, and error handling.

Many people asked me, “how would you recommend beginning with FP?” The answer is straightforward. If the same question were asked in the ’80s, my answer would be completely different. But today, as frontend development is becoming more and more complex, I’d recommend starting with functional TypeScript.

Why? Let’s find out!

Uncertainty

At its core, Functional Programming forces you to write pure function for a simple reason: we need to get deterministic results out of our computations. For instance, if we’re dealing with a function that depends on the user’s input… how many things could go wrong? The user could insert a wrong or incomplete input; the connection may fail, sending data to the server may require an HTTP request that may fail for several reasons… we’re never sure that everything can go as we imagined. How the heck can we get a deterministic result out of this mess? Putting try/catch everywhere? Creating a huge if/else control structure? We know a more elegant way. In the “Handling the try/catch and if/else hell” article, we’ve seen how monads can help us to improve our code flow and resiliency.

  • Data may cause an error? Let’s use Either monad. It will always return two values: Right(<desired-data>) and Left(<error-wrapper>).
  • Data may be null or undefined for some reason? Maybe monad to the rescue! Our data will be wrapped inside Just(<data>) if it exists. Otherwise, we’ll have just a Nothing value to be handled. No more null/undefined/void 0.
  • Data exist, but we have one or more copies of it? List monad will be your friend!
  • Do data depend on a state? State monad will help you a lot!

And so on, and on, and on!

What’s the point of this? We’ll always get predictable results out of uncertain operations while composing functions.

--

--

Published in ITNEXT

ITNEXT is a platform for IT developers & software engineers to share knowledge, connect, collaborate, learn and experience next-gen technologies.

Responses (2)

Write a response