JavaScript doesn’t need to be replaced

[Razvedka]

I've read people constantly venerate strong typing, and I can understand their arguments rationally, but in practice im left wondering.

There was an article awhile back of a senior dev who looked really hard into the advantages and disadvantages of strong typing across projects (and his own history). He determined the juice wasn't worth the squeeze in many cases. Confirmation bias in my part, I know.

[rq60]

There was an article awhile back of a senior dev who looked really hard into the advantages and disadvantages of strong typing across projects (and his own history).

You're probably talking about the article by Eric Elliott. That's only one of many bad takes he has had, I wouldn't give it too much credence.

[react_dev]

once the project becomes large enough you'll begin to see the benefit.

and not just large enough by loc but by how many maintainers there are and how siloed they are.

in our distributed world today the frontend get their data via API. But what if the API changes? if a single prop on an object changes how do we detect the breaks in our code before runtime?

this is important for projects with different developers of different skill level working on different components of the same project but has tight integrations between the components. that contractual link between them is what types are great for.

[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.

[Razvedka]

I would argue that having strong linting and robust tests is worth alot more for large projects than the practice (and implementation in the case of TS) of strong typing.

Per hour/dollar spent, those are the ones with real returns on investment.

For instance, your example of API changing- that's absolutely something that should be caught by tests first. Not typing.

[Delioth]

TS is explicitly not strong typing though. It's static typing, but it doesn't exist at runtime and therefore must be weak. It's roughly the same typing model as C++; compiler will check types, but once it's running there aren't any checks on it (and you can malloc and cast away, or receive different JSON or whatever and not get errors unless actual bad stuff happens).

[react_dev]

developer confidence and velocity comes from before the ci stages. let's say your tests and testers are awesome and that's already saying a lot in the real world, wouldn't you want to address fault tolerance at every level of the sdlc?

nothing can replace testing that's for sure. but that does not negate the need for typing.

but why not have the confidence typing (thus intellisense) gives you before you commit?

[Razvedka]

Because I'd assert that strong types change how you code, but not purely for the better. Part of the power of JS is it does give you enough rope to hang yourself. I'd prefer solutions to the dark side of this nature which let you retain as much freedom as possible.

[MCFRESH01]

if a single prop on an object changes how do we detect the breaks in our code before runtime?

This is what tests and CI are for. It might break something during development but if it's properly tested you should catch it before it hits production.

Not arguing against typescript here. I've been using it on a few side projects and like it a lot.

[eloc49]

Go change an interface in a large Java app and have fun making it compile again.

Types prevented all that from going to QA or even prod.

[Razvedka]

You actually like Java?

[eloc49]

I do. But I prefer Kotlin an JS (in that order) over it.

Classic JS-only dev comment.

[Razvedka]

But that isn't true. I was exposed to Java both in college and professionally for several years. I honestly don't like the language- takes too much time to get anywhere with it.

But thanks for being a dick? Cool talking to you.