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

71–80 of 244 posts

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

#71

Post by breck »

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.

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

#72

Post by Retozi »

mixmastamyk wrote: post #39
_bxg1 wrote: post #34

It's a default for me now, on every new project. It doesn't slow down development because TypeScript allows you to easily "step down" type constraints as desired, and writing nontrivial code without any kind of type hints is just unimaginable to me now.

> unimaginable I imagine adding types gradually as a design solidifies, rather than slow velocity early on. Best not to be dogmatic on these things.

I have never understood why typed languages make you slower at any point in time (early, late etc.).

Because you have to hit more keystrokes to write your program?

That doesn't compute. typing is the thing you do the least amount of when programming. In all best practices we are taught to not save keystrokes. Name your variables expressively. write small functions. document code. Write tests. All ""excess"" keystrokes nobody questions. But when you have to type " ... : number" it's slow velocity?

In my opinion people vastly over-estimate productivity boosts of saving keystrokes. It's the tedious, boring part of the work that you would like to skip entirely, hence excess keystrokes feel way more "slowing you down" than they acutally are.

Although it doesn't matter, you actualy save keystrokes: autocomplete, auto-refactors and less low level unit-tests compensate the couple of type annotations easily.

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

#73

Post by Normal_gaussian »

mixmastamyk wrote: post #63
echelon wrote: post #49

Earlier quoted context omitted.

You'll find that the more you work with types, the less this becomes an issue. You begin to think in types as a first class construct. Types don't slow me down, and I can't imagine working without them.

You also have to type, refactor, and test them. I work in multiple languages and the typed are definitely slower at the beginning, but pay off later. The strategy I outlined is the way to get the best out of both.

Also working in both I don't have this issue. I generally find types make refactors faster - I have less bugs from the refactor.

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

#74

Post by sideshowb »

_bxg1 wrote: post #34

It's a default for me now, on every new project. It doesn't slow down development because TypeScript allows you to easily "step down" type constraints as desired, and writing nontrivial code without any kind of type hints is just unimaginable to me now.

Wait, type checking is good again?

Suits me.

Welcome to 1985 folks :-)

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

#75

Post by alan_n »

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?

Yes I wanted to do this initially but some things, like function overloads are kind of a mess. It depends really on what tags you need. You should look through the typescript issues related to jsdoc. Additionally, it's a bit of a mess trying to output declarations if you mix ts and js because enable checking js disallows emitting declarations, and declarations are only emitted for ts. You can get around this by setting your editor to check js, but leaving it off in the config. But then at that point I have no idea how you'd create documentation for that.

In general, contrary to what you'd expect, documentation options for ts seem poor. Typedocs is painful and ugly. I'll be trying DocFx next but it looks like it has a complicated workflow.

Also you should imo have some typescript experience to be able to write the jsdocs in a way that they work how you expect (e.g. typing a parameter as an object does not work how you would expect, it).

So next thing I thought was to just write js and accompany each file with a manual .d.ts definition. This works when you consume the exports of the file but it doesn't when you're within that file (see https://github.com/Microsoft/TypeScript/issues/30304) which makes it useless imo. Also even if it worked, now that I think about it, I'm again not sure how creating documentation for that would work.

In the end I've reluctantly settled for just switching completely to typescript and hopefully the documentation situation will improve when tsdoc gets farther along.

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

#76

Post by williamdclt »

Retozi wrote: post #72
mixmastamyk wrote: post #39

Earlier quoted context omitted.

> unimaginable I imagine adding types gradually as a design solidifies, rather than slow velocity early on. Best not to be dogmatic on these things.

I have never understood why typed languages make you slower at any point in time (early, late etc.). Because you have to hit more keystrokes to write your program? That doesn't compute. typing is the thing you do the least amount of when programming. In all best practices we are taught to not save keystrokes. Name your variables expressively. write small functions. document code. Write tests. All ""excess"" keystroke…

I completely agree with you, but the criticism isn't usually with typing number, it's typing complex higher-order functions or this kind of things. Where the time lost isn't in typing out the code, but in understanding what the type should be or (worse) what does this cryptic typing error means

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

#77

Post by discreteevent »

externalreality wrote: post #40
eranation wrote: post #37

Earlier quoted context omitted.

If you write a library, or expose a public interface, I do expect a lot of unit tests. Unit tests can run offline, fast, during build time. I don’t mind integ-unit tests that perhaps simulate a database in memory to avoid mocking the entire storage layer. I rather have tests that are technically integration tests as they include more than, well, a unit, as long as they are idempotent, test mainly one thing, and can r…

> breaking something critical that you may have missed in your acceptance tests. So you can miss things in your acceptance tests but can't miss them in your unit tests? Why do you feel more confident with unit tests than with acceptance tests? Maybe because unit tests break more often so they are providing you with a false sense of security? Do you know that when a test fails for a reason other than the specified ass…

One thing I can't find much evidence of is Uncle Bob's experience in delivering commercial software. I get the feeling he works mainly on toy examples which might explain some of the things he advocates that, like you, don't match my experience at all.

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

#78

Post by maaaats »

a-saleh wrote: post #62

I wonder if some of the people here, that like Typescript just fine, would consider less main-stream typed-js solution. I.e. Elm, ReasonML/ocaml/bucklescript, Purescript, Haskell with ghcjs, Rust with web-assembly compilation, or even wasm from Go? I am somebody who really likes to dabble, but is not a fronted person, so I am thinking, what would make you consider switching?

What I mainly liked about TS is that it's basically plain js with some typeinfo sprinkled on top. So no barrier of entry for existing js developers.

Now I work on a project with Elm for the frontend. It's not as easy to just jump into, so wouldn't use it for a project where lots of developers sometimes have to make additions. But once up to speed, Elm is great.

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

#79

Post by hahamrfunnyguy »

a-saleh wrote: post #62

I wonder if some of the people here, that like Typescript just fine, would consider less main-stream typed-js solution. I.e. Elm, ReasonML/ocaml/bucklescript, Purescript, Haskell with ghcjs, Rust with web-assembly compilation, or even wasm from Go? I am somebody who really likes to dabble, but is not a fronted person, so I am thinking, what would make you consider switching?

I know a lot of languages already, so unless there is a significant advantage to using a given language I'd probably pick one of the many I know already.

Typescript has significant advantages over vanilla JS, so that's why I use it. If those other options offered a significant improvement over Typescript AND said features were something I needed, I wouldn't hesitate to use it. For now, getting better at the languages I already know seems like a better use of time.

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

#80

Post by highmastdon »

sideshowb wrote: post #74
_bxg1 wrote: post #34

It's a default for me now, on every new project. It doesn't slow down development because TypeScript allows you to easily "step down" type constraints as desired, and writing nontrivial code without any kind of type hints is just unimaginable to me now.

Wait, type checking is good again? Suits me. Welcome to 1985 folks :-)

Yes, but not the rigid ways of traditional typing but when using duck-typing.
Post reply on HN