Hacker News Reader

Comment by nemild | Hacker News Reader

I think you're missing two major points (which the original 'left pad' post partially noted):

1. There should be one or several libraries (like lodash), where the maintainer provides a high level of quality across many core utilities that are needed, rather than all these functions singly collected across many different users which can lead to variable quality - and a maintenance nightmare over time (plus the potential security risks)

2. You should minimize dependencies when it doesn't provide great value (the bar's especially high if many others could/will depend on your library); there are functions like 'is-positive-integer' that should have been written without external dependencies (but had 3 dependencies); realize that dependencies inject cost into your system (and benefits as well), and weigh one vs the other for your use case, rather than blindly defaulting to a mindset that micro libraries are always the best approach

View on HN

Regarding #1, I strongly think that the JS community should come together and build out a library that fills the same role as Boost does for the C++ community. Sort of a collection of things that are missing from the standard library.

I suppose lodash and others aim for a similar purpose, but clearly left-pad-gate has shown us that they're not quite complete enough.

Or apache commons lang for java.

Agreed, I think one issue is that great libraries for all use cases weren't available in the past so older libs built up these chain of dependencies, and this might be the wake up call that gets people to to a) create a few more unified libs (might be as simple as cherry picking top NPM micro libs + refactoring) and b) gets libraries to switch over to the new unified micro libs.

You'll need both to happen - and that's the benefit of this controversy.

Even so, I think the micro-library dogma might have gone too extreme, without many programmers realizing the cost it injected - and this controversy will likely also help with changing some developers dependency philosophy.

More speculatively, I'll be interested to see if any of this leads to changes in the ECMAScript standard discussions in future years.

There is an equivalent lodash function. Lodash is also nice because you can just include the function you need, a custom build, or the whole library. I use node but I've never felt the need to install a 1 line module.

Lodash has a left pad function that can be installed individually. People just don't know/wasn't available before.

I vote for lodash to become the new STL. It's even faster than native JS.

This ignores the fact that js libraries need to be downloaded on every run. Even if there were a great general-purpose string module that included the functionality, a micro-package like left-pad would be less to download if you didn't need the other stuff so I imagine some developers would still use it.

It's almost ironic really, that js has the worst standard library situation of any popular language yet it would benefit the most from having a good one since it would save everyone bandwidth and page load time.

Maybe someone can write an amazing replacement stdlib and we can all agree to include it from the same CDN so it'll be cached on every browser in the world...

EDIT: I see from other comments that lodash functions can be required individually which I hadn't thought about. But the point still stands, every function that you use in a big project that could have been in the standard library is more to download.

Sounds like all you need there is a compiler (people already use minifiers, right?) that would include or inline the used functions as appropriate and the cost would mainly go away? Or add in the "fetch this version from CDN" library loader code if it's a stdlib we expect to be cached and used by many js scripts.

ES6 modules, combined with a tree shaking build tool solve this issue. You can install a hige library and the output source will only include the parts you use.

Unfortunately, libs that provide function chaining via dynamically extwnding a prototype can't be optimized by tree shaking.

The future :: function bind operator should provide a tree shaker friendly alternative.

You seem to be optimizing size of download as the critical issue, when I think there are a few other optimization points that this controversy highlighted (e.g., quality of external codebase, security risk, maintainer risk, dependency management challenges).

A main issue with the current system is that you're pulling in micro dependencies from a variety of different sources, instead of a few potentially highly reputable sources (fairly or not, I'd feel more comfortable with dependencies from the lodash maintainer, than from 50 different people). One solution obviously is a better standard library, but often to get there, the process is for devs to create common libraries - which over time are (partially) absorbed in language standards.

It already exists in the form of underscore/lodash. If the authors who used left-pad had looked at say underscore.string (https://www.npmjs.com/package/underscore.string), they'd have not only a pad function that works for left and right padding, but a whole slew of other useful (indispensable IMO) general functions and string functions. Next time they need a right-pad, they won't have to go looking for another extension or god-forbid actually copy and paste a 5 line function into their code. These libraries have been around for years and there is no excuse for not using them. Finally, there is no excuse for left-pad, even if no other alternatives were available, unless Copy/Paste functionality completely disappears off the face of the earth.

1a. What problem is that trying to solve? The left pad issue was caused by unpublishing an open source package, it won't fix that. Writing quality libraries is a lot of work, especially for a single maintainer. From experience, maintenance nightmare is Python 2 to 3, or upgrading any "framework" library. Replacing a simple immutable function is easy, I would take 50 of them over one complex monolithic library.

2b. Though this wouldn't fix the left pad issue, mitigating security risks in OS is actually a very interesting topic. Something I haven't seen, but would love to is an ecosystem that allows packages to be code reviewed for security flaws. So users can see that a package (and dependencies) have been reviewed by X people, and Y in their network.

2. This won't solve the left pad issue, at best mitigate it. The main reason this is done in JS libs is to reduce file size of web apps, maintainers brag about it in their READMEs. Babel on the other hand is part of the compilation step, so no need to have that constraint, which it is.

Not mentioned, but this is one way to mitigate security issues, by reinventing the code. Other option is to audit the dependencies.

#2 is an excellent point. If there's one thing my years as a Java developer (and Maven user) taught me, dependency hell is a real and ever present threat. :)

Maven doesn't help in that case either, given that it contains it's own self-contained dependency hell.

I want to say "look at the Java ecosystem", but that's not hipster enough.

Duplicate the Python standard library, call it "batteries" as in batteries included, ???, profit

Reply on news.ycombinator.com