Excellent points made. As much as I am a fan of TypeScript, I agree that TypeScript tends to make me feel too "safe" with my code.
The reason why type annotations are necessary is because we want to avoid "defensive programming", where we use a bunch of if checks just to sanitize and validate input. TypeScript removes this habit by giving us the illusion of type safety.
However, this type safety falls apart in user-facing "interfaces", where runtime data comes from the "outside". In this case, I wholly agree that TypeScript isn't a robust solution. Instead, defensive programming is perhaps more ideal, never mind the type annotations.
But in secure environments where the data has already been sanitized and validated (by means of defensive programming beforehand), I can say that this is where TypeScript really shines.
My main takeaway from this article is that TypeScript lives in a "perfect" world. It's an incredible tool for controlled internal environments. Otherwise, in user-facing runtimes, type "safety" is a dangerous habit that leads us to assume too much about the "outside" world.
Type safety is opinionated, and TypeScript team choose not to emit runtime type checks.
I think Hegel is a tried alternative. I don't know how well it works, though.
You should always consider safety beyond types. Validating users' (or even devs') inputs are way beyond that (e.g. empty string "", and empty arrays [], are possible even in dev environment).
Wow. Hegel looks very promising, but I'd imagine the build times to exponentially soar. I'd say this is an option worth considering particularly for the front-end (i.e. clients and front-facing APIs).
Yup, I believe I am too familiar with that reality. 😂
I just figured that the additional runtime checks make compilation more computationally expensive, hence the longer build times than "just" TypeScript.
As much as I am a fan of TypeScript, I agree that TypeScript tends to make me feel too "safe" with my code.
The key to being a great coder is to acknowledge that "too safe" feeling. It doesn't mean that TS is garbage. It doesn't mean that you should abandon it. It still has many points in its favor. As long as you're fully cognizant of that "too safe" tendency, you'll at least be more likely to guard against it.
we want to avoid "defensive programming", where we use a bunch of if checks just to sanitize and validate input.
Totally agree. That's why my next post will be outlining my approach to that problem, which, I believe, vastly simplifies the problems associated with defensive coding. (And endless if (... checks.)
But in secure environments where the data has already been sanitized and validated (by means of defensive programming beforehand), I can say that this is where TypeScript really shines.
Absolutely!
My main takeaway from this article is that TypeScript lives in a "perfect" world. It's an incredible tool for controlled internal environments. Otherwise, in user-facing runtimes, type "safety" is a dangerous habit that leads us to assume too much about the "outside" world.
That's precisely one of my main points. TS certainly has value. In some cases, it can be an amazing tool. But I'm seriously questioning its usefulness in purely frontend applications that rely on reams of "outside" data to fulfill their purpose.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Excellent points made. As much as I am a fan of TypeScript, I agree that TypeScript tends to make me feel too "safe" with my code.
The reason why type annotations are necessary is because we want to avoid "defensive programming", where we use a bunch of
ifchecks just to sanitize and validate input. TypeScript removes this habit by giving us the illusion of type safety.However, this type safety falls apart in user-facing "interfaces", where runtime data comes from the "outside". In this case, I wholly agree that TypeScript isn't a robust solution. Instead, defensive programming is perhaps more ideal, never mind the type annotations.
But in secure environments where the data has already been sanitized and validated (by means of defensive programming beforehand), I can say that this is where TypeScript really shines.
My main takeaway from this article is that TypeScript lives in a "perfect" world. It's an incredible tool for controlled internal environments. Otherwise, in user-facing runtimes, type "safety" is a dangerous habit that leads us to assume too much about the "outside" world.
"", and empty arrays[], are possible even in dev environment).Wow. Hegel looks very promising, but I'd imagine the build times to exponentially soar. I'd say this is an option worth considering particularly for the front-end (i.e. clients and front-facing APIs).
You know that even
tsc(orts-node/ts-node-dev) can be slow to compile, right? Not as bad as Gradle, though.Yup, I believe I am too familiar with that reality. 😂
I just figured that the additional runtime checks make compilation more computationally expensive, hence the longer build times than "just" TypeScript.
Oh... that's cool. I hadn't even heard of Hegel before. I'm definitely going to look into that one.
Great feedback!
The key to being a great coder is to acknowledge that "too safe" feeling. It doesn't mean that TS is garbage. It doesn't mean that you should abandon it. It still has many points in its favor. As long as you're fully cognizant of that "too safe" tendency, you'll at least be more likely to guard against it.
Totally agree. That's why my next post will be outlining my approach to that problem, which, I believe, vastly simplifies the problems associated with defensive coding. (And endless
if (...checks.)Absolutely!
That's precisely one of my main points. TS certainly has value. In some cases, it can be an amazing tool. But I'm seriously questioning its usefulness in purely frontend applications that rely on reams of "outside" data to fulfill their purpose.