I'm going to hop onto the current bandwagon of discussing one of the most "controversial" incidents to hit the developer community recently. That's right, I'm going to be talking about left-pad. If you don't already know about all the shenanigans you can read up more on it here or here. I would also recommend reading this blog post that was on the front page of Hacker News that sparked the most debate.

For a quick TL;DR, left-pad is a (very) small Javascript library that adds left padding to a string. There were apparently a lot of very core libraries, such as React, Babel, etc, that relied on this library.

Wait what? Really? Yep! Seriously? Facebook engineers have this as a dependency? Yes for rizzles, the code is so tiny, here it is:

module.exports = leftpad;

function leftpad (str, len, ch) {
  str = String(str);

  var i = -1;

  if (!ch && ch !== 0) ch = ' ';

  len = len - str.length;

  while (++i < len) {
    str = ch + str;
  }

  return str;
}

This sparked a lot of debate because there are many who believe that Javascript and its developers are complete shit - this only helped to affirm their bias. You are entitled to that opinion, but before you jump on the hate bandwagon, I want to provide a little more insight and why I am inclined to disagree with the original blog post by David Haney.

Let's talk about Javascript

Before we can talk about left-pad, let's understand a little bit about Javascript. I won't go into the weird nuisances about Javascript or go too in depth on its history, but Javascript was created to allow non-technical people a means to write code for the Web. As a result, there are many weird quirks about the language. These quirks have influenced many experienced coders to believe Javascript is the devil.

For example, what do you think would happen if you divide any number by 0 in Javascript? If you understand math a little, you would know that it's impossible to divide any number by 0. Well in Javascript, you can! And it returns Infinity!! What the shit!!!

Javascript was shoehorned by Netscape to enable non-coders the ability to create their own personal websites. Many years later, a lot of more stuff happened, and whether you agree with it or not, Javascript soon picked up a lot of traction and became the defacto standard of coding for the Web.

Now here's where the problem of Javascript comes in. People are using it more and more to write software that is not just for the web. The advent of Nodejs and mobile have given Javascript additional opportunities to grow outside it's original intended mission. It has evolved so much as a dynamic programming language that a lot of its original simplicity and technical debt have finally caught up with it.

Lack of a core library

The web is unique in that it is the first truly cross platform environment that can deliver software to everyone on any device. Whether you're on Windows, Mac, Linux, iOS, or Android, you have the ability to use any browser and view the same webpage. That's pretty phenomenal.

However, it is the browsers' responsibility to implement the Javascript interpreter and compiler. That's why webpages can look totally fine on Chrome but not on Internet Explorer. That's also why previous versions of a browser (e.g IE8 or IE9) may compile and support Javascript differently because they have older implantations of the ECMAscript standard (this is the organization that defines the next version of the Javascript language).

Because the Javascript compiler has to be written differently for every browser, and because there are multiple versions of Javascript amongst all the various browser versions, it has the unfortunate circumstance of putting the responsibility on the developer to support the variability. Unlike your more "mature" languages, like Java that come with a JVM that will allow it to execute it's code under the same runtime, Javascript can lack features under different browser environments. This means that Javascript has no core library.

If you didn't realize it by now, there's no special ArrayList, HashTable, or any special fancy things you've grown go expect from a core library that comes prepackaged with the language. So how does Javascript overcome this? It relies on the community to build libraries and frameworks, lots of them, and I mean a shit ton (see below).

DRY in action

The lack of a core library has forced developers to write their own implementations of what seems to be "basic" features. Backwards compatibility with older browsers also forces developers to write their code with specific polyfills or special syntax. For example, look at all the different ways to create an object in Javascript, as documented in the Mozilla Developer Network.

There is a concept in Software Engineering called DRY (Don't Repeat Yourself). Because of all the variables to consider when writing Javascript code that can work everywhere, there are risks in writing it yourself, so people take from others. And if you do happen to write it yourself, you now have to copy and paste that code on all of your future projects if you need it again. If someone else has already written it, why try to reimplement it if someone has done all the heavy lifting for you already? That, my good friend, is why there are so many libraries and modules in Javascript, and especially why left-pad exists.

But avoid over-engineering

With all of these libraries and modules, we may have fallen into the trap of over-engineering. Remember my last post where I talked about architecting your code for reusability? We may have gone a little too far with left-pad. Instead we should strive towards building a core library that contains all the most common utility functions we care about. Examples of such implementations are Lodash and underscore, which are the closest I've found that help achieve that goal. However, they both don't implement a variation of left-pad, so yeah....that explains why left-pad exists...

At the same time, it may not be necessarily correct to create an enormous library with all your core features. This can cause huge overhead and if you especially want to use this code on the browser, that's more code the user may need to download, especially if they're on mobile. So this is actually a fairly hard problem to solve. How do you balance the two?

Mutual understanding and empathy

There are still lots of things the Javascript community has to figure out, but this community is very unique. I have not seen a community share code with others at such a large scale. NPM alone claims that there have been over 50 million package downloads in the last day. No matter how small or big these libraries are, ~that's pretty cray yo~.

I won't get into the nitty-grittys of "dependency hell", and I will admit that I think a dependency on a package as small as left-pad is unnecessary. There are so many libraries being created, shared, and downloaded every day, there are bound to be weird kinks along the way. But even though I disagree, I empathize with the community. With so much code pre-written for you (and potentially fully tested on all browsers), this gives you the opportunity to really focus on just building products. NPM and the Javascript open-source community are part of a cool and weird social experiment. I'm excited to see what else comes out of it, whether positive or negative. In the end, it will provide us with more insights that we can learn from, and that is extremely valuable for me.