When to Use TypeScript – A Detailed Guide Through Common Scenarios • Hacker News Board

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

#61

Post by mattmanser » Sun, Apr 07, 2019, 6:29 PM UTC

justintoon wrote: post #56

a_wild_dandan wrote: post #8

Earlier quoted context omitted.

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.

Your stance sounds different to the grandparent's.

There's a world of difference between adding a framework and over-engineering something that could have used a simpler solution.

My experience has been the exact opposite of yours, whenever I added something complicated, it either never got used and unnecessarily complicated the code, or when the time came to use the fandangled cleverness I lovingly wrought, it never quite met the need I actually ended up having.

So I stopped doing that years ago and now always write the simplest code. Never regretted it. I will add frameworks early though.

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

#62

Post by a-saleh » Sun, Apr 07, 2019, 6:35 PM UTC

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?

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

#63

Post by mixmastamyk » Sun, Apr 07, 2019, 6:36 PM UTC

echelon wrote: post #49

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.

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.

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

#64

Post by wincy » Sun, Apr 07, 2019, 6:41 PM UTC

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.

I recently had to write a tool to output a Swagger file from a proprietary api testing format, and writing all the interfaces for Swagger based on the Swagger specification was hugely helpful. I’m not sure I would have been capable of completing the project without TypeScript.

Also coming from JavaScript development first, TypeScript made learning C# and templates a breeze.

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

#65

Post by netghost » Sun, Apr 07, 2019, 6:42 PM UTC

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?

I suspect you can't do some of the fancier type contortions. For the simple case, I think it works just fine.

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

#66

Post by orta » Sun, Apr 07, 2019, 6:45 PM UTC

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?

No limitations (only that it's a bit more verbose than just TS), this is canonical supported by the TypeScript powered tooling which VS Code provides by default on an JS project.

https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-i...

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

#67

Post by mixmastamyk » Sun, Apr 07, 2019, 6:45 PM UTC

mattmanser wrote: post #57

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.

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,…

It does, I’m talking more about module/system architecture than properties. I might go through three designs on a brand new project and futzing with types and tests while factoring it is an inefficient use of time. Waiting until satisfied with design is my advantage.

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

#68

Post by netghost » Sun, Apr 07, 2019, 6:45 PM UTC

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.

Babel can transpile typescript now and strip the types off. So I think it's pretty easy to back out of you ever need to.

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

#69

Post by connor4312 » Sun, Apr 07, 2019, 6:49 PM UTC

bengotow wrote: post #43

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

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 successful (and the compiler will nicely infer the type in subsequent usages once you do.)

For me, with rigorous compiler settings and a good proficiency in type modeling, I've reached the point where I rarely have any runtime errors at all once the code compiles. Sure it might take 2% more time to write code and think through my data model, but I spend 95% less time debugging it and the end result is much more maintainable. Even using typed languages like C# and Go now leaves me slightly dissatisfied!

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

#70

Post by threatofrain » Sun, Apr 07, 2019, 6:51 PM UTC

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.

Saying "Don't do premature optimization" is easy. By saying "premature" you're already implying that you can tell when something is premature. What's hard is when you don't know when something early will come back to bite you later.