> We should be able to define our functions to accept the inputs they are designed for, and not try to handle every possible edge case.

Oh, look, somebody just re-discovered static typing.

Putting API contracts aside, the problem is also that people use a package manager as if it was a code snippet manager.

As in, "how do I check if a string starts with a shebang" should result in some code being pasted in your editor, not in a new dependency. There is obviously a complexity threshold where the dependency becomes the better choice, but wherever it is it should be way higher than this.

The post is complaining about a library for a problem that javascript had 12 years ago, was not a thing for 7 years, and the ecosystem moved on. Typescript was not a thing back then. (or more exactly, it was a small thing out of the all too many transpile-to-js languages, at least)

Yes, having a library named is-number looks very stupid until you look at the state of javascript in 2014. Look at issue is-number#1[0] if you’re interested.

The library is-arrayish exists because array-like objects are actually a thing in javascript.

About is-regexp: the author mentions that their library supports cross-realm values because it’s useful, but then says that it’s an edge case that most libraries don’t need to care about? The whole reason that the library exists is to cover the edge cases. If not needed, yes the consumers of the library would have just been using the simple instanceof RegExp check.

If you’re arguing that there are consumers of those libraries that are wrong, the post might at least make sense – the presented case here is that the writer of the clamp function is stupid, not the other way around. Having a function that determines if a string is a number is not stupid; it’s importing that function and creating a clamp function with the wrong type signature part that’s stupid. Especially when it’s 2025 and typescript is universal.

All of the libraries that are mentioned are like 10 years old at this point. I don’t think we have to beat the dead horse one more time.

[0]: https://github.com/jonschlinkert/is-number/issues/1

I've tried to optimize to avoid these before. The problem is that these libraries are normally not used directly, they are usually pretty low in the dependency tree (root?). The farther you go down in the dependency tree, the older the packages are, where rightfully there's some reluctance to update things for the sake of updating things, risking breaking a stable library. It's a tricky thing and not so easy as to just say "don't use npm's `is-array`, use `Array.isArray()` instead", since every JS/TS package author writing code in 2025 knows that already.

It'd be a lot more productive to ask the authors of the (normally bigger, user-facing) libraries that you use nowadays to avoid using these libraries with deep and outdated dependencies. e.g. I stopped using Storybook because of this, but I'm happy to see that they've been working on cleaning up their dependency tree and nowadays it's much better:

https://storybook.js.org/blog/storybook-bloat-fixed/

> At this point, it seems clear to me we’ve just poorly designed our function. It solely exists to clamp numbers, so why would we accept strings?

To me it sounds like you are using a poorly-designed language

This is what undefined behavior is for. You specify a contract for your function, and then the implementation of the function assumes that the contract is satisfied. It does not check, and does not try to diagnose errors.

It's not about performance, it's about separating concerns: the caller handles the not-a-number case, so the callee doesn't have to.

Then you add optional runtime checking of the contract, preferably in a different build mode (or a different version, e.g. "my-lib1.2-debug"), to get sensible diagnostics quickly in tests and canary deployments. The checks are redundant by definition. Defensive programming.

Problem is, there’s a well known principle of library design: any behaviour you exhibit eventually becomes something someone relies upon. You can choose to live with silent breakage or you can validate your inputs within an inch of their lives. Next, with the best will in the world, even with a small library, you quickly discover a wide range of use cases that should reasonably be supported by your library. So all libraries end up complex, not just because of validation.

Yes, static typing would help with some of this, but very much not all.

Two common ideas I see ITT are that the problem is caused by JS not having either a) static typing or b) a large standard library.

I don't understand this. Python lacks static typing, but it also doesn't have a need for the kind of type-checking that is-number and is-array perform — it's how Python's dynamic typing already works. What JavaScript is missing is strong typing: i.e. it's "fault tolerant" by performing implicit conversions everywhere and minimizing the chance of control flow ever being disrupted by an exception, presumably intended to maximize the chance that the user sees some kind of DOM update rather than the page ceasing to function. Python sidesteps these issues by just raising `TypeError` instead, and by making proper consideration of exception handling an expected part of the programmer's job. The boilerplate in TFA's opening example is essentially what the Python runtime already does.

Similarly, Python has a large standard library, but it's irrelevant to the problems described. The Python standard library doesn't solve the problem of determining whether something is "a number" or "an array"; trying to use it that way does. The Python standard library doesn't solve the problem of determining whether something is "a regex"; if anything, JS' functionality here is more native because you don't need the standard library to create a regex.

As for the "pascalcase" example, the standard library isn't really helping Python there, either. There are multiple third-party libraries for string-casing operations in Python; there are some things you can do first-party but they're almost all methods of the built-in string type rather than part of the standard library. Aside from some useful constants like "a string with all the ASCII letters in it", the `string` standard library implements two failed attempts at string formatting routines that weren't popular even when they did solve real problems, and a "capwords" function with subtly different semantics from the "title" method of strings. Which has existed since at least 2.0.

(Granted, Python documentation has separate "library" and "language" categories, and classifies the built-in types and their methods as "library". But when people talk about the importance of a "large standard library" in a language, I generally understand that they're thinking of code that has to be explicitly pulled in.)

I've only seen these kind of libraries in JavaScript. They are a direct result of poor language design.

Entirely unrelated to the topic, but my mind was blown when I recently learnt that clamp() can be implemented via .median(val, low, high), and the param order doesn't matter!

It’s interesting how multiple of the bad cases the post identifies exist because of how gross the dynamic types in JS are.

If JS’s dynamic types worked like Ruby’s or Python’s then you wouldn’t think to build a library that tells you if something is a regex.

How are the download rates of these things so high?

Are there 1000 people running 100 CI pipelines/day where downloads aren’t cached?

> I don’t really agree with this and think downloading a package for #! 86 million times a week is a bit much.

Yeah. A bit.

Over 10 years ago I was a bit more invested in the ruby environment and the whole duck typing thing. I really liked dynamically typed languages. One thing I remember was when learning rsync that other libraries loved to write specs where all kinds of types and values gets thrown at a function to see how it behaved. Since these languages have no compile step one needs to check how they do at runtime. I remember I picked up a pattern to check if something is looking like a string or number or can be turned into Omer etc. It definitely blows up your test specs but also makes your awesome function even more flexible for the future. Hey you never know what you throw at it tomorrow. Maybe you need to call it with an a number array in string format. I stopped doing that and concentrated to test for the types I expect. Which really breaks with the typeless nature of a language but that is more philosophical. Needless to say I think all these helper packages are way overboard. There is also the tendency under programmers to really “never repeat yourself”. Which ends up in a utility function that has to be introduced into every library or project and starts to grow because of different edge cases from all the different use-cases. Let’s add some flags and overloads. Not excepting the fact that it is sometimes cleaner to just have a copy with special adjustment of code then desperately trying to generalize it.

I feel like the type guarding programming method present in some packages, is a hangover from node js development prior to typescripts rise in popularity.

So now some people just do it by habit.

Honestly the only place having code like that I see being useful is at the controller level inside an api or other untrusted input validation for an application.

I wrote a somewhat related article, after running just this Friday into two blocks of code that were deliberately causing invariant violations (akin to the "max < min" situation) to be ignored silently: https://alejo.ch/3gk - Fail loudly: a plea to stop hiding bugs

Always interesting to think about Postel's law in the context of these kinds of things. ("Be liberal in what you accept and conservative in what you send")

JavaScript had to implement these checks because you could pass a function literally anything and it was on the implementation to deal with it. Typescript has this same problem tbh.

Interesting but the article never takes the time to really explain what exactly is the problem with using these libraries.

The wild part is that a post about bloat concludes with here is more crap to install to visualize your JS stack.

Starting to think that JS based front end is a trashfire top to bottom. Not this framework vs that framework...the entire thing

Well, somebody must validate data on top level. So that's fine to have packages like `is-number`/`is-arrayish` etc.

I think the author has this wrong. Handling a ton of edge cases so I don’t have to do it myself is a good reason to use a library. Importing an endless tree of deps I have no control of - that is the issue.

I would be a little upset if a clamp function could throw a validation error when I passed only numbers. I’ve always written clamp to work even if min is larger than max. Basically, clamp comes down to sorting the three numbers and returning the middle one. I’ve never thought of that as an edge case, it just seems like a more general way to think of the operation that gives you less surprises since every possible input has a well-defined output.

clamp should actually accept anything comparable. E.g. clamp("foo", "bar", "baz") should return "baz".

Notice how this slop doesn't happen in real languages like C++ or Java. It's only the slop languages.

You don't need a "is it a number" package in java, because the function cannot be passed a string, because it actually has a type system. All this slop has come about because meme developers refuse to accept the truth - programming languages have proper syntax for a reason.

This is why every language needs a good standard library, which unfortunately JavaScript never had.

Incredibly shallow post. The level of validation and defensiveness in any piece of code will generally have to do with how close to the edge of your application it is — that is, how close to the input.

Functions near the core can assume more and code less defensively than those near the edge.

Libraries shouldnt be edge case first? What? /What kind/ of libraries? You really can’t imagine a library where it makes sense to code very defensively?

Also the post doesn’t even use “edge case” correctly. Definitionally you can’t have an edge case before you’ve defined the acceptable input. In their clamp function the edge case would be something like a large number on the border of graduating from long to BigInt or something. Edge case does not mean invalid input. Edge case is a rare/extreme input that is valid.

Those kind of function are like a second developer who doesn’t trust the developer of the program.

Have a little faith they validate the input and give the right min and max before they call your function or let them fail to learn.

3 of those 4 examples wouldn't exist in a statically-typed language like TypeScript

I agree with the spirit of this, but I’d go one more step with the example:

export function clamp(value: number, min: number, max: number): number { return }

That is just adding an extra jump and entry on the callstack where you could just have done:

Math.min(Math.max(value, min), max);

Where you need it.

(The example used was probably just for illustration though)