Toxic bias in the Javascript community

by Alexis Hope, 05 Jun 2021

Having been in the Javascript community for a while I’ve witnessed the building momentum towards a Functional Programming (FP) style. I think Javascript and FP are great but there is perhaps a miss-guided favor or emphasis put on FP as something superior. The React community help perpetuate this with the introduction of hooks, moving away from class based components (favoring functions) and libraries like Redux all employing bits of FP.

There is nothing wrong with embracing FP but there is an issue with proclaiming superiority especially when its an unfounded statement. One example of this bias being present is in a popular course on FP and JS Functional Programming For Beginners With JavaScript by James More. Overall not a bad course it covers some sound basics. But in chapter 6 when trying to illustrate the difference between Imperative vs Declaritave (or Normal vs FP) a toxic view presented. Two examples are given that just aren’t comparable and is crafted to favor FP and then jQuery is mocked without validation.

It seems harmless although whats troubling is this course is targeted to new and potentially easily influenced new comers. In this context I believe it establishes a divide or class hierarchy (pun intended) amongst developers. There is nothing wrong with jQuery, there is nothing wrong with imperative programming, FP is not better it’s different.

Lets break down the examples a little more and explore why they are a bad example to present newbies and not a fair comparison.

Declarative FP Example

// this is not line for line from James More code but a consolidated version that captures the esssence
const MEALS = [
  { description: "Breakfast", calories: 460 },
  { description: "Snack", calories: 180 },
  ... 
]

const td = (className, children) => `<td class="${className}">${children}</td>`

// also in scope are functions like table, thead, tr
MEALS.map({ description, calories } => tr([td(description), td(calories)]))

This results in building up a table view to render as HTML. Its a nice approach using smaller functions to compose functionality.

The output:

  <tr>
    <td>Breakfast</td><td>460</td>
    <td>Snack</td><td>180</td>
  </tr>

Imperative non FP Example

The declarative approach is compared against this below “imperative” approach.

$("#app").append("<tr></tr>")
$("#app tr:last-child").append("<td>Breakfast</td><td>460</td>")
$("#app tr:last-child").append("<td>Snack</td><td>180</td>")

Whats wrong with these examples? They’re not comparable nor representative of imperative programming.

In the first example we have employed a data structure and sub routines which aren’t exclusive functional practices. Using data structures and functions are valid imperative programming techniques. Not using them and comparing them. The truth is there would be very little difference between the two styles

And jQuery is shamelessly laughed at. Why is jQuery even being used in this example? The introduction and support of querySelector predates map (if you consider map wasn’t available until IE11 querySelector was available in IE8).

Then the argument is made you can’t compute the total calories in this style of programming. When it makes it hard to compute anything when you have hardcoded the solution.

Below is a more succinct version of this hardcoded solution. Essentially this is comparing the use of data structures and methods to hardcoding something then claiming FP is better.

document.querySelector("#app").append(`
  <tr>
    <td>Breakfast</td><td>460</td>
    <td>Snack</td><td>180</td>
  </tr>
`)

An Imperative C Example (without FP)

In fact these approaches are so well established you can express the FP example in C. C being an imperative procedural language it often isn’t associated with FP. Its more verbose being a strict typed language the Javascript is a little more concise in its handling of strings. The only real difference is in the iteration approach where this uses a for loop rather than map iteration.

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

typedef struct
{
  char description[50];
  int calories;
} Meal;

Meal meals[2] = {
    {"Breakfast", 460},
    {"Snack", 180}};

char *td(char *className, char *children)
{
  char *ret = malloc(100);
  strcat(ret, "<td class='");
  strcat(ret, className);
  strcat(ret, "'>");
  strcat(ret, children);
  strcat(ret, "</td>");
  return ret;
}

int main()
{

  int length, i;
  length = sizeof(meals) / sizeof(Meal);

  for (i = 0; i < length; ++i)
  {
    char *cell = td("", meals[i].description);
    if (cell)
    {
      printf("%s \n", cell);
      free(cell);
    }
  }

  return 0;
}

In closing

This is a cherry picked example. Why I have such a problem with it is this is setting a precedent for the next generation of Javascript developers. And I see this underlining behavior in interactions in professional and open source settings. Making mockery of tooling like jQuery is never appropriate. If you are to do so do so with verifiable objective examples. Not subjective sarcasm.

If you are interested in learning Functional Programming in Javascript. I highly recommend these two books which you can read online.