440GB weekly for “is number”. What in the world is that package doing?
I’m not sure, this is a valid estimate. If they were to replace is-number with its contents, that would mean that the economy is only in HTTP-related overhead.
It maybe will make difference because of building phase, lock-files, package-files, but I am not sure that data-traffic difference is that big
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.
Web bloat in a nutshell and why we need to switch to things like Web Assembly more than ever. It’s not WASM, but I used Laminar which is a Scala.js library, and it’s the absolute pinnacle of (frontend) web development. Scala in general is just really great for idiomatic web code, its flexibility is unbeatable.
Another amazing alternative would be anything Rust. In fact I’ve used that much more than Scala for web. I’ve mainly used Leptos for full-stack and and Actix for backend, but I’ve seen Dioxus and Axum in good use and they both seem really great too.
Apparently Lemmy uses Leptos for its UI so… that’s a +1.
It handles a few weird edge cases, mostly. Only 7 meaningful lines of code and almost 70M downloads week!
I don’t get the concept that depending on 7 lines of code from a third-party package is remotely acceptable. It’s expanding the potential attack surface to save a dev from templating 7 lines of boilerplate. There’s no net benefit or appreciable time saved.
I’m glad I don’t have to deal with this regularly.
ETA: The package is even MIT licensed! There’s no excuse but laziness and not wanting to understand the code to import this rather than inlining or implementing a novel version. If I can spend the time to write:
if err != nil {
slog.Warn("well shit", "error", err)
return err
}
after every function call…I just didn’t get it.
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!
i think programmers need a self inflicted rule of it being less than 500 lines of code means you need to write it instead of using a pre written package/library.
On the other hand, we could make the packages like is-number the worst possible way of checking if something is a number, which would be really fucking funny…
Eh, I can see why you’d want something like that in a language like JavaScript where pretty much all native ways of validating input have weird edge cases. Sometimes you just want the community to figure it out for you instead of reinventing the wheel and finding out you missed something later on.
A whole package that handles validation of inputs, or a math package would be better than a package that just has one function tho.
yeah, generally it seems like you want a more broad package, if for something like validating input, it would be comprehensive across all input for example.
There’s one package on npm called is-even and i think another called is-odd, which according to the author are “learning experiences” which have, considerable amounts of downloads, even though it’s literally just is-even checking. Shit like that should probably get you banned from using keyboards for the rest of your life lol
I have read programs a lot shorter than 500 lines which I don’t have the expertise to write.
Shell scripts don’t count
That’s not a programming language, that’s hieroglyphs
programmers need a self inflicted rule of it being less than 500 lines of code means you need to write it instead of using a pre written package/library.
That’s what I do, but then I end up with similar utils across multiple projects (eg some of these array, map, and set utils: https://github.com/Daniel15/dnstools/tree/master/src/DnsTools.Web/ClientApp/src/utils) and wonder if I should create a library.
Then I end up doing that (https://github.com/Daniel15/jsframework is my most ‘recent’ one, now very outdated) but eventually the library gets outdated and you end up deleting most of it and starting again. (edit: practically this entire library is obsolete how)
It’s the circle of life.
i wonder if maybe we just need personal package repos for shit like this, stuff that probably shouldnt be out on the internet and accessible, but that’s also worth packaging for regular use. Like a sort of “code macro” which is something i see people doing a lot for certain boilerplate strings.
You are describing a state of software development that has existed since the introduction of punch cards.
Practically every business I’ve worked at has had some internal library or repository of commonly used behavior that can be included in day to day projects.
Another day of being extremely thankful I decided not to learn JavaScript
Must be pretty good, considering literally every time I check in on the JavaScript community it is somehow more on fire than it was last time. I guess I must have a front row seat to all their misfortune. Either that or they’re just incompetent, but it couldn’t be that, could it?
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.
Python has other stupid problems related to pip. As much as stupid micro-dependencies suck in Javascript, they’re not the shitshow managing dependencies in Python is. It’s an inefficiency that never actually caused me noticeable issues in my former webdev life.
And let’s not talk about C++… People reinvent all sorts of wheels all the time because sharing anything is so annoying.
I only glossed over it… but this looks like it’s trying to check dynamic typing issues? It’s like a statically typed language with extra steps?
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.
Yeah good point. I suppose the problem is this function that operates on numbers allows numeric strings to be passed in in the first place. The only place where I would really expect numeric strings to exist is captured directly from user input which is where the parsing into a numeric data type should happen, not randomly in a library function.
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.
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.
Even if they did use unicode, any codeset , glyph or language changes over time , ulimately they emerge out of communication, not the other way round.
If some culture decides they want to use the glyph “2” to mean a word “to”, they can and will, and no codeset is going to stop them. And if they get their message to their intended audience it doesnt matter that somebody else’s isnumber fuction get’s it wrong.
A person, community or standard codeset or dictionary cannot deny the accuracy or content of encrypted communication just because they can’t decipher it.
Put another way a more robust isnumber() should maybe have a second argument to specify the codeset being used, and maybe whether written words - in some defined languare - are also to be converted
On the other hand “1/4/12” is not a fucking date.
Lisp code is already like this. That’s why I keep trying to explain it to programmers. Try reading the book SICP, published decades ago by MIT computer researchers.
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.
So the only valid digits are arabic numbers but arabic script numbers are not a valid digit? If we want programming to be inclusive then doesn’t that make sense to also include the arabic script number?
So the only valid digits are arabic numbers but arabic script numbers are not a valid digit?
Some people writing Regex implementations have that opinion. I’ve refrained from saying mine.
If we want programming to be inclusive then doesn’t that make sense to also include the arabic script number?
Maybe. IMO, number tests should be chosen/implemented based on the project’s requirements. If you want to include every Unicode character or string pattern anyone’s ever used to convey a numeric value, that would be a long and growing list. Arguably, it’s impossible: the word “elf” means a number if interpreted as German for “eleven” but not if interpreted as English for 🧝.
Yeah, but “elf” are not digits. Digits are a symbol abstracted from the language itself. Does 5 and V convey different meanings in the context of digits? And yeah, I can see why they would argue about the implementation because inclusivity is important. Especially when designing a language implementation. If you are designing it wrong, it will be very hard to extend it in the future. But for application level implementation, go nuts.
