Live data from Hacker News

Ask HN: Is TypeScript worth it?

news.ycombinator.com

111–120 of 469 posts

Re: Ask HN: Is TypeScript worth it?

#111

You couldn’t pay me to work with Vanilla JS on any real life project. It feels like going back to horse and buggy. The biggest things I wouldn’t be able to live without: - the self-documenting nature of Typescript code (I instantly know what a function accepts and returns by hovering over it). - the comprehensive auto complete my ide gets (saves hundreds of trips to the docs / source code per day). - the incredible p…

> on any real life project Could you elaborate on what the barometer/measuring stick for what makes a project real life? I think I know what you mean. Bigger than ____ lines of code/files I'm guessing? X number of classes/interfaces/APIs?

Not the parent poster, but… the size of the codebase is for sure a criterion, but also code I have to continuously maintain or add to, or code written by a team where I have to read others’ code and vice versa.

Re: Ask HN: Is TypeScript worth it?

#112

You couldn’t pay me to work with Vanilla JS on any real life project. It feels like going back to horse and buggy. The biggest things I wouldn’t be able to live without: - the self-documenting nature of Typescript code (I instantly know what a function accepts and returns by hovering over it). - the comprehensive auto complete my ide gets (saves hundreds of trips to the docs / source code per day). - the incredible p…

[deleted]

Re: Ask HN: Is TypeScript worth it?

#114
#1 – You don't have to upgrade TypeScript versions till you are ready, and newer versions never have breaking changes anyways. The syntax remains strictly compatible with ES6 and beyond. Packages you consume publish compiled JS and aren't dependent on specific TypeScript versions at all.

#2 – If libraries haven't published types, just use them as pure JavaScript (which is what you would have done anyways). Lack of documentation again applies to both JS and TS equally.

#3 – I assume you are talking about compiler errors? I have personally found them to be simple to understand, especially when the exact location is highlighted in your IDE. At runtime there will be no difference since it is all the same JS code under the hood.

#4 – Yes transpilation takes non-zero time. TypeScript has a lot of tooling around incremental compile/watching for changes, so I don't think it should really be that much of a burden during development. I have worked on massive TS projects and don't even notice the compile task running in the background.

I find this post weird because TypeScript does have some real drawbacks – overly complex type system, makes the codebase more verbose, false sense of security (no runtime type mismatch errors), mix of typed and untyped code in codebase etc., but your reasons for disliking it all seem superficial and easy to overcome.

In my personal opinion everyone should be starting new JS projects in strict-mode TypeScript by default unless there is a reason not to.

Re: Ask HN: Is TypeScript worth it?

#115

TS can be a pain. I know, I fight with it all the time. That’s probably my fault though. I’ve learned typescript by being exposed to it in our code base, rather than properly learning it through documentation. For all the struggle, it makes me feel very confident about the code, and its reliability. That’s worth a lot.

There seems to be a lot of bespoke choices when setting up TS which have to be weighed up.

For example:

tsc? webpack+plugin? eslint?

And then all those compilerflags. Especially module targets.

Then monorepo considerations: lots of options.

Then how to generate your .d.ts files if it is a package you will publish.

Re: Ask HN: Is TypeScript worth it?

#116
I'm old enough to have worked on two different large enterprise applications which predated TypeScript and it was a nightmare.

Personally I've found that JavaScript lends better to a functional style of coding but there are no protections in the language to enforce this and both codebases I saw had a weird mismatched set of object oriented and functional style principals. Defined classes, prototypical inheritance, modifying the prototype chain directly, a factory pattern here, a weird "constructor" there, just figuring out the shape of the data was difficult to do.

The lack of guardrails in JavaScript also empowered people writing "clever" code which technically works but was insanely hard to parse and understand, especially when you're 20 function calls down a stack trying to understand what's happening.

I agree the TypeScript compiler's error messages are confusing but you should have see the types of stack traces JavaScript produces.

Re: Ask HN: Is TypeScript worth it?

#117

I think Typescript isn't worth using, and I find this unfortunate. The Typescript team clearly has put years of work into this, and clearly has tried to shore up the deficiencies in Javascript. Are you writing a brand-new codebase that needs to work on multiple platforms, and not exclusively in a browser? Don't use Typescript, use a language with native WASM support. This includes avoiding solutions that involve Elec…

I get what you mean about BS. For me the most painful thing (JS or TS) is if you leave a project for a year you need to use a newer node for security, you need to upgrade modules for security, and some NPM package creators love to have breaking changes or even pull modules completely, forcing a lot of manual work and refactoring to fix.

Whereas in .Net this churn rate is way slower because almost all functionality is provided by the famously backward-compat friendly MS which also sets the culture for Nuget publishers too.

Re: Ask HN: Is TypeScript worth it?

#118
post #114

#1 – You don't have to upgrade TypeScript versions till you are ready, and newer versions never have breaking changes anyways. The syntax remains strictly compatible with ES6 and beyond. Packages you consume publish compiled JS and aren't dependent on specific TypeScript versions at all. #2 – If libraries haven't published types, just use them as pure JavaScript (which is what you would have done anyways). Lack of do…

Just to add to #4, I've worked on some large codebases where transpilation starts taking a very long time, and I begin to think "wow, this is really straining TSC"... so far, every time it's happened, it's been because some sort of data files weren't being excluded from the build.

Re: Ask HN: Is TypeScript worth it?

#119
post #23

> I want to skip over the static typing benefits argument, because I think it is well understood that static typing is a good thing and if we could bless JavaScript with a built-in and robust typing system then I don't think many people would be against that. My issue is with the amount of extra work it places on developers, much of it the "dumb" kind of work which can eat up hours and doesn't deliver all that much v…

Doesn't your counter-argument beg the question whether it is indeed 20% BS vs. 80% value? I think the OP is asking about pretty much that percentage. Personally I feel it's more like 70% BS vs. 30% value. Types, after all, are a very weak ontology, i.e., you still cannot know for sure that just because your code compiles it interprets the values it's getting from other party's code correctly. I would even argue that…

Come on, the OP literally said:

> I want to skip over the static typing benefits argument, because I think it is well understood that static typing is a good thing

The OP is interesting in talking about how much of a pain in the ass TS tooling is, and... it's fair to say it's annoying.

If you accept that static types are good (and the OP explicitly said they do), then what are going to do? Basically the OP is saying, "I want static types but not the TSC compiler or ecosystem"; well... it sucks, but you're never going to get that.

The comment you're replying to is just saying: "Well, if you want static types, you gotta live with the bad stuff".

> Doesn't your counter-argument beg the question whether it is indeed 20% BS vs. 80% value?

Nope.

Re: Ask HN: Is TypeScript worth it?

#120
post #114

#1 – You don't have to upgrade TypeScript versions till you are ready, and newer versions never have breaking changes anyways. The syntax remains strictly compatible with ES6 and beyond. Packages you consume publish compiled JS and aren't dependent on specific TypeScript versions at all. #2 – If libraries haven't published types, just use them as pure JavaScript (which is what you would have done anyways). Lack of do…

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