4 ms·
I love this before/after example of TypeScript being removed from a library as a clear illustration that only occasional simple type annotations are needed: h
by seanwilson 2y ago
I love this before/after example of TypeScript being removed from a library as a clear illustration that only occasional simple type annotations are needed:
https://github.com/hotwired/turbo/pull/971/files https://github.com/hotwired/turbo/pull/971/files
Looks like so much useful documentation for understanding the code, assistance for refactoring, and static checking (which are like always running, fast and exhaustive unit tests for free) for a modest amount of type annotations that each person on the team would need to recreate in their heads anyway. Static type checking is so useful for catching runtime errors to do with optional values and index/key not found error too, that always create a load of edge cases.
Editing JavaScript with no types is scary, especially when you didn't write it. You're mostly guessing what the types must be and hoping your running code exercises enough edge cases to catch any problems. "You should write more tests" as an alternative rings hollow for me because (for the things they will check for you) types are more concise, exhaustively check all values, are ran continuously, are fast, aid with automatic refactoring, document the code in the same file its in, and will locate exact snippets that are causing errors. More often than not, test mostly check happy paths, aren't even close to as exhaustive, and nobody is writing tests that check every combination of function parameters being null vs non-null, string vs number etc. (which would be a huge amount of noise in your test suite that would slow down refactoring too). Types are a compliment to tests as well, not an alternative.
I can't relate to arguments about types getting in the way (as long as you avoid trying to get too clever like with complex generics and TypeScript conditional types). Usually when this happens, it's because it's hard to reason the runtime edge cases in your own head and there's probably a simpler way to write it. I'd love a good non-niche example to the contrary. Worst case in TypeScript, you can use `any` as an escape hatch anyway so as long as you can add types to most of your program it's not a strong reason against for me.
- benatkin 2y agoThat PR is great. Not only do they get rid of TypeScript, they get rid of prettier and some gratuitous trailing commas. https://github.com/hotwired/turbo/pull/971/files#diff-865b8f8ec486a7b449d8d47d9666c452d234fab19927dc49af9439d5d5b00744L172 https://github.com/hotwired/turbo/pull/971/files#diff-865b8f... I’m not joking. I prefer the after. Edit: thanks. Yes, commas, not comments.
- lofenfew 2y agos/ent/a
- vallode 2y agoI could not disagree more, but I am obviously open to it being a personal preference. I've spent months updating JavaScript codebases that are between 3 and 5 years old, most of them written with vanilla JavaScript. A _few_ of them were written with TypeScript at least partially and those files were the least mentally taxing to upgrade. Some of the codebases had tests, a good chunk of which could (and were) eliminated simply by using TSC as part of the build process. I think allowing the compiler and tooling like prettier to make choices for you leaves more space for you to think about the problem, not the myriad of problems _around_ it.
- Shacklz 2y agoFunny, I have exactly the opposite feelings. I've worked on dynamically typed code-bases in the past, and also on code-bases without formatters like prettier... and I'm not going back there. So many odd bugs can be avoided simply by taking a little bit of time and declaring some types. It doesn't have to be a super fancy type-system (I actually prefer if it isn't), but I really want to know whether something is expected to be a string or a number, or what properties an object can be expected to have, or what values a literal can accept, and so on. It's just so frustratingly time-consuming to figure out in hindsight. And all for some person's odd perception of simplicity. Same for formatters - all the squabbling over some personal preferences on how code should be formatted. Hell no. Let's install some opinionated formatter and let it do its job, I want to tackle more interesting problems than yet another narrow-minded discussion about necessity of semicolons, placement of whitespace or line-length. I'm at a point where I straight-up refuse to work with people who prefer to work that way; or at least require them to be a few departments away from me. They can be programming gods; if they can't be arsed to type their code so I can immediately grok it, they can program elsewhere.
- n144q 2y agoSame. I sometimes write TypeScript for 2 hours straight without actually running the code or any unit test, and it would just work -- the return value is exactly what you want. I don't think I can do that for JavaScript for more than 15 minutes even though they are the "same language".
- plagiarist 2y ago> This one is interesting. I would have no idea what a "submitter's" purpose is here with or without Typescript. > I am excited to see how this code base changes without Typescript. The "types" or what things are will have to be communicated in some way. This may lead to very readable code. This is funny to me. "If we don't have the compiler checking types the developers will perfectly compensate with documentation, an improvement." Maybe remove the unit tests as well, then the developers will write accurate code.
- marcosdumay 2y agoIt's using that expendable developer time to free some precious extra developer-machine-CPU time. Who wouldn't want to spend some weeks or hard labor so their computers can work for a few less seconds? Let's keep what's really important in mind!
- Tainnor 2y agoThat PR reminds me why I'm glad that I left the Rails world, despite multiple HN threads recently touting its benefits. Ultimately, DHH just decides things on a whim and ignores everyone's objections.