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

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

#201

Post by rspeele » Mon, Apr 08, 2019, 3:40 AM UTC

z3t4 wrote: post #124

wincy wrote: post #64

Earlier quoted context omitted.

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.

What if the specification changes ? Being static is has both advantages and disadvantages. You can do the checks without running the code, but it doesn't guarantee run-time correctness. I think a better strategy is to type check the actual code via inference, maybe adding some doctype comments to help the static analyzer, then add run-time checks where things are likely to break. And you can make your API easier to u…

The spec changing is the best part! (Or conversely, the worst part when you are 100% dynamic). You change your types to match the new spec (eg adding a case to a discriminated union) and you immediately get feedback on places in your code that are definitely wrong/incomplete now. It won’t find every change you need to make but it’s a big load off and frees up some cognitive capacity for what’s left.

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

#202

Post by rmrfrmrf » Mon, Apr 08, 2019, 3:45 AM UTC

ajxs wrote: post #158

dhab wrote: post #150

Earlier quoted context omitted.

I am not sure about other languages, but I have been programming in Java for many years, and Typescript does what Java does (minus performance on a long running VM on CPU bound computations) at a rate that I assume should be sufficient for most (business) apps, without any bloat. Can you elaborate on promise fatigue. In our setup we use async/await and the latest ES (although most of us prefer not using decorators if…

I've had too many terrible experiences having to maintain and work with buggy and poorly designed Node/Typescript packages. I'm especially thinking of the terrible choice of ORMs available for Node, Typescript in particular. TypeORM seems the de-facto standard and my experiences with it have been horrific. It looks like Hibernate but works like a dumpster fire. There isn't anything as robust as ORMs like EF or Hibern…

FWIW I've helped a team of Java developers transition to Node and the first questions I got were usually about standard library and hibernate. One guy was quite convinced that the NPM world just needed a reimplementation of Apache Commons to see the value in monolithic packages. I also had to do a lot of explanation about strategies for code reuse without inheritance/turning everything into classes.

These are all, at the end of the day, XY-style problems whose suboptimal answers can snowball into unmaintainable code. I do think there is a serious lack of training material in this area, though.

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

#203

Post by steve_adams_86 » Mon, Apr 08, 2019, 3:50 AM UTC

ajxs wrote: post #142

At the risk of being downvoted into Hades, I feel that if your project is complex enough to warrant using Typescript, its complex enough to warrant using a more robust and comprehensive language. After using Typescript extensively working on a back-end application in a complex problem domain I feel that while it is definitely a fantastic improvement to the core language, it doesn't really escape Javascript's worst is…

Part of the appeal of TypeScript is that you could fairly easily migrate a team to it from JavaScript if they're all fairly comfortable and competent with the current JS ecosystem. For most JS devs I've worked with, this wouldn't be true with a language like C# or Kotlin.

I'd argue that buying into a more comprehensive language would probably be worth it if everyone was into it, but in my own experience JS devs really, really like JS and have very little interest in learning something better suited to the problem they're solving. This is true outside of software too. People love familiar tools and methods, even if they aren't the best ones.

There's also the fact that your team's output will be best based on their enjoyment and engagement. Even if the tooling isn't perfect, they'll probably build better software if they're enjoying it. JS and TS are good enough in most cases to get teams where they need to be.

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

#204

Post by orange8 » Mon, Apr 08, 2019, 3:58 AM UTC

sieabahlpark wrote: post #185

ajxs wrote: post #178

Earlier quoted context omitted.

I actually just made the term up myself just then to describe my feelings about the fact that all of the methods in our service layer are just `await this(); await that(); await another(); //...` and so on. Please be aware that this post is describing my own experiences in back-end web-app development using Node. I feel I'm courting more controversy here, but if you're using `async/await` ad-nauseum your app might no…

I think most people think async/await gives them all the previous benefits of async but doesn't

All the previous benefits of async? Did you mean promises, callbacks or async? async/await is just syntax sugar over promises.

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

#205

Post by estebanquito » Mon, Apr 08, 2019, 4:08 AM UTC

ajxs wrote: post #142

At the risk of being downvoted into Hades, I feel that if your project is complex enough to warrant using Typescript, its complex enough to warrant using a more robust and comprehensive language. After using Typescript extensively working on a back-end application in a complex problem domain I feel that while it is definitely a fantastic improvement to the core language, it doesn't really escape Javascript's worst is…

Poor ecosystem? Have you used web frameworks like Express/Koa + a good linter + a modern IDE (e.g. VS Code) and of course npm? It's a breeze working with those tools. Productivity skyrockets and if you think a little bit about your design decisions then typescript (plus the proper support for it) gives you a huge hand in writing correct code from the first try. I think that if you want your opinion to be taken seriously you should propose an alternative. I would be interested to see a better ecosystem.

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

#206

Post by Arbalest » Mon, Apr 08, 2019, 4:16 AM UTC

ravenstine wrote: post #170

Arbalest wrote: post #141

Earlier quoted context omitted.

>If types are really that big a deal that you have a hard time writing an application without a compiler checking your types, you should reevaluate what you're doing. Implying that everyone has exceptional short term memory, and reading old code has virtually no cost.

I never said that TypeScript wasn't helpful. The picture painted by some people that frontend applications without compile-time type-checking are ready to fall apart at the seams and have knobs and springs go flying everywhere, like something from a Looney Tunes cartoon, is patently absurd.

Given what I said, Even for fairly simple examples, it would still be more bug prone, simply due to humans not having perfect cognition. At scale that can add up.

Also keep in mind that this both enables, and follows a trajectory of increasingly complex frontend applications, previously a lot of interactive stuff was done server side.

Patently absurd, if you take it as a strawman, sure. You ended up using that to paint the complete opposite picture, which was essentially that Typescript doesn't actually add any real value, only "perceived" value. Which is true, if all you value is the execution environment. Keep in mind that Typescript was not the first attempt at trying to "tame" Javascript. One example that comes to mind is Coffeescript.

The natural reducto ad absurdum is thus, well why aren't we just writing in ASM, it all boils down to that anyway, right? People were doing fine then too... Could it also be said that accusing people of needing "crutches" is also snobbery?

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

#207

Post by externalreality » Mon, Apr 08, 2019, 4:40 AM UTC

stemmlerjs wrote: post #198

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…

Thanks for reading the article. Perhaps I should have been more specific about what needs testing. In The Clean Coder by Uncle Bob, he says that your unit tests should approach the asymptote of 100% test coverage. Here's where I agree with his statement: On the backend, I agree that all of the domain-layer code should be tested. This is a hard requirement for me. It's also code that has 0 dependencies so it should be…

> You can't refactor code without tests

See this is where the conversation goes south. You will use the phrase "unit tests" when it suits you, and then, like a magician using indirection, generalize to the word "tests" when it suits you.

Why are you listening to Uncle Bob so much?

I mean you can do as you like. However, the strong "Uncle Bob" style assertions should probably be left out of most articles in favor of a more humble "this is what worked for me/us" approach. Universal rules for any discipline are very hard to come by. Sharing what worked for you on your projects is great but it becomes somewhat obnoxious when you try to generalize it to universal rules that works in all environments for everyone.

Also, I think that large unit test suites, where most of the tests are redundant, come about in competitive environments where if you try to make a commit without a test some other competitive coder will try to use it as a "I know better" stepping stone and call you out on the change - "Where is the test". After 3 years of this behavior what do you think your going to have. A nice clean suite of tests or a monstrous big ball of stubs, mocks, faked, copy pasta that resulted from defensive social coding.

Honestly, write a light suite of tests that get to the point, and keep your ability to code swiftly and make changes quickly. As the code matures you'll find the trouble spots and focus testing on those areas. Don't blindly follow methodologies that are going to have you writing large test suite for version pre-alpha 0.0, and now your updating a large test suite for every micro-change just to make it to beta 1.

Here is an old article by DHH where he rails against unit testing dogma. Ironically it was ideas from the Ruby community that formed a lot of the basis of the mad dog McCarthyan style unit test dogma. https://dhh.dk/2014/tdd-is-dead-long-live-testing.html

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

#208

Post by smt88 » Mon, Apr 08, 2019, 4:43 AM UTC

ravenstine wrote: post #170

Arbalest wrote: post #141

Earlier quoted context omitted.

>If types are really that big a deal that you have a hard time writing an application without a compiler checking your types, you should reevaluate what you're doing. Implying that everyone has exceptional short term memory, and reading old code has virtually no cost.

I never said that TypeScript wasn't helpful. The picture painted by some people that frontend applications without compile-time type-checking are ready to fall apart at the seams and have knobs and springs go flying everywhere, like something from a Looney Tunes cartoon, is patently absurd.

> The picture painted by some people that frontend applications without compile-time type-checking are ready to fall apart at the seams and have knobs and springs go flying everywhere, like something from a Looney Tunes cartoon, is patently absurd.

This is a great analogy for my experience with JS projects. Most bugs are found at runtime, which is incredibly frustrating and time-consuming.

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

#209

Post by nurettin » Mon, Apr 08, 2019, 4:44 AM UTC

weberc2 wrote: post #172

nurettin wrote: post #86

Earlier quoted context omitted.

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…

Python’s type system is a particularly bad example. It’s not ergonomic and the type checking is immature.

Not sure what immature or ergonomic means in this context, but I'm pretty sure handling of "private" variables (self._foo) is abysmal.

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

#210

Post by JamesBarney » Mon, Apr 08, 2019, 4:57 AM UTC

ajxs wrote: post #178

bloomca wrote: post #173

Earlier quoted context omitted.

> Promise-fatigue JavaScript actually handles async IO nicely, and I've never heard this term before (callback hell, yes). So promises and async/await sugar actually make it pretty nice. > poor ecosystem Ecosystem is fine, just don't jump on everything new. The well-known problem is standard library, it is indeed a problem, usually addressed with a mix of additional packages. > For the extra tax you pay in terms of b…

I actually just made the term up myself just then to describe my feelings about the fact that all of the methods in our service layer are just `await this(); await that(); await another(); //...` and so on. Please be aware that this post is describing my own experiences in back-end web-app development using Node. I feel I'm courting more controversy here, but if you're using `async/await` ad-nauseum your app might no…

I never mind writing out the awaits. But that might be because I remember what writing asynchronous code was like 10 year ago and damn await is nicer.