Thank you for your comment.

In my opinion, pure functional programming (where no side effects are allowed) is not to practical. I also do not advocate for pure functional languages (Haskell/Elm) since the focus on purity tends to add a lot of complexity.

The best guideline is to have as much of the codebase as possible composed of pure functions, and to move all of the effects to the boundary of the system. Logging though is one exception that I think is safe to add pretty much anywhere without any negative consequences. And yes, logging is a very useful method for debugging, I rely on logging a lot in my day-to-day work (while working in functional languages).

Regarding error handling — the recommended approach is the Result pattern, and it is possible to convert functions that throw into functions that return Result instead (something like try {return Ok(data);} catch {return Error("something is wrong");}).

It is possible to write functional code in JS, and I’ve successfully written quite a lot of good functional code in JS. Although I’d really recommend starting with a proper functional language (Elm/ReasonML/Elixir are good options). It’s hard to think functionally in a language like JS, where one can easily fall back to the imperative paradigm.