Ask HN: Is TypeScript worth it?

i. Dependency management is indeed frustrating. TypeScript doesn't create a new major version for every more-advanced check. In cases where inference might improve or new analyses are added, we run the risk of affecting existing builds. My best advice on this front is to lock to a specific minor version of TS.

ii. My anecdotal experience is that library documentation could indeed be better; however, that's been the case with JavaScript libraries regardless of types.

iii. Our error messages need to get better - I'm in full agreement with you. Often a concrete repro is a good way to get us thinking. Our error reporting system can often take shortcuts to provide a good error message when we recognize a pattern.

iv. Compilation can be a burden from tooling overhead. For the front-end, it is usually less of a pain since tools like esbuild and swc are making these so much faster and seamless (assuming you're bundling anyway - which is likely if you use npm). For a platform like Node.js, it is admittedly still a bit annoying. You can still use those tools, or you can even use TypeScript for type-checking `.js` files with JSDoc. Long-term, we've been investigating ways to bring type annotations to JavaScript itself and checked by TypeScript - but that might be years away.

I know that these points might not give you back the time you spent working on these issues - but maybe they'll help avoid the same frustrations in the future.

If you have any other thoughts or want to dig into specifics, feel free to reach out at Daniel MyLastName at Microsoft .

I have some fundamental guiding principles I apply to engineering, and I find that TypeScript violates these:

1) Reduce complexity

2) Don't be clever

3) Achievement over activity

4) Longevity

---------------------

#1 Reduce complexity

---------------------

Cross compilation introduces additional complexity with debugging and production support. Sourcemaps work fairly well, but often fail on edge cases - normally where you want to be debugging. I've found that JSDoc with good tooling gets 70%+ of the benefit of TypeScript without the additional complexity of cross compilation.

In the browser Javascript ecosystem, I aim to have what executes in the browser be as close as possible to what I've authored. Typescript works against this goal. This is even more important to me on the server side, where introducing a build step diminishes a lot of the value of having a flexible, dynamic environment like Node. If types are desired on the server side due to needed formalism (several problem domains are like this - banking, etc...) there are other languages/execution environments that may be a better choice.

------------------

#2 Don't be clever

------------------

Clever code is frequently a maintenance nightmare. Code should be clear, readable, and approachable. It should tell a story that's easy for anyone (even semi-technical folks) to read.

Typescript lends itself to "clever" and arcane types & structures that increase cognitive load and decrease maintainability, especially as the rules change.

----------------------------

#3 Achievement over activity

----------------------------

I guide my teams to focus on delivering business results and shipping software. I've seen code bases where up to 40% or more of the total LOC are nothing but types and structures to satisfy the compiler, not to provide features. In some cases, that's a good thing - where the business constraint is correctness over TTM, for example. If not though, it can be a company killer. You can end up shackled by your domain models, and small updates have massive cascading consequences.

I've seen developer's entire sprints consumed by tasks that are abstraction related, and don't provide business value. I've personally known several developers that have told me directly that they don't like shipping software, they just prefer to play with frameworks and development theories. While those are extreme cases, I know many more developers that fall somewhere around there. I'm not sure why, but I think Typescript encourages this soft of thing. I get a sense that the whole ecosystem is more about the software process than delivering valuable features to the users. Though those things aren't mutually exclusive, when taken to excess I've seen software process and tooling devolve into a weird sort of navel gazing that's a barrier to delivery.

------------

#4 Longevity

------------

I prefer to stick to standards. I also tend to avoid frameworks, I use Web Components as a component solution, and keep everything as vanilla as possible. I don't mind using stable libraries, like date-fns or lit-html, but I've been burned too many times by multimillion dollar boondoggles that result from framework churn.

I encourage my team to pick technologies and development methodologies that have a five year lifespan as a minimum goal. I have code I've developed in javascript that's been running in production for 15 years without needing a major overhaul, and with stable dependencies.

On the other hand, I've had TypeScript codebases that completely broke based on rule changes that came from a TS update, and required significant revamping within six months of being authored.

While I do think that TS can be beneficial for some projects and teams - specifically ones that require a high degree of formalism - most of the time I don't see it providing concrete business value. I see it consuming dev cycles for limited benefit.

I am looking forward to the optional typing that's currently a stage 1 proposal. I miss AS3, which I thought struck the perfect balance between static and dynamic typing. Static by default, but it was easy to opt out when being dynamic made more sense.

> i. Dependency management is indeed frustrating. TypeScript doesn't create a new major version for every more-advanced check. In cases where inference might improve or new analyses are added, we run the risk of affecting existing builds. My best advice on this front is to lock to a specific minor version of TS.

In my recent case, I needed to update Apollo Server to v4, which needs a newer version of TypeScript (see https://www.apollographql.com/docs/apollo-server/migration#t...), which in turn broke a type used from ProtobufJS. I am still navigating ProtobufJS source code to figure out what is the correct fix here.

> ii. My anecdotal experience is that library documentation could indeed be better; however, that's been the case with JavaScript libraries regardless of types.

Actually I think documentation is almost universally bad, I don't think Go or other languages are that much better (I don't want to wade into that debate though). The thing is, having TypeScript means you need more documentation. Even some pretty well documented JS/TS libraries completely neglect TypeScript and the end effect is that you end up having to guess things, or start reading source code. I don't actually know how you could improve this situation.

> iii. Our error messages need to get better - I'm in full agreement with you. Often a concrete repro is a good way to get us thinking. Our error reporting system can often take shortcuts to provide a good error message when we recognize a pattern.

I will look closer at this and start to think of how it could be better when I see a confusing message. I would probably count this as the biggest area that could yield improvement, because most of the time frustration is born of not being able to understand an error message. Often fixing things lead to trial and error. Can I just open an issue in the TypeScript repo for this sort of thing if I have a concrete suggestion?

> iv. Compilation can be a burden from tooling overhead. For the front-end, it is usually less of a pain since tools like esbuild and swc are making these so much faster and seamless (assuming you're bundling anyway - which is likely if you use npm). For a platform like Node.js, it is admittedly still a bit annoying. You can still use those tools, or you can even use TypeScript for type-checking `.js` files with JSDoc. Long-term, we've been investigating ways to bring type annotations to JavaScript itself and checked by TypeScript - but that might be years away.

Once it is part of the language, that will help a lot :) I considered using Deno or Bun to get me there on the server side, but need to be careful with production services.