JavaScript has emerged as a language in which every programmer needs to be competent, if not masterful. It is the lingua franca of the Web client, and while alternatives such as Microsoft’s TypeScript and Google’s Dart are worth watching, they are not anywhere close to “crossing the chasm” from early adoption to majority use.

JavaScript is a language that’s problematic. Brendan Eich’s heroic effort to embed a language in 1995’s Netscape Navigator is justifiably legendary, but the semantics of the language contain any number of things that make you say “Wut?” (“The only proper response to something that makes no possible sense”). Although an unfair comparison, it’s hard not to smirk a little at the difference in thickness between Douglas Crockford’s “JavaScript: The Good Parts” (176 pages) and David Flanagan’s “JavaScript: The Definitive Guide” (936 pages).

For a variety of reasons, for a decade JavaScript was not shoeboxed into any particular programming style: Programmers rarely argued about the architecture and design of JavaScript modules, which were considered more of a “git ‘er done” tool to gain some functionality on the Web page.

Rather than a network of interconnecting objects, most JavaScript Web pages relied on writing event-handling functions, which could be created inline, anonymously. This was frequently abused, and it was a common sight to open a Web page and find a vast tree of functions nested within functions nested within functions without the slightest rhyme or reason.

That changed with the release (and exploding popularity) of jQuery in the mid-2000s. jQuery popularized passing and returning (rather than nesting) functions. Users were, unknowingly, becoming familiar and comfortable with functional programming techniques.

I’ve talked about functional programming a good deal in this space, generally in the context of languages such as Haskell, Scala and F#. These languages all feature sophisticated static type systems, and while I can argue both sides of the “static vs. dynamic typing” coin (on any given day I generally see the merits in whichever approach I’m not using), it seems a little strange to promote JavaScript as a functional programming language from the get-go.

Not to Michael Fogus, author of “Functional JavaScript,” and Reginald Braithwaite, author of “JavaScript AllongĂ©.” These two books cover much of the same ground, assuming that the reader is comfortable in JavaScript (better still if they’ve digested “JavaScript: The Good Parts”) but not versed in functional programming. This allows both books to focus on the core issue of teaching functional concepts (although some language details, such as JavaScript’s confusing “truthy” semantics, inevitably crop up) and highlighting the benefits of functional approaches.

The books have very different tones. Braithwaite’s is breezier and covers more ground, but risks having the less-attentive reader lose the trail. Fogus’ book is more conscientious to the details, which can make the text a little dry at times, but may provide a more solid foundation for the reader. I cannot recall two books that struck me as so equal in their technical content and accuracy while having such disparate styles.