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.

Thanks for saying this.. I use TS religiously and haven’t been able to go back since diving in, but man is complex Typescript hard! I’m building a DAW right now with pretty large interconnected, dynamic systems and the TS is getting really mind bending with all of the layers of inheritance and generics. A functional architecture as opposed to this OOP one would probably make life easier… but those decisions were mostly out of my control early on.

That being said, as a Svelte user, I really wish Rich would stop dragging his feet on Typescript as much as he does (no TS in markup is a huge bummer). I can’t complain too much though.. the Svelte Compiler is a magnificent beast and I couldn’t write it let alone contribute to it in a meaningful way. If leaving Typescript to the other maintainers helps him be more productive, so be it.

A DAW in TypeScript? How can I learn more about this?

It’s currently private unfortunately but the client is considering open sourcing it once were done using it in a few upcoming projects! Will ping you when that happens.

Nice, that would be great!

> One of the first steps in learning TS is to change the way you write code to make it easier to type.

I think this is a correct answer. TS is just a different language happened to interop js easier than the others.

Fully agree.

Additionally, many of these devs are arguably masters at vanilla JavaScript. Some learned JS before modern features became available. They probably don’t need ES5 features to be productive, let alone the newer features or for that matter TypeScript.

The frustration is that they would probably benefit from using TypeScript in the long run.

I agree. I am a going-greybeard who plateaued at one point in the IE5/6 era building ambitious cross-browser apps using direct-DOM vanilla JavaScript.

I resisted learning TypeScript because it felt like coding with handcuffs on.

I was sold on it when I realized how much easier the handcuffs make it to accept code contributions. I've internalized TS enough that I still get to flow state on my own code. Whole categories of rookie mistakes no longer interrupt my blissful concentration, because they are caught by tooling before making it in to a pull request.

> TS has a powerful Generics syntax that cannot be duplicated in a code comment.

This is false though, but admittedly not documented well.

How can a comment provide useful generics? I'm genuinely curious.

So say we had code like this:

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

We could put this as a jsdoc-style typescript comment just before the `const safeSplice` line:

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

or as a multi-line type declaration:

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

Alternatively, you could do something like this in place of the above:

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

I started out doing the former because I liked using the typescript notation, but I ended up doing the latter more often as I could leave the return type off the signature, which I prefer to do

This is really cool! TIL. At this point though, I feel like you might as well just use Typescript, no? You’ll get more features / tooling and cleaner syntax. I’m intrigued to learn more about advanced JSDoc now though, if anything to be more prepared if I’m ever forced to work with it in the future.

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.

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.

I had similar concerns early on with TS, but they have adhered closely enough to being "ES+types" and done so with such success that it would be hubris to implement a new ES standard type system.

I know I can eject the types and go back to ES, but at this point I trust TS is going to be highly relevant for at least 5 years with a long tail.

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.

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

6. Statistically there's number of data points and there's also weight.

3. Yeah people do that but then the vibe of "language" is gone, just a linter.

5. No jobs.

4. That's why it's not a good idea to coerce dynamic type lang, it barely ends well.

1. Same as 3.

2. Yes

> 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/

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

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

There are specific reasons depending on the project context.

But I'm not speculating ;p I just wonder what arguments could be. "it depends" is generally unuseful for particular context, I interpret it as blank statement.

What I'd expect is .. oh those mostly write libs and frameworks so it's not good fit for that, but then .. well the world of software is compose of libraries.

Public discussion is good! I think that's the point of Ask HN.