Hacker News Reader

I've never encountered a situation where the lack of typing bit me in the ass. Not even once!

You absolutely have. At some point in your career, you've accidentally got the arguments to a function in the wrong order and had to debug what was happening. Or ended up with a `null` where you didn't expect it. Or used an invalid value for a string enumeration, made an inobvious typo in a field name of an options object, accidentally added brackets and called a function when you meant to pass a reference to it, failed to deal with the return type of a promise, or any number of other examples of mistakes that everybody makes all of the time.

These are all examples of common errors that can be caught by a type checker. It's totally valid to debate whether the cost of a type system is worth paying in the context of different environments, but if you're starting from the not-really-credible position of "I have never made a type error, ever", then it suggests that you're working with a set of faulty assumptions about what they offer.

(For my own part, as a Javascript user of some 20+ years now, picking up TypeScript has been the best boost to productivity and code quality I've had in my career. It's got to the point that I'd just point-blank refuse to work with a Javascript codebase now, because it's not worth it.)

> I've never encountered a situation where the lack of typing bit me in the ass

Quite the claim! For me the moment I never want to look back to is to refactor a substantial part of the architecture of a JS app with more than 20k lines of code (And I did write most of it myself). If you don't do large scale refactorings or work mostly on smaller apps, then indeed, types won't be much of an issue.

But you should become aware about how often you see "undefined is not an object" and similar, that's a type error that is almost gone when using TypeScript.

I've got (too many) years of JS experience too, and I started a project in TS last November to see what the fuss is all about.

I have to say I'm a convert. Not so much because it's catching a ton of errors for me, more that it brings such a massive improvement in IDE autocomplete behaviour. TypeScript in VS Code starts to feel almost like C# in 'real' visual studio. (The errors it does catch in my code are usually potential null references which would probably have been fine, but I'm sure it's avoided a few bugs.)

The most interesting thing for me is that it allows me to feel safe doing things I would avoid in plain JS, like using literal union types (which would be magic numbers/strings without the typing).

I still write JS for small stuff, but when you're next starting a new project that'll go over a few thousand lines of code I definitely recommend giving it a try.

Have you tried type annotations in jsdoc?

Inline /* @type */ statements and jsdoc type declarations coupled with .d.ts files for complex types achieves the same thing for me without the extra compilation step.

Yeah that's what I do as well. I actually find TS uglier now. It ends up being full of really long lines like:

    const myFunction(a: Long<TypeName>, b: Another<LongType>): FooBar

It’s never “just you”, though: it’s present you and past you. When I come back to code I wrote months or years ago, static types are super helpful as I try to remember what the heck I was doing. They’re at least as valuable for documentation as they are for catching errors.

Refactoring is much easier in a well typed codebase.

When refactoring is easier, it happens more often, which means code quality and readability are higher, which reduces the likelihood of every other kind of error.

> I've been coding JavaScript for many, many years. I've never encountered a situation where the lack of typing bit me in the ass. Not even once!

Okay, well, here's an example of it leading to a CVE: https://www.mozilla.org/en-US/security/advisories/mfsa2012-7...

The way-and-how of it is that the then-new devtools team working on the then-new JS console lost track of what objects they were passing into a polymorphic function, which resulted in untrusted, content-supplied objects being treated the same as DOM nodes that were supposed to originate from within the JS console implementation itself (for its UI), which resulted in browser-level privileges being given to content authors of ordinary web pages.

> I've never encountered a situation where the lack of typing bit me in the ass. Not even once!

Maybe you just see the "cannot find property of undefined" type of errors as usual business, but this is the #1 kind of error I see in the logs of big applications, and TypeScript really helps to mitigate them.

> Having said that, it might be because when I'm writing JavaScript it's just me.

Well, you don't need types because you only look at your own code. The advantage of having my IDE tell me what to expect when I'm refactoring a piece of code someone else wrote is a few orders of magnitude more useful and informative than having to jump through various functions and files to understand what's happening.

Years of writing code do not equate to proficiency and expertise. You may have been writing code for many years but I would go so far as to assume that you experience is actually very limited.

Agreed on both counts. For me types are not very useful for catching errors. What they are extremely useful for is documentation and navigation of code. Primarily other people's code of course but also for my own code once a certain amount of time has passed.

This reflects my experience when working alone, but when working on a team the experience is drastically different.

I've often speculated that strong typing only seems like a win to the kind of developer who makes a lot of type errors, and a waste of time to those who don't (which doesn't mean they don't make other errors, of course).

Or to the kind of developer that works in a big team for a big project.

Even developers who "don't make type errors" have to deal with bad and unexpected data, which may be in a different type.

If you don't validate that all untrusted data is off the appropriate type, security vulns or "garbage in - garbage out" bugs can result.

Then if you do manually validate the types of untrusted data, then you have to wonder of having built-in type support might be faster.

"Bad data" doesn't just come from the outside world. As teams start to use shared libraries written by other people, it's also valuable adds guards to ensure that shared functions are being called with the expected types.

My own experience is that it doesn't feel like type-related bugs come up often on my team, but when they do the problems they cause can be bad enough to make us wish more of our code had been ported to TypeScript.

Classic example: a CSV parser parsed numbers as strings because a particular spreadsheet quoted the number column. Result: "2"+"2" = "22"

bringing in tooling to eliminate an entire class of potential errors sounds sounds like an easy decision to me.

Not if the errors are rare and the "tooling" slows down development.

Why do you think it would slow down development? Serious question.

I was shocked how slow tsc is. Got spoiled by using ReasonML before.

Those type annotations don't just magically appear. You have to write them.

Yeah, they're optional, but if you don't write them, there's no point in using TypeScript in the first place.

Types are inferred even when you don't specify them; if you are using a library that has type specifications a lot of your code is going to be well-typed just as a consequence of using that library.

1) "Someone else wrote them" doesn't make them free. Given a limited amount of developer time, that means that the time spent on the annotations wasn't spent on other functionality.

2) If the types can be inferred, that should just happen. No objection there. But this piece is specifically about "adding (manually-authored) type annotations to JavaScript"

Huh? Rebundling my 150kloc project takes about 2 seconds after I save a file and has already reloaded by the time I get to my browser window.

Alternatively, perhaps advocates of static typing simply see a larger variety of errors as type errors. In JS, if I typo a key of an object (e.g. `foo.excute()` instead of `foo.execute()`), I would call that a type error... or at least an error that could be caught by a static type system.

> like a win to the kind of developer who makes a lot of type errors

Or just to the developer that likes to offload that cognitive load to their tools.

Why hold that in my head when the IDE can keep track of it for me? Why memorize every single attribute name when the IDE can autocomplete it for me? etc.

This is about manually-written type annotations. About as far as can be from "the IDE keeping track of it for you".

You manually write the type annotation, and then the IDE keeps track of the rest.

Instead keeping track of the type annotation in your head, and then also keeping track of the rest of the stuff in your head too.

I’ve speculated that a lot of developers don’t recognize type errors for what they are.