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

31–40 of 244 posts

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

#31

Post by Hermitian909 »

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)

I use bucklescript/reasonML extensively.

The biggest con is definitely the smaller lib-ecosystem, creating bindings for functions is generally relatively painless but if you're using javascript libraries with large API surfaces that will be a large time sink. Otherwise it's been a joy to use.

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

#32

Post by amzans »

tayo42 wrote: post #22
amzans wrote: post #19

Earlier quoted context omitted.

I couldn't agree more with you on this. I often see good, actually simple solutions get turned down due to people saying "that's too complicated for what we need", only to later hear, after a couple of months in production, that nobody wants to touch the codebase anymore since it's unapproachable and the rewrite will not happen due to high risk since it's critical production code now.

There must be some bias here in what your remembering. Are the projects that didn't need to be extended, simply doing what they need to, sticking out in your memory

You might be right and maybe there is some bias in the projects which I chose to think of. Certainly there are many projects that don't require the same amount of thought from day one.

What I'm referring to in my previous comment is when people underestimate the complexity added by the easy and quick solution today vs the high cost over time. Specially in critical projects.

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

#33

Post by rasikjain »

Coming from C# background, Using Typescript for front-end programming was a breeze for me. This helped me in picking up newer frameworks and saved countless hours during debugging and build time errors. I liked strict validation of props using interfaces while working with restful APIs.

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

#34

Post by _bxg1 »

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.

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

#37

Post by eranation »

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…

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 run fast and offline. Not sure if there is a term for it but I call these integunit tests... (probably the worst name possible)

But unit / unit++ tests are not just for you, they are for me, they give me confidence I can touch your code without inadvertently breaking something critical that you may have missed in your acceptance tests. It gives you peace of mind to be able to refactor. An acceptance test may tell you they something broke, but a good unit test will show you exactly where.

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

#38

Post by Spartan-S63 »

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…

Biggest benefit of having a compiler in your toolchain is that it often serves as the majority of your integration testing layer.

That said, you should proliferate unit tests for algorithmic logic. That can be a small subset of your code, but a large part of your domain (depending on richness). Integration testing can be written manually, or you can pick a compiled language that does a lot of the lifting by type checking and producing the binary. Acceptance tests guide the overall happy path and can protect against weird regressions.

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

#39

Post by mixmastamyk »

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

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

#40

Post by externalreality »

eranation wrote: post #37
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…

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 assertion its a called a false negative and the failure is meaningless? Do you know if your tests fail and no functional or non-functional requirements of the program has changed the failure is also meaningless (you are testing implementation)? Ask yourself how often does your group give you time to do these hypothetical large refactoring that give merit to large unit test suites? How many times, even, do you do small refactorings and find all the test have to go away or significantly change anyway because they made some implementation assumption that is no longer true? How many times have you gone into a test suite and have seen that its been patched up so many times that you can swear its testing something but you just don't know what? I know that Uncle Bob tells us about test for refactoring and this and that, but I just don't buy it any more. The emperor is naked god dammit. Uncle Bob and the like are very famous because people swallow their anecdote without due scrutiny.

Post reply on HN