What's going on with typescript?

Some rather big projects started to remove TS, which upset the community. One if not the biggest is Turbo, from the Ruby-on-Rails guy. He said: "[TS] pollutes the code with type gymnastics that add ever so little joy to my development experience, and quite frequently considerable grief. Things that should be easy become hard". Now there is a bit of a battle whether or not TS is actually all that great.

In my experience, that means they're doing it wrong.

I find that Typescript adds a lot of joy to my development experience. And I haven't need any "gymnastics" since I invested in learning Typescript.
- I haven’t need any
  
  need any
  
  any
  
  How even dare you. PR denied.
- Same, but I come from a C++ background so strong typing is in my blood. This sounds like people who write bad code complaining because the language/transpiler won’t let them write bad code.
- I don't do java- or typescript but that guy's comment definitely translates as "I want to keep on writing messy code and you can't force me to learn to clean my shit up".
- I've heard it's more of a problem on the library side. But I've personally had pains with ts when working with quirky features such as enums or discriminating unions. Part of the problem in my opinion is that the types all disappear at runtime, so you lose a lot of the joy of a statically typed language. For example, an API can pass you unexpected garbage and all your ts type wrangling helps not at all.
is there any real reason?

what are the projects that are removing ts?
- They just say the typing is too much and JSDoc is good enough for them as they get intellisense from it.
  
  Svelte, Turbo and a few others I think.
- It's more for library devs when writing their libraries. Using TS means you're writing in one language and then distributing the compiled version for users.
  
  As users can use things in a lot of different ways you have to do a lot of type "gymnastics" to make your library API as useful as possible.
  
  That means spending a lot of time setting up types when a jsdoc and .d.ts file will do the same thing for library consumers.
  
  It's really a non issue. If some library devs think they can ship code which is easier for them to maintain correctly, and end users have the same developer experience, then it's totally cool.
  
  Of course people with no nuance are using this as an argument for why no one should write in typescript (because they don't like it for some reason). This thread has a bunch of people doing this. That creates drama, but there really shouldn't be any. TS is bae for me, but I totally get why library devs might want to not use it.
The guy is a tool and should be ignored.
"We need exposure to this known set of bugs"

I'm not really involved in javascript land so im parroting off of what i've heard for "why js over ts?"

it reduces file size since you no longer need to ship source maps
ctrl+clicking stuff will take you to the definition rather than an unhelpful type declaration
if you spot a bug in the library, you can edit the source directly than having to recompile/reimport
ts adds some unnecessary type "gymnastics" (can't speak for what this means), when all they really want is intellisense thru jsdoc

So mainly: devs who don't prefer strongly typed languages, and library devs who find typescript to be less transparent and more time consuming for new and old contributors than it's worth

Why do you have to ship a source map? It compiles to vanilla js

Not sure what editor, but in neovim (which uses tsserver on my end for LSP) I can either jump to the type declaration or the actual implementation. This is a tooling problem not inherent to typescript

This doesn't make any sense. You'd have the same problem with minified js or css etc.

It means they are forced to use types properly and do the tiniest bit of thinking and planning that results in fewer type errors (think undefined variables and properties, etc)

Not a bad summary, but I take issue with all the points

Edit: The sourcemap comment is relevant to package size and not to final bundle size per the HN comment linked below. Also, the cmd+click critique rings truer now that I know it's in the context of an installed package. Another critique is build time which is fair enough.
- I understand why some hobbyist individuals with small-ish scripts might not see the value, even though I even still disagree there.
  
  The more code and people touching the code, the more value you'll see.
- Thanks :) I didn't see anyone mention the points made by the svelte guys https://news.ycombinator.com/item?id=35892250 which is a shame since I thought they made better points than the dramatic "type gymnastics" argument haha (i am biased toward type-safety, as long as there is idiomatic, algebraic data types w/ pattern matching)
  
  Overall it sounds like a major change with a few minor/moderate benefits, but it's their choice and time will tell if it was worth it :P

Where do y'all get your programming drama? I'm missing out

https://lemmy.world/post/4786575

Saw a couple of posts like this one.

Edit: I just went on local new on programming.dev and this was the second post: https://programming.dev/post/2807882

Basically some JS library devs have decided that JSDoc will work better for their specific use case as libraries than TS.

As a person who has been writing JS for a very long time, and was building SPAs before the term existed...

It all comes down to return on investment. The arguments I always hear in favor of TS are solutions to problems I've never had, at the expense of writing more code to do the same amount of work.

It's the same for people who tell me that they think everything should be tested then show me the tests they spent the last 40 hours working on, which I can quickly see are extremely brittle and unlikely to ever show any ROI. You will never be able to test every scenario, increasing the amount of things you test arbitrarily just increases the cost of building and maintaining your software. Each test you add should be something worth building and maintaining.

Excess code that isn't providing value is far more detrimental than not having a few extra tests or type safety.