Useful? Often. Helps in debugging? A lot. REQUIRED? no...

There are a lot of cases where doing it serves a legitimate purpose, such as in a global method that could be run using .call() as debugging those can be a bit of a wonk. That's why if you look at polyfills for a lot of ECMAScript extensions to Array or String, you'll see stuff like:

    if (this == null) {
      throw new TypeError('this is null or not defined');
    }

Where String is being checked for non-null since if you Array.call it will go bits-up face-down if you pass null, but be VERY hard to track down WHERE it failed. That's why those type checks are actually in the ECMAScript specification for a lot of routines like Array.forEach or String.repeat .

In my own little scripting library I have a object called _.Throw that's filled with methods to check for a specific type and report a verbose error of what when wrong specifically for polyfills.

To me type checking isn't a all or nothing affair, it really hinges on how confident you are in what's being passed around. If I were writing a library that other people were going to use, yeah I'm gonna throw type checking in even if there is a performance hit, just to make the resultant code easier to debug.

But it's not required by any means.

I come from strongly typed languages, so I might be biased. I think, that checking the type is actually very useful and can help prevent bugs, which might otherwise be security risks, like code execution, personal data leaks, buffer overflow; or lead to fatal program exits.

Instead of using exceptions, though, I strongly recommend self-healing code / defensive programming principles. Functional programming offers us many nice ideas, like monadic results and options. For example, instead of having the application crash or return an error, which would probably lead to an application crash, too, return a Result object, which has to be handled gracefully and can be chained and propagated to a layer of the application, which can handle the problem (in the worst case, the user). I built my own library for that purpose, which uses Rust's rewritten APIs, for example result-js and roption-js. Both can be browserified :)

Using JS extensions and other languages, like TypeScript and Flow, might seem nice at first, but they won't help you the least when they are not used by every part of the application. For example, you write a library in TS, but your users just use the generated JS - all of TS's type-checks will be for naught; useless in the face of what your users do with the transpiled code.

For codebases I have to maintain, param checks are not an optional concern. And I'll go further to say checking arguments should be at runtime not just authortime (as it is with TypeScript and Flow).

Echoing what others have said here checking for your expected params catches a tonne of bugs. It also makes debugging easier. Combined with named params and you'll have a much easier time working with dynamic languages.

Couple of resources to read up:

• Read this article about Error and how to use it properly with Node and you'll be a better programmer for it joyent.com/node-js/production/design/errors (in any language)
• Here's the lib we use for validation github.com/smallwins/validate but it also bundles a better assert which you can get by require('@smallwins/validate/assert') …here is an example usage github.com/smallwins/keystash/blob/1e5a528c999662… (it does require that you follow a named params pattern)

You can do this to add extra layer of security .. However not required for loosely typed languages.

Flow is a good library if you want to use type-checking throughout your js application.