It may do it well, but as elitist as this sounds, senior-level (read: actually competent) developers forced to use Javascript for production work are still expected to be skilled enough to be aware of (and avoid/guard against) issues raised by weakly-typed languages.
At my office, it's a standing order that trying to shovel Typescript-related stuff into production code is a fireable offense. And the senior manager who said this was only half-joking. I can easily shield a junior developer from that punishment ... for a first-time offense. It's called a "junior-level" position for a reason. But a repeat offense? Or a senior developer does it? Nah, sorry mate. I'll put in a good word for you but you're still going to stand tall before the man for it.
Yeah, this kind of thing is best done as an inlined
assert
anyway:
JavaScript:
const someNumber = untrustedClient.getUserInput('penis_length_in_inches'); // User enters "biblical"
assert(typeof someNumber == typeof 9);
naiveTrustingService.broTrustMe.doThingWithNumber(x);
If you're worried enough about type safety that you're considering shoehorning strong typing into a weakly-typed language, this is a better alternative that relies on existing language features. Yes, the above code will crash (well, throw an
AssertionError
, but catching that and taking any action other than screaming loudly is missing the point anyway) but
that is a pain point you want. It should never crash by failing that
assert
, and it will only crash when you (the developer) allow garbage to reach it. In the above example, the right solution is to add validation to
getUserInput()
directly.
What this dipshit's done is taken this bog-simple concept, discarded assert (while still throwing an exception like assert does), made it a function and wrapped it in a god damn module and then shoveled it into npm. So much needless indirection and an external dependency to boot. It's literally a one-line check with built-in language features, but using this "method" instead involves importing a module, instantiating it (or at least assigning it to a local variable), making a function call into the module and wrapping it in a try/catch. Soooo slooooow...
Want to really be sick? Microsoft are
trying to shoehorn Typescript into Javascript now. Submitted to the TC39 committee and everything.
It's kinda funny ... I have some modest respect for tools like Babel for accomplishing what they did when all the "fancy" features started appearing in ES6, like spread operators and classes and the like. Not strictly because those features were super-duper awesome, but because when they "transpiled" ES6 down to plain ol' Javascript they at least made correct choices in how to implement those features as efficiently as possible.
To this day it continues to infuriate me how when new language features get added to Javascript, all the implementations of those features end up being slow as fuck. For instance, as useful and expressive as the spread operator is, it's a dog compared to
Object.assign()
, which is
209% faster according to a silly benchmark.