DEV Community

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...

Read full post

ErikKimsey • Jul 30 '19

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.

Cubicle Buddha • Jul 30 '19 • Edited

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.

Nick Holmes • Jan 7 '20

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).

Alex Sarafian • Aug 1 '19

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.

Cubicle Buddha • Aug 1 '19

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.

Alex Sarafian • Aug 1 '19

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.

saint4eva • Nov 30 '19

Are you sure the above code is C#?

Nick Holmes • Jan 7 '20

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

Jordan Kicklighter • Jul 29 '19

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

Cubicle Buddha • Jul 30 '19

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! :)

Resi Respati • Jul 30 '19 • Edited

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. :)

Cubicle Buddha • Jul 30 '19

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

Matthew Collison • Jul 30 '19

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.

Juneau Lim • Jul 31 '19 • Edited

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.

Resi Respati • Aug 1 '19 • Edited

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!!"

Juneau Lim • Aug 1 '19 • Edited

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

Austin

@amcdnl

@ljuneaul LOL - Thats pretty old and most of those items have been fixed.

18:40 PM - 30 Jun 2019

0 1

Jilles van Gurp • Aug 5 '19

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).

Ryan • Jul 31 '19

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.

Cubicle Buddha • Jul 31 '19

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

Eljay-Adobe • Jul 29 '19

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.

Scott Simontis • Jul 29 '19

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.

Pragmatic Maciej • Jul 30 '19

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

Daniel Kim • May 13 '20

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.

burhanudin hakim • Jul 30 '19

Nice Article!

Carlos Caballero • Jul 29 '19

I love debate!!

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

Thanks!

Casey Cole • Jul 30 '19

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.

Cubicle Buddha • Jul 30 '19

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?

Casey Cole • Jul 30 '19

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.

Cubicle Buddha • Jul 30 '19

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

John Peters • Jul 30 '19

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

Vladimir • Jul 30 '19

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.

Sam • Jul 29 '19

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

Luiz Felipe Gonçalves • Jul 30 '19

Deno...?

Cubicle Buddha • Jul 30 '19

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.

Resi Respati • May 15 '20

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.

Raymond • May 5 '20

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.

Emmanuel Medina • May 12 '20

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

KristijanFištrek • Jul 29 '19

I really love this.