I've literally told my coworkers "I'm not saying we should never use dependencies. But every time you add a dependency, you should hate yourself a little bit more. Some self flagellation can't hurt either."
this post was submitted on 31 Jul 2024
741 points (99.3% liked)
Programmer Humor
19817 readers
213 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
I've honestly never understood why someone at Google or Mozilla hasn't decided to write a JavaScript Standard Library.
I'm not opposed to NPM, because dumb shit like this happens everywhere. If such a package is used millions of times a day, perhaps it would make sense to standardise it and have it as part of the fucking browser or node runtime...
I’ve honestly never understood why someone at Google or Mozilla hasn’t decided to write a JavaScript Standard Library.
load more comments
(3 replies)
someone at Google or Mozilla hasn't decided to write a JavaScript Standard Library.
Core APIs (including data types like strings, collection types like Map, Set, and arrays), Browser, and DOM APIs are pretty good these days. Much better than they used to be, with more features and consistent behaviour across all major browsers. It's uncommon to need browser-specific hacks for those any more, except sometimes in Safari which acts weird at times.
The main issue is server-side, and neither Google nor Mozilla have a big interest in server side JS. Google mostly uses Python and Java for their server-side code, and Mozilla mostly uses Rust.
Having said that, there's definitely some improvements that could be made in client-side JS too.
That's basically how Javascript gets extended. I put off learning jQuery for so long that all the features I'd want are now standard.
Vanilla JS is pretty good on the client side, but leaves a lot to be desired on the server side in Node.js, even if you include the standard Node.js modules.
For example, there's no built-in way to connect to a database of any sort, nor is there a way to easily create a basic HTTP REST API - the built in HTTP module is just raw HTTP, with no URL routing, no way to automatically JSON encode responses, no standardized error handling, no middleware layer, etc.
This means that practically every Node.js app imports third-party modules, and they vary wildly in quality. Some are fantastic, some are okay, and some are absolutely horrible yet somehow get millions of downloads per week.
There's a js runtime called bun that is 90-something% feature equivalent to node and also has built in alternatives to many packages like express and bcrypt. I haven't used it myself so I can't speak to its quality but it's always nice to see a little competition
So is Deno! You can easily import npm: and node: packages and run typescript without transpiling. With Bun and Deno there's no reason to use Node tbh.
load more comments
(4 replies)
load more comments
(1 replies)
I wish they would replace JavaScript with something that was made for what it's used for. JavaScript should have died years ago.
load more comments
(10 replies)
load more comments
(2 replies)
The only two people arguing against the change were both authors/contributors of is-number lol
How many contributors could there possibly be
3, about two lines per contributor
Is it because they included a crypto miner in the package?
Note that the PR was later merged by a member who got fed up with his colleagues.
And who hasn't contributed any code to this particular repo (according to github insights).
Not familiar with this exact team, but a skilled reviewer/issue triager is useful. We can hope this person at least tested the changes.
load more comments
(1 replies)
Another day of being extremely thankful I decided not to learn JavaScript
I mean, the people relying on such packages didn't learn it either.
This can happen in any project that uses dependencies, javascript or not
Sure, but when was the last time you saw, say, a Python project using some third-party library instead of simply calling isnumeric() from the standard library?
There's a reason for these jokes always being about Javascript.
load more comments
(4 replies)
load more comments
(4 replies)
If you think is-number can be replaced with a one-liner, you don't have the enterprise code mindset. What if the world gets more inclusive and MMXXIV, ½ and ⠼⠁ become recognized as numbers? 𒐍𓆾 were numbers in the past but what if people start assigning numeric value to other characters? Are 🖐🔟💯🆢🂵🀌🁅 numbers of the future???
/s
I'm not even all kidding, Regex implementations are split on whether "٣" matches \d.
All junior devs should read OCs comment and really think about this.
The issue is whether is_number() is performing a semantic language matter or checking whether the text input can be converted by the program to a number type.
The former case - the semantic language test - is useful for chat based interactions, analysis of text (and ancient text - I love the cuneiform btw) and similar. In this mode, some applications don't even have to be able to convert the text into eg binary (a 'gazillion' of something is quantifying it, but vaguely)
The latter case (validating input) is useful where the input is controlled and users are supposed to enter numbers using a limited part of a standard keyboard. Clay tablets and triangular sticks are strictly excluded from this interface.
Another example might be is_address(). Which of these are addresses? '10 Downing Street, London', '193.168.1.1', 'Gettysberg', 'Sir/Madam'.
To me this highlights that code is a lot less reusable between different projects/apps than it at first appears.
It's simple ⅯⅯⅩⅩⅣis a number, MMXXIV is not.
You may argue that writiing 2024 as "MMXXIV" and not "ⅯⅯⅩⅩⅣ" is a mistake but while typists who'd use "2OlO" for "2010" (because they grew up using cost-reduced typewriters) are dying out, you'll never get everyone to use the appropriate Unicode for Roman numerals.
load more comments
(4 replies)
load more comments
(1 replies)
load more comments
(15 replies)
It looks like "is-number" was never more than a few simple lines of code. It still has 68 million downloads per week.
https://www.npmjs.com/package/is-number
I checked one of our main projects at work, and it's in there as a dependency 6 levels deep via the "sass" package.
is-number is a project by John Schlinkert. John has a background in sales and marketing before he became an open source programmer and started creating these types of single function packages. So far he has about 1400 projects. Not all of them are this small, though many are.
He builds a lot of very basic functionality packages. Get the first n values from an array. Sort an array. Set a non-enumerable property on an object. Split a string. Get the length of the longest item in an array. Check if a path ends with some string. It goes on and on.
If you browse through it's not uncommon to find packages that do nothing but call another package of his. For example, is-valid-path provides a function to check if a windows path contains any invalid characters. The only thing it does is import and call another package, is-invalid-path, and inverses its output.
He has a package called alphabet that only exports an array with all the letters of the alphabet. There's a package that provides a list of phrases that could mean "yes." He has a package (ansi-wrap) to wrap text in ANSI color escape codes, then he has separate packages to wrap text in every color name (ansi-red, ansi-cyan, etc).
To me, 1400 projects is just an insane number, and it's only possible because they are all so trivial. To me, it very much looks like the work of someone who cares a lot about pumping up his numbers and looking impressive. However the JavaScript world also extolled the virtues of these types of micro packages at some point so what do I know.
Wow you're right, he's the author of the infamous "is-odd" and "is-even" packages. What an odd person.
Someone in the OP PR mentioned the amount of energy used to download these tiny packages and its actually something crazy to think about
load more comments
(2 replies)
load more comments
(1 replies)
What a sassy package depency
Link to the PR? The PR description and the comment somehow contradict each other. Or I am stupid. Or the commenter.
I tried to edit the 'highlights' into a single image, the top is the description of the PR, the middle is a comment replying to another comment
Thanks!
What a shit show.
Seems to me the only reason for these kind of dependencies to exist in the first place is that people really, really, really, REALLY can't code.
Well javascript is the default language of the web, so no surprise it attracts a lot of newbies.
Yeah but if noobs use it as a dependency, who made the package?
And what projects are noobs working on that trigger 440GB of weekly traffic?
I fear most noobs remain noobs.
load more comments
(1 replies)
load more comments
(1 replies)
440GB weekly for "is number". What in the world is that package doing?
is-number is a one-line function. (though it's debatable if a function that complex should be compressed to one line)
You may have heard of a similar if more extreme "microdependency" called is-even. When you use an NPM package, you also need all the dependencies of that package, and the dependencies of those dependencies recursively. Each package has some overhead, eventually leading to this moment in time.
load more comments
(2 replies)
It handles a few weird edge cases, mostly. Only 7 meaningful lines of code and almost 70M downloads week!
Sadly, it's a stupid dependency of a lot of things.
Just ran npm explain is-number on one of my projects, and it's a dependency of to-regex-range which is a dependency of fill-range which is a dependency of....and so on up the chain.
I was hoping I wouldn't find that in there, but alas, it is.
Given that this screenshot is about to-regex-range I think they might be on to something!
🤦♂️😆
Didn't even catch that in the screenshot. lol
load more comments
(2 replies)
load more comments
(1 replies)
I really need a community here solely dedicated to GitHub drama. This is so much better than Twitter drama, more relatable.
It's kind of insane how bad this whole is-number thing is. It's designed to tell you if a string is numeric, but I would argue if you're ever using that you have a fundamental design problem. I hate dynamic typing as much as anyone else, but if forced to use it I would at least try to have some resemblance of sanity by just normalizing it to an actual number first.
Just fucking do this...
const toRegexRange = (minStr, maxStr, options) => {
const min = parseInt(minStr, 10);
const max = parseInt(maxStr, 10);
if (isNaN(min) || isNaN(max)) throw Error("bad input or whatever");
// ...
Because of the insanity of keeping them strings and only attempting to validate them (poorly) up front you open yourself up to a suite of bugs. For example, it took me all of 5 minutes to find this bug:
toRegexRange('+1', '+2')
// returns "(?:+1|+2)" which is not valid regexp
The problem is the underlying API. parseInt(“550e8400-e29b-41d4-a716-446655440000”, 10) (this is a UUID) returns 550. If you’re expecting that input to not parse as a number, then JavaScript fails you. To some degree there is a need for things to provide common standards. If your team all understands how parseInt works and agrees that those strings should be numbers and continues to design for that, you’re golden.
load more comments
(1 replies)
view more: next ›