5 ms·

I feel like TypeScript is definitely worth it BUT it seems to be getting ever more powerful but not in a good way, in complex way. Too much time is spend fight

I feel like TypeScript is definitely worth it BUT it seems to be getting ever more powerful but not in a good way, in complex way. Too much time is spend fighting TypeScript as opposed to writing application code. I have a question for the language experts out there .... why is TypeScript getting so complex? Are other strongly typed languages this complex? Or does the complexity arise from trying to overlay typing on JavaScript which is an incredibly dynamic language? And if it is the case that TypeScript's complexity keeps going up because essentially "strongly typed JavaScript" is a hack, then should we all be moving to a much simpler strongly typed language that compiles to WASM, and yet still richly interfaces with the DOM and browser APIs? Does TypeScript just have to keep getting ever and ever more complex and detailed - is that the unavoidable future?

Aeolun 4y ago
> Or does the complexity arise from trying to overlay typing on JavaScript which is an incredibly dynamic language? Mostly this. There’s still some valid constructs in Javascript that are inexpressible in Typescript (though I’m inclined to believe most common ones are covered by now). But to be honest, that’s not anything you are forced to use. A lot of people do because the benefits it brings are so nice.
- dmak 4y ago
  I have such huge issues TypeScript decorators. It's so obvious on how that would work in JavaScript, but it looks completely foreign in TypeScript.
stickfigure 4y ago
You answered this all yourself. Yes, it's a hack. Yes, probably some other WASM-targeted language will exceed Javascript's mindshare. But that may take many years, and you need to build software now.
dclowd9901 4y ago
Typescript doesn’t just statically type. That’s easy. It does program flow analysis to 1) infer type and 2) ensure the inferred types actually work. I think in most statically type environments, the type analysis engine relies a lot of on the developer to define the correct types in the correct places, but the types in TS are always _logically_ correct. As in absolutely correct (unless of course you eject from the type system using coercion).
- azangru 4y ago
  > but the types in TS are always _logically_ correct. As in absolutely correct Erm... type Test = Array<number>; const xs: Test = []; const x = xs[0]; What's the type of x, according to typescript's default behavior? It's number [0]. What's the logically correct type? Some sort of a Maybe<number>, which typescript doesn't have; so a number|undefined instead. Most people don't use typescript at that level of soundness, both because it would be painful, and because typescript doesn't have it as a default. [0] - https://www.typescriptlang.org/play?#code/C4TwDgpgBAKhDOwoF4oEEBOGCGIA8AdgK4C2ARhBgHwDcAUHQMYD2BiUAHvAFywJKoA2gF16LNkg4pO8QQAZRdIA https://www.typescriptlang.org/play?#code/C4TwDgpgBAKhDOwoF4...
  - mpawelski 4y ago
    there is --no-unchecked-indexed-access option for it. Which is not on by default or in --stric mode because indeed in practise it's painfull https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/#no-unchecked-indexed-access https://devblogs.microsoft.com/typescript/announcing-typescr...
  - dclowd9901 4y ago
    I’ve never found it to be overly painful. If you’re accessing values this way (on an index vs defined fields), you’re already treading into iffy territory, structure-wise, and its good to undermine your assumptions about what’s at the index. An extra check might seem very hand-holdy, but I’ve been doing JS long enough now to have seen a large number of errors originate in this class of index access.
porknubbins 4y ago
I don’t know but my experience with TypeScript is it is the C++ of type systems- it wants to have all possible features and caters to the demands of the most sophisticated users at the expense of the 99%. I also enjoy using simple TS like I like to write simple C++.
- andrewstuart 4y ago
  I wonder if maybe the TypeScript team should have stopped at some point and said "no more, we're just making complex now!". The Wizards Of TypeScript seem to be implementing ever more obscure use cases with ever more diminishing returns in terms of the number of programmers who will ever use those advanced features. What happens when you have a fully funded development team at Microsoft, who actually finished the job long ago? They just keep developing, ad infinitum.

Aeolun 4y ago

> Or does the complexity arise from trying to overlay typing on JavaScript which is an incredibly dynamic language? Mostly this. There’s still some valid constructs in Javascript that are inexpressible in Typescript (though I’m inclined to believe most common ones are covered by now). But to be honest, that’s not anything you are forced to use. A lot of people do because the benefits it brings are so nice.

dmak 4y ago
I have such huge issues TypeScript decorators. It's so obvious on how that would work in JavaScript, but it looks completely foreign in TypeScript.

stickfigure 4y ago

You answered this all yourself. Yes, it's a hack. Yes, probably some other WASM-targeted language will exceed Javascript's mindshare. But that may take many years, and you need to build software now.

dclowd9901 4y ago

Typescript doesn’t just statically type. That’s easy. It does program flow analysis to 1) infer type and 2) ensure the inferred types actually work. I think in most statically type environments, the type analysis engine relies a lot of on the developer to define the correct types in the correct places, but the types in TS are always _logically_ correct. As in absolutely correct (unless of course you eject from the type system using coercion).

azangru 4y ago
> but the types in TS are always _logically_ correct. As in absolutely correct Erm... type Test = Array<number>; const xs: Test = []; const x = xs[0]; What's the type of x, according to typescript's default behavior? It's number [0]. What's the logically correct type? Some sort of a Maybe<number>, which typescript doesn't have; so a number|undefined instead. Most people don't use typescript at that level of soundness, both because it would be painful, and because typescript doesn't have it as a default. [0] - https://www.typescriptlang.org/play?#code/C4TwDgpgBAKhDOwoF4oEEBOGCGIA8AdgK4C2ARhBgHwDcAUHQMYD2BiUAHvAFywJKoA2gF16LNkg4pO8QQAZRdIA https://www.typescriptlang.org/play?#code/C4TwDgpgBAKhDOwoF4...
- mpawelski 4y ago
  there is --no-unchecked-indexed-access option for it. Which is not on by default or in --stric mode because indeed in practise it's painfull https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/#no-unchecked-indexed-access https://devblogs.microsoft.com/typescript/announcing-typescr...
- dclowd9901 4y ago
  I’ve never found it to be overly painful. If you’re accessing values this way (on an index vs defined fields), you’re already treading into iffy territory, structure-wise, and its good to undermine your assumptions about what’s at the index. An extra check might seem very hand-holdy, but I’ve been doing JS long enough now to have seen a large number of errors originate in this class of index access.

porknubbins 4y ago

I don’t know but my experience with TypeScript is it is the C++ of type systems- it wants to have all possible features and caters to the demands of the most sophisticated users at the expense of the 99%. I also enjoy using simple TS like I like to write simple C++.

andrewstuart 4y ago
I wonder if maybe the TypeScript team should have stopped at some point and said "no more, we're just making complex now!". The Wizards Of TypeScript seem to be implementing ever more obscure use cases with ever more diminishing returns in terms of the number of programmers who will ever use those advanced features. What happens when you have a fully funded development team at Microsoft, who actually finished the job long ago? They just keep developing, ad infinitum.