Comment by siempreb | Hacker News Reader

Comment by siempreb | Hacker News Reader

Parent Full thread

> Typescript solves the biggest issue I have with using JS which is a lack of a static type system.

Hmm, the biggest problem with JS is types? Are you sure? I rarely had issues with types in JS. With JS I just used my trusty dynamic type checker at specific places in the codebase, and testing coverage of course even more importantly.

But with TS, the codebases I see on a daily base are mostly a terrible mess of wrong ideas, wrong libraries, wrong constructs, wrong design principles, tooling hell, etc, etc.. Which is IMHO the real issue with JS/TS. For some reason TS proponents seem to live in a world where 'TS solves everything'.

For me TS is just writing 20% more code and regularly needing to use the 'any' keyword to avoid spending hours on getting a basic line of code working. Everything I write non-professionally is not TS, I cannot think of 1 single reason to give myself that burden.

The best thing TS has given me is even more jobs. With Agile front-end developers spend at least 1 day a week in the meeting room, now with TS they spend 20% of their time left to hassling with types. It's hilarious. Especially all those managers that have no clue what's going on, why front-end development gets slower and slower.

The biggest problem the parent comment have with JS is not types, as you say, but __a lack of a static type system__.

They are things as different as that you can actually have type problems only in a really typed system (as a static type system). Javascript has a very weak type system, and that's the problem. I think you do not understand that static typing serves to solve other problems in the code, not to solve type problems ... it would be like saying that an hypothetical language needs functions to solve function problems ... and then you say that you never had problems with functions in that hypothetical language (ex: assembler, with very primitives "functions", where you have to save data in register before jumping to code in another memory address).

Having a static type system is great but it’s just another tool in the toolbox. I’ve been writing Javascript for 23 years without types and didn’t miss them. They’re great when I have them in other languages but not a deal killer in languages that I don’t.

But so many TypeScript fans act as if having types is the be-all and end-all.

And, unless I’m mistaken and something has changed recently, I often wonder how many of the TypeScript proponents don’t realize that they’re mostly only getting compile time type checking since the compiler strips away the types after TypeScript gets compiled down to Javascript.

Don’t get me wrong; TypeScript is great. But I don’t see it as the savior that others make it out to be.

"I often wonder how many of the TypeScript proponents don’t realize that they’re mostly only getting compile time type checking"

Surely the biggest benefit from static typing is for static-analysis tooling. (e.g. strong compile-time checks).

I don’t disagree but the way people speak about static typing is as if it’s present during the life of the application.

Different languages have different types of behaviour under the "static typing" umbrella.

Typescript has chosen to interop nicely with JS, and they took the tradeoff that if you are passed an object (e.g. from an Ajax request) and you assert that it's a Duck, TS will assume that is correct during static typing. Of course this might be wrong at runtime, you may get returned {'foo':1} instead of {'foo':'bar'} and your object.foo.length now returns undefined.

Static typing in general (in other languages) does persist into the lifetime of the application. By persist, I mean the guarantees persist, even if the types are thrown away. Haskell for example throws away the types at runtime (you can't reflect on them) but because it's so strict, you can be sure that X: String->String does indeed return a string. This you cannot be 100% sure of in Typescript.

So why is Typescript useful? Well if you write an entire app in TS (which I am doing now) then all the code you write ... which is the new non-battle-tested code ... is now type checked against itself. Also well written libraries using TS will be well type checked against. People doing stuff like casting to <any> etc. could break things for you. But in general you get Pareto's rule applied and because most of your code is type checked (and it only isn't when getting stuff from the server or using a dodgy library that has exported an incorrect .d.ts or something), then you get almost 100% of the benefit.

Basically am I getting errors due to incorrect types at runtime in Haskell? Never. Am I getting them in Typescript? Not yet but it's possible, maybe 0.1% chance?

While it's fair to say that a static type system adds friction which isn't suitable for some development mindsets, I think it's worth expanding on problems people run into with types.

Bad types at runtime: with a static type system you make the effort to be sure the code does what it says. With plain ol' JS you can get that confidence from tests. -- different trade-offs made each way.

But another benefit to static types is knowing the structure of the data you're dealing with and how to manipulate it, while you're developing/maintaining the code. -- sure: naming, unit tests, documentation etc. can help, but I find not having the static types handy makes things tricky when there's enough indirection/complexity.

As with the stuff about runtime errors, tastes vary, of course.

Tell me more as I want to grok the dynamic typists viewpoint as I’m sure I’ll learn something. So are you doing type check assertions at runtime and throwing errors? Or are we talking about something else?

What I like most about static typing is tooling support for refactoring and how much easier it can be to change a name or significantly change internal apis and jig stuff around with confidence.

Reply on news.ycombinator.com