Working on half a million LOC TypeScript codebase. All strict flags up, low-2-digit team size. We don't really run into many problems. TypeScript is not perfect, but developer happiness and productivity have definitely increased since we adopted it, and defect rates have dropped significantly --while increasing the size of the team & working on more features.
Think of the change as a statically compiled language writing parts of their runtime with assembly or unsafe pointers. It’s not an indictment of TypeScript.
My first impression of the reasons in the design doc is that the change is not well justified, but I also see the point you make; my response, though, was to the direct parent comment.
I have a hard time believing that. We have 10k lines of typescript and that take forever to compile compared to 5x more of the ReasonML code we have that compiles instantly
You have a hard time believing that their team experienced more happiness and productivity with TS...because your ReasonML code compiles a lot faster than your TS code?
They become really frustrating as the project grows in size. Personally, it becomes really difficult to maintain productivity. As compile times tick up, I start bouncing over to other tabs rather than just twiddling my thumbs starring at a terminal. Then I realize I've been on Reddit for a half-hour.
I recently watched this talk by Johnathan Blow[0] where he talks about quality of life in programming languages and spends a fair amount of time talking about compile times and their effects.
I think we collectively need to re-align on being performance focused. Tools are simultaneously amazing but crummy at the same time.
I don't love the compile times, but I'll also say with TypeScript I tend to check the browser that often. TS also means simpler refactoring, for example.
Note also:
* type checks can run in parallel, so they won't block your other build block
* the tsc has been making gradual improvements to performance and techniques to improve compilation and type checking
* there are speedy alternatives to the TypeScript compiler (tsc) (eg: https://sucrase.io) for transpilation
I've worked on javascript codebases pushing half a million lines of code, and my memory is that we didn't run into type bugs all that often. The biggest downside was the lack of automated refactoring tools - this was many years ago now.
It did take quite a bit of discipline, but with a skilled team it really wasn't all that hard.
> It did take quite a bit of discipline, but with a skilled team it really wasn't all that hard.
Out of curiosity, what was the turnover within the team? My personal experience is that static typing helps a lot when you're new to a codebase. Probably less so when everybody can recite the architecture in their sleep.
The turnover didn't start increasing until the 'javascript ecosystem' developed, and suddenly everyone wished that they were following the new community developed practices rather than the ones we'd be following for years. That lead to lots of factionalism within the team and a lot of unhappiness on all sides.
This certainly depends on what the code does and on the use case, i.e. on how critical reliability and performance are. 10k code in a simple web application prototype that will be trashed in 3 months is not "a lot", because it's not critical and piling up technical dept is not a problem. 10k code to specify the core algorithms in a mission-critical, long-living system is "a lot", or at least "much more", because it needs to be crafted and maintained with immense care.
As someone who has maintained multiple legacy projects, 10k is not a lot of code. I normally run into single files in the 10k range, if it wasn't for NP++ and VSCode I would go insane just trying to scroll.