DEV Community

loading...
Cover image for TypeScript is a waste of time. Change my mind.

TypeScript is a waste of time. Change my mind.

bettercodingacademy profile image Better Coding Academy Updated on ・5 min read

I think that TypeScript is a waste of time.

However, with the level of support TypeScript has, I know I'm bound to ruffle a few typed feathers here, but all I ask is that you hear me out.

I'm going to present what I believe to be a rational defense of my position, and then if you want, you can rebut my position in the comments below, and we can have a productive discussion. 🙂

Wait... read this part first!!!

Personally, I have used TypeScript on a variety of local and production setups over the last year or so. Prior to that and concurrently also, I worked on a full-stack JavaScript app, including over 60000 lines of Flow-typed Node.js code and over 40000 lines of Flow-typed React code.

However, as with all things, context is incredibly important.

Do I believe that there are situations out there where TypeScript should be used?

Absolutely! If your team is already using TypeScript, if you want to write code for other developers who may be using TypeScript - it really depends upon the context. However, I am making the argument that the use of TypeScript within your company project / your personal project / any sort of closed-source, non-library project will probably take more time than if you were to not use TypeScript, taking into account development time, bug-fixing time, time spent discerning and typing libraries, and so on.

I have a couple main points regarding this matter:

  1. The pros aren't really pros.
  2. Typed JS is long and difficult to read.
  3. Typed JS is still... untyped.
  4. What's so bad about untyped JS?

1 - The pros aren't really pros.

The commonly listed pros of TypeScript (and pretty much any popular tech product nowadays) always includes the statement: big companies are using it.

Now, if you're learning TypeScript in order to land a specific role at a company, then Godspeed - I'm not here to debate whether it can get you employable.

However, if you honestly think about it, this argument falls apart reductio ad absurdum:

Big companies use TypeScript, therefore I should use TypeScript.

Big companies also use legacy systems, therefore I should use legacy systems.

But wait, you say, the fact that TypeScript is used by big companies means that it is well-researched and supported! But then agan, the same argument can be made for Flow (static typing library by Facebook), React, Angular, Vue, Ember, jQuery, Bootstrap... wait a second, pretty much every popular library out there!

Other pros that people list include:

  • Having access to future features now - don't need TypeScript for this, you can just use Babel.
  • Working with older browsers - polyfills or Babel.
  • Static typing and type inference - see point below.

2 - Typed JS is long and difficult to read.

Kyle Simpson, proficient JavaScripter and author of You Don't Know JS, doesn't like using arrow functions.

Why? Because, and I quote:

I genuinely don't find them more readable in most cases.

Here's an article he wrote explaining it in more detail: https://davidwalsh.name/i-dont-hate-arrow-functions.

Now, not to try and make an appeal to authority fallacy, but I think that this:

import React from 'react';
import ApolloClient from 'apollo-client';

export interface ApolloContextValue {
  client?: ApolloClient<object>;
  renderPromises?: Record<any, any>;
}

let apolloContext: React.Context<ApolloContextValue>;

export function getApolloContext() {
  if (!apolloContext) {
    apolloContext = React.createContext<ApolloContextValue>({});
  }
  return apolloContext;
}

export function resetApolloContext() {
  apolloContext = React.createContext<ApolloContextValue>({});
}
Enter fullscreen mode Exit fullscreen mode

Code sourced from https://github.com/apollographql/react-apollo/blob/master/packages/common/src/context/ApolloContext.ts

Is far less readable than this:

import React from 'react';
import ApolloClient from 'apollo-client';

let apolloContext;

export function getApolloContext() {
  if (!apolloContext) {
    apolloContext = React.createContext({});
  }
  return apolloContext;
}

export function resetApolloContext() {
  apolloContext = React.createContext({});
}
Enter fullscreen mode Exit fullscreen mode

Do check out Kyle's article on why he doesn't like arrow functions... many of the points he makes there rings true regarding my critique of TypeScript also.

3 - Typed JS is still... untyped.

In truly statically typed languages such as C and C++, different variable types are stored differently in memory. This means that it is very difficult, borderline impossible to accidentally store data of the wrong type in a variable.

However, because TypeScript compiles down into JavaScript, regardless of how carefully designed your types are, there always is the chance that a different value type sneaks into a JavaScript variable. It's unavoidable - JavaScript is still untyped.

The truth is, even if you proficiently use and apply TypeScript (or Flow, for that matter) in every way possible, it's incredibly difficult to completely type all your variables, objects, interfaces, etc. properly. I was working with TypeScript on a Node.js project with over 60000 lines of code, and I found that my interfaces file for my Sequelize database models was over 5000 lines long on its own! I found the file to be mostly redundant, telling me what I already knew, however the reason I wrote it is because VSCode kept reminding me with the red squiggly line that I should type my models.

4 - What's so bad about untyped JS?

No, but seriously - what is so bad about it?

Untyped JS Bad Meme

If there is hard statistical data that using untyped JavaScript vs. TypeScript means that productivity decreases by any significant amount (if at all), then I wouldn't mind the verbosity of TypeScript.

However, there is no such evidence, and quite frankly, I personally am convinced that untyped JavaScript is more productive. Here's why I think this to be true.

  1. TypeScript is, by definition, longer than untyped JavaScript. As such, the development time is longer (assuming everything else is equal).
  2. None of the benefits purported by TypeScript (better error handling, type inference) are silver bullet solutions. You still need to test, and you still need to properly name your functions and variables. Adding an interface or a type doesn't solve any of these problems.
  3. Although TypeScript does catch some bugs in development, they're usually fairly trivial (using a number where a function expects a string) and can generally be caught by an experienced programmer anyways. With regard to more complicated issues (e.g. race conditions, memory leaks, etc.), TypeScript is completely useless.
  4. Therefore, as you still need to write the same tests and spend the same (or very similar) amount of time debugging and testing your code, whilst writing more code (see premise 1), therefore using untyped JavaScript makes you more productive than TypeScript.

5 - More importantly, look at design patterns and learn to spot code smells.

Here's an extra tip - instead of worrying about whether to use TypeScript, Flow, or untyped JavaScript, learn to write better code through design patterns and avoiding code smells (structural issues in your code). Learn to spot these issues, and also learn to refactor your code so it is better written. This kind of stuff is cross-language, and is what really can take your programming skills to the next level, and turn you from a junior developer to a senior one. 🙂

Thank you for reading!

To those of you who took the time to read through my article, thank you! I really hope that my content has been insightful.

As always, I come from a place of love and humility, and I would greatly appreciate it if you left non-scathing discussion or criticism in the comments. I would love to learn more about this and have my viewpoint shaped as well.

Happy coding!

Discussion

pic
Editor guide
Collapse
stereobooster profile image
stereobooster

UPD: I turned this thread into article dev.to/stereobooster/type-system-f...

Ok let's start constructive conversation by fixing some terminology: JS is typed language, it is dynamically-type-checked language (or some people short it down to dynamically typed). JS has types: string, number, bool etc. JS has type errors (not much, but still)

null.func // Uncaught TypeError: Cannot read property 'func' of null at <anonymous>:1:6
Enter fullscreen mode Exit fullscreen mode

JS has implicit coercion, which may create impression that there are no types in JS. Read more here.

So the question of use or don't use TS boils down to: do you want to do static type checking or not? (Dynamic type checking always there). And there is a trade of: you need to write a bit more code (type annotations) in order to make static type checker work. It's up to you to decide if it worth it or not.

As well, you may be confused by soundness of type system. Some type systems are sound e.g. they can prove there are no type errors. TS is not sound (any type), but you can bulletproof it with tsconfig, by setting all strict checks to true. And by prohibiting usage of explicit any.

However, because TypeScript compiles down into JavaScript, regardless of how carefully designed your types are, there always is the chance that a different value type sneaks into a JavaScript variable.

You can make a bridge between static type system and dynamic type system. Check that type are valid dynamically on the input (which is unknown and uncontrolled) and rely on the static type checker through the rest of the programm

for example:

const makeSureItIsAString = (x: any) => {
    if (typeof x !== "string") throw new TypeError("Not a string")
    return x;
}
const nickname = makeSureItIsAString(userInput())
// we are sure that nickname is a string in this part of the code
Enter fullscreen mode Exit fullscreen mode

read more about io validation here

Collapse
bettercodingacademy profile image
Better Coding Academy Author

Thank you for your input! Allow me to respond and clarify:

JS is typed language, it is dynamically-type-checked language (or some people short it down to dynamically typed).

Yes, I know. However, I wanted to differentiate between TypeScript / Flow-based JavaScript and JavaScript code that doesn't have TypeScript / Flow. I was first going with "plain", but then again, technically you can have JSX and other non-JS features without static types, so that's why I settled with "untyped".

And there is a trade of: you need to write a bit more code (type annotations) in order to make static type checker work. It's up to you to decide if it worth it or not.

Yes, I agree completely. However, I also believe that it is not worth it in the majority of cases, and that many people are misguidedly using TypeScript believing that it will save them time when in fact it only slows down development in both the short and long-term.

TS is not sound (any type), but you can bulletproof it with tsconfig, by setting all strict checks to true. And by prohibiting usage of explicit any.

This is true; however, in my experience this only leads to lots of red squiggly lines. It's impossible to do completely strict types in TypeScript / JavaScript, and there's always going to be that one case that cannot be fixed with this. Before you know it, you've got half-types and hacked code all over the place, and that's something that's not satisfying at all, especially when you've spent an extra 20-40% of development time writing up types, downloading type libraries and exporting interfaces.

You can make a bridge between static type system and dynamic type system. Check that type are valid dynamically on the input (which is unknown and uncontrolled) and rely on the static type checker through the rest of the programm

You sure can, but I would argue that if you want true type safety and security you should look at a statically compiled, more lower-level language. For example, in many large companies the API that interacts with the database is almost always written in a statically typed language such as C++, C#, Java, etc. - I don't think that TypeScript is the solution here. Plus, importing a function makeSureItIsAString seems like overkill just to make TypeScript support complete.

Once again, thank you for your detailed response, and I hope my response has been appropriate!

Collapse
cubiclebuddha profile image
Cubicle Buddha

I’m really disappointed to hear this same subjective phrase again:

when in fact it only slows down development in both the short and long-term.

I was hoping to find some objectivity. At a minimum, can you please try to convince me that TypeScript slows you down more than it speeds you up?

Consider the fact that I wanted to rename a variable yesterday and VSCode let me do it (and it can only do it accurately because of TypeScript). It changed the variable in 78 files. And this is important: it didn’t just do - “find and replace...” it did it intelligently. To refactor a variable name in JS would have taken a very long time and I would have had to regression test the entire codebase to make sure I didn’t break anything. I would estimate that a full regression test of my application would take 1.5 days.

And you also forgot about the fact that TypeScript helps to communicate your meaning to future developers. Isn’t that important?

So if it helps significantly with refactoring and helps you be a better coworker, then why is it a waste of time?

Thread Thread
pb8226 profile image
Paul

Good point, ease of refactoring is a place where static typing helps.

Thread Thread
xcs profile image
Buleandra Cristian

My experience was the same: I was forced to do numerous refactorings over big codebases, all done by pressing two buttons thanks to TypeScript, refactorings which would otherwise have taken hours with plain JS. TypeScript is a godsend for the JS ecosystem in my opinion.

Thread Thread
wmertens profile image
Wout Mertens

Vscode refactors plain js just fine. Typescript does not help with that.

Thread Thread
g1itcher profile image
G1itcher

I don't think that's true across multiple files and variables. Especially when multiple classes/interfaces have the same variable names

Thread Thread
wmertens profile image
Wout Mertens

Ah - you're renaming a variable in an interface? In that case, yes, probably vscode can do that thanks to typescript, and wouldn't be able to do it without it.

OTOH, all the times I did this, I did a global search&replace, eyeballing to make sure, and having the tests for extra verification.

Thread Thread
jsalinas11 profile image
Jordan

Uh, wait why are you using a single variable across 78 files? If I have to understand 78 files to understand a feature it sounds like you have bigger problems.

Thread Thread
cubiclebuddha profile image
Cubicle Buddha

That’s a lot of judgement Jordan. You seem to be making some assumptions.

“uh, wait why are you using a single variable across 78 files? If I have to understand 78 files to understand a feature it sounds like you have bigger problems.”

For a moment, suspend your assumptions and consider the fact that we had a valid reason for updating the the name of a property on some data. The reason the variable change effected 78 files is because we renamed a property on a data object that we use throughout the entire system. And since we have many api tests, end-to-end tests, unit tests, and more it caused a large change. But that’s the beauty of TypeScript... I can make a change that effects the entire system without causing any quality concerns.

So while your assumptions involve a change to one feature, in reality this change effected all features. When you take a functional / data-oriented approach it’s not uncommon to have many transformation functions that manipulate the data. And since I currently work on a data visualization UI, there are a great many ways that the users want the data to be transformed.

Does that clarify how one variable name can ripple out? Hopefully it communicates how TypeScript allows my team to continuously refactor with safety and without having to spend a bunch of time updating tests just because we learned that we originally misspelled a property on the data an API returns.

Thread Thread
jsalinas11 profile image
Jordan

Yeah, you're right I did judge. Sorry. I don't know your codebase, I just find it odd that a single variable would exist across 78 files. Feels wrong to me. Something like KISS or maybe SRP come to mind. But again I don't know your codebase.

Thread Thread
wmertens profile image
Wout Mertens

I think what they were doing is renaming a key in an interface, like going from data.online to data.isOnline

Thread Thread
xcs profile image
Buleandra Cristian

Or adding data.timestamp. With TS you automatically get notified of all the places where this data has to be set and also you now automatically know everywhere you use data that it also has a timestamp property. Also, TS ecosystem goes further than that, you could have Protobuf definitions that might be updated because data is serialized and sent over the network to multiple other services, and with the updated TS typings everyone just knows about this change and can update their code accordingly. And yes, this data interface could be used by hundreds of files across multiple services and git repos.

Thread Thread
rjmunhoz profile image
Rogério Munhoz (Roz)

Vscode refactors plain js just fine. Typescript does not help with that.

Actually, I might be mistaken, but VSCode uses tsserver to better understand your code and do stuff like refactoring, IntelliSense and stuff.

TypeScript isn't only able to perform static type checking on explicit types, it also infers types quite well. It's even possible to write plain JS, enable allowJs and checkJs on your tsconfig.json and let it infer and type-check stuff for you.

This also takes me to another point: in my experience I hardly type stuff other than function parameters; typescript can, usually, infer the rest. So arguments like "you write more code" get a bit weaker, IMHO

Collapse
cubiclebuddha profile image
Cubicle Buddha

This article has some misinformed opinions being reported as fact. I don’t mean that as an insult, I am just sad that there is no empiricism involved. Allow me to clarify:

For example, in many large companies the API that interacts with the database is almost always written in a statically typed language such as C++, C#, Java, etc.

All of those languages are weakly-typed when it comes to the MOST important aspect:

// valid C#
String myStr = null;

// invalid TypeScript 
const myStr: string = null;

Do you see how big of a problem it is that C# allows reference types to be implicitly nullable? That means that you can never know if your data is there are not. :( But with TypeScript you can have confidence in your code. The only languages that have strict null are TypeScript, Kotlin, and Swift. Can you see now how your subjective statement above is both incorrect and misleading? I feel like it’s the equivalent of “the cool kids are using C#.”

Plus, importing a function makeSureItIsAString seems like overkill just to make TypeScript support complete.

There’s no reason to write functions like makeSureItIsAString when libraries like io-ts do all of that work for you of ensuring type accuracy at compile time AND runtime. So if you’re looking to build an enterprise-grade app, io-ts or tsoa are wondeful tools to eliminate bad data from even getting through the front doors.

Thread Thread
stereobooster profile image
stereobooster

Let's use softer tone. Everybody has holes in their knowledge, it is ok as far as person willing to learn and take part in reasonable conversation. (Conversation was pretty reasonable so far. ❤️@parkroolucas. The title is a bit harsh, but I guess this is meant to be clickbait).

All of those languages are weakly-typed when it comes to the MOST important aspect:

Weakly-typed/strongly-typed is ambiguous terms. See here

Thread Thread
cubiclebuddha profile image
Cubicle Buddha

The title is a bit harsh

Yes. How many of these anti-TS articles are there? But when you look at the usage rates, most of the developers who try TS are interested in using it again.

Thread Thread
stereobooster profile image
stereobooster

I totally get you ❤️. What I'm saying if we all switch to this tone, it would be hard to have constructive conversation ¯\_(ツ)_/¯ (Yes author used the provocative title and text, yet somebody should stay cold-blooded)

Collapse
codemouse92 profile image
Jason C. McDonald

...in my experience this only leads to lots of red squiggly lines.

I don't know much about TS (and not a fan of JS, but let's leave that out of this), but I do know a lot about both C++ (static typing) and Python (dynamic typing).

If your code is filled with red squiggly lines from any linter or other static analyzer, you can almost certainly depend on your code being the problem, not the analyzer!

The same flawed logic in what I just quoted at the top is the reason C++ developers are afraid to turn on -Werror: "but, but, my code won't compile, it'll just give lots of errors.

I've seen that issue in nearly every language I've worked in, so it simply tells me that if someone is working in TS, and is avoiding strict mode because "too many red squiggly lines," you can bet the house they've been writing bad code. Chances are, in fact, they're using TS as if it were nothing more than JS-with-type-hints-on-top...and utterly eschewing the patterns and logic one must follow when working with types.

All that to say, if someone's gripe is too many red squiggly lines, I wouldn't trust the quality of their code in that language.

Collapse
stereobooster profile image
stereobooster

JSX is typed as well - it's just React.createElement() and you can attach dynamic type checking with PropTypes. Or in typescript

Or you can use them both like described here.

Let's stick to correct usage. Untyped means there are no types or what is the same, there is only one type. For example, assembly is untyped language it has only one type - bit strings, Lambda calculus is untyped language it has only lambdas.

It's impossible to do completely strict types in TypeScript / JavaScript, and there's always going to be that one case that cannot be fixed with this

In general it should be possible. The other question if you want or not. Don't mix up two argument.

typed language such as C++, C#, Java, etc.

You realise that all those languages are not type safe?

Java unsound, C unsound

Haskell has a sound type system. The type system of C (and thus C++) is unsound.

-- cs.uaf.edu/~chappell/class/2016_sp...

C# unsound

No, the C# type system is not sound, thanks to array covariance, my least favourite feature:

-- stackoverflow.com/questions/239391...

It means it is totally possible to write program in all of those language which will crash at runtime because of type error.

Don't confuse static types with type system soundness.

Plus, importing a function makeSureItIsAString seems like overkill just to make TypeScript support complete.

You don't need them everywhere you need them only to validate io e.g. user input, server response etc. There are libraries like, io-ts which helps to simplify this process.

Thread Thread
bettercodingacademy profile image
Better Coding Academy Author

In general it should be possible. The other question if you want or not. Don't mix up two argument.

I wouldn't say "in general", I would say "in theory" - however, in practice it is commonly the case that you don't write 100% of the code you use; and as such, you cannot confirm the validity and "typeability" of the code you are given.

You realise that all those languages are not type safe?

That was not my point, and I overstepped when I said "true type safety". Obviously TypeScript does not provide sound type safety and neither do the languages I've listed; however, they do have much stronger, native checks for static typing that are built into the languages, as opposed to TypeScript which still transpiles down before then being interpreted - quite a few layers there where errors can occur.

You don't need them everywhere you need them only to validate io e.g. user input, server response etc. There are libraries like, io-ts which helps to simplify this process.

Could you give an example of when you would need to validate and when you wouldn't? Seems weird to have to validate whether user input is a string, for example.

Thread Thread
stereobooster profile image
stereobooster

Could you give an example of when you would need to validate and when you wouldn't?

If you expect string and you read from the html input you will get string. But if you, for example, read state from URL and decode it and expect some arguments to be numbers, things can go wrong here. Or if you, for example, use JSON.decode to get response from the server, you need to make sure that response is in correct format.

I would validate all user input, I meant to say, that reading IO is typically not that big compared to other logic of application.

however, they do have much stronger, native checks for static typing that are built into the languages, as opposed to TypeScript

Why do you think so? Typescript is quite advanced type system it is based on latest research (and written by the same people who wrote C#, Anders Hejlsberg for example). So this claim needs a bit more evidence.

The fact that it compiled to JavaScript doesn't make it unsafer. All checks happen before compilation. The same for native programs, check happens before compilation, one of the compilation steps is type erasure (unless you use something like Reflections or io validation or pattern matching on boxed values). After type erasure you deal with untyped assembly code. Do you think assembly is more safe than JS? (rhetorical question)

Collapse
sompylasar profile image
Ivan Babak

It's impossible to do completely strict types in TypeScript / JavaScript, and there's always going to be that one case that cannot be fixed with this.

You have to understand where it is impossible: at the I/O boundary where your typed system talks with the outside world. Types help to make sure statically that the typed part of the program does not contain type errors. If the I/O boundaries are clearly delineated, and the data is cleanly marshalled from the untyped world into the typed world, you will clearly see the benefit if the typed world is large. If the only thing you do in your programs is manipulate the untyped data, it is easier without types.

Collapse
noderaider profile image
Cole Chamberlain

With a very strict configuration, TypeScript is more type safe than C#. In C# a reference type can be null. Not the case in TypeScript. With any language you could read in unknown data. It's no different with TypeScript. Use some assertions.

It may not save you time coding (I'd argue it does - see intellisense), but it 💯 saves time in prevention of runtime bugs. If you're seeing red squigglies and don't need to fix them to run your app, you're not doing it right.

If you're explicitly typing everything, you're not doing it right. I'd argue that the TypeScript example with context you posted is more readable due to the ability to read exactly what the context is via the generic type parameter.

TypeScript unit tests are usually shorter and superior to JavaScript's due to there being no point to testing a bunch of silly stuff like does this module export a function or not.

Collapse
kayis profile image
K

I learned that if a type checker just let your app crash "right before a bad access" it is equivalent to untyped.

Collapse
stereobooster profile image
stereobooster

If it allows incorrect type to pass type check process it is called unsound type system, not untyped.

Thread Thread
kayis profile image
K

That's not what I meant.

JS says right before an access on undefined that it is undefined. So the dynamic type check could as well be not there.

Thread Thread
stereobooster profile image
stereobooster

This exception itself is dynamic type check

VM219:1 Uncaught TypeError: Cannot read property 'sd' of null
    at <anonymous>:1:6

JS type checked it for you and because type mismatched, the only thing it is left to do is "panic" (throw exception)

Thread Thread
shavyg2 profile image
shavyg2

It's crazy how clueless some people are. What is confusing is they'll sound so sure when they are talking tho. If the language wasn't type checking it wouldn't crash it'd just keep going with wrong values. Dude said might as well just not be there. If I had a number 98, I think is "a" if I used as a char it would say "a" but because it's typed check, it checked to see how I was using it and crashed so I the developer can be informed and correct my mistake or cast it to explicitly tell the run time no I did this on purpose.

Thread Thread
kayis profile image
K

Sounds reasonable, thanks.

Got my definition of dynamic typing == untyped from a static typing fan prof. at university.

"Either you use static typing or no typing at all, everything else is BS."

Thread Thread
stereobooster profile image
stereobooster

this kind of education. I feel you. I had something similar.

(this is addressed to your professor)

What about IO validation?.. This kind of type checking can be done only at runtime. And all "super" static languages do it at runtime, including such notorious examples as Haskell and OCaml.

I mean even if you use static typing, some checks are impossible to do statically.

Also how to interpret no types? If you would take a look at the parser of almost any language, you would see that parser knows about types. It knows that value in quotes is a string, that value from digits is number, etc. In dynamic languages, there can be no declarations of types of function arguments, but there are always types of values. As well even if type declarations omitted they can be inferred by powerful types systems (to some degree).

What about a gradual type system? Which allows having only some of the types declared.

Thread Thread
shavyg2 profile image
shavyg2

It's just crazy, I mean I'm sure some of you have worked with JavaScript and feel a bit confident commenting. In my mind I'm like but you see typeerror in JavaScript when you use the wrong type some where or it says type error can't call blah on foo. Then you go on to say it has no types. It's like hearing there was a car crash and being like, I bet you no cars where involve. I just don't get how people say stuff like that. I have a few friends trying to learn programming and they like it's hard man, and I'm like naw people just make it confusing because they say so much nonsense and I don't even understand why. Books and paid online courses are the best route sadly because the internet...

Collapse
shavyg2 profile image
shavyg2

Lol, no

Collapse
cubiclebuddha profile image
Cubicle Buddha

Thank you @stereobooster for mentioning io-ts for strong typing at the boundaries of your application. I really think it helps eliminate all of the problems that Lucas mentioned.

Collapse
woubuc profile image
Wouter

For me and the devs at my company, Typescript is only partially about the static type checking. The biggest 'win' that Typescript offers is a direct way to communicate and enforce to the other developers how to use the functions and libraries we build. Using strict tsconfig settings and input validation (like @stereobooster mentioned in another comment), there's virtually no way they can implement it incorrectly, unless they force-override the Typescript compiler. The IDE support and integration of Typescript (autocomplete, etc) is also much better than with plain Javascript (at least with the IDEs I've used recently, which are WebStorm and VS Code).

Regarding the example code you gave for the readability argument, you generally wouldn't define interfaces in the same file as your logic. But that may be a necessary React thing, I'm not sure. I work with Vue which has plugins for Typescript class support and decorators, so I generally don't need to define my own interfaces for that stuff.

Perhaps a similar solution exists for React to make working with Typescript easier? The biggest pain point of Typescript is interop with plain JS libraries (especially if they depend on the dynamic nature of Javascript), but most of the bigger libs, tools & frameworks have Typescript support these days (built-in or through the use of plugins like with Vue).

I completely agree with your last point though. No matter which language you use, be it Javascript, Typescript, Scala or Whitespace, following best practices and writing clean, structured code is paramount to a well-working codebase and a good developer experience.

Collapse
toastking profile image
Matt Del Signore

For me this is the biggest win of typescript. Types act as another layer of documentation. It encodes valuable information in the code that helps future developers use what you wrote

Collapse
alinisarahmed profile image
Ali Ahmed

As a junior dev on my first job who had to read the code other team members wrote in a project, I can testify to this, TS was a godsend! I was up and running in two days max and able to contribute. The code didn't even have a single comment (that's bad or not is another topic,but I feel with TS you don't need much commenting anyway). Without TS I estimate I would've struggled for a week at least just to understand what was going on. I wasn't sold on TS before, but after this I'm never not using TS in a project. The self documenting aspect of TS is enough to warrant its use in every project, let alone all other benefits.

Collapse
bettercodingacademy profile image
Better Coding Academy Author

Thank you for your response! Like I said, there are cases where I think it is appropriate, including:

If your team is already using TypeScript, if you want to write code for other developers who may be using TypeScript

However, I do personally think it is a hassle, and that there are better ways to communicate coding interfaces across teams and developers. I'd also like to play devil's advocate here; even if you do use TypeScript, an ignorant (or arrogant) enough developer can still make coding standards really hard for your team.

Collapse
woubuc profile image
Wouter

We previously used JSDoc comments with type info, which worked fine and is still a decent solution when working in plain JS because most IDEs understand it just as well as Typescript annotations, but Typescript also lets us enforce it instead of just communicating (we still use JSDoc for documentation). Which ways do you prefer to communicate the information?

Along with a very strict tsconfig, we also have a rather strict set of eslint rules, and an .editorconfig file to cover all bases. Developers have to go out of their way by explicitly disabling all these tools to contribute something that doesn't adhere to our coding standards (and even then it'll still get caught by CI). So at that point you're talking about malice which is a whole other discussion.

We do use coding standards based on our common preferences and opinions, to make 'enforcing' these standards as easy as possible on the devs.

Thread Thread
bettercodingacademy profile image
Better Coding Academy Author

As Jeff Atwood said, the best code is the one that is self-documenting. I follow that rule, and I believe that static typing and JSDoc comments just cement in bad code even further (cause then refactoring it takes even more work).

There are certain patterns that become difficult if not impossible to enforce across a codebase. Not using shotgun surgery, for example. I think regardless of how much CI pipelining you do, ensuring the quality of the codebase still comes down to the skill level of the developers, proactiveness of developers with regard to regular refactoring, and the proactiveness of managers in maintaining code review processes and hence enforcing code quality.

Thread Thread
cubiclebuddha profile image
Cubicle Buddha

I agree that JSDocs can get stale, but TS types don’t have that same affliction. Do you realize that you don’t have to explicitly create interfaces? That’s why I’m so confused by this point:

As Jeff Atwood said, the best code is the one that is self-documenting. I follow that rule, and I believe that static typing and JSDoc comments just cement in bad code even further (cause then refactoring it takes even more work).

TypeScript can infer the return type of a function. So it that manner... TypeScript is the most effective language at creating “code as documentation.”

For instance everything in this example is standard JS but when it’s run through the TS compiler it catches the error implicitly:

function createMockUser(){
    return {
         firstName: Bob,
         lastName: Smith
    }
}

const myUser = createMockUser();

console.log(myUser.name.toLowerCase()); // this will cause a compiler error

Update: Based on Edward’s feedback below I’d like to clarify that you have the option of explicitly defining the return type too (more info here). I personally find it amazing that you can have implicit or explicit return types. Is there another language that allows that?

Thread Thread
etampro profile image
Edward Tam

No. That does NOT make TypeScript is the most effective language at creating “code as documentation.” simply because it can infer returned types from the function, because you can always implicitly return the wrong thing.

And put aside whether liking typescript or not, this is the attitude that leads me to dislike the typescript community. The title says "change my mind", and you are definitely not changing anyone's mind.

Thread Thread
cubiclebuddha profile image
Cubicle Buddha

Edward, my goal is to help people to get happier at work. For me, part of that happiness equation is TypeScript. If I’m not being convincing, then please let me know how I can better be of service to the larger community. I want people to understand more. If through that understanding people discover that TypeScript isn’t right for them, then I’m happy. If they discover that TypeScript is right for them, then I’m happy too. So please let me know what I can do. Is there a type of problem or example situation that I can illustrate with a code example?

Thread Thread
etampro profile image
Edward Tam

This tone is better, and I appreciate that.

I work across multiple programming languages over years, and I think that every language has its own philosophy and its own way to achieve certain objectives (either it being the best is subjective).

Typescript is one language that I have to work with closely recently. While I appreciate some of the good things TS can bring to developers, I wouldn't say it is one-size-fit-all language for all the practical use cases.

In this particular discussion, I think a elaboration of how you can achieve "code as documentation" with inferred types in TS with some code example would be helpful. (Though I personally thing proper unit tests and JDoc would server better in this particular aspect, and it is not a TS specific thing).

Thread Thread
cubiclebuddha profile image
Cubicle Buddha

I updated the original comment with examples. I don’t understand the “tone” comment though. If you’re reading my comments and assuming that I have some kind emotion behind them, then that’s a tone that you’re projecting onto it. My goal has always been to spread knowledge and enthusiasm.

As for the testing comment, every professional project I’ve developed recently has over 75% test coverage and it uses TypeScript. Why does everyone bring up testing vs types like they’re mutually exclusive? I like both. A lot.

Thread Thread
etampro profile image
Edward Tam

I do not think testing and typing are "mutually exclusive". But one of the "pros" people keep pitching about Typescript is the "code as documentation" and "less error" talking point, which I think is already achieved by having proper unit tests whether the language is typed or not.

I could be biased here, but just talking about this specific "merit" Typescript can give is not convincing to me. It could be also due to working style, because I tend to write very thorough unit test coverage (~98% across the projects I developed in the past few years).

Collapse
shavyg2 profile image
shavyg2

Don't feel insulted here.
Imma lead with that.

Every now and then you gotta be like, huh and listen to what people are telling you and learn from it.

I don't wanna sound condescending, I was kinda like that when I was younger too pushing my own thoughts. Honestly, listening is an important skill. Learning is an important skill. Being able to take a step back is an important skill.

There are many things in this post that just plain wrong.

There have been some follow up articles about this post that explain what is wrong about it. Read them. They are not opinions btw. As I said plain wrong.

I really hope you take the time because honestly it's a long post. I know you put time in to get it out and not everyone can sit down and do that.

It means you care which is key to getting to the point where you can do amazing things.

Caring is something you can't teach. You can't inform a person, they just have to have it or not.

Listen, to what people are saying and look at it again, perhaps it will give you some time to think. Perhaps write another post afterwards.

At the end of the day I'd rather a person misinformed than one that doesn't care.

Look into it and then come back, wish you the best on your travels.

Collapse
ssalka profile image
Steven Salka

Have you ever worked with a piece of JS code and thought any of these?:

  • "I wonder what fields are in this object"
  • "I wonder what exports are available in this module"
  • "I wonder if I can pass an object instead of a string here"

I certainly have, and all 3 of these things (not to mention several more) slow me down and annoy me as a JavaScript developer. Oftentimes I would have to dig through 3 (sometimes 5+) files to see where an actual value comes from, and sometimes even it comes from an external service that has little or no documentation about its return types.

In TypeScript - unless you are dealing with anys - the problems go away and your IDE or terminal can give you answers to these questions in real-time. Huge productivity boost.

That is why I will never again work on a codebase that doesn't leverage static typing.

Collapse
eliashdezr profile image
Elias Hdez

This.

I have the experience that people that behave like OP in thinking "this is a waste of time tool I prefer raw", usually is people that think their code is a piece of art and there's no imperfection on it, which translates later in a disaster code base.

Collapse
bigredmonsteruk profile image
Big Red Monster

Have you tried using an IDE that does this for you with JS though?

New developer on our team is trying to convince us to switch to Typescript with arguments like this. He has only ever used VSCode (which is terrible out the box for JS) and was trying to impress me with its intellisense. I then showed him IntelliJ and atom which have been doing the same since before TS was born.

I realise I am now in quite a luxurious environment where we use ES6 modules and current functionality with good IDEs. Many people seem to have written JS 5 years ago and are coming back to Typescript with the impression it's that which has somehow "fixed" JS. Almost all the good benefits boil down to things JS now has / VsCode support.

I am currently loving development with ES20## no build step in dev / Babel . Typescript just adds an unweildy and (IMHO) really bad typing system on top and enforces a build step. They could have at least looked at Hindley–Milner types and languages that use them rather than running with what they have.

Collapse
xcs profile image
Buleandra Cristian

I strongly disagree with the article. For me it just looks like a really biased article created just for the sake of having a conversation started (which, comparing the number of likes to the number of comments, it successfully achieves).

Just to enumarate some things that are orders of magnitude faster/better with TypeScript than with plain JS:
1) Refactor code across multiple files.
2) Autocomplete quality.
3) Catch A LOT of errors while you type. The ts strict mode can save you hours of pain and reduce the number "can not read property X of undefined" errors to almost none.
4) For the libraries that come with typings (most of them) you have a much higher chance of using them as intended and always passing the correct parameters. Even if you read the docs, without typings you might pass the parameters in the wrong order, or forget to wrap a variable in an Array.
5) Writing more robust OOP code. Try extending classes, implementing interfaces, having virtual methods and other useful OOP practices in plain JS. Your code will crash a lot at runtime. Yes, you can add checks for abstract classes and implement your own virtual functions, but that doesn't really save time over TypeScript, does it?

It's just like saying you shouldn't use a linter, as it's your job as a programmer to write readable code, research and respect all good practices, while also stating that trying to use any external help to making that happen is bad.

Yes, TypeScript does slow you down if you don't know how to use it and it takes time to learn it, but so does every new language. Once you learn it, it will actually save you time in the long run, not waste time as mentioned in the article.

Saying that typos and other human errors "can generally be caught by an experienced programmer anyways." is like saying a professional athlete never makes mistakes. Yes, it makes them less often, but no human is perfect.

With regard to more complicated issues (e.g. race conditions, memory leaks, etc.), TypeScript is completely useless.
No one advertised TypeScript as being a solution to those problems. For it's the same as bashing CSS that it does not help with fixing HTML DOM update performance issues.

The article also mentions that TypeScript is pretty useless for a senior developer as they can write good code anyway and notice all errors while typing, but I have a strong feeling that the more senior a dev is, the more likely it is that he actually uses TypeScript.

I do think, and if I remember correctly it's also mentioned in the article, that the author never used TypeScript in a medium/large multi-person project, because, once you do, you realize how often you get to think: "wow, if we weren't using TypeScript, fixing those issues would have taken so much time".

Collapse
pozda profile image
Ivan Pozderac

this is exactly my opinion! I just wanted to reply to whole article with simple question: is linter also waste of time? but you also covered main points that I strongly agree with.

Collapse
yaser profile image
Yaser Al-Najjar

Brilliant one, Lucas 👌

It's just so simple:

Wanna write clean code?

Learn how to write "clean code", NOT "static typed code".

Wanna write more reliable code?

Learn how to write tests.

Collapse
stojakovic99 profile image
Nikola Stojaković

No matter how clean code you write, once you reach certain threshold you'll run into problems with JavaScript. There is a good reason why it's one of the most hated languages, and TypeScript makes working with JavaScript codebase much easier in the long run.

Collapse
bettercodingacademy profile image
Better Coding Academy Author

Do you have evidence to back up your claim? My admittedly personal experience with tens of thousands of lines of typed code would lead me to believe otherwise, however I'd love to hear your side of the story!

Thread Thread
stojakovic99 profile image
Nikola Stojaković

This is my personal conclusion reading the experiences of more experienced software engineers + my personal experience working on the custom Node.js e-commerce platform.

I believe that, once you reach certain point in the project (I'm not talking about specific number of lines of code nor any other specific metric), dynamic typed language will actually slow you down a bit, because you'll deal with errors which would be eliminated right at the start in strongly typed environments. Of course, I'm not saying that this could be a substitute for following good practices, but it's much easier following good practices in a language which enforces good practices and prevents yoy from making stupid mistakes, like adding number and string. Yes, you should write your code in a manner that won't allow such things to happen that much, but from a personal experience, this is much more easily done in TypeScript, and even though I had to write more code, in the long run it made me more productive.

Nevertheless, I would like to hear your experience from working on huge codebases in JavaScript (or any other dynamic typed language) and the ways in which you addressed such problems. If I had to write enterprise level software my first choices would definitely be static typed languages, and not TypeScript, but if I had to work inside JS ecosystem, I would definitely choose TypeScript for such task.

Thread Thread
aerorezo profile image
Aerowyne Rezo

Lucas, do you have evidence to back up you claim? Historically, speaking most JS engineers I know forget that the code on nome_modules wasn't written by them yet still count it as lines of code.

So it would nice do see your proof, remember you are defending your thesis here.

Thread Thread
stereobooster profile image
stereobooster

Do you have evidence to back up your claim?

Here you go blog.acolyer.org/2017/09/19/to-typ...

TL;DR: both Flow and TypeScript are pretty good, and conservatively either of them can prevent about 15% of the bugs that end up in committed code.

cc @yaser

Thread Thread
yaser profile image
Yaser Al-Najjar

I haven't gone through the research paper, and I skimmed the article real quick...

Could please correct me if I'm wrong:

Out of 3 million bugs they picked only 400 and studied them to reach that conclusion, right?

Thread Thread
stereobooster profile image
stereobooster

3M is the number of github issues, not all of them bug fixes. Researches were forced to recheck manually if it is a bug fix or not

Each is then manually assessed to determine whether or not it really is an attempt to fix a bug (as opposed to a feature enhancement, refactoring, etc.)

but they picked enough of them to make sure this is statistically significant result

To report results that generalize to the population of public bugs, we used the standard sample size computation to determine the number of bugs needed to achieve a specified confidence interval. On 19/08/2015, there were 3,910,969 closed bug reports in JavaScript projects on GitHub. We use this number to approximate the population. We set the confidence level and confidence interval to be 95% and 5%, respectively. The result shows that a sample of 384 bugs is sufficient for the experiment, which we rounded to 400 for convenience.

Thread Thread
stereobooster profile image
stereobooster

If you want more researches check this article dev.to/baetheus/thank-you-next-typ...

Thread Thread
aerorezo profile image
Aerowyne Rezo

@stereobooster I wasn't asking for support that type systems finds bugs, I was asking that the author of the article defend any of his points. :p

However, if I were to extrapolate the information from that article it would be that two years ago, when TypeScript was still new and lacking a large following (not many public modules were properly typed back then), it still had a significantly positive impact. If they ran that study again today I would imagine the results to be significantly higher, just from the new features in TypeScript let alone the number of fully typed libraries that now exist in DefinitelyTyped.

Thread Thread
yaser profile image
Yaser Al-Najjar

Sorry for my late reply, and thanks a lot @stereobooster for the explanation 🙂

Besides that the researcher is a guy from Microsoft (which could make the research a bit biased), and I'm not a math expert.

But the confidence interval is affected by the variation & the sample size.

And, I find 400 bugs to be a ridiculously small sample size and you know that bugs can vary to an infinite interval.

Of course static typing would discover some bugs, but everything comes at a price.

The Price (blind spot that the research is not looking at):

  1. Supposing the numbers were very accurate, Is the extra effort (using static typing) worth it (the discovery of 10% bugs)?

  2. That 10% of bugs, are they really hard to discover bugs? or just ones that you would open the browser and you would find them right away?
    Generally, bugs that devs find valuable to discover are the logical ones, not the syntax or statically-typed ones.

  3. Typescript would require you to write more code.

And hey, LOC (lines of code) is a liability, NOT an asset... means that extra code need to be maintained.

I just started a discussion from a different angle here (feel free to join):

Thread Thread
yawaramin profile image
Yawar Amin

Besides that the researcher is a guy from Microsoft (which could make the research a bit biased

Yaser, firstly, there are three co-authors on the 'To type or not to type' paper, and two of them are listed as being at the University College London, and one at Microsoft Research. Now, you could argue that the Microsoft Research guy is pushing TypeScript because some other team in Microsoft makes it. Far-fetched, but sure. So then why would the paper say that both TypeScript and Flow were about equally effective? Flow is made by Facebook. Wouldn't that go against your bias argument?

But the confidence interval is affected by the variation & the sample size. ... And, I find 400 bugs to be a ridiculously small sample size

Well, that's how statistical analysis works. You don't need to trust this paper, calculating a sample size for a statistically-significant result is a well-known technique. Go to surveymonkey.com/mp/sample-size-ca... and plug in the numbers (population size 3 million, confidence level 95%, error margin 5%), you will get the same sample size 385.

The Price (blind spot that the research is not looking at):

Nope, they looked at it.

Is the extra effort (using static typing) worth it (the discovery of 10% bugs)?

The extra effort was timeboxed deliberately: they decided to look only at bugs that could be fixed by applying very simple types within a 10-minute window.

are they really hard to discover bugs? or just ones that you would open the browser and you would find them right away?

These were bugs that were shipped to and reported in production. So they passed all quality-control methods that the projects already had in place.

Typescript would require you to write more code. ... And hey, LOC (lines of code) is a liability, NOT an asset... means that extra code need to be maintained.

Unit tests also require you to write more code. That's a liability, don't write unit tests! ;-)

Collapse
yaser profile image
Yaser Al-Najjar

Nikola, my friend...

It's not right to assume that there is some "threshold" without having a solid proof (aka running into one).

Cuz really, tons of companies are doing just fine with the normal JS... not just fine, but actually PERFECTLY FINE.

Even us (Coretabs Academy), we are doing really great with the normal JS, and we super barely have problems.

I mean, before throwing such assumptions about "long-run" and "large codebase", please try it and see how it goes.

Thread Thread
stojakovic99 profile image
Nikola Stojaković

Hey Yaser,

I don't know why you think I'm just assuming it - I actually have experience working with a bigger code base written in JavaScript and TypeScript (our front-end part is written in JavaScript, and back-end is in TypeScript).

I doubt anyone can give a specific proof for this and we can all talk from our experiences. As I answered before, this is my experienced combined with the stories I have read on this topic (dynamic vs static / strong typed systems) written by more experienced software engineers and I'm definitely not saying this is something written in rock and I would like to see examples where this is not true.

Right now I'm working on an e-commerce system written in TypeScript. I don't know how much lines of code it has nor I think it's important here. What I can say for sure is that it makes me much more productive to know upfront if there is some potential problem with my code instead of running into problems in runtime. Time which I would have to spend debugging the problem may not be high, but it adds pretty quickly. At the start it took me more time to properly structure my code, but in the long run, I believe I saved much of my time.

I'm not saying that just using JavaScript will bring you the problem - what I'm saying is that bigger, properly structured TypeScript code base will prevent you from running into the problems which could happen to you more often with the same code base written in JavaScript.

As I said before, writing in strong / static typed language is not a substitute for the proper structuring of your code base, but my personal experience is that it's much more productive to write and manage huge code bases in TypeScript than in the JavaScript. If you think otherwise, I would like to hear your experiences on this topic too.

Thread Thread
maxinertia profile image
Dorian Thiessen

we super barely have problems.

2vue.runtime.esm.js:1887 TypeError: Cannot read property 'members' of undefined
    at e.r (about.js:259)
    at e.value (siema.min.js:1)
    at s.next (about.js:111)
    at click (about.vue?1da6:1)
    at nt (vue.runtime.esm.js:1854)
    at HTMLImageElement.n (vue.runtime.esm.js:2178)
    at HTMLImageElement.Yi.a._wrapper (vue.runtime.esm.js:6876)
it @ vue.runtime.esm.js:1887
rt @ vue.runtime.esm.js:1878
tt @ vue.runtime.esm.js:1839
nt @ vue.runtime.esm.js:1861
n @ vue.runtime.esm.js:2178
Yi.a._wrapper @ vue.runtime.esm.js:6876
about.js:259 Uncaught TypeError: Cannot read property 'members' of undefined
    at e.r (about.js:259)
    at e.value (siema.min.js:1)
    at about.js:76

This is from your site.

If members had type Member[]? this would have been caught by typescript, and you'd be forced to check whether it was defined.

It only took me a minute on your site to find that, what else do you suppose is lurking in there that could've easily been caught pre-runtime?

Thread Thread
yaser profile image
Yaser Al-Najjar

Thanks Nikola for sharing your view, I really understand what you're saying.

My point of view about TS is that it adds extra code... and from my experience: extra code = more work and more time consumed (no matter how it is).

I always see the LOC as a liability, not an asset.

I don't know why you think I'm just assuming it - I actually have experience working with a bigger code base written in JavaScript and TypeScript

I saw your GitHub has 17 contributions in the last year (and mostly on non JS code), it's something you might want to change... cuz people do judge on that (sorry for judging too fast).

I'm not saying that just using JavaScript will bring you the problem

You just laid your hands on the blind spot that I saw in this whole discussion (from other devs in this topic).

Which is (dynamic vs static) typing langs will solve the problem, it's not.

I believe the whole discussion should be about the architectural & design decisions and the developer expertise.

Yes, you're absolutely right about how TS introduces better design decisions.

I faced exactly the same experience when using C# then Python. I said C# (and ASP Core) tells you exactly how to do things, but Python gives you all the flexibility and power to do things in anyway.

In time, I realized that I finish my projects in Python on time much more faster that what I did on C#!

Why? cuz I transferred that knowledge (of doing things the right way) from C# into a language that allows me to do me doing things in anyway.

And that is ultimate power, and the only catch is as you know:

With great power, comes great responsibility

Thread Thread
yaser profile image
Yaser Al-Najjar

@maxinertia

This is from your site.

Does that affect the end-user in any way (would he see any unexpected result)? NO

Then, do I care? NO

Thread Thread
stojakovic99 profile image
Nikola Stojaković

Yaser,

Just because something doesn't affect the user now, doesn't mean it won't affect it later or cause another, seemingly unrelated error.

Thread Thread
eliashdezr profile image
Elias Hdez

That was hilarious, you caught him off guard with that bug.

Thread Thread
kevinclarkadstech profile image
kevinclarkadstech

“It only took me a minute on your site to find that, what else do you suppose is lurking in there that could've easily been caught pre-runtime?”

Hahahahahahaha hahahaha hahaha 😂 these fools with their “TypeScript is not helpful” crap. 💩I can just imagine how hard it would be to understand their codebase.

Thread Thread
worc profile image
worc

...undefined objects during runtime aren't necessarily going to be caught by your static type checker. if the api changes and leaves out that key object, what good did your type system do?

Collapse
woubuc profile image
Wouter

You can write clean code and still find static type checking helpful. These aren't mutually exclusive.

Collapse
yaser profile image
Yaser Al-Najjar

Who said that "they are mutually exclusive"?

I just stressed on focusing on the goal (clean code),

Cuz "static typed code" != clean one

And hey, many people just mix those two!

Collapse
g1itcher profile image
G1itcher

Typescript enforces better coding practice by design and prevents the kind of crazy stuff you see in JavaScript projects.

If you work in a company with contractors or developers at multiple levels of ability, TS will always increase productivity across the team.

Articles like this usually seem to forget that people are inherently fallible and lazy. TS enforces rules that keep the windows from being broken (to steal the uncle Bob metaphor)

Collapse
bigredmonsteruk profile image
Big Red Monster

"Typescript enforces better coding practice by design and prevents the kind of crazy stuff you see in JavaScript projects."

I haven't found that to be true tbh - Almost all Typescript projects I have both seen and been a part of seem to follow standard class based organisation. I would argue that Typescript really pushes people down the class route and then they end up with the same old problems with classes we've all had with large codebases and classes.

Now - you can definitely CAN work without classes in TS but if you say it "enforces better coding practice by design" I would have to disagree. It is most definitely not a crutch for inexperience.

Collapse
bettercodingacademy profile image
Better Coding Academy Author

Well said. You rewrote my whole article in four lines!

Collapse
eliashdezr profile image
Elias Hdez

This is called "subjectivism".

If the majority of people thinks that TypeScript is awesome and productive (according to surveys), then so be it, why try to convince people otherwise because you don't agree with it? We don't need to change your mind and neither us.

All the comments in this "article" are just that, subjective, including mine. The only positive thing here is people pointing out good points based on actual data, not assumptions like this article.

Collapse
trusktr profile image
Joe Pea

A few points you haven't covered:

1) Code refactoring. TypeScript paves the way here. I once refactored some UI code from 1400 lines of typed jQuery to 700 lines of React. I didn't test or even run my code, but I pushed it to a branch and my co-worker pulled it and told me it worked first try and passed all QA. It would have taken much longer to refactor with plain JS, and likely would not have worked first try. From completion in JS, to completion in templates (JSX) to completion in the styles (CSS-in-JS), the refactoring was a total breeze. I have never had such a good time doing major JS refactoring until I used TypeScript.

2) Communication: more than anything, types allow cross-developer communication with nothing but code. Interfaces tell other people what you intend (without them having to open a separate test file for example). It saves time in understanding code. This is important, for future devs coming onto a project (and previous devs leaving).

I think you'll appreciate TS more when you consider those aspects.

Collapse
dwd profile image
Dave Cridland

You're almost immediately destroying your own arguments - all of them - in just one phrase:

"can generally be caught by an experienced programmer anyways"

So your implication there is that if bugs get through that Typescript would have (trivially) stopped, it's because the programmer isn't experienced enough? It's not the code, it's the developer?

In that case, after 25 years of writing code, I'm not experienced enough by your definition.

Maybe you're too good a programmer to need static typing. Maybe you don't need unit tests, either. Maybe you don't need automated tests. And if you do, perhaps you should take your own advice and "learn to write better code".

But as for myself, I'll take all the help I can get - I might not be experienced by whatever definition you use, and I'll readily agree I can always learn to write better code, but what my experience does tell me is that static typing is useful both to me as a programmer, and also my IDEs and other tooling, which in turn make up for my weaknesses and let me concentrate on providing actual value to actual users.

Collapse
shavyg2 profile image
shavyg2

Typescript may not be for you, but what your saying doesn't make any sense. You sound like you work alone more often. I remember getting a snippet of js and not having a clue what was what. I was like console log the variables and send it to me. I remember getting typescript code and instantly knew everything that was going on. So static languages are for static analysis, it's not about run time type checking for typescript.

Typescript makes code readable because it describes the content of the code in the lease possible way, compared to using jsdoc, and typed js has been proven to have less bugs. It's not typing that slows development it's bugs. Look it up

Collapse
trmaphi profile image
Phi

Just being curious, do you prefer compilation error over run-time error? If the answer is the compilation error, I'll say TypeScript is not that bad.

The thing I found most valuable about TypeScript is I can check error on compilation, the required properties on a type/interface already save me and my team hours of debugging, without a doubt if I need to prevent developer errors, this is my life-saving.

And the second thing, I found is that you can use untyped JS in TypeScript. It gives you the option of any and @ts-ignore. Sometimes, I do this just to code faster, I come back later to fix the problem of TypeScript warnings. So, TypeScript give you the power and also the options.

Collapse
quanla profile image
Quan Le

Typing is a great idea, but no implimentation has proved that it works in practice. Typescript is so flawed that it destroy coding experience totally.

From someone who was so annoyed by wrong TS error messages, and had to add too many ts ignore comments

Collapse
yawaramin profile image
Collapse
quanla profile image
Quan Le

So TS is always correct and never gives stupid errors? Even TS team doesnt believe so, that's why they have ts-ignore.

Sure, every newbie's code are swamped with simple mistakes, and simply fixing those typos can make the code "run". That gives you the immpression that the compiler is life saver here. And that is ahuge delusion

Thread Thread
yawaramin profile image
Yawar Amin

If you use it properly, it should be very rare to get a 'stupid' error. Almost every type error is saying something interesting, in my experience. ts-ignore is not something unique to TypeScript, every language provides escape hatches from their static checks. E.g. Rust's unsafe and Haskell's unsafePerformIO, etc.

Thread Thread
quanla profile image
Quan Le

First, why are you so sure that I am not using it properly? Is it that difficult to use a compiler "properly"?

Second, great. Thanks for the point. It helps explain why all static language is failing at a certain level.

Cheers

Thread Thread
yawaramin profile image
Yawar Amin

Is it that difficult to use a compiler "properly"?

Actually, it kinda is difficult. You have to put in some work to understand the type system, error messages, idioms, how to take maximum advantage of static types and their intersection with dynamic values. No such thing as a free lunch.

all static language is failing at a certain level.

Well here's the thing. Static languages have an escape hatch to allow dynamic behaviour. However dynamic languages don't have an 'escape hatch' to allow static behaviour. So really, by sticking to dynamic only, we are limiting ourselves.

Thread Thread
quanla profile image
Quan Le

Right. Thanks. With your reasoning even eating lunch is difficult, you have to learn which one you have to chew and which one you have to swallow immediately, and how to have both together for maximum eating joy...

Sorry for the sarcarsm, but man, using static type is just the easiest thing in programming ever.

Anyway, goodluck with programming

Thread Thread
yawaramin profile image
Yawar Amin

using static type is just the easiest thing in programming ever.

So it's really easy and it can be helpful ... I don't get it, in that case what's your argument against it?

Thread Thread
quanla profile image
Quan Le

Did I say it can be helpful? Maybe, for people who cant determine what type of variable he is looking at. But for me, and the author of this article, TS is doing more harm than good. And it is like a pain in the ass using TS every day

Thread Thread
yawaramin profile image
Yawar Amin

Ha ha, OK, best of luck to you as you are obviously a programming superstar who doesn't need any help from a typechecker.

Thread Thread
quanla profile image
Quan Le

Yeah, sorry if I sound like a jerk, but I had my years with static typing already. At first things are super nice, but then shortcomings start to appear, and now, it totally outweighed the good stuffs.

So yes, typechecking does help here and there, but the tradeoffs are far too big for me. So, no thanks

Collapse
newtonmunene_yg profile image
Newton Munene

I think it all boils down to personal preference. Personally, I feel it takes way longer for me to setup babel and other polyfills than to get started with typescript. It also shortens the amount of time I spend debugging as the compiler and linter catches most syntax errors. I am a junior developer, fairly new actually, so I might be wrong but what's the harm in using typescript?

Collapse
bettercodingacademy profile image
Better Coding Academy Author

Thank you for your response!

Setting up Babel is (mostly) a one-time thing, and is generally mitigated by using bundlers such as Parcel (assuming you're working with the frontend). However, using TypeScript incurs a constant tax of about 20-40% of extra development time (in my experience), so definitely tread wisely.

Collapse
cubiclebuddha profile image
Cubicle Buddha

Explain this “tax” objectively please. And do not cite Eric Elliot’s article since all of his citations have been refuted. The authors of his citations have come out publicly and stated that he is misusing their information to prove the opposite point. The original studies showed that static type checking does improve delivery time.

Thread Thread
bettercodingacademy profile image
Better Coding Academy Author

Like I said, this is "in my experience" :) I definitely am not speaking from statistical evidence. However, like the point I made in my article... writing TypeScript is definitively, provably longer than writing normal JavaScript, so if you are to defend TypeScript and how good it is, the burden of proof is on you to indicate that there is in fact a speed-up to using TypeScript vs. using JavaScript.

Sorry for not explicitly responding to your other items - some of them don't have a "Reply" button and I'm not sure why that is 🤷‍♂️ However on your other point regarding renaming a variable, I'm very curious... could you please describe how TypeScript specifically allows you to rename a variable better in 78 files than with regular JavaScript?

Thank you for your time!

Thread Thread
cubiclebuddha profile image
Cubicle Buddha

Right click “refactor > rename” and VSCode does the rest because it’s aware of TypeScript’s instrumentation of the code.

Thread Thread
bettercodingacademy profile image
Better Coding Academy Author

I can do that with regular JavaScript as well though... isn't this an IDE feature as opposed to a TypeScript feature?

Thread Thread
cubiclebuddha profile image
Cubicle Buddha

Webstorm can’t do this effectively in Javascript. Anyone who has tried that (as I have) will discover that WebStorm gets it wrong because it can only make guesses. However when you provide the IDE with the instrumentation of TypeScripts types then the IDE can be 100% accurate. Yes it’s an IDE feature (which I stated in my original message). So that’s why a failed refactor in JS would necessitate a regression tests of the system.

Thread Thread
cubiclebuddha profile image
Cubicle Buddha

I think it’s wise to consider the trade-off between the initial development costs and then maintenance costs. That’s why I find comments like this concerning:

However, like the point I made in my article... writing TypeScript is definitively, provably longer than writing normal JavaScript

Yes, I can write it faster in JS. But when I fix one bug and it uncovered another bug... that takes more time in total. Each subsequent bug that’s created takes even more time. However, if you just wrote the app in TypeScript the first place then the subsequent bug fixes can be identified by the compiler. Which means:

  • less manual regression tests need to be run
  • bugs that are caught by the compiler are fixed before they even enter production
  • since you don’t have to fix production bugs you can do so with calmness. Doesn’t everyone want calmness and peace? I’d take that over initial development speed any day.
Collapse
redtaped profile image
Jamieson Rhyne

I agree with you in some respects, especially if you have small private methods, typing everything may have diminishing returns.

What sold me on typescript is that it can be used without typing and automatically start giving intellisense and compile errors when passing invalid parameters. So you can add value, even without typing. Then, some models are reused throughout an app, typing commonly utilized models makes things easier for developers to understand the public methods of your well designed, encapsulated classes, without ever having to look at the code to understand the data needing to be sent in. This can be true with primitive types also, on public methods used throughout your app. Having a method clearly indicated as accepting a certain type of data not only gives you type safety which can prevent bugs, but it also make it easier for other developers to understand the code without opening up the class and reading it.

Collapse
fnky profile image
Christian Petersen

Here's my thoughts on the subject: Development time is not calculated by how much code you have to write but rather by how fragile or error-prone writing that code is.

You have to take a look at the trade-offs that statically typed languages have for your code, your team and how things are communicated. It's important to question yourself and the team on:

  • How do you handle API changes—both for the projects, but also for shared code as well as network data?
  • How do you communicate breaking changes that may affect other parts of the product?
  • How do you onboard future maintainers and developers of this code?

A lot of these questions can be largely solved by having type information at your disposal.

Code patterns does not solve these problems. Why? Because we are human and humans make mistakes. All the time, by nature. It does not matter how secure and restrictive your environment is, there will always be a chance of failure.

But the question is what types of failure this is, and how easy they are to avoid either before they happen, but also how that can be remedied after they happen. Some failures are more destructive than others and you have to consider the pros and cons, depending on the type of product that you make.

Avoiding Undefined Behaviour

Statically typed languages can help you avoid undefined behaviour in most common cases. Since you consume the contracts that types and interfaces gives you, it is almost impossible to fall into a rabbit hole of passing wrong data types around and cause unexpected problems that can be hard and tedious to debug.

Discoverability

Statically typed languages provides ways to define contracts, that can be passed around in a program to ensure that at any point where the data flows, you can ensure that integrity of how that data can be consumed.

This also has the benefit of being extremly easy to use an API, without having to consult to external sources or documentations. With types, you don't need to inspect implementation details since the input and output is documented and available upon usage with intellisense and code completion.

Guards can provide safety to public APIs

If you provide a public API that is to be consumed by JavaScript, you can either write guards manually or use a bundle plugin to handle this for you, based on the available type information.

However, in a project that is purely TypeScript and not meant to be consumed by a public audience, these guards only adds more weight.

Inference is your friend

TypeScript uses inference to guess the types of values that you pass around. In 95% of cases, it works really well and you won't need to define type information, given that your code is written in a way that the inference can understand and follow.

This can help you write better code, too, that is deterministic, since that is how inference work.

Of course you can always get around it by forcing your code style, but that comes at a cost that you have to manage the type information yourself, for example by casting or provide types to declarations.

Collapse
ar10642 profile image
Andrew Richardson

Having used both, my feeling is that why it does do some good things, like enforcing you call methods with proper types and helping code completion, nobody wants to talk about the battles you inevitably end up having with the type system when trying to get it to work with some third party library or some older code. You either end up writing silly bits of code to shoehorn it in or giving up and going any, but you've lost 4 hours doing it. I've seen bits of code "providing" window to try to avoid using any, which to me is just madness.

And really, I do find it harder to follow and read just because of all the extra text.

I get why you all like it, I'll use it and not complain too much, but I won't choose it for my own projects.

Collapse
kayis profile image
K

I didn't grow fond of TS either.

While I have the firm believe that JS doesn't mix well with my aversion of TDD, TS is just too C#-y for my taste.

At the moment I'm looking into Reason which seems much more syntactically minimal.

Collapse
cubiclebuddha profile image
Cubicle Buddha

yeah, good luck trying to write enterprise node.js app without typescript

Absolutely. When you work at a large company where team members can be joining and leaving frequently... the only kind thing to do is to document your code so the next person can be productive. And since JSDocs can and often fall out of sync with reality, TypeScript always stays in sync.

I feel like the arguments against TypeScript are from people that plan on staying on a project. But if you have any interest in moving onto another project... how is the next guy going to know how your code works?

Collapse
rafalmaciejewski profile image
Rafał Maciejewski

I feel like the arguments against TypeScript are from people that plan on staying on a project.

I feel like that arguments are from people that are just writing small projects one after another and never had to do any refactoring or didn't even done enough bug-fixing in their career. Working with existing codebase written in TypeScript is by miles easier and clearer than working with codebase written in plain JavaScript.

Collapse
brunobrant profile image
Bruno Brant

Lots of strange terminology being used throughout the discussion.

There are two axis when it comes to classify languages relating to its type system:

Weak vs strong - weakly typed languages are those that allow us to cast between types forcibly. C++, for instance, allow us to cast anything to void and cast void to anything, which can lead to type mismatches.

Static vs Dynamic - static typed languages are those which the types are know at compile time, either explicitly (C++, Java, etc) or implictly (F#, etc). Dynamic typed languages means that types are determined during runtime.

Nullability Nullability is a whole other matter. Null isn't really a type, but it's a property of a variable that denotes "no value". Some static type systems incorporate Nullability better than others, like TypeScript, as some users mentioned, where you can inform the "compiler" whether or not the variable (not the type) can be null. This is similar to how mutability is treated by some languages like F#, where you need to explicitly inform that a variable can be mutated.

The point of the article is the usual one: whether annotating types is worth the effort.

First one must realize whether she believes that validating the code automatically is important. If it's enough to launch the application and test it manually, then the discussion is void.

But throughout the last decade we realized that validating our programs using automated mechanisms are a very good practice and worth the trouble.

I believe that statically typing works in the same problem domain: catch programming errors as early as possible.

If, however, you prefer to write tests with all variable combinations (and check types explicitly in code), there's no need type your code.

However, there's one additional feature that I love about typing: the better code completion/suggestions we get. This may be solved in the future when IDE get even better at type guessing, but for now they are limited when types aren't informed somehow.

Collapse
stereobooster profile image
stereobooster

static typed languages are those which the types are know at compile time

Right. If you open source code of almost any parser you would see that parser knows type of the value at the moment of parsing ("afsd" - string, 123 - number, etc.). By this definition JS is statically typed.

Dynamic typed languages means that types are determined during runtime

If you would use reflection in Java you would be able to determine type at runtime. So Java is dynamically typed.

Weak vs strong

Not CS terms.

Null isn't really a type

Null is a value. "Nullable" type represents set of one value.

type NullableNumber = number | null
Collapse
brunobrant profile image
Bruno Brant

OMFG, what the hell are you talking, son? Is this flame bait?

Right. If you open source code of almost any parser you would see that parser knows type of the value at the moment of parsing ("afsd" - string, 123 - number, etc.). By this definition JS is statically typed.

That's not it. Your examples are values, not variables. Please consider:

function foo(bar) {
   console.log(bar)
}

What's the type of bar? It could be string, number, object, etc. The interpreter will determine it during run time and emit the code to support it accordingly, so if you call foo("abc"), foo(1), and foo({}), you get three compiled code blocks that the interpreter determined during runtime that they where required.

In case you are still not satisfied, check this code:

switch (new Date() % 3) {
   case 0: foo("abc"); break;
   case 1: foo(1); break;
   case 2: foo({}); break;
}

If you call that code, during runtime the JS engine determines the type of the variable bar.

That's the definition of dynamic typing. Types of VARIABLES are not known/determined until runtime. That means that code can fail in runtime, not compile time, if a invalid type is provided.

If you would use reflection in Java you would be able to determine type at runtime. So Java is dynamically typed.

I may not have been clear, so: not you, the programmer. It's the compiler that doesn't know the type in compile time. Java is statically typed because all variables have type that are statically defined in compile time.

One more fundamental thing to note: variable type doesn't change in static typed languages, whereas they can change in dynamic typed languages. Check this code:

// Java/C/C#
int num = 10;
num = "abc"; // compiler error

However, this JS code is valid:

let num = 10;
num = "abc";

Not CS terms.

This is why I got mad at you. What makes you assert this? Take a look at the results in google:

google.com/search?sxsrf=ACYBGNQ7UX...

Not convinced?

google.com/search?tbm=bks&q=weak+v...

This will give you a number of results of books on compiler design that talks about the weak typing and strong typing. I hope this convinces you, for your sake.

Good luck.

Collapse
curtisfenner profile image
Curtis Fenner

There's a few fundamental things I disagree with:

TypeScript is, by definition, longer than untyped JavaScript. As such, the development time is longer (assuming everything else is equal).

This is not true at all! That's because all JavaScript is valid, runnable TypeScript. Just run the TypeScript compiler on your code, and you have a linter that will catch some bugs and give you some hints in your IDE/text editor. This is already a great value, before you even change anything about the way you code.

In fact, this fundamentally means it can't be a waste of time because it doesn't require you to spend any time at all.

I genuinely don't find them more readable in most cases.

I would agree that the file without type annotations is more pleasant to read on its own (though I think at least some of the annotations could be inferred and so omitted). However, I am very very thankful for type annotations when I am opening up my 30th file today and don't have time to scour every line. While it might look like clutter while you're dissecting it, a) you have to do a whole lot less dissecting when you have types, and b) I don't spend time dissecting code all that often, I jump into something, get information, and move on. Types are a big part of that information.

And if clutter is a problem, this is an easily solved problem in your IDE -- just make it hide or make faint any type annotations that don't appear in JavaScript.

Typed JS is still... untyped.

The representation of values isn't relevant to types. C/C++ specify almost nothing about representation, and totally distinct types can be represented the same way.

Types are entirely about making static judgements from code. TypeScript lets you know things about your code before you run it. Sure, TypeScript isn't sound, but neither is Java. However, if you are frequently hitting problems because of unsoundness, that is a separate issue that would require a lot more details.

Collapse
vimmer9 profile image
Damir Franusic

No disrespect to you or Typescript, it is a good idea which should lower the number of errors and fight undefined behaviour. I still don't really like that full stack hype and although I have a history of doing quite complex stuff in React and Node, I still prefer php and mysql as a backend system. All this constant changes, patches and updates have led me to quit the UI dev and go back to low level C, statically typed, compiled and dangerous language hehe 😉. I understand the progress and updates are necessary but I feel that something if fundamentally wrong, UIs require too much power to run; the only step in the right direction is not Typescript or Flow, but WebAssembly.

Many developers these days will probably dislike this comment, but for someone who started programming 20 years ago, I consider myself capable of objectively describing the progression of technology.

What is still mind boggling is that we have so many(too many) programming languages to choose from for all projects other than Web UI. For this very reason, I am an advocate of WebAssemnly because if nothing else, we will at least be given an option to use something other than JS for Web client UI.

P.S.
I know there's a myriad of Web scripting languages out there, but in the end, all of them are just transpiled to JS 😒

Collapse
vimmer9 profile image
Damir Franusic

The everlasting problem of proper documentation. Totally agree. You should try Linux kernel stuff or syscalls, memory mapping, etc. It's all great but for the love of Open Source, somebody please keep the documentation up to date. I spent two days trying to find a bug in my own code when I finally realised that the issue was poorly documented sctp function. I looked around on mailing lists and all I could find was a single post complaining about the same problem. The final conclusion of that thread was that the man pages should be updated. Great, and who is going to do that and when? Anyway, I forked it, did it myself and created a pull request which was approved like instantly 😁

Collapse
ms_35 profile image
ms

Typescript is not a panacea, it's just an extra tool in your toolbox. It's not meant to prevent all problems, just a specific subset of them. Think of it like syntax highlighting in your editor: no one is saying it'll make or break your project or that it's more important than code quality broadly speaking, it's just helpful.

I use Typescript for two main purposes:

  • Declare programmatically that I will never do something and rely on the computer to tell me when I do ("I will always pass an object that has a foo function that returns a string"). This is similar to linting and relies almost entirely on what you want to enforce. You can easily tell TS to leave you alone with any or you can be ultra specific { bla: (a: int, b (c: string) => boolean) => void }
  • Explore complex APIs more easily with auto-completion and type checking. The Apollo example is actually pretty good: Apollo tools have approximately 700 different options, with different types, etc. Not having to jump back to the documentation (or the source code itself) to know that it's addTypename and not includeTypename and that it's just a boolean and not a function is very helpful

I don't think you need to be at a large organization to get these benefits: you're always working with a gigantic codebase, either the browser or Node and probably at least one framework. You're also working with at least one of the most forgetful and error prone developer: yourself.

This article is very helpful about what exactly TS can help you with: css-tricks.com/types-or-tests-why-...

Collapse
catchen profile image
Cat Chen

I worked at Facebook and I focused on driving down production uncaught error for a while. I would say Flow helped prevent a lot of potential error throwing code from being checked in.

All engineers in Facebook are full stack. That means many of them don’t know much about JavaScript but need to write JavaScript. When thousands of engineers from different teams writing JavaScript in a single repo and all the code interact with each other, bad things happen.

For example, one engineer calling function X expects it to accept nullable argument. He checks X’s implementation and it looks like so. He doesn’t filter out null when passing the argument. Everything works in his dev environment. In production, some branch in X calls function Y and some branch in Y calls function Z. Z doesn’t accept null but the argument is passed all the way from X to Z. A production error is thrown.

Why didn’t anybody realize this before the code was pushed to production? Because the authors of function X, Y and Z are all different engineers. The functions are in different files. The authors are from different teams. They never talk to each other. They happened to find a function in the codebase and it looked like the function can fulfill their need, so they called someone else’s function without checking thoroughly.

Flow helped a lot when you need to reuse someone else’s undocumented code as a blackbox. At least it’s a more reliable blackbox now. If you are building your own project and you only depend on well documented libraries, you might not have the problem Flow aims to solve.

Collapse
dinsmoredesign profile image
Derek D

The biggest benefit of using a statically typed language is runtime type checks. Sending data to a server and it throwing an error because you forgot to change your string to a number is awesome. No extra boilerplate to cast a type to something you can work with is great, you enforce your users to send the correct data and if that data changes, you instantly know where the problem is.

TypeScript can't do this. TS only checks types at compile time. This can be useful during development in some cases, but I really question the skills of a developer who's constantly creating type errors in development, where you'd have to rely on a compiler to tell you your mishaps.

I would absolutely use TS if it had runtime checks, but without them, I find coding in TS verbose for very little payoff.

Collapse
stereobooster profile image
stereobooster

The biggest benefit of using a statically typed language is runtime type checks.

Read it outloud. Runtime checks e.g. dynamic type checking.

const validate (x) => {
  const i = parseFloat(x);
  return !isNaN(i);
}

Dynamic type checks are possible in dynamically typed languages.

Collapse
cubiclebuddha profile image
Cubicle Buddha

It does if you use ts-io

Collapse
bergermarko profile image
Marko Berger

Typescript is what JavaScript should have been.
I have been coding in Ts for 2.5 years. Just love it . It prevents (in some extent) junior developers to do stupid things.
Can't wait for Deno to become production ready.

Collapse
stojakovic99 profile image
Nikola Stojaković

Exactly. My current project is small e-commerce system and who knows how longer it would take me if I had to write everything in plain JS and how much more code I would have to use to validate input instead of just using class-validator.

Collapse
yawaramin profile image
Yawar Amin

The Apollo Context code you cited is not exactly a shining example of clear and idiomatic TypeScript code (exported function return types should be annotated, and the defined interface type contains lots of object and any), however I would argue that it's still easier to read than the JS version. If you read the JavaScript version, can you tell at a glance what the context value contains and what you can do with it? It's dead simple in the TypeScript version.

Collapse
absohabsoh profile image
Nathanael Bennett

I just find enums, and in certain cases, interfaces, to be very helpful. For a large codebase, the value of being able to glance at code and understand what it does is very helpful. It's even more helpful because of the dynamically typed nature of Javascript. ONE + ONE could equal 2, or it could equal "11", or it could be undefined, or cause an error.

We're in the day and age where your IDE is your best weapon for producing quality code, and TypeScript keeps your JS IDE experience first class.

Collapse
merott profile image
Merott Movahedi

I always recommend using TypeScript with strict mode on, while avoiding any at all costs. There will be cases where using any is unavoidable but even that can be kept under control with an extra layer of abstraction.

Once you do that, TypeScript will speed up your development multifold because you no longer have to worry about and fiddle around with silly errors. It also makes a lot of unit tests redundant.

Once you start to use any in your project, it becomes a waste of time. You might as well drop TypeScript and go with plain JS.

Collapse
nikpoltoratsky profile image
Nikita

from my point of view, the most beneficial parts of the typescript are following:

  1. Codebase research. Just imagine, you've been assigned to the project with 1 million lines of code. How much time it’ll take you to understand properly how it works without types?
  2. Code navigation. Again, if you have a large codebase, static typing simplifies codebase navigation.
  3. Refactoring. How hard is it to rename a number of variables without static typing?

Also, I want to mention that plain js without types is a good decision for a small project you’ll forget in a week about. While typescript can save you a lot of time in a long run.

Collapse
patrickjh profile image
patrickjh

The key question is rather a 15% reduction in bugs is worth the time investment to implement typescript.

According to several sources I've seen (link for one at bottom), typescript and some other static typing systems achieve a 15% reduction in bugs.

Some math:

I have commonly read that software systems have 1.5 - 5.0 bugs per 100 lines of code.

This means a 1,000 line of code "small project" has roughly 15 - 50 bugs that need to be found. There are various methods for finding bugs, static type systems being only one way.

Mathematically finding 15% of bugs on a 1,000 line of code project means finding roughly 3 - 8 bugs.

In a vacuum this is good - until you factor in that there are alternative methods of finding the same bugs that take much less developer time than using typescript.

According to statistics in Code Complete by steve mcconnell, something as simple as personal desk checking of code catches between 20% and 60% of bugs in software. In fact, in comparison to most of the techniques presented in that book, a 15% reduction in bugs is mathematically one of the least effective methods. Code review, unit testing, beta testing and other methods all have higher percentages of bugs caught. Many of these methods take significantly less development time than using typescript, and end up catching the same bugs typescript would catch.

So on a small project of 1,000 lines my verdict is that typescript is not worth it.

However, that does not hold true once you consider larger projects. A project with 1,000,000 lines of code would statistically have between 15,000 and 50,000 bugs. On such a massive project with an equally massive team typescript would undoubtedly catch enough bugs to be helpful.

So the question is - where is the cutoff. I would argue - unscientifically - that a good rule of thumb is ~ 50,000 lines of code or 5+ coders on a team. Above this level the communication and bug catching benefits start outweighing the implementation costs. Below this level using a combination of other software quality practices (code review, unit tests, beta testing etc.) Will be able to catch most of the same bugs while being more efficient with developer time.

Just my preliminary thoughts, would be interested to hear other arguments.

google.com/amp/s/blog.acolyer.org/...

Collapse
cubiclebuddha profile image
Cubicle Buddha

Your citation (Gao et al., ICSE 2017) doesn’t consider if the repositories studied had code reviews / desk reviews. So the 15% bug saving might be after code reviews. That’s just one of many ways that particular study has been incorrectly applied. The study authors themselves point out that there are other benefits besides bug reduction.

That being said, I really appreciate that you analyzed the data and took a measured approach. That’s much better than this article we’re commenting on which by the authors own words is subjective. But hey, if people don’t like a specific tool, they don’t have to use it. But screws are hard to install with a wrench.

Collapse
patrickjh profile image
patrickjh

Thank you for your thoughtful response.