JavaScript has come a long way since the early days of the web, a time when the language was utilized to add a quick pop-up to a page, make some gaudy graphic move across the screen, or, if you were really fancy, error check a few fields in a web form. Today, javascript dominates the world of web development (both in the browser and on the server through technologies such as node.js), speeds through tasks with performance that makes other languages envious, and proves to be a very capable language in terms of implementing a broad range of programming paradigms.
Many online tutorials demonstrate how to implement Object Oriented Programming (OOP) patterns in JavaScript, and, I must confess, the language proves very capable in this respect. However, it’s JavaScript’s ability to implement Functional Programming (FP) patterns that has benefited my work the most.
Sharing logic
There are many qualities that serve to contrast traditional OOP with FP (e.g, first-class functions, (im)mutability, side effects vs. purity, declarative vs. imperative style, etc.), but I’d like to focus on how logic is shared/reused within applications. OOP paradigms tend to share logic by explicitly pushing it out to objects through inheritance, composition, and/or mixins. In contrast, FP tends to push the data to the logic. FP makes this possible because functions typically act on data values rather than from within them.
For a trivial example of how I typically share logic when programming in JavaScript , let’s consider a function called createFormalGreeting(person) that expects a value (object) that contains a lastName field (string) and an isMale field (boolean). As long as the value contains these fields, it will be able to successfully return a string representation of a formal greeting. An employee value, a student value, or even an alien value (the truth is out there) could all be successfully passed to the function as an argument as long as they possess the required structural compatibility.
haven.js
While JavaScript facilitates many aspects of FP, I’ve missed the ability to declare the structural expectations of function parameters and return types (or, the ability to infer type as Haskell does.) I frequently find myself checking for the existence of fields in functions and doing quick tests of a value’s type to avoid coercion gotchas. In light of these issues, I’ve developed haven.js, a simple type checking framework for Javascript that tests for structural compatibility.
The general idea behind haven.js is to ensure that all of the values passed into and out of functions are structurally compatible with the function’s expectations. It works by replacing function calls with wrapper functions that test the parameter and return types explicitly declared as object fields on the functions themselves. If type compatibilities are identified, the details are logged to the console (although the console is used by default, you can tell haven to throw exceptions instead, as you may wish to do when integrating results into unit tests.) I tend to turn off the type checking (i.e., simple don’t call the function haven.typeCheck) in code that’s released in production to avoid the performance hit.
So far, haven.js has greatly facilitated my work, and I hope you’ll get some benefit, too.
Leave a Reply