DEV Community

Discussion on: Fault tolerance on the web

Collapse
joelbonetr profile image
JoelBonetR • Edited on

TS is no longer what it was at the beginning.

When TS was first introduced In 2012 it had sense because it bring features like classes, still not available in JS, so it solved a real industry need.

But JS had come a long way since then and now TS is struggling to keep up. Is opinionated and bring packages or functionalities like it or not while nowadays (and since long time ago) if there's anything than you feel missing or you don't want to lose time coding it, there's a babel plugin to do it.

Something that pisses me off is how TS is defined as a "Superset" of JS.
TypeScript is a Subset of JS. Is something that compiles into JavaScript, it cannot be a superset by definition. This means it can't do a single thing that is outside of the JS boundaries while it enforces you to code on a strict way. It limits what you can do with JavaScript and obscures it's strong sides while providing a fake peace of mind.

An unneeded feature for JS is static typing by default (you can enforce it with vanilla JS) and TS does it at compile (transpile, currently) time, which breaks a strong point on interpreted languages that is fast development and no compile waits.

Moreover TS will only check types at compile time and only types that are available. Any network calls, system libraries, platform-specific APIs and non-typed third-party libraries have no way of communicating with TypeScript.
As you get used to having your types checked and not having to fully understand the code and the platform, errors and bugs will manifest themselves.

The conclusion is that if you are so bad dev that you need strong typing to avoid committing errors yourself, you may either learn from those errors or work on another career path -you will probably like java -.

Imagine how bad would be the rest of the software (specially the validations) to reach the point where you get a type error and imagine how bad would be the methodology -and lack of testing- of that project to bring this kind of errors into production.

My advice from my experience as a senior dev and tech lead is to avoid TS and enforce good methodologies such TDD and having a good tech documentation, you'll live happier and without fear of your own code while keeping all the power of JS.

Collapse
ecyrbe profile image
ecyrbe • Edited on

What bold assumptions. A tool is a tool and it always fullfill a purpose.
You achieved to tell your peers that if they use typescript or even like using it, or let bugs sleep through, they are bad developers ? really?
Professional environnement ? Catch bugs early ? Keep your maintenance cost low ? Catch a phrase?

Talking about tdd vs typesystem when one is about runtime checks vs build time checks... Maybe i should throw my linter away, there's ttd!
Obviously, a type system is here for a purpose and it's indeniable success means it's usefull to some. Maybe only to those who realise they prefer climbing a building with a security belt? If that means they are bad climbers in your eyes, at least they are still alive. Meaning their project will still be maintainable and evolve 5 years from now.

Collapse
joelbonetr profile image
JoelBonetR

As long as you can check types whenever you like or need with JS and the only feature that "survived" JS evolution from TypeScript is strong typing, why would you like to have this throwbacks?

It limits what you can do with JavaScript and obscures it's strong sides while providing a fake peace of mind.
Any network calls, system libraries, platform-specific APIs and non-typed third-party libraries have no way of communicating with TypeScript

You are confusing having a security belt with always needing this security belt.
Do you need a security belt to walk through the streets from your home to the supermarket? Do you need a security belt to go from your kitchen to your bathroom?

Whenever you need it you can check it is here with typeOf.

I can understand many people that like TS is because they come from Java or C# and it looks more like what they learned, and that is difficult at the beginning to code into JS which has some things to take care of such Async, load orders, etc -depending on the project or implementation- , also being a multi-paradigm language does not help newbies.

Using JS as OO language only and with strong types using TS is most of time a lack of previous analysis of what is the best architecture, paradigm or design you can apply to your solution.

You can simply take a try and develop the same with and without TS, the result would be that in JS you end up with better third-party compatibility, ensuring your app process and in less time -that's the results from 3 iterations we did in the past to take a decision about using TS or not on a much bigger project-

I bet you feel a bit offended with my conclusion, it's not some kind of insult, it's a push for you to make some kind of deep analysis and empiric test to see if it's really a must or it's only some kind of unneeded sugar.

There's no real concern about types if you can discern whether those type checks are strictly needed.

At the end... what will you say of a man who walks it's 5 Kg dog on a flat walk-through thrice a day while wearing a security belt?