DEV Community

Cover image for Thoughts on TypeScript

Thoughts on TypeScript

Matti Bar-Zeev on March 04, 2022

In this post I would like to share with you some of the thoughts I’ve been having for quite some time about TypeScript (TS), after experiencing wit...
Collapse
 
cski profile image
Patryk Cieszkowski

The argument of TS being a propriatery software doesn't hit me at all. It's published under Apache 2.0 license, they can't back that off - they could however start publishing newer versions under a new license, but I don't believe the changes they implement are worth the hassle - the vast majority of the software would still remain opensource.

My issue with TS is the fact it doesn't work; it's sole purpose is supposed to be implementation of typechecking capabilities. And that works OKish, up until the pre-compile stage of development. It doesn't help you at all during actual runtime.

Collapse
 
thewix profile image
TheWix

If you have anti-corruption layers then you can trust what was compiled at runtime. You will not have issues unless you incorrectly deal with untyped data. This is a fact with untyped JS or even C#/Java/etc. If you incorrectly handle values from a form or API you will get an error in any language, typed or not.

Collapse
 
kof profile image
Kof

After years of building big backend projects, transitioning to TS was such an upgrade for me. Apart from making the code more readable, it was a life saver on big refactors.

Other than that the only caveat for me, is having to wait the compilation time each run.

Collapse
 
mbarzeev profile image
Matti Bar-Zeev • Edited

Thanks for the time going over and giving your point of view on each!
BTW, I find that the Babel plugin is a different impl than TSC, which kinda ale
Alarms me. This can cause all sorts of errors along the way which will be hard to trace... Oh well 😏

Collapse
 
etienneburdet profile image
Etienne Burdet

Understanding that TS is no longer a thing to be ignored.

Learning a technology with that reason in mind won't yield any results. It's not TS—or React's—fault. You add a tech to your stack because it solves problem: less runtime errors, less defensive conditions, less Proptypes, safer production builds etc. If it doesn't scratch an itch, then why bother?

In the codebase I work on it's priceless, I use components my team didn't design and I have all the informations straight away instead of digging dozens of subcomponents and I'm more confident I'm feeding them the right stuff.

For a solo dev, that might not be the case… at least if you doesn't have a single clue on how it would remotely solve a problem you face everyday.

Collapse
 
mbarzeev profile image
Matti Bar-Zeev

I think, and don't get this the wrong way please, that saying that you learn only what is derived by whether it solves a problem or not is a bit naive. The industry is well invested in TS, and if you'd like to keep you options open, you need to know you way with it, for it will give you an advantage over another candidate which does not know it.

Collapse
 
etienneburdet profile image
Etienne Burdet

I can understand that-although for something as simple as TS, it's a bit overkill imo.

But then don't expect to see the benefits if it's "just in case" for a project you don't work on yet.

Collapse
 
christiankozalla profile image
Christian Kozalla

Concerning your comment about "proprietary" and licensing: OP stated that Microsoft or Facebook have the right to change the license whenever they like. So, what's the point of referencing the current Apache license? If they can change it whenever they see fit..

Collapse
 
cski profile image
Patryk Cieszkowski

…making it useless.

 
cski profile image
Patryk Cieszkowski

Do you even understand the difference between a language, and a superset?