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>({});}

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({});}

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?

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!