How to deal with dirty side effects in your pure functional JavaScript

We shouldn't have to rely on loopholes to satisfy any hard and fast rules. A lot of writing good code is just being reasonable and explicit.

If you call a function to launch a missile, you'd expect that it's just going to launch a missile and do nothing else. So why are we so concerned that it contains side effects? What other option do we have?

Logging is a bit different. For many, logging is probably a necessity to allowing you to look back and and understand context when things go wrong. But when you're programming functionally, I find that it's much easier to get a grasp on things compared to procedural code, which can become spaghetti much quicker. I also find that bugs are much less common, or otherwise much more obvious in functional code, negating the need for logging in the first place (for functional code).

E.g., suppose you have an SPA that pulls data from a number of Rest endpoints, then does some transforms on that data, produces some HTML and eventually updates the page DOM accordingly.

It makes sense model the "transform" and "produce HTML" steps as pure functions, because they are effectively side-effect free calculations. I think it might also make sense to cheat and treat the Rest calls as pure functions, because this will let you find out quickly in which order you should do them and which of them you can run in parallel.

But why would you want to model the eventual update step itself as a pure function?

  const fOne   = fIncrement(zero);
  const fTwo   = fIncrement(one);
  const fThree = fIncrement(two);
  // And so on…

Unless you code very defensively, there's no way you can guarantee purity, especially in async programming.

Given f(x) = y, if x is a regular JS object, you can't guarantee purity. It works many times because of the single-threaded nature of most JS engines, but the moment you do something async, you can't guarantee x hasn't changed.

That's one of the many reasons I like ClojureScript. It offers interesting guarantees that let me write robust code.

Instead of reading from opaque file handles use three-tuple of (hash, offset, length). Now you have pure input.

Instead of printing to a stream, modify a git repo. Now you have pure output.