A Skeptic’s Guide to Functional Programming with JavaScript
What if the team hates my functional code?
So you learned some functional programming. And it’s glorious! Your JavaScript is cleaner; more concise; elegant. It feels solid. You can’t wait to share it with the team. So you throw up a PR and wait for the comments to come in; eager to hear what they think.
And those comments come in all right. But they’re not complimentary. It starts slowly, but soon they’re flying in like a hailstorm of bullets:
- This code is so elegant it’s impossible to read.
- Recursion in JavaScript performs like absolute garbage.
- I’ve never seen a single situation where currying improves the code. Why is this useful?
- Trying to do immutable data in JS is just painful.
- Bloated ivory tower rubbish.
It’s not what you expected. And you’re stuck. Frozen like a deer in the twin beams of an oncoming semitrailer. How do you even begin to respond to all this? Some of the team’s objections are reasonable. But which ones? Some of their comments are based on nothing but myth and personal bias. But, again, which ones? And how can you have an intelligent, reasonable conversation about it?
It’s like you’re caught in a trap. You know functional programming produces better code—even in JavaScript. You can’t go back to the old way of doing things. But the rest of the team don’t get it. There has to be a way to at least talk about this without starting some kind of blood feud. But how?
Trying to introduce functional concepts can feel like navigating a minefield. Especially when the team seems dead-set against it. But it doesn’t have to be that way. It’s possible to find safe paths.
Level up your code and bring your team on the journey with A Skeptic’s Guide to Functional Programming with JavaScript. Learn how to adjust your code to suit the team’s level of familiarity. Spot performance pitfalls. Use functional techniques to apply performance optimisations with guaranteed safety. Sort the myths from reality. Write functional JavaScript with confidence.
You can learn to defend your code intelligently and diplomatically. And write expressive, elegant code you can be proud of.
Get the book through my Shopify online store, or use one of the buy buttons below.
Prices are listed in USD, unless otherwise specified (see note below).
Answers to questions that I imagine I would ask, if I were buying a book
-
Hey! The price changed when I went to check out. Yeah, I’m really sorry about that. Shopify doesn’t allow you to automatically display local currency on an embedded purchase widget. So, it defaults to USD, then updates it once you set a shipping location. If it’s of concern, you can purchase through the online store, and it should show you the correct price before you check out.
-
What format(s) does the eBook come in? The eBook comes in ePub and PDF formats. Both should work okay with common eBook readers like Apple Books and Kindle. Though, if you’re reading on an actual computer, I recommend Calibre. It’s free. And it has much better typographic support than either Apple Books or Kindle. You can also use it to convert ePub files to other formats if you have a legacy device.
-
How many pages in the paperback book? The paperback has a total of 288 pages.
-
Can I contact you if I’m having trouble purchasing? Yes, send me an email and I’ll get back to you as soon as I can.
-
What’s in it? Can I see a table of contents? Sure. But to save space, I’ll stick the table of context into an expando-box:
Table of Contents
- A Skeptic’s Guide to Functional Programming with JavaScript
- Introduction
- Who is this book for?
- What will you get out of this book?
- How this book is organised
- What’s so great about functional programming anyway?
- Algebraic structures
- Maybe
- Result
- Task
- So you used polymorphism. Big deal.
- So what?
- Functional programming makes JavaScript unreadable
- Currying
- Point-free style
- Readability, familiarity, and expressivity.
- Freedom of expression
- Great, tell that to my team full of haters
- But, my team still has to read my code
- Functional programming harms performance: Recursion
- Recursion
- Measure
- Performance and referential transparency
- Functional programming harms performance: Immutable data
- But, why?
- Immutable data and the virtual DOM
- Memoization
- Records and tuples
- What do we do in the meantime?
- But, performance matters
- JavaScript isn’t a functional language
- Don’t choose JavaScript if you want to learn functional programming
- Functional programming in JavaScript can be frustrating
- Functional programming with JavaScript is a cargo cult
- How to talk about it
- Functional programming is hard
- Functional programming is hard to learn
- The jargon problem
- The unlearning problem
- The beauty problem
- The snobbery problem
- Functional programming is hard work
- What’s so great about functional programming (again)?
- Functional programming produces more expressive code
- Functional programming gives us more confidence in our code
- Conclusion: What do we do?
- Introduction
- Appendices
- What are higher-order functions, and why would anyone care?
- Functions as first-class citizens.
- What is a higher-order function?
- Examples of higher-order functions
- So what?
- The marvellously mysterious JavaScript Maybe monad
- A quick recap of Promises
- A problem to solve
- The Maybe monad
- Maybe of a Maybe? Maybe not.
- But what do you do with it?
- Pointfree style
- Pipelines
- Further reading
- Elegant error handling with the JavaScript Either Monad
- A sample problem
- Exceptions: The good parts
- Problems with try…catch exception handling
- Coming up with an alternative
- Polymorphism
- Left and right
- Really? Is that it?
- Further reading
- How to deal with dirty side effects in your pure functional
JavaScript
- Dependency injection
- Lazy functions
- The effect functor
- So What?
- Summary
- Recursion performance measurements
- Recursive array map performance
- Recursive array map performance with immutable data structures
- Recursive DOM traversal
- Acknowledgements
- What are higher-order functions, and why would anyone care?
- A Skeptic’s Guide to Functional Programming with JavaScript
-
Can I see a sample of what’s inside? You know, see how it looks; what the writing’s like. Sure. You can read a sample chapter online. Or, if you want to see how pages in the actual book appear, you can download a PDF version of the same chapter.
Errata
First revision: 28 November 2022
-
Added missing parentheses around object literal for
Err
. Section 2.3. Page 22 of PDF/Paperback. -
Added missing parentheses around object literal for
Task
. Section 2.4. Pages 24–25 of PDF/Paperback. -
Added missing parentheses around object literal for
Task
. Section 2.4. Pages 26–27 of PDF/Paperback. - Fixed typo ‘But, this reduces’ rather than ‘But, ths reduces’. Section 3.1. Page 40 of PDF/Paperback.
- Fixed typo, ‘signal-to-noise ratio’ rather than ‘signal-to-noise ration.’ Section 3.6. Page 57 of PDF/Paperback.
- Fixed typo, ‘Remember too, that what’s unreadable now’ rather than ‘Remember too, that what’s unreadable no,w.’
-
Fixed typo,
const professorX =
rather thancost professorX =
. Section 5.3. Page 96 of PDF/Paperback.
Second revision: 3 December 2022
-
Changed
const iconPrefix
toconst urlPrefix
. Sections 2.1 and 2.2. Pages 10 and 15. -
Added missing return statement and function call to
addIcon()
function definition. Section 2.2. Page 15. -
Removed parentheses so that anonymous function in
Task()
will return a value. Section 2.4. Page 24 of PDF/Paperback. -
Removed semicolon after definition of
run()
method inTask
. Section 2.4. Page 25 of PDF/Paperback.
Third revision: 11 December 2022
- Added ‘high contrast code’ versions of PDF and ePub files to make code blocks easier to read on greyscale e-Ink devices.
- Corrected typo: “lazy, incompetent programmers who developed an interest in functional programming”. Section 2.0. Page 6 of PDF/Paperback.
-
Added missing placeholder variable name in
catch
statement. Section 2.2. Page 16 of PDF/Paperback. - Corrected typo, spelling of ‘further’. Section 3.1. Page 40 of PDF/Paperback.
-
Corrected typo in implementation of
keyBy()
function, removing extraneousarr.reduce()
method call. Section 5.0. Page 90 of PDF/Paperback. -
Fixed syntax for records and tuples example to push hashes
#
in the right location. Section 5.4. Page 98 of PDF/Paperback.