Hacker News Reader

Comment by martin_drapeau | Hacker News Reader

Is Typescript necessary for front-end Javascript?

In the many years I've done front-end with Javascript, type-related bugs were very, very rare. Textbook logic as why to use strong types make absolute sense. Yet in the real world, I've had to fight with logic, DOM, UX, framework incomprehension and other types of bugs - not types. Type issues were anomalies among bugs. When they came up, they were the easiest to fix.

Am I alone here? Anyone in the community have concrete examples of type-related bugs that took so much time to required using something like Typescript? Can anyone quantify that?

View on HN

> In the many years I've done front-end with Javascript, type-related bugs were very, very rare.

Wow, really? My experience has been the complete opposite.

Most of the bugs that slip into production have been dumb type errors. Things like accessing a property on an null/undefined value, or on an object that doesn't have that property and unfortunately JS just returns `undefined` instead of complaining (these silent ones can live longer before being spotted).

It's because of these kind of bugs that i've found many JS codebases tend to become brittle to the slightest change, and very difficult to refactor into a good shape. And why i'm seeking statically typed languages like TypeScript on that front at the moment.

It's more likely that OP finds such errors just as frequently but because they are relatively straightforward to fix he doesn't weigh them as much as edge case debugging.

I've heard this same argument from a coworker working on a different project recently working on React/ES6 stack - I check their TFS history and find 3 such fixes in last 2 weeks (and they have reviews before checking in to TFS).

There's a lot of type bugs in my code as I type it, and while I'm writing the unit tests, but I've been keeping track for the last year or so when they happen in QA or Prod and they are quite rare for us (as part of an evaluation of if we should move to Flow/TS).

But there was a heavy correlation between type bugs and the kind of code being written. Our transactional frontend apps? Most bugs are browser css issues, weird environment specific edge cases, misunderstandings of the backend, memory leaks, etc.

In apps that are data heavy though, or backend JS apps, its a whole other story. Type bugs all day every day (though a part of it is because we don't do many and they aren't high profile here, they're very light on tests).

So we moved the later to using tests. While it helps a lot, we did end up with a different kind of issues: broken type definition issues and bugs in the type system. Turns out a very large portion of DefinitelyTyped definitions (especially those of the more obscure libs) are broken and you can't trust them, but you lose a lot of time fixing runtime bugs the type system forced you to make. And while they never hit production, there's more bugs than expected in TS itself, and it takes a while to figure out if I'm doing something wrong before I go look at the bug tracker (the issues I hit have almost always been reported already, but I don't expect them). Fortunately that last category rarely cause issues in production.

> while I'm writing the unit tests

With types you can test quite less. You still should but test code is the worst code, it turns legacy so quickly.

If you're only writing good tests, there's very few tests you wont write: eg, if I test that my function returns the string "Foo", I don't need to test that it returns a string.

And even in sound (er) type systems like Haskell or Elm, I'd (probably. There are ways...) have to write that test.

In JS with Flow or TS though, there's very few (good) unit tests you don't need to write anyway. If your tests are filled with "expect(foo()).toEqual(expect.any(string))", the team needs to be coached on writing proper unit tests regardless of types.

Though the topic that most teams don't know how to write effective unit tests and that type systems help those teams is a totally separate one.

But that's really a symptom of a "big ball of mud" design (non-design, really), where everything has dependencies scattered all over the system, and to change anything you have to consider everything.

Type checking can help you with a few kinds of problems you'll have trying to make changes in those kinds of systems, but you still have piles of problems and it doesn't do anything to help improve the underlying issue.

Static types can help you with some small problems, but that doesn't mean much when the problems you have are big.

Static types are especially useful in big ball of mud design because you can refactor it (like change the shape of a canonical object) and mechanically fix all write/read sites without running the code.

Not sure how that's a small problem unless you never refactor code.

> But that's really a symptom of a "big ball of mud" design (non-design, really)

Yep, that's exactly the problem :)

The thing is that, without ease of refactoring, it's very difficult to change that big ball of mud into something prettier. In fact, i'd say that without ease of refactoring it's kind of inevitable to fall into that big ball of mud "design" in the long run.

(Note: static type systems are not the only tools to help with refactoring. Good test coverage, style guidelines, a well documented / simple architecture, are of course very helpful too.)

Exactly. Static types ( I've used flow not typescript, but similar ) and good unit tests allow ridiculously easy and merciless refactoring of enormous swaths of code in an extremely short period of time with incredibly high confidence.

Integration tests ( not to be confused with functional tests / i.e.: selenium ) that test multiple classes in concert via input / expected output give the most bang for the buck, because you know your code works as a whole.

Isn't refactoring TS also unpredictable? since its type system its no sound.

The short answer is: it depends. With TS you can choose how much type "soundness" you want. The --strict option is very useful[1], but even having it enabled you can still choose to explicitly type something as `any`, and bypass the typechecker if you want.

Something to note though: the example given in the article is not showing any problem in TS. That's how its structural type system works. Both Animal and Bird classes don't have any properties, so the type of their instances is the same as `{}`. If you change the Bird class to something like:

  class Bird extends Animal {
    song: string
  }

Then the line that tries to push a `new Animal` into an Array<Bird> will not type-check, because the types are invalid :)

[1]: https://www.typescriptlang.org/docs/handbook/compiler-option...

Unfortunately I feel that this type of example expresses what not to do with type systems -- favoring composition over inheritance goes a long way to not finding yourself in a brittle type hierarchy and especially in a JavaScript environment where composition is so easily used (and with typescript, still type checked)

One solution to the any typing problem is to use tslint with no-any. It's a bandaid, but it's better than nothing.

Type errors might not be the biggest issue up-front when writing new frontend code, but refactoring JS becomes really hard as the LOCs grow. Typescript (static typeing in general) really helps with this as you can get instance feedback about how you're changing interfaces between parts of the system.

Another reason i've enjoyed TS is the editor intellisense support. It's really helpful when using a library to get type info in your editor instead of having to google when you forget what a function returns, for example. This is also helpful when you're coming back to code you wrote a long time ago, or a colleague wrote it, and you don't know what particular variables/function arguments/object properties are at a given spot in the code.

Oh yeah, that's another great point (although you're still stuck with the fact that somebody can access object properties by key).

Couldn't you solve this with privates, either via a naming convention or with symbols, as well as using getters?

Not really. If I declare that an object has property xyz obj.xyz and obj['xyz'] are both valid ways of addressing it.

Absolutely. Typing is a real timesaver as it adds so much to how much an ide can help you.

Like others, my experience was also complete opposite.

The app I did was a financial related app so we do some good amount of number crunching. From calculations, to transfers, and storage.

You won't believe how many type errors we had throughout the stack. It's definitely because of JavaScript's inability to do type checking.

One workaround people did was to do the type checking in the first few lines of the function call, which is how people that still do raw JavaScript, do it today.

    function add(a,b) {
      if (typeof a !== 'number') { ... }
      if (typeof b !== 'number') { ... }

      return a + b;
    }

This eventually creeps throughout in the code and introduces this code smell.

This above can be solved by just using TypeScript.

For me it is not about catching bugs that would make it into production; I agree those are relatively rare. It is about catching simple mistakes while I'm in the middle of coding or refactoring. These are mistakes that even without the warnings would probably not even make it into a commit, but the warnings directly in my editor in real-time are an even shorter round-trip than test executions. It results in less fumbling around to find the actual cause of some failure.

I have seen quite a few of those - mostly in returning promise vs actual value from function in some special case.

The other class of errors was with objects that reference other objects - e.g. function takes `loggedUser` parameter which is expected to have property `finishedLevels` or some such and someone sends it `bestFriend` object that kinda looks similar but does not have 'finishedLevels` property.

Most importantly, you have to code differently when writing without typing. It felt as if my hands were cut of at first - I was often in "I would solve this easily in Java just by making interface that would communicate list of needed methods, but cant in javascript because there is no such thing as interface". This is also the likely reason why you do not see many bugs - you probably learned to avoid all those patterns and idioms.

Even more importantly, it really helps with refactoring if you can rename function/variable or change number of its parameters and have all the places (and exactly them) that call that place return error. I can refactor much more aggressively when working with java vs javascript. In java, I spend a lot of time changing existing stuff, when I am tired to do hard work. In javascript it is special thing you do when you are well rested and fully focused.

One major argument is that TypeScript gives you arity checking on function calls, especially as you're refactoring. Seems like a simple thing, but after using TypeScript I realized how much time I wasted solving things like that.

> Am I alone here?

I am not a Javascript person, but my personal experience has been similar.

FWIW, I used to do maintenance programming on a ~250 KLOC application suite written in C. And nearly all of the "type errors" the compiler caught were instances of using some type T where you needed pointer-to-T or vice versa, which is a non-issue in Javascript.

Lately I have warmed up to statically typed languages, but among all the bugs I have run across in dynamically typed languages, unexpected/invalid/wrong types were very, very rare.

The benefit of good type system - IMHO - is not that it keeps you from putting string where a number is required. That kind of problem happens, but is usually easy to fix. But a type system that helps you distinguish between, e.g., numbers that are temperatures and numbers that are air pressure measurements is worth having around.

EDIT: I admit, C's type system is exactly the most sophisticated one I've seen.

> FWIW, I used to do maintenance programming on a ~250 KLOC application suite written in C. And nearly all of the "type errors" the compiler caught were instances of using some type T where you needed pointer-to-T or vice versa, which is a non-issue in Javascript.

How is that a non-issue? If you don't have unit tests covering your entire code base you wouldn't notice a bug like that until it broke in production.

Having type checks let's you catch obviously wrong things like accessing a Promise return value directly rather than interacting with it as a Promise (i.e. then or async/await).

> How is that a non-issue?

In C, there is a distinction between a value and a pointer to some value. In Javascript, as far as I understand, everything is a reference, so the specific mistake the C compiler caught would be impossible to make in Javascript in the first place. (Then again, C does not have concept of promises.)

I am not saying type checks are bad or useless. In fact, over the years, I have grown to appreciate every little bit of advice a static analyzer can give me. But among the bugs I have produced using dynamically typed languages, few had to do with using the wrong type.

> C's type system is exactly the most sophisticated one I've seen.

Oh-oh, too late to edit.

Of course, what I meant to say was: C's type system is NOT exactly the most sophisticated one I've seen. ;-) I like C a lot, but type safety was not its top priority.

Is it "necessary"? Of course not. Lots of people have done without. I do find that it makes it more productive and easier to debug, especially if you're making something like a SPA with complex functionality.

Also, the point isn't so much that there is one major, hard-to-fix bug, but that there are lots of small ones that you never encounter.

I agree. Type-related bugs of the kind that TS can catch are indeed rare and trivial. However, TS does help with documentation, intellisense and refactoring. Personally, I will usually go with Babel/JS, since I don't find that the benefits of static typing outweigh the costs.

I find the costs of static typing very low. What costs do you have in mind?

Everything required to add that to regular Javascript: transpilation, extra markup and understanding and mastering a new tool. Another layer to manage and debug if you will.

Oh. But these days most JS projects are in some task runner anyway.

Assuming you use ES6+ in production, so you need a build step anyways, would you still say TS adds costs that aren't worth it to you? And if so, which costs? I mean that in full honesty, as I generally find myself conflicted whenever I start a new project: TS or ES2015+?

Now browsers support most of ES6, so you only need build step for deployments, and can have fast reloads without a build step when developing.

> Javascript, type-related bugs were very, very rare.

That's because you're not seeing them. I bet that if you plug your frontend to an error-reporting tool (e.g. Sentry) you will be overwhelmed to see all the corner-cases you are overseeing.

but how much of these edge cases are really happening?

Sentry and tools like it are reporting errors that are happening in production to real users.

Ah okay, so it's not reporting theoretical edge cases but real errors?

Yes

Javascript without type info is nearly impossible to refactor effectively.

Catching wrong-type bugs is, for me, relatively low on the list of reasons I enjoy using Typescript. A few of my higher items would be: strictNullChecking, intellisense, and refactoring.

Agree the academia-touted benefit of type-checking isn't that helpful in practice. But types help with documentation and tooling (completion, data-mapping etc).

Types are (apparently) crucial for large projects. However, the #1 benefit is speed, which I don't think Typescript can provide.

Sorry I can't quantify any of that.

EDIT I am curious why this was downvoted.

The number one benefit is that it makes it painful to write certain classes of error prone and hard to read code.

Reply on news.ycombinator.com