I think there's two points related to that:

1) JS is unique in that it is delivered over the wire, so there is a benefit in having micro-modules instead of a bigger "string helpers" module. Things like webpack are changing that now (you can require lodash, and use only lodash.padStart).

2) JS's "standard" library is so small, because it's the intersection of all of the browser implementations of JS dating as far back as you care to support. As pointed out in sibling, a proposal for padLeft is included in ECMA2016. But we'll still need Left-Pad for years after it's adopted.

Point 1 was addressed years ago by Google Closure Compiler, which used "dead code elimination".

Also, the Haxe language, which compiles to JS, has DCE.

Micro-modules is certainly a solution if you don't want to use pre-processing or compilers. So is copy/pasting, or manually writing your own util libs, which seems safer than relying on third parties to provide one-liners for you.

Eh, to date, a large part of the JS community still recommends including .js files in script tags in HTML. So, while this has been possible for a while, there hasn't been widespread adoption.

I'm not sure dead code elimination works in that situation. Consider:

  var obj = {
   a: ...
   b: ...
   c: ...
  }

If a, b, and c are functions, there is not necessarily a way to determine at compile time whether they will be used at runtime.

  var prop = webrequest();
  obj[prop]();

In that scenario, a, b, and c cannot be eliminated. But it would be worth testing Google Closure Compiler to see what it does in what scenarios.

I've heard ES6 modules solve this problem, but it seems like dynamic access to an ES6 module might still be possible, which would cause the same problems for DCE. Perhaps no one writes code that way, so it doesn't necessarily matter. But what about eval?

There are lots of tricky corner cases. It seems better to use small atoms than a monolithic package.

In simple mode, Closure Compiler would rename the local variable "prop" but not alter the properties.

In advanced mode, Closure Compiler would globally rename properties and statically eliminate dead code. In your example, it would remove a, b, and c and break the dynamic invocation.

This behavior is all outlined in Closure's documentation with examples.

[1]: https://developers.google.com/closure/compiler/docs/limitati...

Im not really sure how this is an argument against DCE. If theres no way to tell at compile time if these functions will be used, then you have to include them in the final delivered code, whether or not you are using monolithic or micro packages or dead code elimination.

DCE will help you if you pull in huge-monolithic-package and only use one function from it. In that case its basically the same as if you had used the micro package.

Javascript must be written specifically to anticipate Google Closure Compiler's dead code elimination.

Since the vast, vast majority of Javascript doesn't work with it, the issue certainly wasn't addressed years ago.

"Addressed" doesn't mean "solved!" ;)

Yes, you're right, making use of dynamic behaviour will break DCE.

> 1) JS is unique in that it is delivered over the wire, so there is a benefit in having micro-modules instead of a bigger "string helpers" module. Things like webpack are changing that now (you can require lodash, and use only lodash.padStart).

JS isn't even remotely unique in this regard, almost every static language has had dead code removal for decades.

I agree with you, but they weren't saying that JS is unique for having dead-code elimination, but rather for having to be served over a network connection nearly every time it's needed (not accounting for caching and offline apps, etc), which presents an entirely new set of problems that webpack and others attempt to solve.

A in-browser web application requires the left-pad module. Should it include the 500kb library that includes a left-pad function, or import just the 10kb version, which having left-pad function as a module by itself allows?

Yes you can use left-pad module in a browser application using the npm install infrastructure.

JavaScript much to my dismay has no sprintf. It's one of the most annoying omissions ever for server side work.

The biggest thing I've run into is that there's no built-in `mkdir -p`. There is, of course, a module that is literally just mkdirp.

require('util').format gets you pretty close.

No it really doesn't. It is so far away from even Perl's printf (considered ancient by most JS programmers) that it is not even funny.

es6 has one

No it doesn't. It comes with template strings. Any sprintf type functionality requires you to call functions on the input. It is a tiny tiny step forward.

Uh, no Left Padding is NOT built-in in JavaScript. The proposal to add `String.prototype.padLeft()` was just added to ECMAScript 2016.

JavaScript had a very minimal standard library, it's pretty asinine of you to compare it to C or any other language with a pretty extensive standard library.

C didn't get a standard (or a standard library) until 1989. It had been around for 17 years at that point. Two years after its invention, JavaScript was standardized in 1997. That's almost twenty years ago.

I've never thought of C as being a particularly good example of "extensive standard library."

I wanted to say that it's built-in in pretty much every other language apart from JS

But alas, here we are, talking about the JavaScript language and it's ecosystem.

It's easy to say "I don't see why there's a need for an 11 line module to pad left on a string" when your language of choice has a robust standard library with such abilities built in.