Your DDD link is dead (so technically it’s a DDDD link :)
When to Use TypeScript – A Detailed Guide Through Common Scenarios
81–90 of 244 posts
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#82Earlier quoted context omitted.
Yep I feel the same. TypeScript improves my workflow tremendously and I use it for everything now. Going back to regular javascript feels like driving without a seatbelt. Sure you can but why? Type-checking and smarter autocompletion mean I don't make mistakes as often and my productivity is higher. (No longer run the app, see I misspelled a function call, fix and run again, etc.) I also feel unit-level tests are les…
> I also feel unit-level tests are less necessary with TypeScript. Especially with strict compiler settings, including strict null checks, and the good type conventions they encourage. To give a small example, if you have a value that can either contain an error or a successful result, you can model it as the union of a success and error state. This prevents you from accessing the value until you check the result is…
With C#, I am pretty sure you can get some of what you mentioned by using stricter compiler settings.
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#83I 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 tes…
Tests should be testing behavior, not implementation (this was the original intent of unit testing but it got sidetracked over time).
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#84Honestly, the only downside to me of typescript is occasional grief from @type libraries or some build complications when you're first getting setup. But having working code completion and non-surprising return values/argument parameters is so much worth the initial minor pain points.
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#85Honestly, the only downside to me of typescript is occasional grief from @type libraries or some build complications when you're first getting setup. But having working code completion and non-surprising return values/argument parameters is so much worth the initial minor pain points.
The other issue is dealing with module compilation... this part still always screws me over.
Once it's up and running TS is freaking amazing
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#86Earlier 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…
It is not the typing per se. Anecdotally, I started adding types to my python code and it is somewhat useful.
That usefulness is diminished when you are fighting the type system instead of getting things done.
Like when you have to make exceptions in typescript by using Any. Like when an interface for a js library is missing and you don't want to do all that work.
Or when an API returns a field with a different type in between two calls and you have to make exceptions in the code when parsing with jackson in java.
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#87Earlier quoted context omitted.
Yep I feel the same. TypeScript improves my workflow tremendously and I use it for everything now. Going back to regular javascript feels like driving without a seatbelt. Sure you can but why? Type-checking and smarter autocompletion mean I don't make mistakes as often and my productivity is higher. (No longer run the app, see I misspelled a function call, fix and run again, etc.) I also feel unit-level tests are les…
> I also feel unit-level tests are less necessary with TypeScript. Especially with strict compiler settings, including strict null checks, and the good type conventions they encourage. To give a small example, if you have a value that can either contain an error or a successful result, you can model it as the union of a success and error state. This prevents you from accessing the value until you check the result is…
Honestly, good integration of union's (Algebraic Data Types) is a good chunk of what makes Rust such a comfy programming language for personal projects. Being able to use a common, standard method to say "there may be a result or there may not, and if there is, here it is" is so expressive. Since the Option type is built into the language, it comes with lots of utility methods to make things even easier on me.
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#88Earlier 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.
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.
> types as a first class construct
A wild Idris programmer appears
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#89> 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…
That is an excellent approach for new projects. On stable projects it's pretty common to have lots of little "special" bits where someone over-designed and created an unholy mess. (I'm guilty of this as well, of course.) In stable systems simple is almost always best.
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#90It'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.
I'm also using it as my default. I also find it great that with every release, they are pushing features that promote immutability; ReadonlyArray, and const assertions, to make developer workflow better and safer.