DEV Community

Cover image for No, TypeScript is not a waste of time.

No, TypeScript is not a waste of time.

Resi Respati on July 29, 2019

Header image by Chris Leggat on Unsplash. Another day, another heated “discussion” about how static typing in JavaScript is both the single greate...
Collapse
erikkimsey profile image
ErikKimsey

Yesterday, I read an article arguing that typescript was verbose and pointless.

To be candid, I don't use typescript frequently. But, I was shocked to read someone thought it was verbose. I mean, let's survey all languages. If the author of the article I mentioned thinks typescript is verbose, he's not had much experience with Java or C++ !

Geesh.

Collapse
cubiclebuddha profile image
Cubicle Buddha • Edited on

Yea I think people forget that in Java and C# you can’t equate instances that have all the same things. Look at this gross C# code:

Class User {
   public string name;
}

Class Person {
   public string name;
}

function saveName(Person: person){
    log(person.name)
}

saveName(new User()) // won’t work

^ now that’s verbose. In TypeScript anything that has the same data shape fits the interface, due to structural subtyping. So I can cut that code in half.

Collapse
nickholmesde profile image
Nick Holmes

I think its very weak to compare to languages by trying to force the approach taken by one into another. You need to compare idiomatic solutions to the same problem to really understand them.

In strongly-typed object oriented languages, you need to be specific about polymorphisms. In general, I would like the compiler to stop me trying to pass (e.g.) an Order object to an User related process. To take your example, if I notice that a User is also a Person, I can write this;

class Person {
    public string Name;

    public void SaveName() {
        Logger.Log(Name);
    }
}

class User : Person { }

Now, User inherits the SameName method and more generally, I can use a User as a replacement for a Person. I could have also used an "IName" interface if I wanted naming to be distinct from class hierarchy.

So, there is no code to "cut in half", and no chance that anything I didn't expect to be passed to the SaveName method will even compile. Also, if I ever change SaveName, no chance that code will break (at runtime).

Collapse
sarafian profile image
Alex Sarafian

You "can" (maybe more quotes are necessary) with type converters which you need to declare and implement in code hence the quotes.

I'm of C++ and C# background and when I read about such features in javascript I get the chills. Maybe I'm old school and I feel that structure similarities don't mean much. When I need them, I just interface them or implement the extra glue code. I'm all for strictness and clarity even if some extra coding is required. Extra coding for me means, that I implicitly enable the same option/functionality. I like scripting languages that are more flexible but I believe that each has its place and purpose.

Thread Thread
cubiclebuddha profile image
Cubicle Buddha

Yea structural subtyping is really convenient but it is not as strict as nominal type system (like that of Java/C#). The TypeScript language devs are looking into adding opt-in for nominal types. I think it would be cool to have the option. I guess that’s one of the pros of TypeScript is that it gives your strictness but also some escape hatches. Kinda like C# will let you do crazy dynamic things via reflection.

Thread Thread
sarafian profile image
Alex Sarafian

I'm not sure that reflection falls under the same category but I would agree with you about the spirit of TypeScript you mention. This is also a big difference, like generation differences, between C, C#/Java, JavaScript. Each addressed problems based on that periods concerns, let them be software or hardware.

Collapse
saint4eva profile image
saint4eva

Are you sure the above code is C#?

Thread Thread
nickholmesde profile image
Nick Holmes

I'm certain it is neither literally C#, nor idiomatic of the features the language provides.

Collapse
matthew_collison profile image
Matthew Collison

Fantastic post - there’s nothing to prove really. Anyone who says “X language / framework is a waste of time” is coming from a close-minded perspective and it’s really not useful as programmer to have that kind of outlook.

Being open to different paradigms and ways of coding is one sign of an excellent developer.

Collapse
jwkicklighter profile image
Jordan Kicklighter

Thank you for clearing up a lot of misrepresentated info from the original post.

Collapse
cubiclebuddha profile image
Cubicle Buddha

Yes! It’s nice to see the pros of static type analysis properly represented.

But honestly, I’d just like to see people give the tooling a shot. Once you try it you just might love it. I know I do! :)

Collapse
resir014 profile image
Resi Respati Author • Edited on

Speaking of tooling, I forgot to mention Babel's integration with TypeScript via @babel/preset-typescript on the post, which was a game changer indeed. For large projects already tied to the Babel toolchain, it's finally safe to include TS into the toolchain, while keeping all the great features of Babel. It also allows you to use the many plugins that the ecosystem provides (e.g. babel-plugin-styled-components).

Oh, and all @babel/preset-typescript does was strip out the type checking, type-checking is still done by the TS service (and is pluggable to a CI service). Which is really useful for those who want to edit, save, and preview/debug quickly without type errors constantly blaring at them. :)

Thread Thread
cubiclebuddha profile image
Cubicle Buddha

Don’t forget how awesome Create-React-App —TypeScript is. It just works! :)

Collapse
jillesvangurp profile image
Jilles van Gurp

I inherited some frontend code at the end of last year and as a backend engineer, I had some catching up to do to take ownership of that.

I made good progress learning my way around the code base. I started with small additions. Then I updated the build system and dependencies. After a few weeks of messing with this and getting quite frustrated by the amount of stuff that broke everytime I touched something, I added typescript support. At that point I was pretty sure lack of types were slowing me down.

Adding typescript made life vastly easier. Before I did that, refactoring was a pain and I had essentially no idea if my changes would actually work. After that, at least the parts I migrated to typescript (properly, with strict mode), became a lot easier to deal with and I started editing with a reasonable level of confidence.

After having migrated a few thousand lines of js to ts, the lines of code you gain in terms of verbosity is very limited. Mostly you end up with the same number of lines of code or at best a few percent new lines.

Mostly the annotations happen in lines that you would in any case have: method and class declarations. This adds a lot of value as it also documents what is expected. The extra lines you gain would be things like interfaces to add strong typing to e.g. objects you deserialize from an API. I'd argue doing this adds a lot of clarity and VS Code makes doing this stupidly easy. Just go CMD+. and add the declaration automatically.

But then, typescript is in my opinion nothing more than a gateway drug for something better. If you like it, there are much nicer languages. Some of them even transpile to javascript or to WASM (or both in some cases).

Collapse
stylestrip profile image
Ryan

Nicely written!

I think there's a lot of good qualities for TypeScript that outweigh the bad qualities that the other article tried to point out.

TypeScript can be really useful for new frontend developers who know next to nothing about JavaScript. It seemed to work really well when I pushed hard to get our developers to use it on our React project.

Collapse
cubiclebuddha profile image
Cubicle Buddha

Great point! In many ways TypeScript can be used as a tool for teaching Javascript.

Collapse
voidjuneau profile image
Juneau Lim • Edited on

party time 🌟

I haven't learned it yet. Though saw many people who hate TypeScript, however, I think I will like it if I use it. Personally, dynamic languages make me sick.

Collapse
resir014 profile image
Resi Respati Author • Edited on

Yeah I've seen that. That article really is the worst example of those kinds of posts. /:

It really screams "I used this for two weeks. Here are the minor inconveniences I encountered which proves it's an Evil Technology that should be avoided at all costs!!"

Collapse
voidjuneau profile image
Juneau Lim • Edited on

LOL I feel a bit of guilty and think it's my duty to defend them a bit.

Collapse
eljayadobe profile image
Eljay-Adobe

I found TypeScript (v0.8 ... it was a while ago) to be pretty good.

One of its features was bringing ES6-isms to ES3 and ES5, and that was fantabulous! These days, everyone has ES6 (and later) at their fingertips. But it still delivers on static type checking, which eliminates a very large class of bugs, especially for large programs.

When I was doing TypeScript, I was looking enviously at CoffeeScript. But at that time, it looked like CoffeeScript's days were numbered. Now there is CoffeeScript 2, huzzah! (Of course, CoffeeScript isn't about type safety, it's about expressivity and succinctness.)

Programming languages are tools. Some are more suitable to a particular domain. If I were targeting JavaScript I'd be using... well, Elm. But if I were on a team, and the team was gung-ho on TypeScript, I would be fine with that.

Collapse
ssimontis profile image
Scott Simontis

I hope we get more support for algebraic datatypes. The union and intersection types are so close to the discriminated unions of F#...if they can gross that gap Typescript is going to become a much more powerful tool. The benefit of static types becomes less about catching careless mistakes and more about designing types that don't allow for any illegal states in the first place.

Collapse
macsikora profile image
Pragmatic Maciej

I hope this can help - dev.to/macsikora/more-accurate-the...

Collapse
dnkm profile image
Daniel Kim

Typescript is not bad at all, especially compared to all other typed languages.
For applications that need to have a high level of integrity, I think it's a must.
Having said that, I do not use typescript in any of my personal projects. I love the simpleness (and the apparent and inevitable sloppiness) of JavaScript.

Collapse
udnpico profile image
burhanudin hakim

Nice Article!

Collapse
carlillo profile image
Carlos Caballero

I love debate!!

Good opinions in both point of views, although I think that TS is the way.

Thanks!

Collapse
jwp profile image
John Peters

People who fight Typescript are like those who 40 years ago fought C, C++, Pascal, C#, Java preferring assembly language instead.

Collapse
olvnikon profile image
Vladimir

I agree with you that static typing brings more benefits than drawbacks. Big applications scale better and the code is self documented. Small applications can provide typed api, e.g. index.d.ts.
Typescript doesn't provide soundness. Flow and, especially, reasonml do. This is one of the biggest reason why I don't like and don't use typescript. It cannot guarantee type safety while reasonml does guarantee runtime type safety.

Collapse
caseycole589 profile image
Casey Cole

It is verbose and a waste of time, one step away from java and c#. I don't want or need an ide to edit my code.

Collapse
cubiclebuddha profile image
Cubicle Buddha

Obviously you're expressing a preference-- a preference that I hold the opposite of. Bu thats cool. To each his own! :)

Anyway @caseycole589 , I'm just curious. What are your thoughts on SQL?

Collapse
caseycole589 profile image
Casey Cole

I love it, great for it's domain, I don't have a problem with types as long as they don't make things over verbose but when it's list> things are getting out of hand.

Thread Thread
cubiclebuddha profile image
Cubicle Buddha

Well if you like SQL “for it’s domain” then you can understand why backend developers like me want to use typeorm to keep our NodeJS business logic in lock-step with the SQL schemes. Check it out. It’s way more fun and flexible that writing a backend in C#/Java/C and it’s honestly a lot less verbose.

I’m not sure that I would always reach for TypeScript for UI code. But for backend code, I can’t imagine he productivity loss of not using s type system.

Anywho, check out typeorm sometime :)
typeorm.io

Collapse
santypk4 profile image
Sam

You also have awesome projects like io-ts and runtypes to have type validation at run time

Collapse
lffg profile image
Luiz Felipe Gonçalves

Deno...?

Collapse
cubiclebuddha profile image
Cubicle Buddha

Good point. When the inventor of Node creates a new runtime that is designed specifically for TypeScript... you know what there’s something special about TypeScript. I can’t wait for Deno to gain traction.

Collapse
resir014 profile image
Resi Respati Author

Deno's different tho. What I meant about "runtime" is checking for types that occur at the runtime (e.g. API requests). Deno is a fork to Node.js.

Collapse
kristijanfistrek profile image
KristijanFištrek

I really love this.

Collapse
javaarchive profile image
Raymond

Why would someone every say static typing is bad. If I didn't have static typing I would make mistakes 30% more than normal. Thank you for writing this article.

Collapse
minardimedia profile image
Emmanuel Medina

I spend 14 hours trying to figure out how to work around react ref with a third party library Draft.js . So for me is a huge waist of time trying to implement on top of third party libraries