Re:It’s OK for your open source library to be a bit shitty (...
by TAForObvReasons on Sunday May 17, 2020 @01:12AM
(#23209754)
While `left-pad` certainly wasn't the most optimized implementation, it wasn't a "click-grabbing" project of the sort saurik was positing. It solved the problem the name suggested it would solve. The fallout around it really didn't have anything to do with "resume-driven development"
EDIT: Not sure why this was downvoted, maybe people forgot that padStart and friends appeared in ES2015, long after left-pad was created
Re:It’s OK for your open source library to be a bit shitty (...
by vxNsr on Sunday May 17, 2020 @02:22AM
(#23209998)
off-topic: I still don't understand the use case that left-pad solved. I'm not into js at all but why do you need a dependency to add space to text? I'm asking honestly, I just don't get what the use for this was.
Re:It’s OK for your open source library to be a bit shitty (...
by scambier on Sunday May 17, 2020 @02:54AM
(#23210149)
Literally what it says: https://github.com/left-pad/left-pad/blob/master/index.js
Now if you ask "but why?", ultra-small packages like this are popular in JS because of the lack of a standard lib. Lots of devs prefer to install a dependency for each one-liner utility rather than write them themselves.
The only added value of those packages is that they're usually unit-tested against weird edge-cases that you might miss if you wrote them yourself.
Edit: related discussion at https://news.ycombinator.com/item?id=20223190
Re:It’s OK for your open source library to be a bit shitty (...
by TAForObvReasons on Sunday May 17, 2020 @03:07AM
(#23210219)
the small libraries are best compared to stackoverflow code snippets. Instead of reading and copying a solution that may be out of date, you can use a (theoretically) tested solution that receives bug fixes. In many ways it is superior to the copy and paste of lore
Re:It’s OK for your open source library to be a bit shitty (...
by vxNsr on Sunday May 17, 2020 @12:07PM
(#23212874)
You're misunderstanding, what is the use-case of that specific package? like I've never found myself needing to pad text on the left, just trying to understand why this was such an important package.
Re:It’s OK for your open source library to be a bit shitty (...
by zomglings on Sunday May 17, 2020 @01:07PM
(#23213358)
Probably for command line tools that need to add some level of hierarchy into their output. You can add 1 to pad length and pass it to a subcomponent to display its output.
Re:It’s OK for your open source library to be a bit shitty (...
by scambier on Monday May 18, 2020 @03:07AM
(#23219254)
I don't have any use for it either, but this package is not important by itself. It happens that this package is (was) at the very bottom of the dependency chain for some huge packages (like Babel, Webpack, popular frameworks, ...).
When its creator removed it, they literally destroyed the foundation of those popular packages. That's what made it suddenly important.
Re:It’s OK for your open source library to be a bit shitty (...
by chris_wot on Sunday May 17, 2020 @03:10AM
(#23210232)
The smaller the library, the better.
Re:It’s OK for your open source library to be a bit shitty (...
by crehn on Sunday May 17, 2020 @03:18AM
(#23210270)
The less there are dependencies, the better.
Re:It’s OK for your open source library to be a bit shitty (...
by redis_mlc on Sunday May 17, 2020 @05:55AM
(#23210899)
> I'm not into js at all
Programming in JS is just this way.
I had to include moment.js yesterday just to format a date. Nothing fancy, but no easy way around it.
Re:It’s OK for your open source library to be a bit shitty (...
by smichel17 on Sunday May 17, 2020 @06:26AM
(#23211008)
I'm not sure this is a good example; dates are actually pretty complicated.
Re:It’s OK for your open source library to be a bit shitty (...
by HereBeBeasties on Sunday May 17, 2020 @02:16PM
(#23213935)
Yes, dates are very complicated. But that doesn't stop pretty much every modern language from having good built-in support for doing this, because it's such a totally common task. JavaScript is such a mess. It doesn't even support integers, for crying out loud, let alone decent date/time/timezone handling. That moment.js is the most popular band-aid to fix this, despite it having a nasty gotcha API that mixes mutable and immutable functions/types in confusing ways just rubs salt into the wound. Heck, you can't even compare two moment dates with inequality operators without either casting them by prepending a plus sign, or calling functions - it just silently does the wrong thing.
Re:It’s OK for your open source library to be a bit shitty (...
by ZeikJT on Sunday May 17, 2020 @07:19PM
(#23216448)
Silently? Since when is comparing objects in JS with (in)equality operators the right thing to do? There's no operator overloading nor special symbol you can implement in objects to make this work seamlessly ever. Casting/stringifying or calling functions is the only way for all objects.
Re:It’s OK for your open source library to be a bit shitty (...
by orange8 on Monday May 18, 2020 @02:58AM
(#23219196)
You did not have to, moment.js is just a wrapper around the dozens of inbuilt functions provided by the Date object.
Why could you not have used Date.toLocaleDateString() or Date.toDateString() or Date.toISOSting() or any other of the inbuilt functions outlined here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Re:It’s OK for your open source library to be a bit shitty (...
by z3t4 on Sunday May 17, 2020 @07:55AM
(#23211352)
The module system in Node.js (not ES6 modules) makes it super easy to use modules because a module is bound to a variable and you can require the module from anywhere and it will be scoped to the function. It's like if all code in the global JavaScript collective is available in global scope.
As far as I can tell this is a node-specific problem. I would argue it's a byproduct of resume-driven-development, not of open source culture. I think the onus is on npm to guard against obvious click grabbing projects (like is-odd, is-even, leftpad...), but it's also on the JS standards committee to develop a standard library that doesn't need 1 or 2 line dependencies to function the way a reasonable human would expect it to function.
> sure: it is totally their fault for deploying something without carefully reading your code to figure out that it was a bit shitty beforehand... but should they really have to do that?
Yes, you should at least read through the README and take a look at the issues before using any project. Code with 0 issues filed, no forks, and no stars...should not be used in production without proof reading. You can get a benefit of the doubt if it's clearly a popular project (i.e. apple/swift, google/flutter), because at least then you know multiple people before you have tried it out and been satisfied enough to want to help out.
> if you bring something that you know tastes bad or will make someone sick to the potluck and put a little sign on it saying "gourmet enchiladas: much better than what you get at the store" and put it in the center of the table, it is still a problem
The problem is that this is subjective. What does "tastes bad" mean? Are you expected to know what will make someone throw up? Sure, you'd be a dick for serving raw chicken - but the raw chicken projects generally don't have READMEs in the first place, because they were never intended for usage by others. It's your fault if you incorporate raw chicken into your meal and get sick from it.
The problem is that some people view a package manager as a farmer's market while others see it as a restaurant. Should you serve gourmet meals, or are berries OK too? If you sell raw chicken at a farmer's market, it should be obvious to the consumer that they have to cook the chicken first before eating it. The problem is when a customer goes to a farmer's market expecting it to be a restaurant and gets sick from something they didn't understand.