When to Use TypeScript – A Detailed Guide Through Common Scenarios
khalilstemmler.com
When to Use TypeScript – A Detailed Guide Through Common Scenarios
1–10 of 244 posts
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#2I 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 zero evidence. I prefer to keep my unit test suite lite and sweet (try to test what is very sensitive at the unit level - easy to miss or algorithmic things) and then try to get the most out of my acceptance test suite. Sorry, but I just worked on too many systems where the unit tests suite breaks no matter what you touch and you spend more time updating the tests than actually getting shit done.
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#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.
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#44 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)
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#5> 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.
This.
I always focus more on the "foundation" part, in this case, it's common React Hooks and its API for the components to use.
The good part is, if some hooks are wrong, we can just write new one and replace old ones within old components without the need of taking care of the old wrong Hooks.
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#6Why does everyone treat TypeScript like a full language? Besides some features like generics 98% of it is just javascript with type annotations (sorta similar, including in syntax, to py3 with annotations). And in that view its probably foolish not to use it as the cost of these annotations is so low relative to the refactoring/safety/easy-of-use/code-completion/etc it offers. These type annotations are so easy to add!
I can't even imagine writing JS without these annotations esp given all the odd behaviors of the language.
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#74 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)
There are lots of alternatives to vanilla JavaScript. Why stop at types and encapsulation?
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#8> 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 never regretted that decision in the end.
If people here want to use a 5 gallon bucket on an initial 5 gallon job, go for it. Best of luck to you. I'll be over here starting with a 10 gallon bucket and not sweating when the customer needs to add another gallon...
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#9I 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…
"Write tests. Not too many. Mostly integration."
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#10Regarding TypeScript, the benefit of catching way more errors at compile time greatly outweighs the amount of extra work for adding types. If you're starting a new JavaScript project, you should definitely think long and hard if you pledge not to use TypeScript.