DEV Community

Cover image for 17 Compelling Reasons To Start Ditching TypeScript Now.
Mahmoud Harmouch
Mahmoud Harmouch

Posted on • Updated on

 

17 Compelling Reasons To Start Ditching TypeScript Now.

If you're anything like me, you're probably using Typescript because you were forced to. Your company decided that it would be the language of the future, so you were forced to learn it. At first, you were excited to use Typescript. You knew that it had a lot of potentials and would help you make more robust apps. But after using it for a while, You started to realize how annoying and frustrating it can be.

In this article, I am going to vent my frustrations with Typescript. I had just started using it, like one month in, and was struggling to get the hang of it. After using it for a while, I've realized that it's so bad, and there are things I don't like about it at all.

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

🀫 Pssst: This article caused outrageous chaos in the Matrix.

⚠️ Warning: Some of the points shared in this article are highly opinionated, while the majority are well-referenced facts.

πŸ“ Note: I believe that it is important to choose the right tool for the right job. I also believe that it is important to do your own research on this topic, and I appreciate you taking the time to carefully read my article. I hope that it will be helpful in one way or another. Enjoy!

πŸ‘‰ Table Of Contents (TOC).

What is Typescript?


TypeScript Logo.

Developed and maintained by Microsoft, TypeScript, also known as JavaScript that scales, is an object-oriented, open-source programming language. It's arguably considered a superset of JavaScript, which I'm afraid I disagree with, containing additional typing. Here is a simple snippet of code that demonstrates the difference between JavaScript and TypeScript:

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

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

And you guessed it right. There's no difference at all. So, TypeScript is a statically, not strongly, a compiled programming language for writing clear and concise JavaScript code. It fulfills the same purpose as JavaScript and can be used for client and server-side applications. In addition, a codebase written in JavaScript is also compatible with TypeScript, which is a good thing to have.

However, Typescript promises to make web development easier and safer than ever through its typing system. Unfortunately, it doesn't live up to its promises. Typescript is a difficult language to learn and often comes with an annoying learning curve. Even experienced developers find themselves struggling with this language [0].

Why Do We Have TypeScript?


Image by Gordon Johnson from Pixabay.

πŸ” Go To TOC.

You might be thinking, "Why would I want to do that? I can use JavaScript, instead." The reason is that, by typing your variables, you can catch errors at compile time instead of runtime. For example, if you try to add a string and a number and store the result as a number, you'll get a type error:

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

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
Enter fullscreen mode Exit fullscreen mode

As you can see, types can help you catch errors early on in the development process. By adding optional static types, TypeScript allows us to be more explicit about the code they are writing and identify potential issues quickly. This makes it easier for teams to collaborate and reduce time spent debugging code.

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

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

Even though we are pushing a number onto an array of strings, TypeScript doesn't recognize the type mismatch and type-checks the code successfully. This is problematic because it is not immediately obvious that there's a type mismatch, which can lead to runtime errors.

Despite my reservations about object-oriented programming, TypeScript might be an incredibly useful tool for OOP fans who need strong object typing. Using the TypeScript compiler, we can generate code with all the features and benefits of object-oriented programming. While JavaScript does not support strongly typed object-oriented programming principles, TypeScript does.

But this doesn't mean you should consider TypeScript for all your projects. As stated in their docs, not many companies are the size of Microsoft [1]. If you're working on a large-scale JavaScript project, TypeScript may be a good option. However, if you're starting with programming or working on a small project, you may be better off sticking with the usual plain good old JavaScript.

Should I use It?


Image by Dave M from Pixabay.

πŸ” Go To TOC.

Now the question is: Should you use TypeScript for your next project? And the answer lies in its features. As I stated previously, TypeScript provides optional static typing, classes, and interfaces, which can help you develop large-scale applications more effectively.

I would argue that working with TypeScript on a medium-large-sized project with multiple developers might be better, but sometimes it is not actually the case. The benefits of using TypeScript include the following:

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

Shortly put, we had a more specific, better documented, and more bulletproof code of higher quality. However, after using it for a while, you may find that it makes your code less readable, among many issues that we will go over in the next sections. As such, you should carefully consider whether or not TypeScript is right for your project before using it.

Issues With Typescript.


Most Disliked Aspects of TypeScript by State of JS.

In the following sections, we will explore a list of the things I started ditching Typescript more than ever. While Typescript is a powerful tool, it also has some major drawbacks that have led me to go back to JavaScript more frequently.

1. The Learning Curve.


A steep learning curve (Image by author).

πŸ” Go To TOC.

Typescript can be difficult and time-consuming to learn. You must become proficient in JavaScript and type systems to use Typescript effectively. This means you must invest time in understanding the intricacies of type systems and how you interact with JavaScript code. Even experienced developers can find this difficult to grasp, making it a huge barrier to entry for any new development project.

In addition, Typescript has some idiosyncrasies that can be difficult to work around. For experienced developers, there is still no denying that learning Typescript can be a time-consuming process. Teams must invest heavily in training to ensure that everyone is up-to-date on the most recent changes and best practices. This can also create a challenge when understanding existing code bases that utilize Typescript as its primary language.

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 stringent 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 example of a type-only bubble sort using an arithmetic utility type is overly strict and difficult to work with [3]. Although the comparator type is clever, it abstracts away a couple of the conditionals, making it hard to debug and maintain. This type of code is particularly difficult for beginners to grasp, as it requires a deep understanding of types and their behavior.

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]>;
Enter fullscreen mode Exit fullscreen mode

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 verbosity of Typescript can be quite a hindrance when trying to learn the language and debug code. This is because it can be difficult to keep track of all the different elements in your code.

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
  }
}
Enter fullscreen mode Exit fullscreen mode

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")
Enter fullscreen mode Exit fullscreen mode


Image by author.

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

Typescript syntax can be difficult to understand, especially for those new to programming. The language uses conventions unfamiliar to developers coming from other languages and can make it difficult to read and understand the code.

Even after you feel comfortable with the language's syntax, errors can still be difficult to decipher for beginners. This is because Typescript has very strict rules and conventions, so even if something looks valid, it may not be accepted by the compiler. For example, Typescript requires that variables are declared with a type and that each parameter in a function must have a type assigned. If these requirements are not met, you will receive an error message that can be confusing for those new to programming.

The only way to overcome these hurdles as a beginner is to be patient and stick with it. Don't get me wrong. Typescript is still a powerful language that will allow you to write cleaner, more efficient code, but it will take time to get used to the syntax and conventions.

5. Lack of Compatibility.

πŸ” Go To TOC.

TypeScript may seem like a great tool, but it does not always play nicely with other tools. For instance, I recently wrote a Lambda function for a NodeJs environment. The project manager wanted to be able to edit the function using the AWS online editor. Unfortunately, using TypeScript would have required transpilation, making this impossible. It was a deal breaker for the project manager, so I had to revert to regular JavaScript.

So, you will struggle using TypeScript when trying to integrate with existing technologies or frameworks. Suppose you're working with a legacy system that doesn't support TypeScript. In that case, you'll find yourself in a tricky situation where you must manually convert your code into JavaScript before it works properly. This can be time-consuming and tedious, especially if you don't know all of the nuances of both languages.

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.


Image from istockphoto.com.

πŸ” Go To TOC.

Coding in Typescript can be slow and cumbersome, especially compared to more streamlined languages like JavaScript or Python. This can be extremely frustrating for other developers who are used to working quickly and efficiently in other languages and me.

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

Also, I'm not too fond of TypeScript because it's a language that tries to sell you the idea of solving all JavaScript problems. It's trying to take over Javascript as the "go-to" language for web development. I like Javascript just the way it is, and I don't want TypeScript to come in and try to change everything.

Even under the assumption that the lack of typing in JS is a problem, TS does not solve it. Do you know who does? Java, C, C#, and other compiled languages. They can safely guarantee strong typing at compile time and runtime. Interpreted languages are just not capable of it.

A while back, Deno, a javascript runtime built on the V8 engine, Rust and Tokio, shared its own experience with Typescript, which turned out to be a major hindrance to productivity and added unnecessary complexity to the system. In their document, they shared an example that entails that this is difficult to have visibility into because of the complexity of generating the runtime code. This is in stark contrast to what the language promises: it will help them organize their code. While this may be true in some cases, it seems that it can have the opposite effect in other cases.

8. Lack of Flexibility.

πŸ” Go To TOC.

Typescript is a language that was created with the intention of making JavaScript more accessible, which is why it has become so popular in recent years. Unfortunately, due to its design, TypeScript puts a lot of restrictions on what you can do with the language. It attempts to limit what you can do with JavaScript and obscure its strong sides while providing a false sense of security. This can be extremely detrimental to developers as they cannot explore the true power of JavaScript or use it in ways they want or need to.

Developers need to understand that this lack of flexibility does not make them better developers; indeed, it may even hinder 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 comforting lie from Typescript.

If you're serious about becoming a great developer, you should not settle for a language that limits your creativity and hides the true power of the language. Instead, you should learn JavaScript and embrace its flexibility. Only then will you be able to truly unlock your potential as a developer.

9. Giant Corporation Abuse.


πŸ” Go To TOC.

Typescript is backed by Microsoft, one of the biggest companies in the world. This means they have a vested interest in pushing their own agenda and getting developers to use their technology. This can be seen in the way they are marketing Typescript as the "best" language for developing with JavaScript. However, this type of marketing has been criticized by many developers who believe it is misleading and forcing people to choose their product.

Furthermore, this type of big-business backing can create an environment where developers feel pressured to conform and use the technology presented by Microsoft. This can stifle creativity and lead to a 'one-size-fits-all' mentality regarding coding solutions. The goal should be for developers to be able to choose from a variety of options that best suit their needs, not be forced into using something that a corporate giant pushes.

Microsoft's strategy also creates confusion among developers who may not understand all the aspects of Typescript or why it would be better than other languages like JavaScript. Companies like Microsoft need to ensure they provide accurate information about their product so that developers don't get confused or misled about what will work best for them.

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 dubious patent claims.

One of Microsoft's biggest issues today is its involvement with Typescript. While the company has been trying to make strides 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 often focus on writing clever and complex code rather than efficient and effective. This can lead to a lot of wasted time debugging and trying to find solutions for problems that could have been avoided in the first place.

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.

Developers need to remember that the primary goal should always be customer satisfaction. If a solution isn't making the product better or easier for users, it isn't worth wasting time on it. Clever developers should focus on creating solutions that improve customer experience instead of just attempting to make themselves feel proud of their code.

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;
Enter fullscreen mode Exit fullscreen mode


Image by author.

12. Slower Compile Time.


Image by author.

πŸ” Go To TOC.

One of the primary issues with using Typescript is the slower compile time. This can be especially noticeable when working on a large codebase that needs to be compiled. The TypeScript compiler is not as efficient at optimizing code as other compilers, meaning that it takes longer to complete a compile task. This can lead to larger file sizes and a longer time waiting on the compiler to finish its job [5].

The main reason for this slower compile time is due to the statically-typed nature of Typescript. This means that the compiler has to do more work than a compiler for a dynamically-typed language like JavaScript, which can lead to longer compilation periods. Additionally, the TypeScript compiler does not have access to the same optimization tools that Babel does, further increasing compile time. Consequently, this will affect our productivity, too.

Typescript code can be painfully slow to compile, especially when you're working on larger projects. In their document, The maintainers of Deno noticed an incremental compile time when changing files in cli/js take minutes. This is crushingly slow and painful to modify [6]. As someone who's just started using the language, I can attest to how frustrating this can be. You make a small change, wait a minute or two for the compiler to finish, and then repeat. It's a huge time-sink, and it quickly becomes frustrating.

I understand that some people prefer the type safety that TypeScript offers, but in my opinion, it's not worth the tradeoff in terms of productivity. Additionally, it can be achieved with JSDoc and some VSCode settings.

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.

In addition, the TypeScript compiler can sometimes generate code that may be confusing or difficult to read. This is because it attempts to add type-safety to your code, which can sometimes result in longer or more complicated variable names. While this is not always a bad thing, it can make your code more difficult to understand, particularly for newer developers who are not yet familiar with TypeScript's conventions.

14. Lack of Performance.

πŸ” Go To TOC.

If you're writing code in TypeScript, you might find that your code is running slower than expected. That's because the TypeScript organization/structure imposes a runtime performance penalty.

When you use TypeScript, you're essentially telling the compiler to organize your code in a specific way. And this organization can create problems when it comes to runtime performance. For example, if you have a large array of objects, TypeScript will likely create a new variable for each object in the array. This means that each time you access one of these objects, you must look up its variable in memory. This can be a huge overhead at runtime and can cause your app to perform poorly.

15. Writing Unit Tests.

πŸ” Go To TOC.

When writing unit tests in TypeScript, I often find myself frustrated by the need for precision. With JavaScript, I could simply pass an object with the necessary properties to a test, but with TypeScript, I am required to define the type of the object and all its properties. This can be incredibly time-consuming, especially for those just starting out. As a result, I would much prefer to use JavaScript when writing unit tests.

The extra time spent defining types and properties detracts from the overall efficiency of my work. Not only that, it makes debugging and refactoring much more difficult as well. For example, if I need to change a single property of an object used in a test, I would have to go back and modify the type definition and the test code itself. This additional step wouldn't be necessary if I were writing my tests in JavaScript.

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 come from a statically typed language like Java, you might think that types are always good. However, in JavaScript, types can actually be more of a hindrance than a help. For one thing, JavaScript is a very dynamic language, which means that types can often get in the way of flexibility. For another thing, the type system in TypeScript is actually not that great.

Additionally, TypeScript's type system isn't really necessary for most JavaScript applications. Most applications don't need the extra safety and flexibility that types provide, so using TypeScript adds complexity without providing any real benefit. Therefore, it's often better to stick with plain JavaScript when developing an application.

TypeScript also supports type inference, when the compiler tries to guess the type of a variable based on how it is used. This is not always reliable; if the compiler can't figure out the type, it will default to any. That means that all type checking is effectively turned off for that variable. That defeats the purpose of using TypeScript in the first place.

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


Image by author.

17. Heavier Tech Debt.


Image from istockphoto.com.

πŸ” 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.


Image by author.

πŸ” Go To TOC.

Ok, so here's the deal. TypeScript is a great tool, but it's not the only one out there. JSDoc is another tool that can be used to annotate your code. And it turns out that Microsoft is also using JSDoc for their core TypeScript code! So why are we arguing about which tool to use? Let's just use whatever works best for us!

But what if you want to avoid using TypeScript? Or what if you want to use JSDoc without using the compiler? There are several options for type checking and generating type definitions in JavaScript. The two most popular options are JSDoc and Flow. While Flow is more popular and has more features, JSDoc is a valid alternative that can be just as effective.

1. JSDoc.


Image by author.

πŸ” Go To TOC.

For those who don't know, JSDoc is a JavaScript documentation tool that uses special comments to generate documentation for your code. Here are a few reasons why you might choose to use JSDoc over TypeScript:

  • JSDoc eliminates the need for a compiler. This makes it much easier and faster to write code and get up and running with your project. Additionally, JSDoc is often much more lightweight than their TypeScript counterparts, allowing you to focus on the features and functionality of your code rather than worrying about type checking and other complex syntax issues.

  • JSDoc allows you to focus more on the quality and readability of your code. Since you don't have to worry about type checking or maintaining complex types, you can spend more time refining the details of your code and ensuring that it is properly documented. Plus, with JSDoc, you can easily add annotations to your code which will help you understand what each section of code is meant to do. This makes debugging and maintenance easier in the long run.

  • You can just write your tests in vanilla JS and rely on JSDoc to give you the types you need. This makes it much easier to write tests for code that doesn't care about types but still needs to be reliable. JSDocs are more flexible and allow for easy customization of test cases. With TypeScript, you are limited by its rigid type system, but with JSDocs, you can easily create custom test cases or tweak existing ones as needed. This makes it very easy to tailor your tests for specific scenarios or edge cases that cannot be tested with TypeScript alone.

  • TypeScript requires annotations to generate documentation. And you guessed it right. This means that JSDocs are still necessary for TypeScript to generate documentation. There is very little difference between the amount of typing required for vanilla JSDoc and TypeScript + lightweight JSDoc.

  • One of the main reasons you might choose to use JSDoc over TypeScript is that it's natively supported by almost every IDE. This means you don't have to install any additional dependencies to get JSDoc working. Additionally, JSDoc provides a more powerful way of documenting your code than simply using comments.

  • 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 trying to create a narrative that the only way to fix the type issue is to switch over to TypeScript. This, however, is not true. It's clear that Microsoft's decision here is motivated completely by profit and not by what's best for developers or users of their products.

In summary, using JSDoc instead of TypeScript may be beneficial for some projects where type safety isn't necessarily required or where time or resources are limited. However, if your project requires strong typing or complex logic, then TypeScript may still be the better choice to ensure that your application meets its requirements.

2. Flow.


Image by author.

πŸ” Go To TOC.

If you're not interested in using TypeScript, Flow is also a great alternative. Flow is a static type checker for JavaScript. This means it can help you catch errors in your code before you even run it. This is extremely powerful and can help you avoid many potential problems.

Like TypeScript, Flow also allows you to define types for your variables and functions. This can be extremely helpful in large projects, where keeping track of types can be difficult. Flow also has a few other features that TypeScript doesn't have, such as support for 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.

  • Backed by a Giant Corp: Meta, formerly known as Facebook, has developed and maintains both React and Flow. This means that the two tools are fully compatible and work together seamlessly. Meta's commitment to these tools ensures that they will continue to be supported and updated, making them a reliable choice for us as web developers.

  • Flow has a smaller footprint: Flow is the simpler choice when it comes to integrating into projects. That's because Flow requires no additional dependencies. Unlike other type checkers, Flow does not create any extra files, such as .d.ts files. This means that Flow has a much smaller environmental footprint and a much easier and simpler integration into any given project.

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.

Now the question becomes: which one should you choose? It depends on your preferences and what you're trying to accomplish. Flow is more popular and has more features, but JSDoc is also a valid option. Either way, you'll get some level of type-checking and generation for your JavaScript code, so it's worth considering if you're working on a large project.

What's next for Javascript?

πŸ” Go To TOC.

It seems like every day there's a new proposal to change javascript in some way. And while some of these proposals are great, there's one in particular that I think could ruin the language as we know it.

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.

Javascript could become a lot more like Java, with strict rules and regulations that must be followed. And while that might be fine for some people, I think it would ultimately make javascript less accessible for beginners.

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.

So, why would anyone want to use TypeScript over javascript? In my opinion, javascript is a better language for writing code that is bug-free, readable, and maintainable. While TypeScript does offer some benefits, I believe that the benefits of javascript outweigh the benefits of TypeScript.

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.

At the end of the day, it's totally up to you whether or not you choose to hate Typescript. But if you're looking for a reliable way to write code that will keep your application functioning for years to come, there's no denying that learning how to work with it is an invaluable skill. So don't give up on it just yet; keep coding and be humble about your own knowledge!

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.

Top comments (359)

Collapse
 
gweaths profile image
Grant

So, the article seems very biased from someone who is a huge advocate for JS, rather than pointing out actual flaws of the Typescript language.

I think the point of time consuming learning the language isn't valid and again opinionated. The syntax is not that different compared to JavaScript in reality. There are much more convoluted language syntax out there e.g Python, C++ to name but a few.

verbosity, is the whole point of any real strongly typed language. Without it, everything is simply dynamic types, making it difficult to know the schema of an object. Again it's the whole nature / reasoning for a typed language.

"The language uses conventions unfamiliar to developers coming from other languages and can make it difficult to read and understand the code."

In what way is syntax difficult. What are you comparing it with. You seem to be implying the syntax of JS is easy however TS really isn't that different.

Your testing point, I'm not following the scenario you're describing. Why would you wish to change the property of a type in a single test ? Are you referring to the value, or the type of the property ? If the latter I'd say you need to reassess the test / object needs

"For another thing, the type system in TypeScript is actually not that great."

What are you are actually referring to. Why isn't it that great. You simply state your opinion but don't explain why.

Collapse
 
leob profile image
leob

The problem with the article is that all of the 17 reasons are subjective and highly debatable. Other devs (the ones who do use/like TS) are adamant that it does have benefits for them. Who is "right"? No idea, this is an endless debate, but I've never seen any arguments from either side which totally convince me.

The only thing I see is that the "market share" and usage of TS are growing steadily, and by now it's becoming dominant ... so all I can conclude is that "TS must be doing something right". Just from looking at the stats and the rate of adoption I think TS is the future, whether we like it or not.

Collapse
 
jfbrennan profile image
Jordan Brennan

I’ve learned to be cautious with popularity and market share as objective metrics. React is popular because Facebook has spent millions marketing it and because the frontend community suffers from peer-pressure, β€œEveryone uses React why don’t YOU use it?!” The same is true for TS.

There are several frameworks that are objectively better than React (smaller, faster, easier, compatible with WC, valid template syntax, and better features like SFC), and yet folks are practically afraid to admit they don’t like React.

TS imo is a wash. Yes, the code can be more clear but you can also make a mess. JSDoc gets you the intellisense and your app is not runtime safe no matter how much TS you throw at it. And like React people are shy or just flat out not sure what to make of TS, so they follow what’s popular and the popularity grows.

Thread Thread
 
wiseai profile image
Mahmoud Harmouch

OMG! I couldn't agree more! It's so refreshing to see somebody with level-headed thinking in this day and age. We need more people like you to help set the world back on track. Thank you for speaking up and showing true sanity!

Thread Thread
 
olddutchcap profile image
Onorio Catenacci

"There are several frameworks that are objectively better than React" (emphasis mine).

I don't think you understand the meaning of the word "objectively". I can't think of many things in software development that are objectively better than other things.

Thread Thread
 
jfbrennan profile image
Jordan Brennan

Bundle size is an objective measurement. Svelte, Riot, and Vue all have much smaller bundle sizes than React. They are better than React in this regard.

Legacy baggage is an objective measurement. React has legacy junk it can’t get rid of, others do not and that’s better.

Learning curve is objective. Riot and Vue and other frameworks have many attributes that make them easier to learn than React.

Web standards compatibility is an objective measurement. React, for example, scores 71% for Web Components compatibility while Vue scores 91% and virtually all other frameworks, including Riot and Svelte and Angular, score 100%. Also, React templates use a proprietary version of XML mixed with JS while virtually all other frameworks just use HTML. Adherence to web standards by non-React frameworks is objectively better than React’s incompatible non-standard designs.

Thread Thread
 
derappelt profile image
Simon Appelt

Don't get me wrong, i'm a full time Vue developer and I like Vue way more than react. But to say something is objectively better is nonsense.
It completely depends on the goal you have.
Lot of you points are totally irrelevant in certain situations. Even though you can measure them.
It's like saying bicycles are better than cars because they are objectively lighter.

Thread Thread
 
jackmellis profile image
Jack

That's it I'm swapping my car for a bicycle tomorrow!

Thread Thread
 
jfbrennan profile image
Jordan Brennan

I was originally responding to a comment about the false virtue of popularity and Onorio’s comment about objectivity. I understand why someone might be cautious to use the β€œO” word when it comes to a tech stack, but we also shouldn’t ignore facts or suggest that an attempt at objective comparisons is β€œnonsense”.

There are tradeoffs and personal preferences. Got it. Understood. I’m all good with thatπŸ‘

But I’m also unbiased and like to just let technologies speak for themself. React is fatter, slower, less compatible, has legacy baggage and a steeper learning curve compared to new stuff. That’s just the facts. I am fine with React, but it is objectively not the better choice.

Maybe I’m wrong though, so to your point, in what situation would someone pick a frontend framework because it’s bigger? Or slower? Or harder to reason about and has compatibility issues? I can see subjective reasons to choose React, like preference and external factors outside of a side-by-side comparison like talent pool.

Thread Thread
 
jackmellis profile image
Jack

All of those reasons have caveats or a degree of subjectivity. You could also make a list of other statistics that supposedly show that Vue or Svelte are objectively worse.

Personally I think these frameworks are converging to the point that it barely matters which you choose. I'll always choose Vue for my own projects because I like the syntax and I had a good community experience. But I also work with React every day and I'm okay with that. Why do we need to constantly prove one library is better than another anyway?

The reason React is "winning", I think, is because it has momentum. It was the first serious contender to Angular which was a huge breath of fresh air at the time. It quickly gained a following, which translated into being taken seriously in business. I worked at a company that built their MVP in Vue, but for their v1 they moved to React because it was easier to find candidates and market. Nothing to do with what we devs consider objectively good, it's just "the standard".

Rant over.

Thread Thread
 
spock123 profile image
Lars Rye Jeppesen

Angular is not AngularJS.

Thread Thread
 
ozzythegiant profile image
Oziel Perez

@jfbrennan exactly! So many devs acting like sheep because it's popular, provides jobs and is "easy", when all they are doing is shooting themselves in the foot learning a convoluted framework that brings nothing of benefit to the table. I will not be persuaded. Svelte is the way to go, get back to the basics of web development! #DeathToReact

Thread Thread
 
derappelt profile image
Simon Appelt

@jfbrennan I'm just tired of the never ending debate over what framework ist better, overrated etc.
It's such a useless discussion where no one will ever win. When you start a fresh project you can and should debate with you team which framework is the best fit. But the answer will only partially depend on hard facts like bundle size or web standard compliance.
Of course you will not pick a framework because it's bigger or slower. But for most of the projects all modern frameworks are small and fast enough.
So it really comes down to thinks lice developer expertise or availability.
In my opinion most of the people that say framework ... is too slow are simply doing things wrong.
If you follow your arguments consequently you should not use a framework at all. This was you will have the smallest bundle size the (potentially) most performance and the best standard compliance.

Thread Thread
 
leob profile image
leob

React is dominant in the market and provides the jobs and the $$$ - that's enough reason for many people to use it, even when they don't like it. We need to put bread on the table, that's the harsh truth, and in many cases you can't even choose yourself, a company or a customer will make the choice for you and you need to deal with it.

Thread Thread
 
jfbrennan profile image
Jordan Brennan

I agree. My original comment was just that popularity can often be misleading, then people started claiming objectivity is nonsense and doesn’t exist in software πŸ˜‘

There many reasons people use what they use. Some devs are lucky enough to pick. I picked Vue for the last greenfield project I worked on. Not really married to any of them, but when it comes to React I have eyes wide open.

Thread Thread
 
ozzythegiant profile image
Oziel Perez

The argument nowadays isn't about performance, that's a smaller argument. The biggest issue particularly with React is that it promotes anti-patterns and bad ways of coding that should have been handled with classes to begin with. Components are always written poorly, causing a huge mess, and because of how flexible React is, everyone has their own way of writing React code that causes the project to be unmaintainable in the long run.

Thread Thread
 
leob profile image
leob • Edited

My chief complaint about React is not that it doesn't use classes or objects - it did use them, but deliberately moved away from them in favor of functions - FP (functional programming) is a valid alternative to OO.

No, my main complaint is that the burden of handling and optimizing the "low level stuff" is left to the developer - you really need to be (or become) an expert in "React best practices" in order to avoid excessive re-rendering of your components - this is, what I call, the "low level stuff", which should be taken care of by the framework, so that the developer can focus on business value!

I mean, how many lengthy, complicated articles have I read recently about all kinds of arcane patterns or 'practices' we need to follow with React in order to avoid unnecessary component re-rendering ... let me repeat it once again: THE FRAMEWORK SHOULD TAKE CARE OF THIS KIND OF LOW LEVEL STUFF !

(don't get me started on things like useMemo, that's just an ugly hack - when people's apps perform like a snail and they start "fixing" that by peppering their code with useMemo all over the place, then you know it's the beginning of the end)

I don't want to spend my time to become an "expert" in arcane React techniques to prevent my app from performing like a pig - I want to create business value for the client!

(other case in point - look at the ridiculous amount of discussions about Redux versus Context - mainly how "unnecessary" Redux is, and that it should be replaced as soon as possoble with "Context" - then watch the same people, 1 or 2 months later, complaining how their app inexplicably got slow like a turtle ...)

Thread Thread
 
jasper91 profile image
Jasperrr91

Bundle size is an objective measurement. Svelte, Riot, and Vue all have much smaller bundle sizes than React.

Not sure where Riot is coming from, if you want a modern comparable framework with high popularity; choose SolidJS. Bundle size of all these frameworks, including React, is still small enough that it really does not matter.

Poor image optimisation, large stylesheets, external scripts, they all diminish any optimisation gains made by the core library bundle size.

Legacy baggage is an objective measurement. React has legacy junk it can’t get rid of, others do not and that’s better.

Bold statement, all code has legacy stuff and will gain more legacy code as time goes on. Only extremely new frameworks (a SolidJS for example) have little legacy. But new frameworks have the trade-off that they have small communities and thus have less support/information available. This trade-off will always exist.

Learning curve is objective. Riot and Vue and other frameworks have many attributes that make them easier to learn than React.

Learning curve is a highly subjective matter. Some people find Vue concepts easier to grasp, others React. Some people love Svelte, I personally strongly dislike the syntax. This is the most subjective measurement out there.

Also, React templates use a proprietary version of XML mixed with JS while virtually all other frameworks just use HTML. Adherence to web standards by non-React frameworks is objectively better than React’s incompatible non-standard designs.

JSX transpiles down to regular old HTML, it's nothing more than a templating syntax. Just like Vue and Angular have a lot of custom HTML attributes, and Svelte has logic blocks. Even in React you can write 100% valid HTML.

The compatibility with custom components is a bit poor indeed. Although it too has 100% support in the experimental release so that is coming up in the future.

React is fatter, slower, less compatible, has legacy baggage and a steeper learning curve compared to new stuff. That’s just the facts. I am fine with React, but it is objectively not the better choice.

Looking at the aforementioned facts, this simply does not hold true. Every language has its pros and its cons and more often than not your locked in to a default framework used within a company. If you have the choice, pick whatever framework you feel most comfortable with, chances are 99% that you are not working on a cutting-edge website that needs every micro-optimalisation out there.

Personally, if I had the choice I would go with SolidJS (as spoilered by my first line of writing). But Svelte with Sveltekit is also a strong contender. Remix and NextJS on the other hand also deliver very solid applications. Seriously, there's a whole world out there and every framework will probably do just fine. It's mainly a trade off regarding developer experience. (And yes, that too is subjective).

Thread Thread
 
jasper91 profile image
Jasperrr91

@leob

(other case in point - look at the ridiculous amount of discussions about Redux versus Context - mainly how "unnecessary" Redux is, and that it should be replaced as soon as possoble with "Context" - then watch the same people, 1 or 2 months later, complaining how their app inexplicably got slow like a turtle ...)

Redux and React Context will more often than not give you the same re-rendering headaches. It's mainly a issue of a proper architecture and for that you need a good understanding of how rendering in React (or whatever framework you prefer) works.

Thread Thread
 
jfbrennan profile image
Jordan Brennan

Does driving a car have an easier learning curve than piloting jet?
Does Python have an easier learning curve than Rust?

Will some people learn faster than others? Yes, but that doesn’t change the fact one thing is measurably easier to learn than another.

Thread Thread
 
favna profile image
Jeroen Claassens

Regarding the whole React vs X debate that's been going on here, I'd say the only real argument against React you can make is the lack of two-way-modal-binding that at least Angular and Vue (I do not have personal experience with others) do have.

Having to constantly track state updates in useState, use state set calls, manually write event handlers (i.e. onClick or onChange) is a huge chore compared to the aforementioned alternatives.

This is especially a problem in larger enterprise applications that are very form-heavy. Think of dashboards for customers where they have to provide upwards of 20 text fields, dropdowns, and radio buttons to place an EU standards compliant train driving order (coincidentally the system I've been working in for the past 2 years (public domain information so I can divulge this, don't worry)).

I've been writing React for the past 3,5 years for work and personal projects (even longer) but for the latter I've recently picked up Nuxt (Vue framework) and I absolutely love how much easier it is to make forms and track data.

Thread Thread
 
jackmellis profile image
Jack

I hate getting into these "my framework could beat up your framework" debates which are inherently futile, but I just have to agree with your last point. Vue is just so easy to work with. I use React for most work-related stuff, but I'll always pick Vue for anything else.

Thread Thread
 
jfbrennan profile image
Jordan Brennan

I’m with you. I don’t care to argue about which framework is best -there’s lots of reasons a tech stack is what it is - my point was simply that when comparing frameworks there are objective benefits some have over others.

 
jackmellis profile image
Jack

Car vs jet is not a fair comparison to React vs insert-favourite-framework.
Car vs jet is more like assembly vs sketch or something.
We argue otherwise but the differences between view frameworks are marginal at most, and in reality, we're all fighting over which shade of light blue is the best light blue.

Thread Thread
 
favna profile image
Jeroen Claassens • Edited

It's periwinkle blue by the way ;) (/s)

Thread Thread
 
jackmellis profile image
Jack

Periwinkle is slow and bloated and doesn't have the community support of other shades and only has traction because of big corporation adoption.

 
ozzythegiant profile image
Oziel Perez

Based on that logic, its also possible to say that in the end if end-users and developers don't care about the quality of their code or how they write it, then why do we even bother with standards, best practices, etc. Why do we go through the trouble of writing blog posts on how to have a good app architecture if in the end people just choose React, create messy components, and call it a day. We need to turn that mindset around if we are going to create better quality software

Thread Thread
 
urielbitton profile image
Uriel Bitton

So you're saying if you don't use TS, your code is guaranteed ti be bad structure and messy?

Thread Thread
 
ozzythegiant profile image
Oziel Perez

Actually I was talking about React, although I do encourage people to use TS to help with that regard. React has only lead to messier components because some people don't follow standards

Thread Thread
 
jackmellis profile image
Jack • Edited

Shame on those people. I can write "neat" components and everywhere I've worked either had standards in place (with code reviews etc.) or I lobbied for standards to be followed when joining.
Yes you can make a mess of React components if you're new or lazy - the same applies to all frameworks and languages - but that's a negative that falls on the developer not the library surely?

Thread Thread
 
urielbitton profile image
Uriel Bitton

exactly. "Because some people don't follow standards". That's their fault only. That means you can ditch TS and have a JS codebase that is as clean as any TS codebase. Don't make the mistake to think TS does anything apart making sure you pass the right type to your components/functions. Anything you think it does more, is just your imagination.

 
jackmellis profile image
Jack

Funnily enough, the messiness of a codebase is one of my biggest worries when joining a new company πŸ˜…

Collapse
 
gmartigny profile image
Guillaume Martigny

I'm not sure language adoption is a fair metric. Some people are pushing the use of TS in all circumstances regardless of real interest. As stated in the article TS might be a great solution for large project. But not for smaller team with less experienced devs.

Collapse
 
wiseai profile image
Mahmoud Harmouch

Thank you for your comment. I strive to provide quality content that is both informative and enjoyable to read. I am sorry to hear that you felt the article was not up to par in terms of your agreement with my opinion, which is ok.

Not only that, I am not quite sure if 17 flaws are not good enough to accurately convey my opinion in the language, but that doesn’t mean you should give up on my words altogether.

Furthermore, I think it is also important to keep in mind the context of my writing by taking the time to read my words carefully before responding. This will help you ensure that you don't miss any important information or points that I am trying to make.

Thank you again for taking the time to leave a comment. Have a good day/evening.

Collapse
 
brense profile image
Rense Bakker

So, you write a subjective article about typescript, because you dont like it and when a reader raises some valid questions, instead of giving a substantive response, you respond with something along the lines of: "if you dont agree with me you're stupid". Or: "I'm so smart you dont understand me".

It seems to me that your only perogative here is to start a flame war and I hope people will report your abuse.

Thread Thread
 
dancxjo profile image
Travis Reed

This was exactly my attitude when I started with TS. It's a very different mentality: when I learned JS, i got in the habit of runtime type checking. Getting rid of that, learning new idioms and considering compile time takes a lot of effort.

Thread Thread
 
brense profile image
Rense Bakker

Change always takes effort, nobody will dispute that and the road can be challenging depending on your history, but to write an article like the author did and put in this amount of effort to come up with unfounded reasons not to change... Thats a really bad attitude. Furthermore, you can tell what the authors attitude is by the responses they gave to some of the replies they got that disproved the reasons they gave.

Thread Thread
 
wiseai profile image
Mahmoud Harmouch

So, you write a subjective article about typescript,

I don't think there is anything wrong with writing a subjective article. In fact, it can be quite helpful to other developers who are considering using the language. By reading about another developer's experience with TypeScript, they can get a better sense of whether or not the language would be a good fit for them. Additionally, subjective articles can provide insights into how best to use TypeScript in order to get the most out of it.

I know that objectivity is key when writing about technical topics. Next time I will focus on more facts and data rather than personal opinion or being subjective.

because you dont like it and when a reader raises some valid questions, instead of giving a substantive response, you respond with something along the lines of "if you dont agree with me you're stupid". Or: "I'm so smart you dont understand me".

I mean, If I were to respond the way I wanted, I would look redundant. I would repeat the same points raised in the article, which is why I suggested reading it carefully. However, it is ultimately up to the reader whether or not they want to read it. I am not trying to prove that I am smarter than anyone but merely wanted to raise what seems to be important issues.

It seems to me that your only perogative here is to start a flame war and I hope people will report your abuse.

It is ok to remind people to use their damn minds.

Change always takes effort, nobody will dispute that and the road can be challenging depending on your history.

But, is it worth it? I say "it depends". The best answer comes from looking inward and determining if the change you seek is for betterment. If so, then making the effort to change will undoubtedly lead to a more positive outcome full of new opportunities and experiences.

but to write an article like the author did and put in this amount of effort to come up with unfounded reasons not to change...

Everyone has their own perspectives, however, it is important to remember the code of conduct of the platform when publishing an article. Everyone has the right to express their opinion in a respectful manner, and by doing so, it will help ensure that any conversation remains civil and respectful.

Peace!

Thread Thread
 
smolinari profile image
Scott Molinari

React is popular because Facebook has spent millions marketing it

There is in no way any evidence to prove this. In fact, as I see it, all they did was pay devs working on React to do a number of talks when React came out. The React docs have sucked almost to this day aka no real investment (they just got reworked and are somewhat better now). They did very little in terms of video tutorials either. They definitely had no paid advertisements.

What they did do is hit a nerve of the JS community at the time, namely the acknowledged hackery of using jQuery to update the DOM when data changed. Using the power of reactive programming, React turned the frontend world upside down for the positive. Now everyone can let their data do the walking. That is why React is so popular.

Scott

Collapse
 
aradalvand profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Arad Alvand

You are an insufferable idiot, as has been pointed out to you already, you must know that.

Thread Thread
 
wiseai profile image
Mahmoud Harmouch

When you decide to become respectful, we can carry on our discussion in a more positive and productive manner.

Thread Thread
 
matronator profile image
Matronator

I actually agree with him...

Collapse
 
shadowfaax profile image
Shadowfaax

Using typescript instead of native JS, the gain is minimal compared to the flaws. FrontEnd is UI/UX, it's only an interface, you don't need to make it over-complicated.

The simple concept of typing everything is completely irrelevant in Front where you only need to display numbers and strings, and send forms.

The business layer is Backend and must stay in there.

Collapse
 
kukulaka profile image
Tanya Byrne • Edited

verbosity, is the whole point of any real strongly typed language. Without it, everything is simply dynamic types, making it difficult to know the schema of an object. Again it's the whole nature / reasoning for a typed language.

This! Also if you come from a background where you are used to using strongly typed languages, I would argue that picking up typescript is pretty straight forward. Point 16 seems like a "you" problem rather than an actual issue.

This article is highly subjective and I would argue kind of misleading and reductive to boot.

Collapse
 
wiseai profile image
Mahmoud Harmouch • Edited

Also if you come from a background where you are used to using strongly typed languages, I would argue that picking up typescript is pretty straight forward.

Why would someone switch from a strongly typed language to Typescript, which is less type-safe, probably not at all as @idleman pointed out. In my opinion, you better go for JavaScript if you are looking for forgiveness' sake. I mean, I don't get it. Is type safety a spectrum? I just don't see the point in sacrificing that level of safety for the sake of convenience. If you want convenience, use JavaScript(Also, I am not advocating for neither JS nor TS. But it just seems the logical fit in this case.)!

For me, the sweet spot between readability and type annotations is JSDoc. I find that it strikes a nice balance between the two. While bloating the code with type annotations can make it less readable, JSDoc, however, allows for a more powerful way of documenting our code by also providing type annotations.

Just sayin'.

Thread Thread
 
kukulaka profile image
Tanya Byrne

because they have to because that's what their job uses?

Collapse
 
somecallmetim profile image
Tim Mensch

TypeScript is the go-to language for both frontend and backend developers today. Poe's Law is preventing me from being able to tell whether you're actually serious or you're just trolling TypeScript fans.

I mean, you point out that there's more typing...and then duplicate the types in the TSDoc, which isn't necessary. The TypeScript types are vastly superior to the unverified and likely stale JSDoc comments. Also, having real types in your app, in my experience, speeds up development by 2-5x, so any extra actual typing is more than compensated for by the increased development speed.

And types aren't useful? Only if you press the any button too often, which is another of your "downsides." Yeah, it hurts when I do that? Don't do that.

And FlowType...which is used on Facebook projects and practically nowhere else. Where's the DefinitelyTyped equivalent? Pretty much absent.

And unit tests in TypeScript don't need to be hard to use. Instead of having them take a class parameter, have them take an interface that needs exactly the members you need in the function you're testing.

So many others are just reaching. "I hate Microsoft. Sort of." Really? Whatever.

Again, masterful troll, poor actual technical critique. TypeScript gets you to a level of software engineering impossible in JavaScript.

Collapse
 
leob profile image
leob • Edited

Haha:

"whether you're actually serious or you're just trolling TypeScript fans" ...

I'm pretty sure the author is serious, although for a moment I also thought he might be trolling.

Collapse
 
brense profile image
Rense Bakker

Its both, he is serious but also trying to start a flame war at the same time because it helps his statistics. This article is going to be at the top of the listings for a while.

Thread Thread
 
szsz profile image
Sz.

Yeah, and it's kinda sad. I'm very new to dev.to, just test-driving, but I think I'll just skip it (the same way as TikTok), if it continues with this content ballooning strategy (which I don't think it can/would change, actually).

Thread Thread
 
leob profile image
leob

I think the discussions are often fun, and in many cases they're more interesting (and sometimes even higher quality) than the articles proper ... the good thing is that the discussions (almost) always remain respectful and on-topic - kudos to the dev.to moderators!

Thread Thread
 
wiseai profile image
Mahmoud Harmouch • Edited

I think it is always better to post good constructive criticism than to simply ramble on. However, there is always a time and a place for both types of comments. Sometimes, it is helpful to simply vent and get our thoughts and feelings out there, even if they're not perfectly articulated. But, It is better to post well-articulated arguments like what @tqbit did in his comment. Anyways, thanks for contributing to the discussion!

Thread Thread
 
brense profile image
Rense Bakker

Strong disagree there. I have seen very few discussions with opposing views that remained respectful and when the author of the article shows their utter contempt of the people with different views (which is extremely disrespectful in my humble opinion but not against the rules for some reason). If the people in question respond, the dev.to mods ban THEM instead of the author who created the context and is the actual instigator of the disrespectful discourse. Discussions can be fun, but only if one of two scenarios is true: Either they moderate the platform equally and everyone who shows disrespect gets banned, OR you allow the community to moderate itself which means if someone acts like an ***hole, you can tell it to their face. Instead of the current situation where you get muzzled by the dev.to moderator team, while they allow the instigators (trolls) to continue.

Thread Thread
 
brense profile image
Rense Bakker

People DID post constructive criticism with examples that proved some of your points were NOT valid and you responded by putting yourself above them and suggesting they didnt read your article properly. Thats arrogant and disrespectful and you should be banned for it in my humble opinion.

But not to worry though the dev.to team got your back and they will probably ban me instead for calling you out on your behavior. Succesful troll succeeds πŸ‘

Thread Thread
 
wiseai profile image
Mahmoud Harmouch • Edited

People DID post constructive criticism with examples that proved some of your points were NOT valid

I completely understand that. I'm just like you, a human being who is trying to become perfect. And I know that it's not always easy. But I do think that some of the points in the article are still valid. Especially when it comes to using TSDoc to document your TS code, whereas you can use JSDoc with JS and it provides everything that TS has to offer.

suggesting they didnt read your article properly.

That's what it seems like. If not the case, it is OK and I would be responding with the same points written in the article. That's why I suggested reading it. And it is also sad that some people are jumping straight into the comment section without even daring to read the introduction.

I have seen very few discussions with opposing views that remained respectful and when the author of the article shows their utter contempt of the people with different views

Discussions can be fun

Hence my comment:

Sometimes, it is helpful to simply vent and get our thoughts and feelings out there, even if they're not perfectly articulated.

Thread Thread
 
leob profile image
leob • Edited

I think we also shouldn't be too quick and eager to be calling for others to be banned, something with the pot and the kettle ... ;)

Sometimes you just need to let it go, the way I see it is that discussions like these are mainly a bit of fun, even when they get "heated" - let's not take it too seriously and be TOO sensitive, it's not the end of the world.

Thread Thread
 
wiseai profile image
Mahmoud Harmouch

More of this, Please. Thank you.

Thread Thread
 
brense profile image
Rense Bakker

Maybe the author should let it go and just not use typescript if it upsets them so much. Instead of going on a dev platform and trying to start a flame war that might get others banned of said platform. 🀷

Thread Thread
 
longebane profile image
Long Dao • Edited

As much as I disagree with author, I think he is perfectly fine writing a controversial article like this. It's an opinion piece what can excite flaming, sure. But it can also be educational for others who don't have a strong inclination towards a side.

Thread Thread
 
idleman profile image
idleman • Edited

It is not a controversial article, more like educational because people don't know most of the stuff he points out. They are like you, refuse to accept the truth. But most points is correct.

If TypeScript provided real type safety, it would enforce every single type at runtime and for the most basic primitives, enforce memory constraints and so on, like Rust/C++.

Thread Thread
 
brense profile image
Rense Bakker

Except theres nothing educational about it, as was already pointed out by several others. The examples are fabricated. In other words: the author is lying in order to provide argumentation for their personal opinion.

Thread Thread
 
idleman profile image
idleman

No, most of the stuff he mention is correct. You just donΒ΄t know better because you have been told massive with lies and cannot check it yourself. You probably want to believe it yourself too, making it even harder for you too see the truth.

One of TypeScript largest myth is about it has type safety, which is bs. You can cast anything to anything is TS, can it is by definition not type safe. In C++/Rust you cannot do it, because those language has REAL type safety. If you want to prove TypeScript is type safe, you need prove the "cast" operator do not exist in TypeScript and all objects has memory constraints (= fixed memory size). And this is 100% not the case.

Common kids, this debate is over 40 years old. Types don't make any real difference if you take everything into account. It is time to grow up, really.

You swap development speed for catching simple bugs, that never reach production anyway if you have a good tests (which is required anyway!).

Want development speed: Go JS.
Want types: Go Rust/C++ and compile it to WebAssembly
Want slow development speed and no type safety: Go TypeScript.

That is the hard truth.

Thread Thread
 
brense profile image
Rense Bakker

I think you misunderstood what the word type safety means.

The ability to typecast does not make a language not type safe:

function someFunc(funcParam:string, anotherParam:number){
  // you can rely on funcParam always being a string
  // and anotherParam will always be a number
  return anotherParam as string
  // you can rely on this function always returning a string
}
Enter fullscreen mode Exit fullscreen mode

This is what typesafety means. You do not have to write arbitrary conditions in your code to check whether a function returned what you hoped it would return. Without typesafety the function above would look something like this:

function someFunc(funcParam, anotherParam){
  if(typeof anotherParam !== 'string') return anotherParam.toString()
  return anotherParam
}
Enter fullscreen mode Exit fullscreen mode

And that check is still highly naive what if anotherParam is of a type (like undefined) that does not have a toString() method? Exactly, you get a runtime error.

Also if you think c++ does not have typecasting... youre just plain wrong: typecasting in c++

So come on kids, instead of acting like kids and talking BS about stuff you know nothing about, how about go read up on the things you want to talk about. In the spirit of that, I will admit I know nothing about c++, but that page about typecasting was easily found.

Thread Thread
 
idleman profile image
idleman

You have no clue what you are talking about. I know TypeScript claims to have type safety and I know they do static checks that is obvious wrong, but beside that, no fking type safety at all! They are just wishes, please give me an an object of "type" and you may get an object of "type", say an integer. In C++ and Rust if you say you want some primitive value, 100% of the time you you get it. Real typed languages have CPU constraints and memory constraints. You can simply speaking TRUST an int is an int if the type says it is an int. In TypeScript you cannot DO IT! It is just a wish.

You should not try to teach other people what type safety means, when you clearly does not know even be basics in programming beside some fancy TypeScript stuff that are 99% just adversating talk from the team that sell the product.

I am not against types, but if the language says it is type safe, and a lot of people just repeats the lie when it is simple to provide this is not the case, it is extremely annoying. Sure, I know TS core team know it is not type safe, but they want to sell their product so it is reasonable they continue to spread the lie. But rest of you, what are your excuse?

Thread Thread
 
leob profile image
leob

In my opinion, both Renske and you are overly aggressive in your style of debating ... we don't need to be over-sensitive but "you have no clue what you are talking about" and Renske's "BS" paragraph are examples where you guys resort to needless "ad hominems".

This article really started a flame war, nice for the entertainment if you're into it, but we're not really getting anywhere. My take on TS is, if you think it benefits you then use it, if you think not then don't use it.

Thread Thread
 
idleman profile image
idleman

Yeah, its my mistake. I don't mean to be so aggressive.

Thread Thread
 
leob profile image
leob

No worries :)

Thread Thread
 
brense profile image
Rense Bakker

It was actual BS though. And they continue digging a deeper hole of BS. Tbh their nonsense is so far out there that it's not even worth responding to anymore.

Thread Thread
 
somecallmetim profile image
Tim Mensch • Edited

Yeah, I'm with you there. You were appropriately calling a BS argument BS. That's not an ad hominem.

Saw a video recently about static types and C++ that had a related point: If you're arguing, you're losing.

We're arguing. They have an emotionally based disklike of TypeScript. We will never move the needle with logic.

I mean, above the surgery calls my post a ramble, and accused me of not reading the article. But then he goes on to repeat the same misinformation that I've already debunked. Speaking of not reading what was written.

Let them use inferior tools and celebrate that practice. There's nothing we can say to change their opinion.

The video is long, but it details a guy spending years trying to advocate for C++ in the embedded community, and he was far more patient and strategic than I've ever been--and yet he still failed. It's a good watch.

 
brense profile image
Rense Bakker

The points raised in the article are not correct as was already pointed out by several other commentors. The examples are fabricated and the only substance that remains is the authors personal aversion of Typescript.

I am sorry Typescript isnt working out for you. Nobody will force you to keep using it if you have convinced yourself that Typescript produces more runtime errors than using plain Javascript. Goodluck with that. πŸ‘

 
leob profile image
leob

Yeah actually I had a negative experience, once, with dev.to moderation - I received a one week ban, and my "opponent" as well, while my verbiage was still reasonably polite and moderate, while his was just extremely rude - but we both received exactly the same kind of slap on the wrist (one week ban) ! That did feel unjustified, but oh well, in a case like that you sometimes need to let it go and think "whatever".

Collapse
 
wiseai profile image
Mahmoud Harmouch

And types aren't useful? Only if you press the any button too often, which is another of your "downsides." Yeah, it hurts when I do that? Don't do that.

I didn't do that. The compiler chose the any type, not my fault.

And unit tests in TypeScript don't need to be hard to use. Instead of having them take a class parameter, have them take an interface that needs exactly the members you need in the function you're testing.

It becomes harder when you decide all of a sudden you should change a specific variable type which reflects on the test case.

So many others are just reaching. "I hate Microsoft. Sort of." Really? Whatever.

I mean, what's your decision when you realize that the CEO of the company you are working with shared such an opinion on Linux and open-source in general? Of course against him.

Again, masterful troll, poor actual technical critique. TypeScript gets you to a level of software engineering impossible in JavaScript.

Sorry if you took it that way. I think you will change your mind if you ever considered reading it carefully. But, it is ok if it is not the case.

Thanks for leaving a comment, btw.

Collapse
 
vectorjohn profile image
John Reeves

It becomes harder when you decide all of a sudden you should change a specific variable type which reflects on the test case.

In javascript, in the best possible scenario your unit test then fails and you have to fix the code anyway. More than likely, your test continues to pass and your start getting silent errors at runtime.

Collapse
 
insidewhy profile image
insidewhy • Edited

I didn't do that. The compiler chose the any type, not my fault.

Because you didn't enable strict mode. Which no TypeScript developer I've worked with would fail to do. So I wonder you actually use TypeScript that much.

Collapse
 
seanmay profile image
Sean May

The compiler chose any because you have a var that is declared but not defined, and also not typed. If you don't give either a type or a value to a variable, then it's going to class it as any, so that you can put whatever you want into it, later.

let a = "x";
let b = 5;
let c = a + b; // <-- knows it's a string
Enter fullscreen mode Exit fullscreen mode

100% valid TypeScript.
Solved problem.

Collapse
 
iseiryu profile image
Sergey

when you realize that the CEO of the company you are working with shared such an opinion on Linux and open-source in general

US dropped nuclear bombs on Japan. Japan slaughtered China. Britain colonized the world. I won't even say what Germany did. And yet, those countries are globally respected.

That CEO has been retired for a very long time. Nowadays Microsoft uses Linux to run their own servers and apps.

It's also worth noting that GitHub, VSCode, npm, Azure are also their products. Their representatives also put weight into development of things like OpenTelemetry, CNCF (cloud native computing foundation), WASI and many other important things.

Collapse
 
vectorjohn profile image
John Reeves • Edited

The first example in "why use typescript" is not an example of Typescript not catching an error. It's an example of Typescript working exactly right. You said "TypeScript doesn't recognize the type mismatch and type-checks the code successfully" - there is no type mismatch. You literally said the function push accepts arrays that contain numbers and strings. So pushing a number into it is perfectly fine. Arrays that contain mixed types is allowed, how else would you type something like that?

If you want to do what it looks like you _meant _to write, you would say:
function push(arr: Array<number> | Array<string>) ...
or if you didn't want to look like you read the TS hello world yesterday:
const push = (arr: number[] | string[]) ...

In other words a function that accepts arrays of numbers or arrays of strings. Then it would notice that you didn't check the type in the arr.push call. Perfect.

Also your Rectangle class example is misleading. You say you're just comparing Typescript to JSDoc but they are two very different programs. Your JSDoc version doesn't allow strings and you're comparing it to a Typescript version that does allow strings. You also wrote it in a very naive way that should really be cleaned up. If you want to (very weirdly) allow string | number everywhere, make that a type. type RectAttr = string | number, then use that everywhere. Bam, cleaner and more informative than the JS one. But since your JS version just completely blindly accepts any input and happily coerces it to number at runtime, it's not really showing the strengths you think it is. It sucks, frankly. What good is a program that runs without complaint when I write (new Rectangle({})).calcArea()? That shouldn't get past anything but it does.

As others have suggested, this sounds like just an error of not having any experience using Typescript. This isn't even advanced stuff, that's the basics. I recommend you take some time and learn Typescript, once you actually get past hello world, it becomes apparent that it's very powerful.

There may be reasons to have misgivings about Typescript, possibly. But they'd have to be reasons that vanilla JS is better, and it simply isn't. This is very close to not even being a matter of opinion anymore. Even a mediocre type system (and TS is an excellent one) is better than none.

Collapse
 
wiseai profile image
Mahmoud Harmouch • Edited

or if you didn't want to look like you read the TS hello world yesterday:

Arrow functions are now a higher standard, ok.

As others have suggested, this sounds like just an error of not having any experience using Typescript. This isn't even advanced stuff, that's the basics. I recommend you take some time and learn Typescript, once you actually get past hello world, it becomes apparent that it's very powerful.

Alrighty. We have a TypeScript Chad over here. I have put this simple example intentionally just to show how people are ridiculously good at throwing insults, rather than pointing out how the compiler can sometimes act drunk. Since you have some TypeScript experience, I suppose you worked with enums before. So, could you please tell me what's wrong with the following enum?

enum ChatStatus {
  Online,
  Offline,
}

let chatStatus: ChatStatus;

chatStatus = 999999;

console.log(chatStatus)
Enter fullscreen mode Exit fullscreen mode

And guess what? OMG, The strict mode is enabled! Could you please tell me what is the point of enums if it doesn't limit the values to just 0 and 1?

JS is better, and it simply isn't.

It would be great If you could prove that TS is better than JS.

Here you go another example when the compiler assigning the type to any which is a valuable type to have, I guess?

interface Foo {
  objects: { id: number; }[];
}

class TestFoo {
  foo: Foo | null;

  doSomething(ids: {}) {
    if (!this.foo) return;

    for (let index in this.foo.objects) {
      const object = this.foo.objects[index];
      const objId = object.id();

      if (!ids[objId]) return;
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Result:

any type

That said, I doubt that TypeScript is worth learning like at all. It trips you up a lot more than just writing vanilla JavaScript. In my experience, the benefits of using TypeScript are not worth the trouble it causes.

Have a good day.

Edit: I am not going to list every single flaw / common pitfall in TypeScript. You get the point. However, One fact still stands:

TS is NOT better than JS.

Collapse
 
vectorjohn profile image
John Reeves • Edited

With the enums, well, congrats you found a skeleton in the closet of the language, a bad design choice made early on that they are trying to fix but are kind of stuck with. I'm sure Javascript has none of those. Enums just shouldn't be used in my opinion because they are not actually enums. As designed, they're meant to represent bit flags unless you use string enums. Instead, one should just use unions or one of the many other more enum-like things.
Keep in mind, Typescript isn't C# or Java, you have to actually learn it not just assume all the constructs work the same way.
Anyway, on to your next example. That doesn't compile for me. When I write const object = this.foo.objects[index] it fails with "object has implicit type any". As expected. This is from the noImplicitAny flag, which is also enabled by simply using strict mode as many of the comments in this thread have told you repeatedly is the standard if you want type safety.
The any type only exists to babysit old bad Javascript code and idioms. It shouldn't be used explicitly nor should you allow things to implicitly become any, which is why the noImplicitAny flag exists.

It trips you up a lot more than just writing vanilla JavaScript.

This is an assertion made without experience. There is no way this is true, javascript has libraries of books and exobytes of websites dedicated to teaching people how to avoid all the pitfalls and rough edges of Javascript, not use certain dangerous language features, and on and on. It trips up beginners and newcomers to the language by acting differently than expected (especially with people who think it's similar to the language it is named after). The language is full of surprises and weird behavior, it's practically a meme. Typescript takes many of those lessons learned and enforces them with a compiler which is eons better than a human at actually finding errors.

You're taking these few odd edge cases that many people never even noticed after using Typescript for years and saying because of this odd edge case the language is bad and not useful. This is absolutely hilarious and ironic coming from someone advocating for Javascript.

TS is significantly better than Javascript and to me, that's an objective fact. There may be some reasons to like JS still, from time to time, but usually not. Development time is faster in Typescript, quality is better, readability (the actual most important part of code) is better. All the complaints you may have about Typescript apply just as well to Javascript, but none of the benefits of Typescript apply to Javascript. You find weird edge cases that don't come up in practice and ignore the 99% of the time where the language does exactly what you expect.

As a professional software developer with 20 years experience and most of those using Javascript, I would never go willingly back to Javascript and actively promote upgrading Javascript (or Java for that matter) code into Typescript where possible. I also recommend against hiring anybody who would argue things like Javascript being preferable. Typescript is just so much easier to use and better on every level.

Thread Thread
 
wiseai profile image
Mahmoud Harmouch

A bad design choice made early on that they are trying to fix but are kind of stuck with.

Ah, I see.

Enums just shouldn't be used in my opinion because they are not actually enums.

That's what I have learned from this example.

Instead, one should just use unions or one of the many other more enum-like things.

I see.

which is why the noImplicitAny flag exists.

Got it!

Keep in mind, Typescript isn't C# or Java, you have to actually learn it not just assume all the constructs work the same way.

I am not sure if I am the only one who doesn't understand the motivation behind TypeScript, but I will give it a shot. First of all, C#, also created by Microsoft, is a strongly typed language that can be used to create web applications. However, JavaScript is a dynamically typed language that can be used to create websites. So, my question is, what is the place for TypeScript in this equation? Don't get me wrong. I am not saying that innovation is a bad thing. What I meant to say is that it looks like TypeScript doesn't seem to me fulfilling a practical use case. However, it is highly likely to be acting like a bridge between C# and JavaScript, allowing developers to use familiar syntaxes while leveraging the power of dynamic languages like JavaScript. In this case, that would make sense.

The language is full of surprises and weird behavior, it's practically a meme.

Exactly. Hahahaha.

Typescript takes many of those lessons learned and enforces them with a compiler which is eons better than a human at actually finding errors.

Cool.

You're taking these few odd edge cases that many people never even noticed after using Typescript for years and saying because of this odd edge case the language is bad and not useful.

Alright!

As a professional software developer with 20 years experience

Now, we are talking.

I also recommend against hiring anybody who would argue things like Javascript being preferable.

Lol. Really? But, I think that advocating for either JS or TS is the same thing. Since you will end up with JS code in both cases. However, I think that C# is a better option than TS in my opinion.

Typescript is just so much easier to use and better on every level.

Will see.

Collapse
 
brense profile image
Rense Bakker

Your enum example has nothing to do with enums.

You are reassigning the chatStatus variable, it's not longer an enum. Its the same as complaining your array is no longer an array when you reassign it:

let someArray = [1, 2, 3]
someArray = 'now its not an array duh'
someArray = 42
someArray = undefined
// what is your point?
Enter fullscreen mode Exit fullscreen mode

Obviously if you reassign a variable its not going to complain, since you are reassigning it... Reassignment is not a typescript thing, its a javascript thing. Thats how javascript works and since typescript is a superset of javascript, its also how typescript works.

This DOES throw an error:

enum ChatStatus {
  Online,
  Offline,
}

const chatStatus: ChatStatus = 999999
Enter fullscreen mode Exit fullscreen mode

This would ALSO throw an error:

enum ChatStatus {
  Online,
  Offline,
}

type User = {
  chatStatus: ChatStatus
}

const someObject: User = { chatStatus: ChatStatus.Offline }
someObject.chatStatus = 999999
Enter fullscreen mode Exit fullscreen mode
Thread Thread
 
wiseai profile image
Mahmoud Harmouch • Edited

Your comment shows the lack of understanding of what is the point of enums like at all. Besides readability, enums are used to limit the values in a certain range. In Java for example, you can't do this because 999999 is a value outside the enum range [0 for Online, 1 for Offline]. Moreover, enums are mainly used in facade design pattern.

Back to your rambling, you can't assign, however, a value of type string to an already declared number variable:

Image description

In the case of enums, the compiler should complain that 999999 is outside of [0, 1].

That's the whole point.

Have a nice day/evening.

Edit: I think TS is following the same C# philosophy where it can accept any value that a number can. That's why 999999 doesn't throw any exceptions. Alrighty.

Thread Thread
 
brense profile image
Rense Bakker • Edited

Your point is that you want typescript to work exactly like C# Have you considered just using C# then?

In any case, congrats, you found one quirk in Typescript. Enums are implemented kinda shitty, according to you that invalidates the whole concept of Typescript... Good for you. Luckily most other developers are capable of being a little less biased. If you need to have typesafe enums in Typescript, you can try to not be an obnoxious hater and use unions like everybody else:

type ChatStatus = 'Online' | 'Offline'
let chatStatus:ChatStatus = 'Online'
chatStatus = 9999
Enter fullscreen mode Exit fullscreen mode
Thread Thread
 
wiseai profile image
Mahmoud Harmouch

Typescript, you can try to not be an obnoxious hater and use unions like everybody else:

Yup, that's what most folks suggested.

Thread Thread
 
brense profile image
Rense Bakker

You could have done somesthing constructive and wrote an article about why not to use enums in Typescript, explain to people its better to use unions. You would get less, but much better responses and people would actually learn something. Or if you have a suggestion on how Typescript SHOULD implement enums, you can make a pull request on their repo: github.com/microsoft/TypeScript or create an issue: github.com/microsoft/TypeScript/is... they are pretty open for constructive feedback from users.

Thread Thread
 
wiseai profile image
Mahmoud Harmouch

You could have done somesthing constructive and wrote an article about why not to use enums in Typescript, explain to people its better to use unions.

Noted.

Or if you have a suggestion on how Typescript SHOULD implement enums, you can make a pull request on their repo: github.com/microsoft/TypeScript or create an issue: github.com/microsoft/TypeScript/is... they are pretty open for constructive feedback from users.

I am afraid to contribute to that repo cause, by now, every engineer at MS thinks I am mentally disabled or something along this line. LMAO.

Collapse
 
joelbonetr profile image
JoelBonetR πŸ₯‡ • Edited
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.

Yeah... I mean... Abso-freakin-lutely!

Just the same that happens when you start a project with any language and platform.

The cost of redoing that is related to the team's expertise on the old and new language/platform/framework as well as the LoC, complexity, maturity (of both the project and the team) and quite a few points more.

Still I can't see why TS is set here as example, it's honestly worse with vanilla JS.

On the other hand that's one of our jobs (for us Tech Leads and software Architects) to do the right tech choices based in different points we need to weight and tackle before even a developer writes a LoC.

I am a big advocate for JSDoc, not as a replacement for TS but because the reality is that there are way more vanilla JS projects than TS + Flow + whatever new type-system-for-JS combined, and using JSDoc along TS Pragma makes it way easier to migrate the project to TS later on.

On small to middle projects, JSDoc may suffice with the condition that you set some automatic checks to ensure JSDoc is not only added to new functions but maintained when refactoring/modifying existing ones.

On middle to large projects TS is the choice. Flow is nice and so but we're not a research institute (at least in any company I worked in), that's the real market and the decisions should be backed; TS has a large community and maturity thus it's the option (like it or not).

Last but not least I won't let THIS kind of code to be merged into develop. You know? This code that's complex for the complexity, not splitted enough, bunched with arbitrary stuff... A.K.A. "overengineering", bad practices, "look how complex this looks, gimme a rise" and so on and so forth.

This just depends on the people doing the CR and just like with management, PO, DM or any other responsibility job position... You can get either lucky or burned depending on who's sitting on those chairs, and that my friend is not TS's fault.

But if any reader got the stars aligned in a good project and still doesn't like what he's doing, then you're either burned down or you lack the required skills for the job you're doing, and the solution for both is to find a new job.

Hope it helps somehow,

Cheers!

Collapse
 
wiseai profile image
Mahmoud Harmouch

I appreciate your feedback on this matter. I am in agreement with many of your opinions. However, the following could be a valid argument, but not a strong one. One could argue that reformatting code from JavaScript to python or any dynamically typed language is much simpler than reformatting code from typescript to python. This is because when refactoring from JavaScript to python, you don't have to worry about removing the types that were present in the typescript code.

Refactoring from typescript to python however requires more work as you have to manually remove all the types that have been declared in the source code. This can be a time consuming process and may lead to errors if not done correctly.

Thank you for responding. I am a big a fan of your work/opinions! Let's keep fighting!

Collapse
 
joelbonetr profile image
JoelBonetR πŸ₯‡ • Edited

Hi Mahmoud,
Thank you for your answer!

Let me tear this down a bit.
While that could be true in certain situations, it's not usually the real experience.

First of all, there are almost no reasons to translate "literally" from JS to Python.
Reasons:

  • Python doesn't work for frontend (you'll need to add JS inside Python anyway and/or use a template engine like Jinja), if you're about to do SSR it's better to use Next JS or similar straightforward (good for horizontal scalability, finding devs for the project, UX and so on).
  • Node is -usually- faster than Python for backend purposes, way better for availability and you'll end up adding a Node JS gateway at least so why add a new language to the equation? it will only harm your ability to find new devs.
  • If you're about to add a new language it will probably be Java, C# or similar, due to the ecosystem around them which can add benefits at the top of what JS or Python can offer.
  • If it were a task for python such ML, NN... you'd already have coded it in python instead.
  • If you need Python (or any other language) for any reason to tackle down a critical building block in your APP it will probably be a webservice/endpoint and not replacing the others that already work great.

On the other hand, it's not a matter of "I have to remove the types manually" as something that bothers you.
Having the types brings you the possibility to slowly but surely write similar functions for the necessary use-cases without the frightening errors in runtime that the QA will point out few minutes after the merge of your PR (or at least way less than without having type hints).

On the other hand, Python does have type hints that work in dev time (just like TS) thanks to IDE implementations and are a nice to have as well.

So, for this given TS function:

const sayHello = (name: string) => `Hello ${name}`;
Enter fullscreen mode Exit fullscreen mode

you will probably write this in Python:

def sayHello(name: str) -> str:
    return 'Hello ' + name
Enter fullscreen mode Exit fullscreen mode

and the equivalent in JS would be

const sayHello = (name) => `Hello ${name}`;

// or 

const sayHello = (/** @type {string} */ name) => `Hello ${name}`;

// or

/**
 * Returns hello {name}
 * @param {string} name 
 * @returns {string}
 */
const sayHello = (name) => `Hello ${name}`;
Enter fullscreen mode Exit fullscreen mode

Depending on the project (to be honest, it's usually the first use-case πŸ˜‚)

If I was to say something negative around TS is that it sure takes more time to having things done than JS at the beginning and maybe compile transpile times can be itchy, specially if you have a low-spec computer (I'm so used to transpile JS using babel, webpack, Parcel... that few seconds are not doing the difference at all) and of course that the learning curve is higher, but assuming you got the basics on CS you already checked C/C++, Java and many other languages that are for sure more complex in depth than JS/TS hence... idk, it may be just a matter of point of view and self experience 😁

Thread Thread