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.

Both authors emphasize pragmatics over programming-language theory, but the scope of both books is deep enough so that there’s no avoiding sentences that are difficult to casually unpack (“Apply is a method that is implemented by every function that takes a context as its first argument, and it takes an array or array-like thing of arguments as its second argument”). Both books do a good job of presenting many source-code examples and practical recipes. Neither book pretends to be a comprehensive text on functional programming. Both authors write clearly and accurately. I’m not normally averse to making a recommendation, but in this case, I think it’s truly necessary to read Braithwaite’s sample chapter and decide if the tone is to their taste.

Even with both books at hand and fresh in my mind, when I had a small challenge yesterday (converting an array of strings holding file paths into a tree-like data-structure), I hacked it with an F# REPL, not a JavaScript one. But although there are F#-to-JavaScript compilers, I wouldn’t expect to use F# or Scala or Haskell inside an enterprise application. JavaScript is, for the foreseeable future, the language of the browser. Every developer who writes Web applications should have, on their shelves, a copy of Crockford’s “JavaScript: The Good Parts,” and one—if not both—of “JavaScript Allongé” or “Functional JavaScript.”

Larry O’Brien is a developer evangelist/advocate for Xamarin. Read his blog at www.knowing.net.