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

191–200 of 244 posts

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

#191

Post by hn_throwaway_99 »

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 completely disagree. Or rather I'd say if you're making a bunch of remote calls, and you need the results before taking the next step, then you're going to need to be doing something like this in any case. FWIW I feel a backend controller in Node is much easier to write, and to understand, with async/await than the equivalent patterns in Java.

As you put it, "Once you get into the controllers they tend to become entirely procedural and effectively completely synchronous" but that's because for most people it's far easier to think about a problem as a series of individual steps. Even then, if you have a bunch of serial awaits it's usually pretty trivial to go back and then await on a Promise.all() if you realize things can be run concurrently.

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

#192

Post by nickbauman »

fxfan wrote: post #188
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…

That's why there are compile-to-Js languages that see widespread adoption. Elm, bucklescript, Scala.js to name a few.

... Clojurescript. A React app is 10x more complicated than a Reagent app. http://reagent-project.github.io/

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

#193

Post by innocentoldguy »

TimTheTinker wrote: post #119

The article mentions object-oriented programming several times as a helpful paradigm (especially for domain-constrained problems where DDD is helpful). I’d also like to point out that functional programming is tremendously helpful for solving these types of problems, especially when combined with use of modules. TypeScript is absolutely capable of modeling, checking, and otherwise handling types in a functional progr…

I found functional programming in TypeScript a bit cumbersome. I think Elm is much more accessible if you’re looking to do functional programming in a JavaScript environment.

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

#195

Post by ajxs »

hn_throwaway_99 wrote: post #191
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 completely disagree. Or rather I'd say if you're making a bunch of remote calls, and you need the results before taking the next step, then you're going to need to be doing something like this in any case. FWIW I feel a backend controller in Node is much easier to write, and to understand, with async/await than the equivalent patterns in Java. As you put it, "Once you get into the controllers they tend to become en…

I think I might not have explained myself too well up there. I was referring to entirely sequential async calls. Like: ``` Thing thing = await loadThing(); Thing other = await thing.doSomething(); thing = await saveThing(); // repeat x1000... ```

I see this over and over.

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

#196

Post by koyote »

TimTheTinker wrote: post #119

The article mentions object-oriented programming several times as a helpful paradigm (especially for domain-constrained problems where DDD is helpful). I’d also like to point out that functional programming is tremendously helpful for solving these types of problems, especially when combined with use of modules. TypeScript is absolutely capable of modeling, checking, and otherwise handling types in a functional progr…

Although I haven't used TypeScript extensively, I fail to see how it has better support for functional programming over C#.

Could you provide some examples?

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

#197

Post by je42 »

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…

we have await this() and await that() also in python aiohttp and we will have in C++ co_wait this() and co_wait that() and we have in C# await this() and await that() this is not something specific to JS / Typescript...

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

#198

Post by stemmlerjs »

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 easy to test. TDD pairs really nicely with DDD.

Unit tests give you the needed confidence in order to do refactoring. You can't refactor code without tests. If you do, there's a risk involved. Therefore, in order to safely improve the design of existing code, it needs to have tests. This "detrimental rumor backed by zero evidence" is one of the fundamental takeaways from Martin Fowler's book on "Refactoring" in addition to Uncle Bob's chapter in The Clean Coder on Unit Testing.

Here's where I disagree with his statement on 100% test coverage.

I used to spend a lot of time writing brittle tests by testing front-end UI code. I used tools like Selenium and Cypress. Because the front-end is the most susceptible part of a system to change, I found myself spending an equivalent amount of time maintaining these tests in addition to adding new code. This is a hard place to find a balance. In Angular, I merely ensure that I write tests for services. In React, I spend a lot less time writing Enzyme tests on rendering and a lot more time testing the redux operators.

Uncle Bob clears this up in his book by saying USUALLY, it's not necessary to write UI tests. I'd say by UI tests, he means "rendering tests". His solution is to ensure that you have a way to run acceptance tests that work through the API, as it should be a lot less susceptible to constant regressions. This way, you're essentially testing the features that the API is executing. If you're using DTOs, the inputs and outputs of your system should remain relatively the same anyways, and you should spend less time changing old tests, and more time adding new ones.

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

#199

Post by stemmlerjs »

ChristianGeek wrote: post #81

Your DDD link is dead (so technically it’s a DDDD link :)

Haha. Yeah, that's the next article for me to write. I just started this blog recently. My approach has been to track which dead links have been clicked the most and then write about that topic next. DDD is far in the lead. Expect it soon.

Thanks for reading!

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

#200

Post by stemmlerjs »

will_pseudonym wrote: post #98

FYI, the link to "concrete classes" is incorrectly linking to https://khalilstemmler.com/articles/when-to-use-typescript-g... . I assume the correct link should be pointing to https://khalilstemmler.com/wiki/concrete-class/

I appreciate that. Thank you!
Post reply on HN