When to Use TypeScript – A Detailed Guide Through Common Scenarios • Hacker News Board

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#241

Post by kazinator » Tue, Apr 09, 2019, 12:07 AM UTC

josteink wrote: post #237

kazinator wrote: post #227

Earlier quoted context omitted.

Your remarks apply only to cranking out new code. Static typing prohibits making fundamental changes to an existing body of code, like changing a core, widely-used data structure. To make such a change, you have to be extremely sure that you want it and that you're doing it right. Then you can commit to the days and weeks of refactoring at the end of which you once again have a program you can run. Under dynamic typi…

> Your remarks apply only to cranking out new code. Static typing prohibits making fundamental changes to an existing body of code, like changing a core, widely-used data structure. To make such a change, you have to be extremely sure that you want it and that you're doing it right. I’m reading this and I have just no idea what to say. With static typing you don’t have to be very considerate in this work, because you…

I don't necessarily want the compiler diagnostics to go away; I just don't want them to prevent me from running the program.

A good language has a run-time type in every object, regardless of the type checking system, and allows programs to be run safely even if they are incompletely checked or if inconsistencies have been positively identified.

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#242

Post by breck » Tue, Apr 09, 2019, 3:38 AM UTC

monkpit wrote: post #128

breck wrote: post #71

Earlier quoted context omitted.

Cool, thanks. I generally love TS, but I have one project which I converted to TypeScript, and then reverted back to ES7, because the project is quite complex and the overhead of TS was not worth it. I wonder if by using this Jsdoc/ts strategy in critical sections I can get 80% of the benefit.

> the overhead of TS Do you have any concrete examples? I would argue that a complex project that is already in TS benefits more from remaining in TS, so I’m curious what your reasoning was.

1) Import/export syntax hell. This project is 148 Javascript files, 12k LOC. Everything runs in both Node and Browser environments. Without TypeScript I just use CommonJS syntax and rewrite the scripts on the fly via a server-side pass through for a browser environment. But because of the module hell (import/export/script modules/relative vs absolute paths/defaults) I couldn't find a good formula for write once, run everywhere for this large project. I needed to be outputting 2 different builds to 2 different places which led to all kinds of path problems. This is very much unique to this project though, which has unique runtime require requirements.

2) Compile time overhead when iterating. For many visual development tasks it just takes too long to change something, compile and see results in the browser. Without TS it's 0 latency. With TS it was a few seconds. Without TS I could make 10 changes with 2 seconds latency, and perhaps I make 1 type mistake costing me 20 seconds of debug time, for a total of 40 seconds. With TS I make 10 changes with 5 seconds latency and zero mistakes but now total overhead if 50 seconds. I want to be able to get the documentation and static type checking benefits without giving up that instant feedback.

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#243

Post by _Codemonkeyism » Wed, Apr 10, 2019, 6:02 AM UTC

woah wrote: post #143

lewisl9029 wrote: post #127

Earlier quoted context omitted.

2. TypeScript's type checker, at least in its current state, has been downright painful to work with for functional programming with functional composition and higher order functions in general, with errors that are incredibly opaque and unhelpful, and its poor inference introduces so much seemingly avoidable type-related verbosity that it completely distorts the signal to noise ratio in our code. A prime example for…

This is probably not what you wanted to hear, but I’m glad they don’t optimize for Ramda. On projects where I’ve had to use it, it just generally results in a bunch of fanciful syntax flourishes from the Ramda enthusiast on the team. They’ll jump on anything that looks like array manipulation, eager to try some neat Ramda tricks. In the end a “dumb” solution with loops usually ends up being shorter and simpler (not t…

... and then they go, leave the code behind and make another team happy.

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#244

Post by _Codemonkeyism » Wed, Apr 10, 2019, 6:04 AM UTC

52-6F-62 wrote: post #121

lewisl9029 wrote: post #116

This doesn't seem like a common occurrence, judging from all the praise of TypeScript sung on this thread and elsewhere, but I've had an overall negative experience working with TypeScript so far. Here's some thoughts on what has contributed to that so far: 1. TypeScript pushes you towards its own build pipeline (based on tsc) that doesn't play nicely all the time with mainstream JS build pipelines (usually based on…

My experience is exactly the opposite of yours. Babel has always caused me headaches. Setting up Babel-based build systems is troubling—the same setup will work sometimes and not others even on the same machine. TypeScript vastly simplified working with modern JS for me. It’s consistent, requires far fewer dependencies, and is much more succinct. YMMV, of course...

It's the Maven (dumb) vs. SBT (very clever) build tool argument. Wherever I've been, there are people in the first camp and people in the second camp. I personally don't like highly extensible build tools because I can't manage them and end up with lots of complexity on it's own, taking time from me building features.