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

141–150 of 244 posts

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

#141

Post by Arbalest »

ravenstine wrote: post #139

The amount of fanboyism in these comments is astounding. TypeScript is a great tool. At the same time, people have written apps with vanilla JavaScript for a very long time now, and it works just fine. 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. It's not "dangerous" to use plain ol' JavaScript, an…

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

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

#142

Post by ajxs »

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 issues. Issues like Promise-fatigue, poor ecosystem, terrible native types are still there under the hood. For the extra tax you pay in terms of build pipeline, tooling and dealing with the ecosystem, you may as well upgrade to a language more suitable for this kind of development for little extra cost. I just feel this debate is somewhat of a false dichotomy. People in this thread are debating Typescript vs Javascript as if these are the only two possible options for web development.

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

#143

Post by woah »

lewisl9029 wrote: post #127
lewisl9029 wrote: post #116

This doesn't seem like a common occurrence, judging from all the praise of TypeScript sung on this thread and elsewhere, but I've had an overall negative experience working with TypeScript so far. Here's some thoughts on what has contributed to that so far: 1. TypeScript pushes you towards its own build pipeline (based on tsc) that doesn't play nicely all the time with mainstream JS build pipelines (usually based on…

2. TypeScript's type checker, at least in its current state, has been downright painful to work with for functional programming with functional composition and higher order functions in general, with errors that are incredibly opaque and unhelpful, and its poor inference introduces so much seemingly avoidable type-related verbosity that it completely distorts the signal to noise ratio in our code. A prime example for…

This is probably not what you wanted to hear, but I’m glad they don’t optimize for Ramda. On projects where I’ve had to use it, it just generally results in a bunch of fanciful syntax flourishes from the Ramda enthusiast on the team. They’ll jump on anything that looks like array manipulation, eager to try some neat Ramda tricks. In the end a “dumb” solution with loops usually ends up being shorter and simpler (not to mention, much easier on the memory without all the copying), and this is the style of code that Typescript optimizes for.

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

#144

Post by crooked-v »

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…

What other languages would you recommend for frontend web development, given that you'll still need a build pipeline and so on?

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

#145

Post by ajxs »

crooked-v wrote: post #144
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…

What other languages would you recommend for frontend web development, given that you'll still need a build pipeline and so on?

My post was directed at back-end development in Typescript/Javascript. My apologies if that wasn't clearer. I don't really have any experience in front-end development in Typescript, so I can't really comment on that. It could be a real improvement there for all I know.

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

#146

Post by int_19h »

ravenstine wrote: post #139

The amount of fanboyism in these comments is astounding. TypeScript is a great tool. At the same time, people have written apps with vanilla JavaScript for a very long time now, and it works just fine. 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. It's not "dangerous" to use plain ol' JavaScript, an…

People have written apps in C for a very long time now, and they work just fine, but it's not exactly the first language of choice for new projects these days outside of some very specific niches.

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

#147

Post by voidreaper »

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…

Other than Ruby and PHP, I've only really worked with JS/TS on the backend. Which strongly-typed programming language would you recommend on the backend?

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

#148

Post by int_19h »

eranation wrote: post #37
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…

If you write a library, or expose a public interface, I do expect a lot of unit tests. Unit tests can run offline, fast, during build time. I don’t mind integ-unit tests that perhaps simulate a database in memory to avoid mocking the entire storage layer. I rather have tests that are technically integration tests as they include more than, well, a unit, as long as they are idempotent, test mainly one thing, and can r…

If you write a library or expose a public interface, I expect functional tests that cover that interface. Unit testing would require going below that level, and test implementation details - which is exactly why those tests tend to be so brittle, and the overhead of maintaining them is so high.

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

#149

Post by AtHeartEngineer »

threatofrain wrote: post #70
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.

I had this problem last year, I ended up just rewriting an entire web application in a couple weeks. It wasn't a big or complicated app, it was only going to be used by a few people, but I had one requirement change that made me redo a lot of work. If I "over engineered" a little bit more it would have totally been fine.

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

#150

Post by dhab »

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…

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 we don't have to - only used it with mobx for UI code) bundled through webpack.

I am not sure what you mean by poor eco-system either. Both JS and TS (increasingly), I feel like is the second best eco-system (in terms of libraries and tooling) after a mainstream language like Java.

There are some warts I think in JS (around numbers, stream handling in pipes), but I think very few languages don't, and it depends on how likely you would be fiddling in those areas.

Extra tax on build pipeline cannot be escaped for anything with any complexity.

I feel like anyone who can write a complex app in good js, refactoring along the way at good speed, and meeting deadlines along the way and not introducing too many regressions, and come back and maintain it after a 6 month context switch, either has way too much time on his hands and/or works too many hours, or is much more smarter than I am and has it figured out.

Post reply on HN