Samson and JavaScript

Eric Elliott and Douglas Crockford tout functional programming (or FP) and prototype-based OOP as the two “pillars” of JavaScript. These are the main strengths of the language. Apparently, it’s a killer combination that makes JavaScript a wonderful programming language. Who knew?!

The problem is, both pillars are made of Styrofoam. JavaScript is not a particularly good FP language. It’s never mentioned in the same breath as Haskell, Erlang, Clojure, Scheme, Scala, F#, and others. Its wonky semantics does not support FP well. And JavaScript is missing many of the qualities of “real” FP languages (whether “pure” or “multi-paradigm”). Things like currying, pattern matching, and immutability are done through special libraries and programming patterns. They are not directly built into the language. It’s not impossible to write functional code in JavaScript; it’s just not a “natural” way to do it. Heck, if I try hard enough, I can hack Go or Smalltalk to write functional code, too. In all of these instances, the code will never be as clean and elegant as in a “real” FP language, such as Haskell, Clojure, or Erlang. When you use a good FP language, the code will look better, read better, and be more maintainable. If you truly care about functional programming, then JavaScript would certainly not be your first choice.

Prototype-based OOP has also not gained traction in IT. None of the mainstream programming languages use object prototypes, not even the new, up-and-coming languages such as Go, Rust, Kotlin, Swift, and others. Even within the JavaScript universe, prototype-based OOP is poorly used, if it’s used at all. Just look at the many open source JS libraries out in the wild–how many of them use object prototypes well? If they use OOP, it’s usually class-based, and it’s pretty ugly, too.

The fact is, most of the IT industry is firmly settled on class-based OOP. Prototype-based OOP is a very hard sell, even though it’s been around for nearly 30 years (since the introduction of the Self programming language). Most developers intuitively sense that prototype-based OOP does not scale well for large applications. No wonder ECMA added classes to ES6 under pressure from the IT community. And TypeScript has been gaining in popularity precisely because people want class-based OOP.

Even if you do adopt object prototypes in your application, how would you explore and maintain all the object relationships?

Perhaps you can go through your code, line by line, following the trail of object creation. Without a handy tool (akin to a class browser) to aid you, you’d have to meticulously document all the object relationships in your application. Sounds like fun, doesn’t it?

As Eric Elliott is fond to remind us, the vast majority of JavaScript programmers know or use JavaScript very poorly. JavaScript is, first and foremost, an imperative, procedural language with some FP and OOP styling thrown in for good measure. Most novices will first learn JS as imperative. It’s no surprise, then, that when JS is used to adorn a webpage (even with jQuery), people write a bit of imperative code to glue things together. At what point will they pick up FP or OOP?

The bigger problem is that these two pillars of JavaScript are resting on a shifting foundation of garbage, an untreated landfill, if you will. It’s pretty easy to topple these pillars as you struggle against JavaScript’s many problems. Peter DiSalvo writes a brilliant and eloquent critique of JavaScript right here.

We are like Samson pushing back on the spurious promises of JavaScript, the lie that has beguiled a generation of naive developers. How do you counter so many foolish minds?

James Mickens, a Harvard professor of computer science, has an amusing tale to tell you: