Ask HN: Why JavaScript experts tend to not use TypeScript?

Why don't you ask them and tell us instead of speculating? ;)

There are specific reasons depending on the project context.

I think there is a fear TS will be deprecated in favour of a newer version of JS that supports what TS offers. I still remember back in ~2016 when a company I was working for was heavily invested in CoffeeScript. Granted, CoffeeScript was awesome and introduced some syntactic sugar (e.g., Class) that made the code easier to modularize and read. Nowadays JS brings almost all the nice things CoffeeScript was bringing to the table, so there is no need for CoffeeScript anymore. They are still working with CoffeeScript because refactoring the whole damn thing would cost a lot and they cannot justify it.

I think somthing similar may happen to TS.

Two of the links you listed have pretty good reasons:

The creator of uhtml believes there are transpilation bugs. I can't say whether this is true, but if it's an issue for them, I guess that's a valid reason.

Jason Miller's tweet also includes a common reason: he isn't good at it and doesn't understand it, or in his words "the amount of time I have to spend screwing up my already-working code to make TypeScript happy". This is a big one. TypeScript is hard, and poorly written TypeScript increases complexity. My last job was a TS codebase written by people who didn't understand it and it was a major impediment to productivity.

The Rich Harris tweet represents a common misunderstanding about TypeScript types. If your types can be represented by primitives like `string` or `number`, then his JSDoc approach is fine, but when writing TS those sorts of primitives are barely scratching the surface. For example, TS has a powerful Generics syntax that cannot be duplicated in a code comment.

TypeScript is very complex because it needs to be able to type all valid JS code, which means being able to describe things that most other languages would never even allow. JavaScript is very flexible and permissive, and all of us are used to working with them in a way that's hard to type. One of the first steps in learning TS is to change the way you write code to make it easier to type. You have to make decisions earlier in the process, and yes, there is usually more time spent writing code initially, but if done well, you can screen out a lot of bugs.

IMO these devs have the luxury of not using TS because they can expect the community to provide the types for them.

  const safeSplice = (items, start, deleteCount, ...itemsToAdd) => {
    const copy = [...items];
    const deleted = copy.splice(start, deleteCount, ...itemsToAdd);
    return {
      deleted,
      list: copy,
    };
  };

  /** @type {<Item>(items: Array<Item>, start: number, deleteCount?: number, itemsToAdd?: Array<Item>) => { deleted: Array<Item>, list: Array<Item> }} */

  /** @type {<Item>(
    *   items: Array<Item>,
    *   start: number,
    *   deleteCount?: number,
    *   itemsToAdd?: Array<Item>
    * ) => {
    *   deleted: Array<Item>,
    *   list: Array<Item>
    * }}
    */

  /*
   * @template Item
   * @param {Array<Item>} items
   * @param {number} start
   * @param {number} [deleteCount]
   * @param {Array<Item>} itemsToAdd
   */

There are situations where you want a loosely typed scripting language, and there are times you don't.

1. Use `noEmit` if you don't want to use the transpiler -- You can also use babel.

2. Use a modern target, my transpiled code is 1:1.

3. You can use JSDoc type annotations, I use this for some projects.

4. TS works well in functional code bases. If you prefer JavaScript's dynamics, expect pain.

5. You can also use Flow.

6. Your sample size is 3

For me: 1. Drag on productivity (slower to refresh/recompile & much slower to write)

2. Harder to grok code (spaghetti)

3. I don’t want to give Microsoft any more leverage over the development ecosystem

4. TS will likely go the way of CoffeeScript eventually

5. TS is massively complex because of the difficulty of typing JS, I’d much rather use a language designed from the start as a strongly typed language.

6. The types are removed after compilation, so they’re only helpful during development.

However, I do like to add JSDoc types and run the Typescript compiler to check things and generate types for TS users.

> The creator of Svelte (not go all-in)

[SvelteKit] (official Svelte framework) uses TypeScript quite a bit.

First, the internal code was ported to TypeScript, then DX for TypeScript was added. The official template supports JSDoc TS (default), TypeScript, or no typing.

I think another community member added TS support, and Rich said he couldn't have done it by himself. (Or maybe that was regarding the VS Code TS support tooling.)

[SvelteKit]: https://kit.svelte.dev/

For me TypeScript is something that you need when you want to solve a big problem with constrained typed code. I have written way too much JavaScript in my career that I know what is going on and sometimes the types given for libraries and frameworks just are wrong, out of sync or just get in the way of doing stuff. When writing regular JS I would just make a comment that if the reader hadn't seen this before what is going on but with TS I am denied that behavior and instead restricted to some type someone wrote and TS complaining that I am not doing the thing the way someone defined it as (why aren't you coding like this? I specifically requested it!).

Essentially, TS feels like training wheels for small codebases and red tape for large codebases. I do feel it helps for large codebases where someone might not be familiar with everything but reading the code works way better than types. If someone can not understand the code then that means: 1) it is not documented correctly, 2) the person needs more instruction/tutelage, 3) it is probably incorrectly implemented or 4) something more clever.