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.
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.
That doesn’t seem a fair assessment at all. In strongly typed languages the types are part of the base syntax and usually not onerous, but rather straightforward to write. In TypeScript they’re tacked on in a way that makes quite a lot of work for developers while also making the code difficult to read and reason about (although good syntax highlighting certainly helps.)
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.
Well yes, if you don’t take care of properly typing external data, you won’t have it properly recognised. But that’s the same in any language that e.g. consumes external JSON data. Use the tools that Typescript gives you (like type guards) or the tools the community has built (like io-ts).
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.
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.
How even dare you. PR denied.
I would say sorry, English isn’t my first language but that would be a lie 😬
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.
That doesn’t seem a fair assessment at all. In strongly typed languages the types are part of the base syntax and usually not onerous, but rather straightforward to write. In TypeScript they’re tacked on in a way that makes quite a lot of work for developers while also making the code difficult to read and reason about (although good syntax highlighting certainly helps.)
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.
Well yes, if you don’t take care of properly typing external data, you won’t have it properly recognised. But that’s the same in any language that e.g. consumes external JSON data. Use the tools that Typescript gives you (like type guards) or the tools the community has built (like io-ts).
For your API issue, have you tried using type guards or something more sophisticated like Zod?
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.
Does anyone use Turbo outside of Basecamp?
“We need exposure to this known set of bugs”