Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When to Use TypeScript – A Detailed Guide Through Common Scenarios

khalilstemmler.com

Post reply on HN
Print view View original

121–130 of 244 posts

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

#121

Post by 52-6F-62 »

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...

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

#122

Post by [deleted] »

a_wild_dandan wrote: post #8
chmln wrote: post #3

> will most often write vanilla React.js apps when: the codebase is small This one never ceases to amaze me. Any codebase is small, until it gets big. And once it's big, the effort to rewrite is hard to justify. You don't build a house and add the foundation later.

I see so many HN comments endorsing "build the product to exact specification using the minimum reasonable tool set." When you then ask "what happens when the specification changes?" you get hilarious answers like "just say no to the user", or "just extend the app!" This is why I always over engineer a bit, especially on new projects. I'll happily, for instance, add a framework before it's strictly necessary. I've ne…

[deleted]

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

#123

Post by lewisl9029 »

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...

I don't know if what you've described is an _opposite_ experience. I think TypeScript would work fine for me too if I never needed anything compilation-wise outside of what tsc is already capable of. But as soon as you do, the lack of extensibility of tsc compared to babel becomes painfully obvious.

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

#124

Post by z3t4 »

wincy wrote: post #64
marcosdumay wrote: post #55

Earlier quoted context omitted.

Well, imagine type-first programming, where you design your system first just by writing the types, look how it works, and only when satisfied go bother with implementation. I'm not sure TypeScript is good enough for doing that (I don't know TypeScript that well), but it's simply much better than starting with code.

I recently had to write a tool to output a Swagger file from a proprietary api testing format, and writing all the interfaces for Swagger based on the Swagger specification was hugely helpful. I’m not sure I would have been capable of completing the project without TypeScript. Also coming from JavaScript development first, TypeScript made learning C# and templates a breeze.

What if the specification changes ? Being static is has both advantages and disadvantages. You can do the checks without running the code, but it doesn't guarantee run-time correctness. I think a better strategy is to type check the actual code via inference, maybe adding some doctype comments to help the static analyzer, then add run-time checks where things are likely to break. And you can make your API easier to use by checking the parameters, throwing helpful and descriptive errors, allowing several different types as input, so the user doesn't have to convert his/her model to your model.

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

#125

Post by wesleyfsmith »

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…

This is exactly my experience. If your project doesn't have a nice build pipeline for TS then it can become quite awkward and take more work, especially if you have isomorphic code that isn't all in TS already. Also, a lot of the interface syntax can get pretty weird when you are trying to type untyped libraries, which definitely slows me down. I love types in languages like java where it feels like the types have first class support--but TS by definition often involves calling out to libs that aren't written in TS which feels awkward and loses a lot of the advantages.

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

#126

Post by dmit »

danso wrote: post #92
dmit wrote: post #59

Earlier quoted context omitted.

To be fair to CoffeeScript, it introduced and popularized features that eventually made it to the EcmaScript standard. You could make a case for it being the kick that started the wave of improvements to JS that we've seen in the past decade. As for GP's post, I can only hope that Typescript leaves a similar legacy, even if the language itself ceases to exist.

That kind of historical retrospective is an article I would definitely read. As much as Coffeescript seems like a dying language when compared to where JS is today, its appeal was very strong for it to have become a default include in Rails 3.1, and to have been the primary choice for teams like Dropbox and Github [0]. 0: https://en.wikipedia.org/wiki/CoffeeScript#Adoption

I'm pretty sure Jeremy Ashkenas has commented before on how he's satisfied with the role CoffeeScript ended up playing. Don't know if there are full-fledged articles on the topic, and I can't tag him here, but if you're really curious you can always reach out at https://twitter.com/jashkenas!

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

#127

Post by lewisl9029 »

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…

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 ramda's pipe function: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...

A simple function that composes functions together in reverse order requires:

1) The definition to be an exhaustive list of all the variations of input functions that pipe can accept (which of course would technically require an infinite number of declarations to fully specify, so ramda had to call it quits at 10).

2) The user of pipe to specify output types for every single function being composed at every step, even though that should be possible to infer using the return type of each function in the pipeline.

These kinds of limitations plague our codebase everywhere we try to define higher order functions in our own code as well, because it means we have to ask users of the function to specify the result of the function argument as a generic parameter even though it should be perfectly inferrable from the function argument itself, and the noise buildup becomes exponential as you start composing higher order functions together due to pipe suffering the same limitation. The issue also rears its head when using higher order components with recompose, which we make heavy use of as well.

I'd love to hear how other teams working with functional programming in TypeScript work with these limitations. Perhaps we're missing something fundamental that could vastly improve our experience?

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

#128

Post by monkpit »

breck wrote: post #71
leeoniya wrote: post #17

i recently learned you can actually have typescript annotations without [imo] polluting the syntax or requiring the TS compiler: http://seg.phault.net/blog/2017/10/typescript-without-transp... does anyone know if there are limitations to this style?

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.

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

#129

Post by wesleyfsmith »

One challenge I have with TS is that when writing interfaces for untyped libs it's easy to make a mistake. I've had issues where VScode was telling me something was the incorrect type because someone else on the team had written an incorrect type in. Instead of debugging it like I would in normal JS I banged my head against the wall because I was convinced that is TypeScript was telling me something was a certain type, it HAD to be true.

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

#130

Post by mandeepj »

TimTheTinker wrote: post #119

The article mentions object-oriented programming several times as a helpful paradigm (especially for domain-constrained problems where DDD is helpful). I’d also like to point out that functional programming is tremendously helpful for solving these types of problems, especially when combined with use of modules. TypeScript is absolutely capable of modeling, checking, and otherwise handling types in a functional progr…

> TypeScript over C#

TypeScript is a transpiler for JS. C# is a server side language. Can you please clarify how former is the replacement for latter?

Post reply on HN