By the way, now that I think about it, I could draw a parallel here, remembering another recent thread here on HN: - TypeScript is easy for reading but hard for writing code - Tailwind is easy for writing but hard for reading code

I think stuff like this really comes down to getting used to and accepting.

I had the same views on code prettiers. I thought, aligning your code by hand makes you think about the structure. That you'd invest more time in making your code readable and thus it would be more readable.

When I first got to use prettier on a team and accepted it's value, the benefits I perceived were so vast, that my arguments seemed irrelevant in comparison.

Sure! I want prettier for types. So I don't have to manually type the obvious things. The IDEs are smart, but I haven't found one that would be that smart.

I'm wondering what do you mean by obvious things, do you have any example? TypeScript can infer types[0] even through context, and it's even a good practice to let TypeScript do that for you.

[0]: https://www.typescriptlang.org/docs/handbook/type-inference....

but wouldn't the static code analysis complain in that example?

at least once you want to do anything meaningful with that x

IntelliJ / WebStorm has this exact feature.

You can also generate API types based on your backend.

That is cool. Will try that. But the type information the IDE provides to me is sufficient even without TypeScript. So, back again to the question — is TypeScript worth it?

I had the same question initially. TypeScript is the way you configure intellisense. Some types can be inferred, but not all, and most of the typing I do is to _restrict_ what data can be used. TS gives you feedback anywhere you ask for it, and paired with IntelliJ I feel like I have superpowers.

Another point: You can create types for your API client programatically, meaning your front-end can be aware of exactly what types your backend is returning. This cannot be accomplished with intellisense.

Let's think about what happens on a team: If a single person goes and reads the source code to learn how the public API works instead of simply using the exported types, that's a wasted thirty minutes instead of two - okay, fine, whatever. If all of my engineers have to do this, suddenly each of them is spending that amount individually; and just like that, we've wasted an entire man-day, for nothing.

As you declared in your own comment, TypeScript is great for reading, hard for writing. I don't know about you, but my code is read several times more often, and by different people, than written. TypeScript is a no-brainer, time-saving wise.

I don't agree that typescript makes writing code hard. I believe the opposite- it makes writing code easier

I am a strong believer that every developer on a team should know how the code works. Emphasis on HOW. You only know that if you go to the source of truth. That is how people become proficient with a skill — by doing and re-doing and re-doing things.

I disagree that it's wasted time. The time spent investigating how a piece of code works is time extremely well spent.

If the code is too difficult to understand — of course one can hind behind types.

So, yeah, to sum it up — I think types are an overhead for a well written piece of code.

If the codebase is small and owned by a few people then it might be true. But when the codebase gets large enough and worked on by multiple teams - it is unreasonable to expect that everyone will understand the workings of the whole application.

How big is the team that you work with ? The benefit really shines in a large project with lots of devs.

I guess this comes down to personal preference. For me, this is mixing the interface with the implementation. You shouldn't need to know how something works to be able to use it, for me, that's the real overhead. Maybe this works on a small scale, but what if the source code changes?

That being said, I do like inspecting the source from time to understand it better, or make up for missing documentation. Sometimes though, with this being JS, I wish that I could unsee the things that I've seen, code that production depends upon, deep within the dependency tree.

I agree with the idea of fluency when writing without types, but for me it's not about how fast you can write code. Code for me is a lot of rereading and understanding what the hell you wrote just a few days ago, I find typed code easier to get back into and it's faster to find things that broke in parts of the codebase that you're less familiar with when you change something.

When you use TS purely for annotating strings and generic Record<string, any> 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.

You should try out something like Rescript then. It uses the ocaml type system including its ability to infer all types. You get all the benefits of the compiler enforcing consistent usage of types without having to annotate everything.

"I also think this makes one a better developer."

It's a glorified way to put "slowing you down". When you go to your root store key and think about a better name, a single rename action traces all the usages _safely_ down throughout the whole codebase, across packages in a workspace; now compare that with the manual process. No, search & replace doesn't come close to this convenience. Having this kind of refactoring ability at hand makes you speedier, flexible, adaptive, exploring new ideas, and it makes work fun - these in fact makes one a better developer.

"typing obvious things and boilerplate"

That was the center of reservations against TS until I figured out that it's the wrong way of using it. Normally you very rarely have primitive type annotations, or any kind of obvious things, because that's inferable.

For me, it's the tsConfig part, it gets more and more complicated, especially when you work with monorepos, the lack of full config examples in the official doc, they just give you properties and explanation, you have to mix and match to get it right.

> obvious things

Obvious things may not look obvious from other programmers or for yourself sometime in the future or from a code you'd written while feeling asleep.

If you'd totally think that's an obvious overhead, just give it "any". Though I never use it.

Automatic type mismatch warning and auto completion in the editor feels quite worth the little "documentation" static typing effort.

Of course, if anyone is using some basic editors that don't even highlight TS errors in real time, then it feels like a complete waste of time.

I've also been working in JavaScript for 20 years and TypeScript for 5. You will have to claw TypeScript out of my cold, dead hands. You shouldn't need to type obvious things in most cases, TS should be able to infer it. In my experience TypeScript has prevented many bugs, makes coding more enjoyable, clear and faster, and best of all, refactoring becomes like a super power. I've yet to do a large refactor in a good TS codebase that caused a single regression. The word "good" here is a pretty strong caveat though. TS is only as good as you make it, and overlaying types onto a dynamically typed language (especially manually) can cause issues for sure.

I feel like my JS skills are way above average so I agree with you that if you have the chops then typing obvious stuff just wastes time. However, new developers or those unfamiliar with the ins and outs of JS need help to understand what are they working with. I also feel when a project gets really big/complicated then TS starts to help convey data structures but I think at that point TS becomes the documentation you should have been writing all along. However, the one thing I really don't enjoy about TS is when some library is typed it'll be very strict to the point that valid JS isn't allowed and the invocation of telling TS not to check needs to added for the segment which in turn looks like a code smell. Or the types get to meta-program oriented and I have to start inserting types everywhere instead of them being inferred.