17 Compelling Reasons To Start Ditching TypeScript Now.

TL;DR

TypeScript is mid. Use Rust or C# for example if you wanna go 100% strict. Otherwise, stick to JavaScript + JSDOC + some tooling.

TypeScript has gained immense popularity as a reliable tool for developing complex applications. However, some developers have expressed their dissatisfaction with the language due to its tedious and annoying nature. This article aims to delve into the challenges of using TypeScript that can potentially complicate your projects unnecessarily. A significant downside is its time-consuming setup process which may lead to frustration among users. Furthermore, its strict type system often leads to lengthy development times and unwarranted errors cropping up frequently during coding sessions.

While there are benefits associated with TypeScript usage, it's crucial to weigh them against potential drawbacks before deciding whether or not you should use it for your next project. This piece aims to provide insights into these downsides so that you can make an informed decision about choosing the right language for your upcoming projects without any confusion or hesitation whatsoever!

But before going over its drawbacks, let's start with a gentle high overview of the language.

🆕 Update:

The creator of Svelte recently had a discussion with ThePrimeagen, which can be found in this video on youtube, where he made an impressive case for why Typescript may not be necessary. He explained how everything that Typescript offers can also be achieved using JS and JSDOC. This is significant news for developers like us who have been relying heavily on Typescript until now.

This discussion offers a new outlook on the dilemma of whether to employ pure Javascript or switch over to TypeScript for software development. The beauty lies in the fact that developers have complete autonomy and can choose based on their preferences, as both options offer error-checking capabilities through JSDoc without necessarily requiring TypeScript adoption.

This update brings about a fresh perspective regarding whether one should use plain Javascript or opt-in with TypeScript when developing software applications. Developers are free to choose between either option since they will still benefit from having their codes checked against errors by utilizing JSDoc instead of TypeScript.

👉 Table Of Contents (TOC).

• What is Typescript?
• Why Do We Have TypeScript?
• Should I use It?
• Issues With Typescript.
  • 1. The Learning Curve.
  • 2. Strict Type Checking System.
  • 3. Verbosity And Lack of Readability.
  • 4. Lack Of Intuitive Syntax.
  • 5. Lack of Compatibility.
  • 6. Low Productivity.
  • 7. False Promises.
  • 8. Lack of Flexibility.
  • 9. Giant Corporation Abuse.
  • 10. Clever Devs Abuse.
  • 11. Not A JS Superset.
  • 12. Slower Compile Time.
  • 13. Additional Transpilation Step.
  • 14. Lack of Performance.
  • 15. Writing Unit Tests.
  • 16. Types Are Not That Useful.
  • 17. Heavier Tech Debt.
• TypeScript Alternatives.
  • 1. JSDoc.
  • 2. Flow.
• Which One Should You Choose?
• What's next for Javascript?
• Conclusion.
• Bonus.
• References.

What is Typescript?

TypeScript, an open-source programming language created and maintained by Microsoft, is commonly referred to as "JavaScript that scales" due to its object-oriented nature. Although some may argue it's a superset of JavaScript because of the added typing feature, I personally disagree with this notion. To illustrate the contrast between these two languages better, consider this straightforward code snippet:

// JavaScript
let name = "World!"
console.log(`Hello, ${name}`)

// TypeScript
let name: string =  "World!"
// Or simply
// let name =  "World!"
console.log(`Hello, ${name}`)

Absolutely right! There's no difference between the two languages. TypeScript is a programming language that compiles statically and enables the development of comprehensible JavaScript code without strict typing requirements. It performs identical tasks to JavaScript and can be effortlessly utilized in both client-side and server-side applications. Additionally, any current JavaScript application will integrate seamlessly with TypeScript for an effortless transition experience.

The introduction of Typescript has brought a new level of ease and security to web development with its advanced typing system. However, the reality is that it falls short of delivering what it promises. Learning this language can be quite challenging as there are many complexities involved which may cause frustration for even seasoned developers who find themselves grappling with its complexities [0].

Why Do We Have TypeScript?

🔝 Go To TOC.

Perhaps you're wondering, "What's the point? I could just use JavaScript." However, there is a compelling reason to type your variables: it allows for error detection during compilation rather than runtime. Consider this scenario - if you attempt to combine a string and number and save the outcome as a numeral value, an error of type will arise.

let x: number = 1;
let y: string = "2";
let z: number = x + y; // output: Type 'string' is not assignable to type 'number'.ts(2322)

However, if you were to try this in JavaScript, the code would run without any errors:

let x = 1;
let y = "2";
let z = x + y; // output: 12

It's evident that utilizing types can help in detecting errors at an early stage of development. TypeScript provides the option to include static types, which enables us to be more precise about our code and identify any possible problems. Consequently, this facilitates team collaboration and minimizes debugging time considerably.

However, there are still some situations where it falls. For instance, consider the following code snippet:

function push( arr : Array<string | number> ) {
    arr.push(99);
}
let foo : Array<string> = ['foo'];
push(foo);

Even though we are appending a new string to an array, the TypeScript compiler fails to recognize the mismatch in data types and approves the code without any errors. This can potentially cause complications as it becomes challenging to detect type-related problems that may lead to runtime errors.

Despite my initial skepticism towards object-oriented programming, I have come to appreciate how valuable TypeScript is for those who prefer strong typing when working with objects. By utilizing the capabilities of its compiler, developers can create code that incorporates all aspects associated with OOP principles - something that JavaScript cannot provide on its own.

However, this doesn't mean you should automatically adopt TypeScript for every project you work on. As noted by their documentation [1], only a handful of companies possess resources comparable in size and scope as Microsoft's development team; therefore if your project requires significant scale or complexity then using Typescript might make sense but otherwise sticking solely with plain old Javascript would suffice even if starting out new at programming altogether!

Should I use It?

🔝 Go To TOC.

The question at hand is whether TypeScript would be a fitting choice for your upcoming project. The answer can be found in its attributes. As previously mentioned, TypeScript offers the convenience of static typing, classes and interfaces that could significantly enhance productivity while developing extensive applications.

In my opinion, opting for TypeScript when collaborating on a project of medium to large scale with numerous developers could potentially yield positive results. However, it is important to note that this may not always hold true. The advantages associated with utilizing TypeScript are as follows:

• Static Typing: This is a pretty straightforward one. It means you can catch errors at compile time before your code even runs. This makes code more predictable and easier to debug. But, as we saw previously, it is not always the case

• Type Inference: TypeScript can often infer the types of variables, which means you don't have to declare them explicitly. This can make your code more concise and easier to read. However, this also can be achieved with JavaScript and JSDoc.

• IntelliSense: This is a feature of Visual Studio Code that provides autocomplete suggestions based on the types of variables. This can, again, make your code easier to write and less error-prone. However, IntelliSense is not tidily coupled to TypeScript but is also supported in JavaScript [2].

In summary, our code is now more precise, thoroughly documented, and robust with superior quality. Nevertheless, upon implementation, you may discover that your code is less readable along with other concerns which we will delve into shortly. Therefore, before incorporating TypeScript in your project it's imperative to thoughtfully evaluate if its suitability aligns with the goals of your project.

Issues With Typescript.

In the upcoming sections, we shall delve into a compilation of reasons why I have been increasingly abandoning Typescript. Despite its strength as a programming language, there are significant limitations that compel me to revert back to JavaScript with greater frequency.

1. The Learning Curve.

🔝 Go To TOC.

Learning Typescript can be a challenging and time-intensive process. To effectively use this language, one must possess proficiency in both JavaScript and type systems. This requires investing significant effort into comprehending the complexities of these structures as well as their interaction with JavaScript code. Even seasoned developers may struggle to grasp such concepts, making it an enormous obstacle for any fresh development endeavor.

Furthermore, Typescript presents some peculiarities that may pose challenges in implementation. Even seasoned developers cannot deny the fact that training oneself with this programming language can be a time-intensive endeavor. Teams must allocate significant resources towards training to ensure everyone is well-versed on current updates and optimal techniques. This could also prove problematic when attempting to comprehend pre-existing codebases written primarily in Typescript.

In short, the learning curve associated with Typescript can be quite steep and require significant time and effort to master.

2. Strict Type Checking System.

🔝 Go To TOC.

Another issue is that Typescript's type-checking system can often be overly strict and difficult to work with. This strict approach can lead to extra work and debugging time when dealing with complex types or features that don't fit into the type system cleanly. This extra effort can add up quickly over time and ultimately slow down development cycles.

The following implementation of a type-only bubble sort, utilizing an arithmetic utility type, is excessively rigid and poses challenges in terms of practicality [3]. While the comparator type may seem clever at first glance, it actually obscures some conditionals which can complicate debugging and maintenance. As such, this code proves to be especially challenging for beginners as they must possess a thorough comprehension of types and their respective functions.

type Test1 = BubbleSort<[1, 4, 1, 3, 2]>
//   ^?
type Test2 = BubbleSort<[4, 2, 1, 8, 5]>
//   ^?
type Test3 = BubbleSort<[-1, -9, 999, 50]>
//   ^?


//// ----------------BUBBLE SORT----------------

type BubbleSort<N extends number[]> =
  BubbleSortPass<N> extends Is<infer OnePass, number[]>
    ? BubbleSortPass<OnePass> extends BubbleSortPass<N>
      ? BubbleSortPass<N>
      : BubbleSort<OnePass>
    : never

type BubbleSortPass<N extends number[]> =
  N extends [Is<infer First, number>, Is<infer Second, number>, ...infer Rest]
    ? Rest extends number[]
      ? Rest extends []
        ? LessThan<First, Second> extends true
          ? [First, Second]
          : [Second, First]
        : LessThan<First, Second> extends true
          ? [First, ...BubbleSortPass<[Second, ...Rest]>]
          : [Second, ...BubbleSortPass<[First, ...Rest]>]
      : never
    : never



//// ---------------UTILITY TYPES---------------

type LessThan<A extends number, B extends number> = 
  IsPositive<A> extends true
    ? IsPositive<B> extends true
      ? A extends 0
        ? B extends 0
          ? false
          : true
        : B extends 0
          ? false
          : LessThan<Subtract<A, 1>, Subtract<B, 1>>
      : false
    : IsPositive<B> extends true
      ? true
      : `${A}` extends `-${infer PosAStr}`
        ? `${B}` extends `-${infer PosBStr}`
          ? StringToNumber<PosAStr> extends Is<infer PositiveA, number>
            ? StringToNumber<PosBStr> extends Is<infer PositiveB, number>
              ? LessThan<PositiveB, PositiveA>
              : never
            : never
          : never
        : never

type Is<T extends U, U> = T;

type Add<A extends number, B extends number> = StrictTupleLength<
  [...TupleOfLength<0, A>, ...TupleOfLength<0, B>]
>;

type Subtract<A extends number, B extends number> = 
  TupleOfLength<0, A> extends [...TupleOfLength<0, B>, ...infer Result]
    ? Result['length']
    : never;

type IsPositive<N extends number> = 
  `${N}` extends `-${number}` ? false : true;

// https://stackoverflow.com/a/70526775/16121252
type StringToNumber<T extends string, A extends any[] = []> =
  T extends keyof [0, ...A] ? A['length'] : StringToNumber<T, [0, ...A]>


/// Types the utilities rely on

type StrictTupleLength<T> = T extends { length: Is<infer L, number> }
  ? L
  : never

type TupleOfLength<
  T,
  L extends number,
  R extends T[] = [],
> = R['length'] extends L ? R : TupleOfLength<T, L, [...R, T]>;

3. Verbosity And Lack Of Readability.

🔝 Go To TOC.

As I started my journey with Typescript, I first noticed how verbose the language was. It requires a lot of extra typing compared to JavaScript. This can be attributed to the rigid syntax and the numerous rules one must remember. This can be quite frustrating for those who are used to writing code quickly and efficiently in other languages.

The excessive verbosity of Typescript may pose a challenge when attempting to comprehend the language and troubleshoot code. This is due to the complexity involved in keeping track of various components within your program.

The language supposed to bring readability and clarity to the codebase obscures it instead. The code below is an example of documented TypeScript, which is incredibly bloated. This makes the code difficult to read and understand, which is one of the main arguments against using TypeScript.

class Rectangle {

  width: number
  length: number

  /**
   * Create a Rectangle instance.
   *
   * @param width - The width of the rectangle.
   * @param [length] - The length of the rectangle.
   */
  constructor(width: number, length: number = 20) {
    this.width = width
    this.length = length
  }

  /**
   * Calculate the area of a rectangle.
   *
   * @returns - The area of a rectangle.
   *
   * @example Correct usage.
   *
   * // Returns 200
   * calcArea(10, 20);
   *
   */
  calcArea(): number {
    return this.width * this.length
  }
}

You'd have to add so many type annotations along with your code. Seriously, just use JavaScript. It's faster and simpler, and you don't have to worry about all that type of stuff as they are presented through JSDoc.

class Rectangle {
  width
  length

  /**
   * Create a Rectangle instance.
   *
   * @param {number} width - The width of the rectangle.
   * @param {number} [length] - The length of the rectangle.
   */
  constructor(width, length = 20) {
    this.width = width
    this.length = length
  }

  /**
   * Calculate the area of a rectangle.
   *
   * @returns {number} - The area of a rectangle.
   *
   * @example Correct usage.
   *
   * // Returns 200
   * calcArea(10, 20);
   *
   */
  calcArea() {
    return this.width * this.length
  }
}
const rectangle = new Rectangle("10")

This example demonstrates that you can also achieve static type checking using only JS and JSDoc and enabling CheckJS in File > Preferences > Settings > search for "CheckJS" in VS Code. If you consider looking at the official core TypeScript codebase, you will notice an excessive amount of TSDoc comments used throughout the codebase. This shows that you should avoid using TypeScript whenever possible and rather stick to Javascript with JSDoc.

4. Lack Of Intuitive Syntax.

🔝 Go To TOC.

For those new to programming, understanding Typescript syntax can be challenging. The language uses conventions that may not be familiar to developers coming from other languages, making it difficult for them to read and comprehend the code.

Even after becoming comfortable with the language's syntax, beginners may still find errors hard to decipher due to its strict rules and conventions. For instance, variables must have a type declaration while each parameter in a function requires an assigned type - failing which will result in confusing error messages.

However daunting this might seem at first glance; patience is key when learning as these limitations can only be overcome by sticking with it. Despite all of this complexity though: remember that Typescript remains one of the most powerful tools available today for writing cleaner more efficient code- just give yourself time!

5. Lack of Compatibility.

🔝 Go To TOC.

Although TypeScript can be a valuable asset, it may not always integrate seamlessly with other tools. In my experience, I created a Lambda function for NodeJs and the project manager requested to edit it using AWS online editor. However, utilizing TypeScript would have necessitated transpilation which rendered this task unfeasible. This was unacceptable for the project manager's requirements; thus forcing me to revert back to traditional JavaScript code instead of TypeScript implementation.

Incorporating TypeScript into existing technologies or frameworks can present difficulties. If you're working with an outdated system that doesn't accommodate this language, manually converting your code to JavaScript becomes a requisite and time-intensive task. This scenario may prove complicated if you aren't proficient in the nuances of both languages, rendering it harsh as well.

So, don't assume that TypeScript will fit seamlessly into your existing workflow; Do your research and ensure that it will actually work with the tools you're using or you risk wasting valuable time and resources.

6. Low Productivity.

🔝 Go To TOC.

While coding in Typescript, one may experience a slower and more brutal process compared to the smoother flow of languages such as JavaScript or Python. This can be particularly annoying for developers who are used to quick and effective work with other programming tools - myself included.

When you are trying to rapidly prototype something during a Hackathon, the last thing you want is to deal with the extra overhead of Typescript. This can often lead to frustration and wasted time as you try to work around the limitations of the language.

Over time, Typescript can be quite frustrating, especially compared to other more rapid development languages. If you are looking to build something quickly, you would be better off using our beloved language, Javascript.

However, the question now is: what about the bugs in production? Typescript catches type bugs that would otherwise end up in production. But why is it common among Devs who are overconfident in their ability to write bug-free code?

7. False Promises.

🔝 Go To TOC.

In all honesty, TypeScript doesn't quite resonate with me as it seems to promise a one-size-fits-all solution for any JavaScript-related issue. It's attempting to surpass Javascript and become the primary language of choice in web development- an idea that I'm not particularly fond of. Personally, I prefer sticking with good old-fashioned Javascript without having everything altered by TypeScript's interference.

Although some may argue that the absence of typing in JS poses an issue, TS does not provide a solution. However, compiled languages such as Java, Rust, C, and C# have the ability to ensure strong typing both at compile time and runtime which is impossible for interpreted languages to achieve.

Some time ago, Deno - a javascript runtime that utilizes the V8 engine, Rust, and Tokio - narrated their experience with Typescript. They discovered it to be adding unnecessary complexity to the system, and make it slow. In their report, they offered an example that illustrated how difficult it was for them to gain insight due to the complexity of generating runtime code; this is contrary to what Typescript promises in terms of helping developers organize their codes. While there may be instances where such claims hold true, on other occasions its implementation can have negative effects instead.

8. Lack of Flexibility.

🔝 Go To TOC.

Typescript was developed to enhance the accessibility of JavaScript, and its popularity has surged in recent years. However, it comes with certain limitations that restrict developers from fully exploring the language's capabilities. In fact, TypeScript aims to shorten some of JavaScript's strengths while providing a false sense of security which can be detrimental for programmers who cannot utilize or experiment with all aspects of this powerful language as per their needs and desires.

Developers need to understand that this lack of flexibility does not make them better developers; indeed, it may even slow their development process and lead them away from truly understanding how JavaScript works and how to use it effectively. Having limited capabilities can potentially lead to the inability to utilize the full potential of JavaScript. If you want to become a great developer, you need to understand the true power behind JavaScript and all its features rather than settle for a lie from Typescript.

To truly excel as a developer, settling for a language that suppresses your creativity and hides its full potential is simply not an option. Embrace the versatility of JavaScript to unleash your true capabilities in coding. Only then can you reach new heights and become the great developer you aspire to be.

9. Giant Corporation Abuse.

🔝 Go To TOC.

Microsoft, a global giant in the tech industry, backs Typescript. As such, they have an inherent desire to promote their own interests and encourage developers to adopt their technology. Their marketing strategy for Typescript positions it as the ultimate language for JavaScript development - a claim that has been met with skepticism from some developer communities who view this approach as manipulative and limiting choice.

In addition, the support of major corporations can establish a setting that compels developers to comply with and adopt Microsoft's technology. This may slow innovation and result in an approach where coding solutions are limited to one standardized option. Ideally, developers should have access to various alternatives tailored to their specific requirements instead of being forced into utilizing products endorsed by corporate giants.

Microsoft's approach can lead to confusion among developers who may not be fully aware of the nuances of Typescript or its superiority over other programming languages such as JavaScript. Companies like Microsoft must provide precise information about their product in order to prevent any confusion or misinterpretation that could slow a developer from making an informed decision on what language would best suit their needs.

If you don't know yet, Microsoft has a long history of being an anti-open source and anti-Linux. In 2001, their CEO Steve Ballmer declared Linux a "cancer" [4]. The company sponsored SCO's copyright attack on Linux and claimed that Linux violated unnamed Microsoft patents. Microsoft also forced Linux-based Android vendors to pay for questionable patent claims.

One of Microsoft's biggest issues today is its involvement with Typescript. While the company has been trying to make success in recent years to improve its relationship with the open-source community, its history still casts a long shadow.

So, even though Typescript is a powerful programming language, it's important to note that a historically bad corporation backs it.

10. Clever Devs Abuse.

🔝 Go To TOC.

The issue with clever developers using Typescript is that they unnecessarily over-complicate the code. This leads to several problems, making code difficult to read, maintain, and debug. Additionally, it can cause issues with scalability and performance.

When clever developers use Typescript, they tend to prioritize crafting complex and convoluted code over producing efficient and impactful one. This may result in a significant amount of time being wasted on debugging and troubleshooting issues that could have been preemptively addressed.

Furthermore, clever developers may prioritize their own pride over the product itself. They may be too focused on creating complex solutions when simpler ones are available. This can lead to solutions that don't actually make the product better for users or customers.

It is crucial for developers to keep in mind that client/customer satisfaction should always be the ultimate objective. Any solution that fails to enhance the product or simplify user experience is not worth investing time and effort into. Instead of solely striving for personal gratification through their code, clever developers must concentrate on crafting solutions geared towards improving overall client/customer experience.

Let's all agree that just because "clever developers" use something doesn't mean it's a good tool. But if so many big open-source projects have moved to TS and told me that it made their development easier, I'll trust them, especially because it made mine much easier and less stressful.

11. Not A JS Superset.

🔝 Go To TOC.

One of the key selling points of Typescript is that it is a superset of javascript, meaning that every JavaScript program is a valid TypeScript program. However, in practice, this has not always been the case. And TypeScript is neither a subset nor a superset of JavaScript.

For example, a valid piece of JavaScript code may not be valid TypeScript code, such as the following:

let foo = {};
foo.bar = 42;

12. Slower Compile Time.

🔝 Go To TOC.

One of the main challenges encountered while using Typescript is its slower compilation time, which becomes more evident when working on a large codebase. The TypeScript compiler lacks efficiency in optimizing codes compared to other compilers resulting in longer completion times for compile tasks. Consequently, this may lead to increased file sizes and prolonged waiting periods as one waits for the compiler's job to finish [5].

The primary reason for the delay in compiling is attributed to Typescript's statically-typed characteristic. This implies that the compiler has a more extensive workload compared to its counterpart for dynamically-typed languages such as JavaScript, resulting in prolonged compilation durations. Furthermore, unlike Babel, TypeScript's compiler lacks access to similar optimization tools which worsens this issue and ultimately hinders our productivity.

The process of compiling typescript code can be a tedious and time-consuming task, particularly when dealing with extensive projects. Deno maintainers have acknowledged that modifying files in cli/js leads to an incremental increase in compile duration which takes minutes, causing significant frustration [6]. As someone who has recently adopted this language, I can vow to the annoyance experienced while waiting for even minor changes to complete the compilation before repeating the cycle again. This is not only a main waste of time but also incredibly annoying.

While I acknowledge that TypeScript may appeal to those who prioritize type safety, personally, I believe the potential loss in productivity outweighs its benefits. Furthermore, similar results can be achieved through JSDoc and certain configurations on VSCode.

13. Additional Transpilation Step.

🔝 Go To TOC.

This issue is somewhat related to the previous one. As a JavaScript developer, you're probably used to transpiling your code with Babel. TypeScript introduces an additional transpilation step which can, unfortunately, introduce a bottleneck regarding development speed. It's true that the compiler can spot flaws and flag them before they can cause any damage, but this comes at the cost of having to wait for the entire codebase to be transpiled each time. This can be particularly frustrating for larger projects, where the compilation time can quickly add up.

Moreover, the TypeScript compiler has a tendency to produce code that can be perplexing or challenging to comprehend. This is due to its endeavor of ensuring type-safety in your code, which may lead to lengthier and more intricate variable names at times. While this approach isn't always unfavorable, it could pose difficulties for novice developers who haven't yet grasped the norms of TypeScript's syntax.

14. Lack of Performance.

🔝 Go To TOC.

In case you are writing in TypeScript, it is possible that your program's execution speed might be slower than anticipated. This could be attributed to the fact that the organization and structure of TypeScript is a subject of a performance cost during runtime.

By utilizing TypeScript, you are instructing the compiler to structure your code in a particular manner. However, this organization may lead to runtime performance issues. For instance, if you possess an extensive collection of objects, TypeScript will potentially generate a distinct variable for each object within that array. As such, whenever you access any of these objects individually later on during execution time requires searching through memory for its corresponding variable - resulting in significant overhead and suboptimal application performance overall.

15. Writing Unit Tests.

🔝 Go To TOC.

Writing unit tests in TypeScript can be a daunting task that demands precision. Unlike JavaScript, where passing an object with the appropriate properties suffices for testing purposes, TypeScript necessitates defining the type of every property within the given object. This process is time-consuming and often frustrating for beginners who are just starting out. Therefore, I personally opt to use JavaScript instead when crafting my unit tests as it saves me valuable time and effort while still yielding effective results.

Taking more time to define the various types and properties tends to slow my overall productivity. Additionally, it also complicates debugging and refactoring processes considerably. To illustrate this point further, if I need to alter just one property of an object utilized in a test scenario, then I would have no choice but to go back and modify both the type definition as well as the code for that particular test case. This added step could be avoided entirely had I been writing tests using JavaScript instead.

I understand why TypeScript requires this level of precision; It helps add an extra layer of safety during development, but it can sometimes be incredibly tedious and frustrating. For this reason alone, I will continue to choose JavaScript over TypeScript when writing unit tests.

16. Types Are Not That Useful.

🔝 Go To TOC.

If you have a background in statically typed languages such as Java, it's natural to believe that types are always advantageous. However, when working with JavaScript, the opposite may be true - types can sometimes slow progress rather than ease it. This is because JavaScript is an incredibly dynamic language where flexibility reigns supreme and rigid type systems often fall short of expectations.

Although TypeScript's type system can be advantageous, it may not always be necessary for the majority of JavaScript applications. In fact, many applications do not require additional safety that types offer and implementing them could result in unnecessary complexity without any significant benefits. Hence, opting to use plain JavaScript while developing an application might prove to be a more practical choice overall.

Furthermore, while TypeScript does support type inference - where the compiler attempts to deduce variable types based on usage patterns - this feature is not always reliable. When unable to determine a specific data type for a given variable or object property during compilation time; any becomes its default value instead of providing accurate typing information as expected by developers who use Typescript which ultimately defeats the purpose of utilizing such technology from start-to-finish in your project workflow.

let a: string;
let b: number;
let c;
a = 'Hello World';
b = 5;
c = a + b;
console.log(c);

17. Heavier Tech Debt.

🔝 Go To TOC.

When it comes to tech debt, Typescript can be a major issue when a project's scope, tech stack, or architecture changes halfway through the process. The tech debt will increase as new features, and changes are added to the codebase. This can cause projects to become bogged down with tech debt that could have been avoided if an earlier assessment of the project scope and design plan had been conducted.

For example, suppose you decide to use Typescript for your project. You may think this language will be easier to maintain in the long run as it is more type-safe than other languages. However, halfway through the project, you realize that a different technology stack would be better suited for your particular project. You now have to go back and refactor all of your existing code from Typescript into the new technology stack, which can take considerably longer than if you had chosen the correct language from the beginning. As a result, you find yourself weighed down by tech debt that could have been easily avoided with proper planning at the start of your project.

However, you may argue that TypeScript is especially powerful when used in conjunction with other technologies. For example, Python and Go are two of the most commonly used general-purpose programming languages, while Bash is often used for smaller glue scripts. GNU Make is often misused as a project entry point (make run, make build, etc.).

I wouldn't say no to TypeScript, as this would force the always overworked operations team to write more quality code instead of fast hacks. But, at some point, this accumulated debt will reach critical mass, and it will be a long downtime just to write more fast hacks to get back up.

Therefore, it is important to assess your project scope and design plan thoroughly before deciding on which language to use to ensure that you do not end up with unnecessary tech debt further down the line.

For all the above reasons, type-only code is needlessly complicated to work with.

TypeScript Alternatives.

🔝 Go To TOC.

Ok, TypeScript is a fantastic tool/language, but it isn't the only one available to annotate your code. JSDoc is another option that Microsoft even uses in their core TypeScript code! So why argue over which tool to use? Let's choose what works best for our project.

But maybe you prefer not to use TypeScript or want to utilize JSDoc without compiling. No worries - there are plenty of options for type-checking and generating definitions in JavaScript. The top two contenders are Flow and JSDoc, with Flow being more popular yet less flexible than its counterpart alternative: JSDoc can be just as powerful when used correctly!

1. JSDoc.

🔝 Go To TOC.

JSDoc is a remarkable tool for documenting JavaScript that employs designated comments to generate documentation for your code. There are numerous compelling advantages of using JSDoc over TypeScript, which you may not be familiar with yet.

• JSDoc prevents the necessity of a compiler, thereby simplifying code writing for your project. Moreover, JSDoc is frequently more lightweight than its TypeScript equivalents which enables you to concentrate on enhancing features and functionality without being bogged down by complex syntax issues or type-checking concerns.

• JSDoc empowers you to prioritize the excellence and comprehensibility of your code. You can devote more attention towards perfecting its complexities and guaranteeing that it is accurately documented, without being affected by type checking or managing complex types. Moreover, JSDoc enables effortless integration of annotations into your codebase which clarifies each section's intended purpose - facilitating debugging and maintenance in the future with ease.

• Writing your tests in vanilla JS and counting on JSDoc to provide you with the necessary types is a feasible approach. This method simplifies writing tests for code that doesn't prioritize types but still necessitates dependability. The versatility of JSDocs allows effortless customization of test cases, unlike TypeScript's inflexible type system which restricts possibilities. With JSDocs, customizing or modifying existing test scenarios becomes hassle-free; thus making it easy to tailor your assessments for specific situations or edge cases beyond what can be tested using TypeScript alone - an added advantage worth considering!

• TypeScript requires annotations for documentation generation, which implies that JS/TSDocs is still a requisite. The difference in the amount of typing required between vanilla JSDoc and TypeScript + lightweight JSDoc is negligible.

• One compelling reason to opt for JSDoc instead of TypeScript is its widespread IDE support. With JSDoc, you can avoid the need for extra dependencies and start documenting your code right away. Furthermore, this tool offers a robust documentation solution that goes beyond basic commenting features.

• While TypeScript is a newer language and has gained quite a bit of popularity in recent years, many developers, me included, still prefer to use JSDoc. While it does not have all of the features of TypeScript(~90% of TS features, in my opinion.), it is still a very useful tool for us as web developers.

• JSDoc is well established and the standard for JavaScript documentation. JSDoc is a widely accepted and adopted standard, making it much easier to find libraries that use JSDocs as opposed to TypeScript def files.

• If you have to compile TypeScript into JavaScript, why not just use JS? Seeing as the means for achieving what you require already subsist, those familiar with JavaScript outnumber significantly those who know about TypeScript; finding personnel is simpler, and conjoining with existent teams is easier.

• JSDoc adheres to the KISS principle by providing a simple yet powerful syntax that allows you to document your code briefly. With JSDoc, you can easily create documentation for your JavaScript code that's easy to read and understand.

As you can see, JSDoc offers so many advantages for writing hints for the IDE, and it would be wise for us as web developers to use it instead of TypeScript. It provides granular control over code, requires fewer steps when inserting a function name, and offers an independent standard that ensures everything functions properly.

Microsoft is promoting a narrative that TypeScript is the sole solution to resolve type problems, but this claim lacks validity. It's evident that Microsoft's motive behind such promotion arises from their financial gain rather than prioritizing developers' or users' needs and preferences.

To sum up, opting for JSDoc over TypeScript can prove advantageous in certain projects that don't necessarily demand type safety or when there are constraints on time and resources. Nevertheless, if your project involves complex logic or demands robust typing support, then TypeScript would still be the more cautious choice to guarantee meeting all requirements of your application.

2. Flow.

🔝 Go To TOC.

For those who aren't keen on utilizing TypeScript, Flow presents a good option. It functions as a static type checker for JavaScript and is capable of detecting errors in your code before execution. This feature holds immense power and can prevent numerous potential issues from arising.

Flow, like TypeScript, provides the capability of defining types for functions and variables. This feature can prove highly beneficial in sizeable projects where managing multiple types becomes a challenge. Additionally, Flow offers several unique features that are not present in TypeScript; one such example is its compatibility with React's propTypes.

The following are a few reasons why you might choose to use Flow over TypeScript:

• Ease of use: Flow is more forgiving than TypeScript; it serves as a softer introduction to static types in JavaScript. With Flow, you can get up and running quickly without having to learn all the details of type checking right away. Additionally, because Flow uses a per-file opt-in methodology rather than requiring users to specify types everywhere upfront (as TypeScript does), it may be easier to add Flow into an existing project that doesn't already use static types.

• With the backing of a massive corporation, Meta (previously known as Facebook) has crafted and maintained both React and Flow. As a result, these two resources integrate flawlessly with one another. The dedication that Meta shows towards maintaining these tools guarantees their ongoing support and enhancements - making them an optimal choice for us web developers who seek dependability in our work.

• Flow is a more streamlined option for project integration, as it requires no supplementary dependencies. Unlike other type checkers that generate additional files like .d.ts, Flow doesn't create any extra files. Consequently, the environmental impact of using Flow is significantly smaller, and its incorporation into projects is much simpler and straightforward.

So if speed, accuracy, and simplicity are important to you, Flow might be the right choice for your project.

Which One Should You Choose?

🔝 Go To TOC.

The ultimate choice is yours to make: which option aligns best with your requirements and objectives? Flow offers a more extensive set of capabilities, whereas JSDoc presents itself as an equally feasible alternative. Regardless of the decision taken, both alternatives offer some level of type-checking and code generation for JavaScript projects - rendering them valuable considerations when working on large projects.

What's next for Javascript?

🔝 Go To TOC.

Recently, there are new suggestions to modify javascript. Although some of these ideas possess merit, one proposal stands out as a potential threat that could fundamentally alter the language we have come to know and rely on, today.

Static typing is something that has been proposed for javascript before, but it never really gained much traction [7]. However, with the recent popularity of languages like TypeScript and Flow, it seems like more and more people are open to the idea of adding types to javascript.

Personally, I'm not a huge fan of static typing. It can make code more verbose and difficult to read. But more importantly, it could make javascript less flexible and less forgiving.

Right now, javascript is a language that is easy to learn and easy to use. It's forgiving of mistakes, and it's flexible enough to be used in a variety of ways. But if we start adding types to the language, all of that could change.

There is a possibility that Javascript may adopt strict guidelines and rules similar to Java. Although this could be acceptable for certain individuals, I believe it would eventually render the language less approachable for novices.

So while I'm not opposed to the idea of static typing in general, I think it could be a disaster for javascript if it becomes mandatory. Let's hope that doesn't happen.

Conclusion.

🔝 Go To TOC.

In conclusion, being a humble developer, I think TS is good, but it's not always necessary or suitable for all projects. You can achieve bugproof and readable code with JavaScript along with JSDoc with type definition plus a few config tweaks in VS without needing another compiler. Ultimately though, I think this depends on the team you work with and what sort of project you're dealing with; if you need to do things quickly and work with junior developers, then a codebase built on a strong foundation of TypeScript may be necessary to ensure quality. Still, other approaches may be more suitable if you have proper code reviews and knowledge-sharing culture.

What is the rationale behind choosing TypeScript instead of javascript? From my perspective, when it comes to crafting error-free and comprehensible code that can be effortlessly maintained, nothing beats javascript. Although TypeScript does provide certain advantages, I am convinced that they pale in comparison to those offered by its predecessor -javascript.

In my honest opinion, going from JavaScript to Typescript is like transitioning from PHP to C#. The core concepts remain the same. However, you are adding a layer of type safety and an additional compilation step.

In the end, it is entirely up to you whether or not you hate Typescript. Nevertheless, if your goal is to create maintainable code that will keep your application running smoothly for years to come, mastering this language can prove invaluable. So don't give up hope just yet; continue coding and stay humble in regard to your own skills!

Bonus.

🔝 Go To TOC.

A collection of examples where TypeScript code results in undefined behavior:

References.

🔝 Go To TOC.

[0] Ryan Carniato. The Trouble with TypeScript Ryan Carniato, dev.to, Retrieved 2022-12-28.

[1] typescriptlang.org. Why Create TypeScript, typescriptlang.org, Retrieved 2022-12-28.

[2] visualstudio.com. JavaScript IntelliSense, visualstudio.com, Retrieved 2022-12-28.

[3] typescriptlang.org. Type-only bubble sort in TypeScript, typescriptlang.org, Retrieved 2022-12-28.

[4] theregister.com. Ballmer: 'Linux is a cancer', theregister.com, Retrieved 2022-12-28.

[5] stackoverflow.com. Typescript compiling very slowly, stackoverflow.com, Retrieved 2022-12-28.

[6] docs.google.com. Design Doc: Use JavaScript instead of TypeScript for internal Deno Code
, docs.google.com, Retrieved 2022-12-28.

[7] tc39 on Github. ECMAScript proposal for type syntax that is erased - Stage 1, github.com, Retrieved 2023-01-01.