Hacker News Reader

Comment by adambard | Hacker News Reader

I think it speaks to just how lacking the baseline Javascript standard library is. The libraries that come with node help, but all of this stuff seems like it should be built-in, or at least available in some sort of prelude-like standard addon library. The lack of either leads to all these (apparently ephemeral) dependencies for really simple functions like these.

That said, I work with Java, Clojure and Python mostly so I may be more used to having a huge standard library to lean on than is typical.

View on HN

So many people use lodash as a drop-in standard addon library that I'm surprised people aren't just using the padding functions that are right in there... Some of the packages that broke yesterday even have lodash included as dependencies already!

Probably they do use that if they need left padding but also have a dependency on another package that thinks 'lodash is too big when all I need is left padding' so we get to this situation

What if lodash itself was unpublished? I'm having a hard time drawing a line here, obviously a 10 line function is too far on the bad side of lazy, but I can't tell what is an acceptable dependency.

I think it would be annoying but recoverable. It's used so widely that somebody would republish it, at worst under a different name.

Edit: But there would sure be a period of chaos.

So it's the same with pad-left. But some how people are wrong for depending on pad-left.

If you depend on Lodash, you depend on Lodash. You have 1 point of failure.

If you depend on 2,000 tiny individual modules, each from different authors, you depend on 2,000 tiny individual modules. You have 2,000 different points of failure. Any one of those authors going rogue will break your build or compromise your system, and every one of those tiny modules has a lot less attention and care paid to it than a larger library like Lodash.

Looking at the changelog, there have been more than 70 versions of Lodash in less than four years. The first was in April 2012. [1]

  _.padleft

does not exist. It was added as part of version 3.0.0 January 26, last year and renamed to _.padstart in Version 4.0 on January 12, this year.

So in less than a year "padleft" came and went away because all strings don't start on the left and someone decided that "left" means "start" except that the reason that it doesn't is the reason that it was changed. Even worse, the 4.0 documentation does not document that _.padstart renamed _.padleft. It's hard to grok what cannot be grepped.

Why blame someone for depending on padleft in a world where libraries swap out abstractions in less than a year? Breaking changes are bad for other people. Semantic versioning doesn't change that.

[1]: https://github.com/lodash/lodash/wiki/Changelog

Yes, I found a number of the stylistic changes made in Lodash 4.0 made it more complicated to upgrade than needed.

Dropping the this param with no period of deprecation? Pretty breaking change to make with no warning. Renaming first/rest to head/tail? Was it really worth it? Particularly when they go the opposite direction of replacing traditional functional names with more explanatory names by removing the foldr alias for reduceRight.

All this in a language that doesn't make it easy to do automated refactoring means that you basically break everything upgrading to Lodash 4.0 so you can't refactor parts to the newer style piece by piece.

The reason for the name change and the Parma change is that String.prototype.padStart is being added in the next ECMAScript release, and lodash was changed to be compatible with the newly built-in version (so it's a polyfill).

An easy solution would be to have both padStart and padLeft, with a note in tbe changelog saying padLeft is deprecated and will be removed in a future version.

Damn, yeah, that's a totally valid reason. I was under the impression that lodash was more stable than to have that kind of stuff happen.

This seems like the right answer to me. It's not that we forgot how to program, it's that Javascript forgot a stdlib. You could easily write your own left-pad function in any language, but a stdlib (or this module) gives you a standard way to reference it, so you don't have to look up what you named it or which order the args go in.

Agreed the JavaScript standard library is poor and instead of addressing it they've mostly just added syntax changes to ECMAScript 6 and 7. It's incredibly disappointing.

For instance I added a utility to my own library (msngr.js) so I could make HTTP calls that work in node and the browser because even the fetch API isn't universal for some insane reason.

I think in some ways a good standard library is a measure of programming language maturity. I remember when C++ had a lot of these problems back before you had the STL etc. In the early 90's it was a dog's breakfast.

We have a large internal C++ app at my work of that vintage (~1992) it uses its own proprietary super library (called tools.h++) which is just different enough from how the C++ standard evolved that its not a simple task to migrate our codebase. So now every time we change hardware platforms (has happened a few times in last 30 years) we have to source a new version of this tools++ library as well.

I find it amusing Javascript hasn't learnt from this.

Reply on news.ycombinator.com