|
|
Log in / Subscribe / Register

A single Node of failure

A single Node of failure

Posted Mar 31, 2016 0:10 UTC (Thu) by jberkus (guest, #55561)
In reply to: A single Node of failure by bronson
Parent article: A single Node of failure

Maybe the solution is to create a more complete standard library, then? I mean, the fact that JS doesn't have an lpad() function, but it had to be added by a solo developer, is pretty alarming.


to post comments

A single Node of failure

Posted Apr 1, 2016 2:57 UTC (Fri) by smurf (subscriber, #17840) [Link]

The real failure appears to be one of "language culture". In most languages, you search for some way to achieve e.g. a left-pad function, you find the code on a Forum or Wiki page and you copy that to your local library of utility stuff, if not inlining it altogether.

With node.js, all you get is the name of the library to include, and I can only assume that people don't even look at the code they're including that way, most of the time.
When I search for something like that, I incorporate the principles involved directly into the code I'm working with instead of calling out. I like to think that this improves my understanding of what the hell I am doing. That opportunity is lost if you don't even look at the stuff.

A single Node of failure

Posted Apr 1, 2016 17:44 UTC (Fri) by lsl (subscriber, #86508) [Link]

I'm not so sure. Looking at other packages available on NPM it seems that even if Javascript had a sprintf (which is what lpad is called in most other languages) there would still be a package on NPM that just calls sprintf with the right arguments or so.

Heck, there's even a package "is-positive-integer" that depended on three other packages *and* made breaking API changes in the past! It's hard to believe this is not a joke.

A single Node of failure

Posted Jan 5, 2017 6:31 UTC (Thu) by Otus (subscriber, #67685) [Link]

> Maybe the solution is to create a more complete standard library, then?

Given the variety of runtimes code needs to run on that just amounts to pushing all such code into transpilers and polyfills.

Is it better to have fewer and larger dependencies? Not sure. It has its upsides, but there is no way I'm going to review such a massive codebase while small dependencies I can and have read through.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds