Type system is like a seat beat, its not going to save your from a head on collision with 18 wheeler. But it will mitigate you pain and suffering in small to medium accidents.
The TypeScript Tax
31–40 of 120 posts
Re: The TypeScript Tax
#32> Missing Features — HOFs, Composition Uh... I'm pretty sure I've used both in TypeScript projects.
Yeah, I use both all the time.
I will admit I have to pass type hints via generics to my compose / pipe calls more often than I would like, but it definitely still works.
Re: The TypeScript Tax
#33I freaking LOVE Typescript.
I shipped an app about 90 days ago based on Typescript.
It's basically a document manager which supports annotations, comments and keeping your documents in the cloud.
Typescript was a MASSIVE win. If you're on a simple code base doing a refactor is easy. Anything significant and it's a nightmare.
If you change an object method JS won't complain.
With Typescript and IntelliJ or VS Code it's just a simple refactoring and your code just works.
I would have probably given up on the project had it not been for TS.
Re: The TypeScript Tax
#34He asks the question "But should you use it for your large scale app development project?" I thought that was literally the reason TypeScript came to be. Microsoft were having lots trouble wrangling Bing web app and internal MS devs wanted a tool to help catch the bugs! I would say, if you are embarking on a large scale app, you most definitely want to include TypeScript from the start. It will pay dividends in the e…
It pays dividends long before the end.
My usual "time to 'oh thank you typescript'" is roughly 2 days from the beginning of the project.
Re: The TypeScript Tax
#35Earlier quoted context omitted.
I think grandparent was referring to the fact that you can tell the compiler to ignore type errors if you so choose. The TypeScript compiler is perfectly happy to compile the code in your example, if you disable strict type checking and treat type errors as warnings. On top of that, there are simple annotations you can add that let you silence warnings as they come up, e.g. `const testVar: any = {}; testVar.asdf = "a…
Sure... I guess you're saying that you can use the typescript compiler just fine as long as you turn off literally the only reason for it? Have you been on a team that adequately managed a list of thousands of warnings, always finding and fixing just the ones that are "important"?
Not advocating for this, but that's not too far off from how some C/C++ codebases work.
Re: The TypeScript Tax
#36Earlier quoted context omitted.
I think grandparent was referring to the fact that you can tell the compiler to ignore type errors if you so choose. The TypeScript compiler is perfectly happy to compile the code in your example, if you disable strict type checking and treat type errors as warnings. On top of that, there are simple annotations you can add that let you silence warnings as they come up, e.g. `const testVar: any = {}; testVar.asdf = "a…
Sure... I guess you're saying that you can use the typescript compiler just fine as long as you turn off literally the only reason for it? Have you been on a team that adequately managed a list of thousands of warnings, always finding and fixing just the ones that are "important"?
Yes. As a matter of fact, I'm currently working on a large JS codebase that is a decade old. We switched over all the code to TypeScript in one go, and we are gradually fixing the type errors over time. VSCode does an excellent job of showing you type annotations and type errors inline, so the typing is very useful even if you have thousands of errors elsewhere in the project and never even run the type checker globally.
In fact, out of the dozen or so TS codebases I've worked on, I've rarely seen one completely free of type errors. And yet no team has ever doubted the value of the type system. It's a very pragmatic approach which works very well for many teams in my experience.
Re: The TypeScript Tax
#37But if you’re in the position of deciding whether or not to use it, you should have a realistic understanding of both the benefits and the costs. Will it have a positive or negative impact? I strongly disagree. You can start using typescript without thinking for a second about what parts of it will be beneficial. Initially you can just run javascript through the typescript compiler and let type inference find some bu…
I don't know where this misconception started, but you can't just run javascript through a typescript compiler. There is a huge amount of valid javascript that is not valid typescript. Try something like `const testVar = {}; testVar.asdf = "asdf";`. Node web frameworks, for example, are based entirely off this ability to monkey-patch the request object.
`const testVar = {}` doesn't mean that the object is immutable, it means that testVar will never point to something else.
Re: The TypeScript Tax
#38Could have been titled "static typing vs. dynamic typing" but I guess TypeScript is more clickbaity.
Re: The TypeScript Tax
#39I don't think the author adequately addresses the positives of development velocity with Typescript. I find I'm able to read and write code much more quickly with Typescript than without, especially once I am beyond 50-100 loc. I doubt I _ship_ fewer bugs to production, but I certainly catch and fix my own mistakes much more quickly _as I go_, and am able to make more ambitious changes much faster when I have types o…
Yup. He didn't address the biggest winner for me -- the ease of refactoring code you wrote 6+ months ago without breaking everything.
Re: The TypeScript Tax
#40Let me save a few minutes of your time. The author of the article believes that static typing is mostly a waste of time. Consequently, in his point-based model, he assigned that particular feature of the language +0.1 points. "Typing overhead", on the other hand, got -3 points. And then, after adding all the points, he unsurprisingly concluded that the overall score is negative. If you agree with the premise that sta…
> Consequently, in his point-based model, he assigned that particular feature of the language +0.1 points.
That's because his stupid chart is comparing a bunch of different things to TS instead of just comparing it to JS. In that case he's putting it up against TDD + code reviews, for reasons that I entirely do not understand. His numbers are so wildly incommensurate that they don't even make sense for any sort of informal water-cooler analysis.
[EDIT] if... if I'm reading his reasoning for that 0.1 score correctly, he'd still give it a -3.9 ROI if it caught 100-friggin-percent of bugs that would otherwise reach production, unaided by any other tools or practices. WTF.
[EDIT EDIT] for reference, that means he rates the overhead of noting one's types at 3x as bad as the benefit of magically catching 100% of bugs would be good. This is what I mean by these individual values being ZOMGWTF incommensurate.