>TypeScript never set out to build a separate, distinct, and prescriptive language. Instead, TypeScript had to be descriptive.
Sadly, the majority of people writing Typescript rarely care about descriptive and readable code these days. Somehow the focus shifted from using types to better understand complex systems through the code itself, to writing whatever polymorphic union type abomination that yields the best IntelliSense auto-completion in VSCode.
The polymorphic union type abominations are precisely because TypeScript is insistent on being a thin layer on top of JS.
In particular there is no built-in ADT syntax, but the type system does support ADTs using the aforementioned polymorphic union abominations, so it is possible yet tedious to write them.
They are in a tricky situation because TC39 really does not care about TypeScript at all when introducing new features into JS. So TypeScript is doing its best to avoid breaking future compatibility with a standard they have no control over. Sometimes this makes the language worse, but they are playing the long game.
I've had a very different experience than yours with the Typescript codebases I've encountered, which were mostly well designed.
I have no doubt codebases with polymorphic union type abominations exist, but I wouldn't say they are the majority, far from it in my experience.
It also seems to me those are a case of "problem lies between chair and keyboard", not a fault of the language. Bad code can be written in any language.
> I've had a very different experience than yours with the Typescript codebases I've encountered, which were mostly well designed.
Agreed. And in fact, the founders of a project having explicitly chosen TypeScript is often in and of itself an indicator that the team cares about code quality and writing style.
As you say, you can write poorly in any language. But people who care about quality choose TypeScript.
I agree, but I would like to say that this is more due to the limitations of TypeScript (and JavaScript) and the need for developers to work around those limits, rather than anything else.
TypeScript is great, but it is also still very far from being complete in my opinion.
I used to do mostly Java and a bit of TypeScript, changed teams and now do mostly TypeScript and a bit of Java, and this unfinished feeling is striking, even for relatively basic things (enums).
I think the modern compiler options / TypeScript rules such as "hey this variable can be undefined but you didn't specify it", "hey, it can also be null, don't forget that" are commandable, but just don't work well for the web. I know it's configurable, but it just makes for a bad experience.
Still, love TypeScript. I wouldn't do any JavaScript project anymore, installing the TS compiler is always my first step.
I‘m not well versed in type theory and some of the types libraries require, especially in the React ecosystem, really make my brain hurt. And sometimes it seems unnaturally hard to figure out what is even expected to type something correctly.
The whole reason Microsoft made TypeScript was so that Intellisense would work. Then that became part of the religion and elaborated on with millions of dollars of marketing.
This. Probably every TS codebase I ever worked in had zero to none function- or inline docs with people always claiming "documented by TS". I call that BS, and you can see that in their projects. "Typescript codebase" became the equivalent of "generic low quality codebase" imo.
I'll never understand why people need a programming language inside a programming language and refuse simplicity (i.e. using jsdocs, which has perfect IntelliSense support).
I tried jsdoc + JavaScript for a while to minimise the distance between me and the browser, but in the end TypeScript was just the easier choice. Less documentation to type, and the checks are better. I found that using TypeScript basically like JavaScript + jsdoc delivers the best value. I avoid any advanced TypeScript features as TypeScript is just not a proper statically typed language.
However I tend to only use /** a comment */ before a type definition or argument which will add the comment along with the type in autocomplete.
I get the feeling you've stumbled more on the debate about commenting code/inline docs vs code that self documents. My general impression of Javascript developers is that they are comfortable adding comments whereas Typescript people are not so comfortable for some reason. Maybe because a lot of them are coming from Java and C# where writing clean code™ is more preferable to adding comments.
Personally I think there's a middle ground. I've met some Javascript developers insisting on adding a comment before each statement and I've met some java developers having a no comment policy in their codebase (so that pull requests wont merge if there are comments).
This is entirely applicable to JavaScript codebases, except that at least in typescript you have less reverse engineering work to do.
If you want to have documented codebases, work with people who document their code. You’ll find that typescript doesn’t always mean undocumented, and incidentally you’ll find that documented doesn’t mean high quality.
Most high quality codebases in the JS ecosystem after 2016 ish are in typescript.
Sadly, the majority of people writing Typescript rarely care about descriptive and readable code these days. Somehow the focus shifted from using types to better understand complex systems through the code itself, to writing whatever polymorphic union type abomination that yields the best IntelliSense auto-completion in VSCode.