JS isn't really a functional language, it's an imperative, prototype-based language with partial functional support that allows multiple coding styles, like most of the popular scripting languages.
The fun, and funny, and maybe (probably) even terrible, thing about javascript is that while it -is- functional, and (IIRC) always has been, historically it wasn't originally used that way!
Only relatively recently have programmers embraced its functional aspects; prior to that it was mostly used as a procedural language.
Then people started to used functional aspects of it to "shoehorn" it into allowing a quasi-OOP form of programming style, and this form has been baked (in no small part) into the latest version of ECMAScript.
But people following this path, coupled with (I believe) using JQuery, NodeJS, and other tools (and now React) have led most of them (raising hand here) to more fully embrace it as a functional language.
But here's the thing:
You can still use it as a procedural language - and an OOP language - and a functional language! All at the same time if you want - it doesn't care (much)! It's like this weird mismash of a language, a Frankenstein's Monster coupled to Hardware's killer robot.
Yes - with today's Javascript you can still write a unicorn farting stars that follows your mouse on a webpage while playing a MIDI file - and do it all procedurally. In fact, there's tons of code examples out there still showing this method.
You can mix in simple class-like constructs using anonymous functions and other weirdness - or just use the latest supported ECMAScript OOP keywords and such - go for it!
Want to mix it up? Combine them both together - it don't care!
Oh - and why not pass a function in and return one back - or an entire class for that matter! It's crazy, it's weird, it's fun!
It's maddening!
And yes - it's a crazy quirk of history - a language that was created by a single programmer over the course of a weekend (or so legend goes) at Netscape has and is seemingly taking over the world of software development.
Not to mention Web Assembly and all that weirdness.
I need to find an interview with that developer; I wonder what he thinks about his creation (which is greatly expanded over what he started with, granted) and it's role in software today - for good or ill...
> Oh - and why not pass a function in and return one back
The "function" in "functional programming" is a reference to mathematical functions. Mathematical functions do not have side effects, and consequently are referentially transparent (the result doesn't depend on the evaluation order or on how many times the function is evaluated). Code with side effects is not a function in the mathematical sense, it's a procedure. The defining characteristic of functional programming is the absence of side effects. That isn't something you can just tack on to an imperative (or "multi-paradigm") language. No matter how many cosmetic features you borrow from functional languages, like closures and pattern-matching and list comprehensions, you still have the side-effects inherent in the support for imperative code, which means your program is not referentially transparent.
Haskell manages to apply the functional paradigm to real-world programs by essentially dividing itself into two languages. One has no formal syntax and is defined entirely by data structures (IO actions). This IO language is an imperative language with mutable variables (IORefs) and various other side-effects. The formal Haskell syntax concerns itself only with pure functional code and has no side effects. IO actions are composed by applying a pure function to the result of one IO action to compute the next action. Consequently, most of a Haskell program consists of pure code, and side-effects are clearly delineated and encapsulated inside IO data types at the interface between the Haskell code and the outside world.
You can write pure code in almost any language, though some make it easier than others with features like lexical closures and algebraic data types. But is that the idiomatic form? Is it evaluated efficiently? And can you count on libraries to be written the same way?
Javascript without any support for mutation or other side effects wouldn't really be recognizable as Javascript any more.
It's not required to write idiomatic JS, but pure functional code is very much idiomatic. (I.e. pure functional code isn't considered unidiomatic in JS as it might be in some other languages). Many people write the meat of their code in pure functions, and this paradigm is encouraged by React (especially with the invention of hooks).
As for libraries, you can just treat them as stateful external things you have to interact with the same way IO / network calls are stateful.
Did you watch the video? The most popular language is JavaScript, which is only not functional but a quirk of history.
The video makes an argument for marketing being the reason.