[yakshaving_jgt]

> This cones as no surprise to me

If your comment were code, TypeScript would have caught your typo at compile time, versus JavaScript where your users would have experienced this (potentially catastrophic) error at runtime.

[ddek]

Had the original typo been corrected, TS would have also caught your reply and told you to update it.

This is the main value we get out of TS. If we rename a property on a viewmodel, we then update a TS file containing all the models. In this trivial example an auto refactor might propagate the change, but if it didn’t we get type errors all over the application telling us to change this. In JS, there’s an overwhelming possibility we miss one of these, and it isn’t picked up until production.

[smichel17]

Worse, it might even work properly in production for many common use cases, then blow up in your face somewhere down the line.

Real-life example: I recently came across some code that checked for a rare error. It was in the form,

    if (object.property === CONST_ERR_CODE) { /* handle it */ }

At some point, `object` had been refactored and `property` was no longer on it, effectively turning the statement into "if (false)".

This class of issue is probably my least favorite thing about js at any type of scale. It's so incredibly permissive that even simple tweaks need to be scrutinized carefully, whether by human eyes or unit tests. Using human eyes means I can't write js when I'm tired at the end of the day (otherwise the perfect time for small, no-functional-changes refactoring), and unit tests for trite details are boring -- I'd rather spend that effort up front, to appease the compiler.

On the other hand, js is incredibly nice for prototyping, before I have to care about edge cases.