The easy way to tell types apart in ordinary JS is to have consistent naming conventions. If you always name things such that the name implies the type (not Hungarian style, but more natural language oriented), you can infer the type from the name correctly 90% of the time. E.g. always write arrays as plurals, map-like objects as keyToValue, and so on.
No thanks, not an easy way. instanceof and typing are the tools, not some funny notation that I have to rely on everyone to follow and parse, including me, under a pressure, after a year. Nobody can infer/assert types three modules away from a scope of their commit when it’s in the name.
But the easier answer is to just use Typescript.
Typescript is duck typed, you can’t save your day by “type Date = string” in it in a sense of a type safety. Nothing is wrong with object classes, apart from personal affinities accumulated from scary blog posts about classes in non-js languages and how that was bad. Objects have different types and different operarions on them. There is no clear reason to erase this difference and to evict methods only to group them into a scope and match by name manually, losing literally all benefits just for a functional swag.
Having a whole layer of abstractions and keywords built around class literally just adds complexity. Not to mention how obtusely "this" works in JS. The whole layering of special syntax around class just serves as a crutch for those coming from other languages.
Nowhere does it simplify anything really, aside from those who are already familiar with that abstraction. It's objectively simpler to have fewer abstractions, given that you can use object literals and regular functions to achieve the same results in similar amount of code. If class saved a lot of verbosity from alternative approaches, there may be a compelling argument for it. 99% of userland code does not need or use prototypes in modern JS
Typescript largely obviates need to do runtime type checking, except at API boundaries. But networked apis can't return classes by definition (not supported in JSON spec).
If I were to create shapes, I would interface the data and have a simple type field like "rectangle" "circle", etc. Or even simply duck typing it. Very easy and consistent way to check without having special prototype specific syntax of instanceof.
Using fields to imply the type is json compatible too, and works sent across the network. With Class you would need to have hooks at Json receipt point to instantiate the instances of the class. Class is a whole layer of unnecessary abstractions that don't even reduce verbosity.
I think this answers a question in my other comment. Not sure if I agree, but at least it feels like I start to get your point. Need to get some sleep, cause this mood makes me sound unpleasing sometimes, sorry if that manifested too much.
No thanks, not an easy way. instanceof and typing are the tools, not some funny notation that I have to rely on everyone to follow and parse, including me, under a pressure, after a year. Nobody can infer/assert types three modules away from a scope of their commit when it’s in the name.
But the easier answer is to just use Typescript.
Typescript is duck typed, you can’t save your day by “type Date = string” in it in a sense of a type safety. Nothing is wrong with object classes, apart from personal affinities accumulated from scary blog posts about classes in non-js languages and how that was bad. Objects have different types and different operarions on them. There is no clear reason to erase this difference and to evict methods only to group them into a scope and match by name manually, losing literally all benefits just for a functional swag.