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

51–60 of 244 posts

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

#51

Post by ufmace »

externalreality wrote: post #2

I agree with this article. Good stuff. One minor gripe: > if you care about the code, you need to have unit tests for it. That's not really true. You can test at a differently granularity and still have the same confidence in your code. Scores of brittle unit tests crowding your productivity is not what you do to code you care about. I wish people would just stop propagating this detrimental rumor that is backed by z…

I agree. I think it's important that your test suite gives you something useful with every test, instead of writing a bunch of pointless extra tests just to get to 100% coverage because you read somewhere that that's good.

I feel like I ought to write more on this one of these days, but I have a few testing pet peeves, as far as tests you shouldn't write. Don't write tests that are a copy-paste of the code you're testing. Don't write tests to validate things that should be proven by your type system and lack of compile/parse errors. Beware of tests so tied to implementation details that they make your code harder to refactor. Don't write tests for things talking to external services - the only real test is that it correctly handles the actual service responses.

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

#52

Post by gav »

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…

One of the things that I've learnt is that the world isn't clear-cut enough for YAGNI[1] all the time, and that it's usually worth building things slightly more generic/flexible than the original ask, because it's rare that the original requestor understood the problem enough first time round.

[1] https://martinfowler.com/bliki/Yagni.html

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

#53

Post by mst »

tyingq wrote: post #16
fxfan wrote: post #4

4 of the most popular language creators here https://www.youtube.com/watch?v=csL8DLXGNlU agree that type systems are useful. I would suggest definitely not using Vanilla JS. There are excellent type systems over JS, TypeScript, Scala.JS, BuckleScript to name a few each with their pros and cons (I don't know what cons BuckleScript has though, maybe relatively smaller lib-ecosystem)

Larry Wall is endorsing strong types? I'll have to watch that now. I guess you can use Perl 6 in a way that approximates it, but it's very optional.

I believe the idea is 'gradual typing', where you add types as you firm up an interface.

Lots of the perl6 code I've seen types most stuff at least at interface boundaries.

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

#54

Post by giancarlostoro »

> For example, it's almost always expected that your app is going to still work offline in some capacity; and when users ARE online, it's also usually expected that they're going to get real-time notifications without having to refresh the page.

I never expect something to work while I'm offline, or do they mean the cached contents like a page would work if it were just cached HTML and CSS? As for real-time notifications, I don't know anybody who uses those, the other day someone was telling me how pissed off they were that they always get them from some news site, and they didn't mean to enable them, now they can't find where to turn them off!

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

#55

Post by marcosdumay »

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.

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.

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

#56

Post by justintoon »

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…

It’s rare that I find a comment which validates my own practices like this. I personally love creating systems and abstractions, and admittedly I will sometimes create one when a simpler solution would suffice. However those “over-engineered” solutions have frequently saved me lots of time much later when business requirements change.

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

#57

Post by mattmanser »

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.

It doesn't as you've already made that decision when adding a property. Almost always you get rid of the property entirely and replace it with a new one (and the type), you extremely rarely change the type.

And you will almost always know what type a property needs to be. Name? string. IsActive? boolean. Last modified? Date. Etc.

Also typescript just has number, so you're not even faffing around thinking "int, float, long, double, decimal, unsigned, signed" when adding a number. Although this is ultimately a bad thing.

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

#58

Post by jorblumesea »

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…

I think it depends on what you're engineering. For example, adding static typing to a language has immediate gains regardless of code base size. It is also low risk and easy to implement.

Designing a spring quartz scheduler backed by a DB when a simple cron job would do? That's overkill.

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

#59

Post by dmit »

oaiey wrote: post #50
fourseventy wrote: post #35

Isn't anyone worried that TypeScript will go the way of CoffeeScript?

I am not. CoffeeScript was never as popular as Typescript already is. TypeScript is a tool which solves a problem, CoffeScript is a language (IMHO) no one needed.

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.

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

#60

Post by _bxg1 »

marcosdumay wrote: post #55
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.

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.

TypeScript works reasonably well for this approach; it's how I tend to do things. It has some gaps when you want to do really advanced stuff, but it gives you tools like typecasting for crossing those gaps. One of the great benefits of JavaScript type systems is that since they're overlaid on a dynamic language, you can just "turn them off" as needed (when the type system fails to understand that what you're doing is safe). You can comment out type checking for a particular line, or even let your whole project successfully build while type errors remain. The type system then becomes purely a tool, and never a roadblock.
Post reply on HN