Not chiming in on the class vs no class debate, but a technical note on using the instanceof construct.

This can actually in some cases be a legit, practical problem in combination with the common modern web architecture where we can have hierarchies of external dependencies in different versions.

Statically typed languages usually don’t have this problem as external dependencies tend to be linear, not trees, and as such there are only one constructor it can match with.

Let’s say you use something like Bacon.js in your codebase, and a module you depend on can also use that same library. And you want to check if you have a Bacon observable. Like so:

import Bacon from 'baconjs';
import someBaconFunction from 'external-tool';

if (someBaconFunction() instanceof Bacon) {

  // May or may not be an observable

}

You don’t really know whether or not you have a Bacon Observable. Things like default de-duping in NPM 3 will make this more probable to be true, but that depends on your version ranges and the version range of the external tool (Also, hadn’t the CommonJS-ish module loader most usually use always returned “singleton” modules, this could be a bigger issue.).

This may be exactly what you want, though. Where you want to check if you have the exact same instance from the exact same module — but, in my experience, more often than not this is surprising behaviour. As JavaScript is dynamic, it has a different semantic behaviour of instanceof, and even if that is by design it can cause bugs in your code. I don’t think everyone has this clear in mind when using instanceof — and it may become a bigger problem as classes get more and more used.

I think it’s at least important to not use the JavaScript class keyword as classes from a class based object oriented language, but know that it is syntactic sugar on top of a different paradigm. Using a JavaScript class as a C#/Java/Whatnot class will lead to unexpected behaviour.