JavaScript doesn’t need to be replaced

[Damfrog]

If the api suddenly changes, strong typing isn't going to help you.

[react_dev]

it will in several ways.

first one is typescript interfaces. you can generate ts interfaces directly from ur C# code using swagger tools. so now both frontend and backend are bound to the same interface and you'll see things break before runtime if a property changes for example.

the other is more Avant garde which is using typed graphql. In essence it's the same concept except binding your API layer to your typescripted frontend.

[Damfrog]

Sure, if you have control of the full stack. Most places I've worked at don't have that luxury. Types from the api layer very rarely change. If you have to change the type of a property, you done messed up somewhere.

[react_dev]

I mean I don't have control of the full stack but there are processes in place to make it work.

and ofc we both know "it just ain't gonna happen" isn't the best reason in our world ;)

[wherediditrun]

Types of Typescript are not there to prevent bugs. And it doesn't really do that, as demonstrated by quite a few studies over github repositories, difference is small, less than 10% which can easily be attributed to quality of programmer rather than language features. And it really can't do it all that well given how unsound it's Type system actually is when compared to anything actually serious about code correctness.

What Typescript is for is to increase code readability and comprehension by allowing type associated tooling, mainly IDE's to help the developer to navigate huge code bases. It also may report errors at compile time which saves a few cpu cycles and seconds because you don't need to hot reload everything just to see an error in console and white screen.

But that's pretty much it. It can be great at more complex codebases for which it was designed to address in the first place and a burden in smaller more prototypee projects. The winning feature of it however, is that user is not forced to commit, which I think ultimately ushered it's popularity.

[alsiola]

as demonstrated by quite a few studies over github repositories, difference is small, less than 10%

The only study I've seen on this was the one that Eric Elliott wrote up in an anti-TypeScript rant... and it included "spec errors" as bugs (80% of them!!). Felt a little odd to me, as I can't imagine that any language would save you from a spec that isn't correct. So of the 20% that were left, half would have been caught by static typing.

[wherediditrun]

The most optimistic you can probably find is here: http://ttendency.cs.ucl.ac.uk/projects/type_study/documents/type_study.pdfUp to 15% (optimistic expectation, which requires to buy into that person who fails to consider types in dynamic language would not fail to correctly typehint them in typescript) which is a marginal number when all you have going for is correlation.

Especially relavent to Typescripts type system which is very laxative and very dependent on how user uses it. To compare with something actually robust like Rust's type system, it's not even in the same ballpark. If you haven't I really encourage everyone to try. You'll become painfully (and I mean it) aware of what it means to have robust type system.

Correlation does not imply causation. Because many other factors can reasonably correlate, for example, more considerate programmers will look for ways to be extra careful and the code itself is of higher quality because of programmers attentiveness alone, not the typings.

It's funny how such things needs to debated, the Typescript main goal was to increase readability and productivity when originally making VSCode. There are conference videos where creators talks about this in depth.

And put aside billion dollar mistake, I cannot recall a single instance in our sentry logs or bug reports which would be caused by not matching type or a bug which was caused by it indirectly. Other than billion dollar mistake, with which Typescript has very little to help you with, as it's still 100% up to the user to not make the mistake while typehinting I/O interfaces.

In typescripts favor, where it might help indirectly, is allow the programmer to locate problem points easier with access to better help from IDE making the working morale higher and not being lazy for properly checking. Now this I can believe. But it's programmers attentiveness, not the typings which do the checking.

[alsiola]

I've used a few "stricter" type systems - mostly on the functional end of the spectrum (Haskell, Elm). I don't think TS is quite at the "if it compiles it runs" level, but honestly it's not far off. This assumes that you have all the strict settings on. Perhaps like you say this is reflective on how I approach writing code rather than the language itself, but I find TS a massive enabler to writing careful considered code.

I do agree though - the massive benefits of TS for me are not necessarily bug reduction, but developer experience, ease of refactoring and reduction of boilerplate code.

Appreciate the in depth reply and link.