davidbgk
/
larlet-fr-david-cache

title: NPM & left-pad: Have We Forgotten How To Program?
url: http://www.haneycodes.net/npm-left-pad-have-we-forgotten-how-to-program/
hash_url: 68b4ccd13ef04eb9a617d50741c15945

<p>Okay developers, time to have a serious talk. As you are probably already aware, this week React, Babel, and a bunch of other high-profile packages on NPM broke. The reason they broke is rather astounding.</p>
<p>A simple NPM package called left-pad that was a dependency of React, Babel, and other packages. One that, at the time of writing this, <a href="https://github.com/azer/left-pad">has 11 stars on GitHub</a>. The entire package is <a href="https://github.com/azer/left-pad/blob/master/index.js">11 simple lines that implement a basic left-pad string function</a>. In case those links ever die, here is the entire code of left-pad:</p>
<pre class="brush: jscript; title: ; notranslate" title="">
module.exports = leftpad;
function leftpad (str, len, ch) {
  str = String(str);
  var i = -1;
  if (!ch &amp;&amp; ch !== 0) ch = ' ';
  len = len - str.length;
  while (++i &lt; len) {
    str = ch + str;
  }
  return str;
}
</pre>
<p>What concerns me here is that <i>so many packages</i> took on a <b>dependency</b> for a simple left padding string function, rather than taking 2 minutes to write such a basic function themselves.</p>
<p>As a result of learning about the left-pad disaster, I started investigating the NPM ecosystem. Here are some things that I observed:</p>

<p>All of this leads me to wonder…</p>
<h2>Have We Forgotten How To Program?</h2>
<p>On what possible plane of existence is this a better solution to past problems? How are hundreds of dependencies and 28,000 files for a blank project template anything but overly complicated and insane?</p>
<p>I get the impression that the NPM ecosystem participants have created a fetish for micro-packages. Rather than write any functions or code, it seems that they prefer to depend on something that someone else has written. It feels to me as if the entire job of an NPM-participating developer is writing the smallest amount of code possible to string existing library calls together in order to create something new that functions uniquely for their personal or business need.</p>
<h2>Functions Are Not Packages</h2>
<p>Functions are too small to make into a package and dependency. Pure functions don’t have cohesion; they are random snippets of code and nothing more. Who really wants a “cosine” dependency? We’d all really like a “trigonometry” dependency instead which encompasses many “tricky” functions that we don’t want to have to write ourselves. This is much more akin to how .NET and other frameworks create a “core” library of basic functionality. Such a library is vetted by the creators of the language and pretty much guaranteed to be correct and bug-free.</p>
<h2>Third Party Problems</h2>
<p>There’s absolutely no guarantee that what someone else has written is correct, or even works well. Even if correct, is it the most optimal solution possible? At least when you write the code yourself, you can easily modify it to fix bugs and improve its efficiency. Not that there should be many bugs in 1 line functions.</p>
<p>Second, even if the package’s logic is correct, I can’t help but be amazed by the fact that developers are taking on dependencies for single line functions that they should be able to write with their eyes closed. In my opinion, if you cannot write a left-pad, is-positive-integer, or isArray function in 5 minutes flat (including the time you spend Googling), then you <b>don’t actually know how to code</b>. Hell, any of these would make a great code screening interview question to determine whether or not a candidate can code.</p>
<p>Finally, stringing APIs together and calling it programming doesn’t make it programming. It’s some crazy form of dependency hacking that involves the cloud, over-engineering things, and complexity far beyond what’s actually needed.</p>
<p>What’s worse is that if any of your code (or the 3rd party library code) has a bug or breaks, you won’t know how to debug or fix it if you don’t know how to program.</p>
<h2>Strive For Few Dependencies</h2>
<p>Every package that you use adds yet another <b>dependency</b> to your project. Dependencies, by their very name, are things you <b>need</b> in order for your code to function. The more dependencies you take on, the more points of failure you have. Not to mention the more chance for error: have you vetted any of the programmers who have written these functions that you depend on daily?</p>
<p>Take on a dependency for any complex functionality that would take a lot of time, money, and/or debugging to write yourself. Things like a database access layer (ORM) or caching client should be dependencies because they’re complicated and the risk of the dependency is well worth the savings and efficiency.</p>
<p>But, for the love of all that is programming, write your own bloody basic programming functions. Taking on dependencies for these one-liners is just nuts. Don’t believe me? Just ask the React team how well their week has been going, and whether they wish they had written those 11 lines for left-padding a string themselves.</p>