And the truth is that TS got popular not because of types and certainly not type-safety (though that term gets bounced around alot leading to (I presume) a false sense of security) but because these application developers are infatuated with editor/IDE features like C#/Visual Studio and Java/Eclipse developers before them.
Granted Babel had already introduced that compilation step but it was perfectly happy as long as your JS was syntactically correct.
I like types; I just don't like how TS deals with them; ultimately TypeScript is still JavaScript, i.e. JS is not “just a compile target”; TS deliberately accepts limitations so that it can be gradually adopted in a JS code base (though from a working JS code perspective TS is a subset of JS; TS is only superset in terms of language features). Well then …
Then esbuild and Vite happened; as long as your TS made sense on the JavaScript level, they would generate runnable output quickly without having to deal with tsc or LSP complaints.
So now you can forge ahead experimenting a bit using TS-syntax with near instantaneous transpilation either before you decide to just delete it or perhaps keeping the experiment and even writing a few tests before taking the time to address tsc's issues with the types.
Finally it was reasonable to use TypeScript for what it is actually good at: to lint JavaScript types (just because your types check doesn't mean the code is type-safe—it's probably mostly type-safe).
“If you can't beat 'em, join 'em”
So now that you found a use for TS, the inconvenient truth is that despite TS's flaws you might as well learn it far better than most people who “use” it and evangelize for it.
TypeScript is easy for those who largely consume pre-typed libraries through LSP supported editors but if you tend to write lower level JS code in order to minimize dependencies using TS's type language to explain to tsc that your code is just fine can become a bit of a chore until you are much more comfortable with its extract types from value space into type space approach.
The bonus of knowing it well is that you can keep pointing out to TS fans how flawed TypeScript actually is.
Once you get to a certain competence level you can start to entertain adopting TS JSDoc where it makes sense.
Leading provider of intuitive and powerful APIs designed for seamless business integration. With a focus on real-time, accurate data, aiming to drive operational efficiency and decision-making for its
Nobody cares what you do for internal projects except perhaps the people who have to work on it now and in the future.
However once you have published interfaces, TypeScript support for your users is now table stakes—TypeScript support is now part of the cost of doing business.
I remember in March 2020, I liked the fact when I took Svelte 3 for a spin that it wasn't TypeScript centric but the lack of TypeScript support was hurting its adoption at the time.
All that changed in July 2020 and that shift was likely instrumental in its move into 4th position behind React, Vue, and Angular (and getting support from Vercel).
The kerfuffle around SvelteKit's move to JSDoc in May 2023 really just highlighted how many TS developers don't understand the finer details of the tool chain they work with on a daily basis.
Moving forward SvelteKit wasn't abandoning TS support for their users but they had simply decided to internally shift to a workflow where TypeScript wasn't used as a language but only as a type linter.
That gave them full control over the runtime JavaScript and removed the TypeScript syntax as a barrier with respect to any tooling they wished to leverage.
The issue with the DHH situation (September 2023) was that he discarded pre-existing project type information and put any future typing effort squarely back into userland (which tends to be less than ideal as user type contributors are often not familiar with the packages core functionality which can influence user types).
In some ways your projects may benefit from people who are capable and willing to sling TS JSDoc.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Because it adds a compilation step while still not doing it's job properly compared to something like ReScript; I call that poor ROI.
And the truth is that TS got popular not because of types and certainly not type-safety (though that term gets bounced around alot leading to (I presume) a false sense of security) but because these application developers are infatuated with editor/IDE features like C#/Visual Studio and Java/Eclipse developers before them.
Granted Babel had already introduced that compilation step but it was perfectly happy as long as your JS was syntactically correct.
With TS your have to explain your program on TS's terms before it will finally shut up and give your runtime code.
I like types; I just don't like how TS deals with them; ultimately TypeScript is still JavaScript, i.e. JS is not “just a compile target”; TS deliberately accepts limitations so that it can be gradually adopted in a JS code base (though from a working JS code perspective TS is a subset of JS; TS is only superset in terms of language features). Well then …
“I often wish I worked in a language where I could start dynamic and end statically”
Then esbuild and Vite happened; as long as your TS made sense on the JavaScript level, they would generate runnable output quickly without having to deal with
tscor LSP complaints.So now you can forge ahead experimenting a bit using TS-syntax with near instantaneous transpilation either before you decide to just delete it or perhaps keeping the experiment and even writing a few tests before taking the time to address
tsc's issues with the types.Finally it was reasonable to use TypeScript for what it is actually good at: to lint JavaScript types (just because your types check doesn't mean the code is type-safe—it's probably mostly type-safe).
“If you can't beat 'em, join 'em”
So now that you found a use for TS, the inconvenient truth is that despite TS's flaws you might as well learn it far better than most people who “use” it and evangelize for it.
TypeScript is easy for those who largely consume pre-typed libraries through LSP supported editors but if you tend to write lower level JS code in order to minimize dependencies using TS's type language to explain to
tscthat your code is just fine can become a bit of a chore until you are much more comfortable with its extract types from value space into type space approach.The bonus of knowing it well is that you can keep pointing out to TS fans how flawed TypeScript actually is.
Once you get to a certain competence level you can start to entertain adopting TS JSDoc where it makes sense.
Using Typescript without compilation
Pascal Schilp ・ Mar 26
Well Thanks a lot for sharing this, and adding to my list of arguments why I reject any suggestion of using TS in any project we have 🤙
Nobody cares what you do for internal projects except perhaps the people who have to work on it now and in the future.
However once you have published interfaces, TypeScript support for your users is now table stakes—TypeScript support is now part of the cost of doing business.
I remember in March 2020, I liked the fact when I took Svelte 3 for a spin that it wasn't TypeScript centric but the lack of TypeScript support was hurting its adoption at the time.
All that changed in July 2020 and that shift was likely instrumental in its move into 4th position behind React, Vue, and Angular (and getting support from Vercel).
The kerfuffle around SvelteKit's move to JSDoc in May 2023 really just highlighted how many TS developers don't understand the finer details of the tool chain they work with on a daily basis.
Moving forward SvelteKit wasn't abandoning TS support for their users but they had simply decided to internally shift to a workflow where TypeScript wasn't used as a language but only as a type linter.
That gave them full control over the runtime JavaScript and removed the TypeScript syntax as a barrier with respect to any tooling they wished to leverage.
The issue with the DHH situation (September 2023) was that he discarded pre-existing project type information and put any future typing effort squarely back into userland (which tends to be less than ideal as user type contributors are often not familiar with the packages core functionality which can influence user types).
In some ways your projects may benefit from people who are capable and willing to sling TS JSDoc.