Live data from Hacker News

Ask HN: Is TypeScript worth it?

news.ycombinator.com

391–400 of 469 posts

Re: Ask HN: Is TypeScript worth it?

#391

I've been working with JavaScript for 20 years. And 5 years with TypeScript. And, well. I still am not convinced. Too much overhead for me. I really dislike typing obvious things and boilerplate. Probably my fluency with JS is to blame. I don't need to see types and autocompletion. If I really need to — I just go to the source and inspect the source code, that is how I familiarise myself with the interface. I also th…

When you use TS purely for annotating strings and generic Record types, sure. What's the point. Why don't exhaustive matches, unions, and data modelling not get mentioned more often? That's where the true strength lies.

Those are the things I want to use TypeScript for, but it often requires me to adopt the whole ecosystem. I want a middle ground solution; I really just want JavaScript with some parts of TypeScript.

Re: Ask HN: Is TypeScript worth it?

#392

Earlier quoted context omitted.

Comparing Java & Javascript? This reminds me the last recruiter message I got on LinkedIn. "You are a Javascript expert, I have this mission for you with the same language! They're looking for a Java expert!"

I am pointing out that they are not comparable except very superficially.

It's a pointless point to make, and I think people are rightfully calling you out for it. "If my grandmother had wheels she'd be a bicycle."

Re: Ask HN: Is TypeScript worth it?

#393
post #162

I feel like TypeScript is definitely worth it BUT it seems to be getting ever more powerful but not in a good way, in complex way. Too much time is spend fighting TypeScript as opposed to writing application code. I have a question for the language experts out there .... why is TypeScript getting so complex? Are other strongly typed languages this complex? Or does the complexity arise from trying to overlay typing on…

> Or does the complexity arise from trying to overlay typing on JavaScript which is an incredibly dynamic language? Mostly this. There’s still some valid constructs in Javascript that are inexpressible in Typescript (though I’m inclined to believe most common ones are covered by now). But to be honest, that’s not anything you are forced to use. A lot of people do because the benefits it brings are so nice.

I have such huge issues TypeScript decorators. It's so obvious on how that would work in JavaScript, but it looks completely foreign in TypeScript.

Re: Ask HN: Is TypeScript worth it?

#394

Oh, thank heavens! Finally someone says the quiet part out loud. I thought it was heresy and that the TS bubble would never pop. From my perspective, it's not worth it at all. It's just another hype train. It doesn't prevent bad programmers from writing bad code, nor does it cause good programmers to write better code. It mostly just adds bureaucracy and hindrance, in the ways you allude to in your list. It doesn't m…

Yes, 100%. This is exactly how I feel about it - and the idea it has become some unfalsifiable religious ideology is particularly poignant. It's such a drag on development and personally I just don't see the upside that much, just some assertions from people that seem to be repeating something they've heard elsewhere without much experience weighing in on the discussion (except for autocomplete and self documentation which imo is the best part, although could be replaced by something like JSDoc).

Sure, I'm okay to live with TS, and it has its uses, but I thought it was about time we had a discussion about how much harder it can make development.

Re: Ask HN: Is TypeScript worth it?

#395
post #369
post #335

Earlier quoted context omitted.

I think type checking helps with that both directly and indirectly. It helps directly by making it much easier to know what type or shape everything is. Without types, all you have are variable names and tracing the code back up the stack yourself. Sometimes good naming conventions are enough. More often than not, a variable called `product` can be one of 3 different types and you have no idea why unless you go up th…

> I find it also helps indirectly by making clever code harder to write. The dynamic nature of JavaScript encourages a degree of cleverness and meta-programming that makes things harder to understand. While you can do the same in TypeScript, making the complier happy makes it much harder to do so, which encourages more straightforward code. Interesting. Not having to define types makes JS feel very fluid to me when u…

I just can’t get behind the dynamic typing arguments in the slightest anymore.

It doesn’t take any time to type your code. We’re talking seconds on the hour, and the benefits are huge

Re: Ask HN: Is TypeScript worth it?

#397

One of the biggest mistakes that I see devs making is caring too much about making TypeScript happy when they know it doesn't really matter. There are a lot of cases where it's totally reasonable/rational and honestly fairly safe to just throw in a well-scoped "any" cast, a `// @ts-expect-error` comment, etc. If you know what you're trying to do, and TS isn't understanding, sometimes it's just a lot more expedient to…

TIL: `@ts-expect-error`

I've been using ignore a lot and leaving a comment.

Re: Ask HN: Is TypeScript worth it?

#398
post #120

Earlier quoted context omitted.

Regarding #1: this is not true always. Libraries publish types and their type definitions could use new TypeScript features that could force an update.

That shouldn't happen https://github.com/DefinitelyTyped/DefinitelyTyped#i-want-to...

I didn't know about this, thanks.

Re: Ask HN: Is TypeScript worth it?

#399
The TS type system is incredibly powerful, and I wish I could apply to other languages out there. The biggest annoyances with it come from the fact that it isn't its own language; you get runtime errors due to incorrect or out-of-date types (often maintained by people other than the library authors). Also, "any" and "unknown" types tend to sneak in via default generic arguments, vague external module typedefs, etc. These types can spread through your codebase, preventing the type checker from doing its job, and the "strict" mode doesn't do much about it!

Generally speaking, I have to be extremely careful with working on a JS/TS project. I use the strictest modes possible and enable as much linting as possible. I also use the type-coverage module and fail the build if the `any` type gets applied anywhere.

As another general complaint, NPM doesn't do enough to incentivize its users to release quality software. JS/TS has always been very trend-based and social, and even just running a few simple lints and prominently displaying a score on NPM would probably really help the community improve its standards.

Take pub.dev (Dart), for example. Here's a module page: https://pub.dev/packages/firebase_core. The score is displayed prominently, and if you click on it you get a full breakdown of how it was calculated: static analysis, up-to-date dependencies, and documentation (although the coverage is not 100% for this module, so I think it's wrong to assign full points). When you upload to pub.dev, you want a score of 100! It doesn't guarantee that the module is fantastic software, but at least the basics have been taken care of.

In my opinion, the most important piece missing from the score on pub.dev is test coverage. Take for example a page from Metacpan (Perl packages). Here's a module I've released: https://metacpan.org/pod/Algorithm::AM. On the left you see displayed the automated test results, including the test coverage, which has been submitted by volunteers who downloaded and tested the code on a variety of platforms and Perl versions. There's also link to a "kwalitee" page, which is similar to the pub.dev score (though this could be much improved by having an actual score and displaying it prominently on the main module page).

Now an NPM module: https://www.npmjs.com/package/react. What info do we have about the quality of the package? Essentially just the activity from the community (open PR's and issues, downloads). We have no idea how well it's tested, what kind of static checks have been performed, whether your editor will be able to display documentation or typing when you mouse over a method from the library, etc. (TypeScript is mainstream enough now that it should be fine for NPM to provide a bit of special handling for it.) Most 3rd party libraries are from individual authors and probably have very little activity. When deciding whether or not to use them, right now you need to dive through the code to check if the basics are taken care of. Having some of this automated would save a lot of time.

Re: Ask HN: Is TypeScript worth it?

#400
post #390

I share your feelings. These times, whenever I'm setting up a new TS project, feel like: 1) Look up "this months current way of doing things" 2) have a couple of horrible hours wrestling with tooling and the module system 3) add a new feature, install 1 lib with 30 deps 4) figure out that one dep does not work with TS/the chosen module system/whatever versioning related thing 5) go for a walk. scream into the void. c…

This is exactly what I struggle a lot with. I just want JavaScript with simple type checking. TypeScript goes way overboard. I also hate TypeScript decorators. I've seen that grossly abused in codebases that just drive my insane.

Maybe we should just jump to a different timeline in which Facebook's Flow won the war against TS
Post reply on HN