I love Redux, I love your dedication to the community (also on Reddit), and I love your work. But this is the first time I find myself completely disagreeing with you.
The bigger a project gets, the more unreadably TS snippets you run into. The cost/benefit ratio is awful; I've sometimes taken the actual author of the code and myself to analyse it, and it would take us over an hour just to get to the bottom of something that would be incredibly simple in regular JS.
From your article:
> Ah, the joy of reviewing a PR for a lib you maintain, when the PR contains code that you are not even remotely qualified to pass judgment on...
And then that code. Look at that. That's not nice. That's terrible code, horrendous. That should be rejected for the simple reason that it's unmaintainable.
> I begged for help on Twitter, and got a solution from the community that worked. I don't even pretend to understand the type declaration, but here it is:
The problem in larger teams is exactly this:
Some self-important TS lover in your team spends 4 hours tinkering together some arcane magic TS definition by copy/pasting a ton of shit from StackOverflow, is proud that it works, commits and pushed it, creates a PR... and everyone reviewing it is clueless what's going on. But it works.
Hell, if he understands it and it works, it must be good. Accept PR. Merge. Fast forward 3 months. Someone has to add a feature to this particular part of code. They look at the TS definition and 2 weeks later they have a new job.
I've seen people flee projects because of endless amounts of arcane TS...
If I'm imagining the perfect project it's based on a few qualities that I hold dear:
1. Sensible unit testing in place
2. Well defined code review standards
3. Strict naming conventions for code
4. Optional JSDoc where it makes sense
5. Minimalistic but readable amounts of code*
* Meaning that code should be short and concise, functional programming to the max, but not one big clump of inline nested functions.
JSDoc in itself allows you to type parameters and variables, it even adds human readable comments to the mix.
Then, when reading the project's code, you'll stumble upon a beautiful and sleek code base that just makes intuitive sense from the start.
---
I recently had a chat with someone about us developers always inventing the next pain in the ass to deal with. I think TS is a pain in the ass. When I started out with Classic ASP (Visual Basic 6.0) it was basically functional programming (functions and subprocedures) and we'd get everything done in record time, blazingly fast.
If VB6.0 was released by Microsoft today, millions of people would be fawning over it and it would become the next best thing. "What a cool Python alternative, thanks Microsoft!"
Same with Perl. Cool language. Hardly anybody uses it anymore. It's mostly Booking.com recruiting endless amounts of Perl developers because they're almost as rare as the fossils they often are (I worked there, I'd know.)
When we switched to XSLT and XML it was basically Handlebars, except not restricted, full of features, and just gorgeous to work with. But it lost its sexiness for some reason; mostly because JSON isn't compatible with XSLT. So nobody uses it anymore.
Now there's JSX, and that will also disappear over time. Probably for no good reason at all. Look at Angular and VueJS, they offer alternatives that are vastly inferior in many ways (no intuitiveness would be one, you need to learn the damn frameworks before you can get started), but they're the new kids on the block.
TypeScript is too often too easily accepted as the standard addition to a project. And I've experienced it NEVER to be the right call. And I've gotten other developers on said teams to–sometimes after some prodding–agree with my assessment.
Every project would be better off without TypeScript. I fail to see any of the benefits people mention because I've never seen them, I've only seen the exact opposite.