Pretty simple, which do you prefer and why? I have read many conflicting opinions on it and wanted feedback from here.
Look, types are great. They really are. But I also don’t want to have to be bothered to add them. Doing so can be a lot of extra work. And they can greatly over complicate code. I saw a pretty good example recently of how wild TypeScript can get the other day but I’ll never be able to find it again. The type annotations accounted for about half of the code in the file.
Luckily, type inference is a thing. Double-luckily, editors like VS code can run the TypeScript compiler over your non-ts js code, and thanks to type inference and even type info gleaned from comments, can do a pretty good job of keeping you in line.
So yeah, I like TypeScript, but most of all when I don’t have to deal with it directly and can just write JavaScript while still reaping the benefits of it. And I don’t even need a compiler to run the code! 
2 Likes
That’s great. I feel much of the same about the two. The area in my company where I work is shifting tech stacks and I wasn’t sure exactly why Typescript was being pushed versus leaving the option open for Javascript. I think the main two reasons was TS is the hot new buzzword like “DevSecOps” and “Agile” and the second reason was for the ability for scrum teams to hop in and out of code that maybe they did not write and be able to understand a little faster than inferring.
Yeah, the types can help with better code comprehension, but they can have limits there too if you’re not familiar with the codebase. Typescript lets you define inline types like
let value:{key:string}
which lets you clearly see in that declaration that value should be an object with a property named key that should contain a string value. But more likely than not you’ll see something like
let value:ContainerType
and you’ll probably have no idea what ContainerType is unless you go looking for it or already have familiarity with the code.
Types can also be defined outside of the source file and that works really well for libraries that support both ts and js where the source can be js and the ts definitions are maintained completely separately. I can think of a nice little tiny library that does this, its source code a small 14-liner JS file without types and its d.ts file… oh look at this, one that fits what I was describing earlier - a d.ts file which is 125 lines (with comments). This being redux-thunk (js, d.ts).
So it can help just browsing source files, probably better than not having types as long as you can deal with the extra mental overhead of visually parsing them. But you’re best off when going through a tool/editor that can parse the type information (and jsdoc comments) statically and provide that info to you firsthand in tooltips and the like. And as I was saying before, you can get a lot of the way there with pure JS.
And yeah, TS is the (a?) current hotness, and has been gaining steam especially after Angular started embracing it fully. Babel integration was another big boon. And they’ve been doing a good job keeping up with additions to the spec, supporting stage-3 level language features, keeping people happy with new language features before they’re available. The latest of these are Optional Chaining and Nullish Coalescing.
Not too long ago I started a project up at work and initially went in with TypeScript, but ended up backing out because none of the devs working on it had any experience with it and they had a hard enough time trying to learn or catch up with react (some of them having no experience with that either). But I try to keep up with JSDoc commenting, and enforcing others do the same in code reviews meaning we still get pretty good typing info fed to us through VS code (and I’m not checking the code through ts right now because it currently fails 
but maybe I’ll get around to fixing that one day).
1 Like