The developer experience is excellent with Typescript. It's so much nicer to get auto complete suggestions based on a type system rather than mostly heuristics in plain JS. Refactoring is breeze. I enjoy using TS. I enjoy basic correctness guarantees caught at transpile time.<p>Of course there's trade-offs, but the whole article is a list of unconvincing appeals to authority.<p>And then the author ends with:<p>> Our tendency to just blinding reach for tools because it’s what Google or Facebook does often just makes things worse for both developers and the people who use what they build.<p>You spent 4 paragraphs giving examples of other people using plain JS as the reason we should be blindly switching back to plain JS. Svelte swapped back to JS for n reasons that aren't applicable to you or most people.<p>> I help people learn vanilla JavaScript, and I believe there’s a simpler, more resilient way to make things for the web.<p>> I create courses and ebooks, run online workshops, and host the Vanilla JS Podcast. My developer tips newsletter is read by over 14k developers each weekday.<p>Oh.
I have not been able to jump on the TS train. For the longest time, it has just not quite felt right. Adding layers upon layers of complexity for a static type system and some related syntactic sugar, all while guaranteeing that it remains a superset of JavaScript has left it in a similar position to C++. It’s fragility has left it with a house of cards-type feel with unending dependency trees and poor visibility into itself as a runtime.
> I’ve been a developer for a decade now and never run into an issue where JavaScript’s loosely typed nature has created a problem for me.<p>yeah... ok
Cannot disagree more. The author is either a Javascript savant or has never worked on a 100k LOC Javascript project.<p>I remember the days before Typescript, chasing down those “undefined” Javascript bugs. Not fun.
For smaller applications, an acceptable middle ground is using the TS language server[0] and JSDoc[1] comments.<p>Writing<p><pre><code> // @ts-check
/** @type {number} */
let x;
</code></pre>
works very well for example in VSCode. The JSDoc comments are not as convenient as Typescript, but otherwise the experience is almost the same. The language server correctly keeps track of the types for me.<p>[0]: <a href="https://www.typescriptlang.org/docs/handbook/intro-to-js-ts.html" rel="nofollow">https://www.typescriptlang.org/docs/handbook/intro-to-js-ts....</a>
[1]: <a href="https://jsdoc.app/" rel="nofollow">https://jsdoc.app/</a>
> Incremental compile time when changing files in cli/js takes minutes. This is crushingly slow and painful to modify.<p>This is in my opinion the worst offender of TypeScript. TSC is insanely slow even in incremental mode for large code bases, and no alternative compiler exists. There are projects which <i>can</i> strip types and convert TS into JavaScript, but they do not check types.<p>Alternative implementations have been swatted down by TypeScript maintainers like Daniel Rosenwasser, with the leading argument being that the TS spec moves insanely fast and keeping two or more implementations up to spec would not be worth it due to the work it would require.
I do wish we were in the timeline where we got a super powered jsdoc, instead of TS.<p>Something like that would be my guess for what’s next, once this current trend has run its course.
I could definitely see the benefit of TS on a giant, modern app with a big team. However, at my job I am a solo developer on literally dozens of smaller JS projects of varying age that I need to keep running essentially forever. Typescript is enough of a pain in my npm build process that I just ditched it long ago. The fewer dev dependencies the better for me personally.
For small things, sure. Substantial things like apps, its like shooting yourself in the foot before you've ever begun, and good luck refactoring anything with any confidence short of covering your whole app in tests.<p>Also, I think the examples given in the article are circumstantially exceptional, if you read more closely into the why.