[wanted2]

> , and to everyone's benefit.

Why? I've worked on large codebases in Coffeescript, ES6 and Typescript. Whatever this whole community sings and believes, but Coffeescript still wins for me. ES6 is still trying to catch up but will probably never reach the beauty and ease of Coffeescript. Both are transpilers, only ES6 with Babel is a total horror to manage (just upgraded a large codebase to Babel 7..).

Typescript takes about 2x the time to write if you want to create all your typings properly. I hear you say; only in the beginning, later it will speed up the development process. I've never seen that in reality! I've actually never seen a proper codebase in Typescript. Show me a Typescript codebase not using the type 'any'! In a decent system language you can't get away with that, it's just a fake sense of security.

A good codebase should not be dependant at all by Typescript or whatever hype comes next. Writing a good codebase is IMHO a craft and should not depend on the language or a bunch of tooling. If Typescript is way to go, what about Python, Ruby, abandon it, deprecated? Are those inferior languages compared to Typescript? Typescript is just another hype, very smart play by Microsoft btw.

[ng12]

> Typescript takes about 2x the time to write if you want to create all your typings properly.

Not true at all. You balance all of this stuff inside your head anyways: this object has this shape, this function takes these arguments, etc. The only overhead is actually writing them down -- which in itself arguably speeds up development because then your IDE knows about them too.

I pushed back migrating from Coffeescript to TypeScript and I consider it one of the only times I was really wrong about a front-end technology.

[eleclady]

> I've actually never seen a proper codebase in Typescript.

That's the problem then. I have, and have clearly seen in the real world why it's superior. ES6/Coffeescript can obviously be done correctly, but chaos tends to ensue as the flexibility is abused. Over time it makes debugging/understanding difficult. TypeScript makes changing/navigating large codebases a breeze. In other words, it's much easier to do correctly than ES6/Coffeescript.

[yaseer]

There are multiple benefits from having TypeScript a clear winner.

1. One standard typed version of JS (As appose to flow and TypeScript) is a better use of open-source developer time. It also reduces decision fatigue when architecturing new JS projects. 2. TypeScript tooling is fantastic. Using VSCode or Webstorm spoils you. 3. TypeScript is a testing ground for experimental language features. It can shape the direction of future versions of JS. 4. Finally, the language is clearly well liked, in addition to being popular. We can debate the pros and cons of its quirks, but overall, the stats say developer satisfaction is high. https://hub.packtpub.com/4-key-findings-from-the-state-of-ja...

[preommr]

> ES6 is still trying to catch up but will probably never reach the beauty and ease of Coffeescript. Both are transpilers, only ES6 with Babel is a total horror to manage (just upgraded a large codebase to Babel 7..).

...

> Both are transpilers

You don't have to transpile es6 if you don't want older browser support.

[kjaer]

> Show me a Typescript codebase not using the type 'any'! In a decent system language you can't get away with that, it's just a fake sense of security.

I don't know the comparison to system languages is fair though, because the use-case for JS is quite different from system languages.

Javascript (and by extension, Typescript) is commonly used to interface between the user and the network, both of which often are outside the bounds of the type system. Add to that any code that interfaces with plain JS, such as external libraries or legacy code. When dealing with those, it's natural to use statically untyped values and type ascriptions based on reasonable assumptions.

Taking that into account, I actually think Typescript's type system is fairly well-designed for the use-case. The problem isn't really with Typescript, it's just intrinsic to the use-case of JS.

[s_tec]

Exactly. Even strongly-typed languages have this problem. In C, it looks like `void *`, while in Java, it's `Object`. The `any` keyword is just the latest in a long line of escape hatches. Pretty much every language has one.

[dragonwriter]

> Even strongly-typed languages have this problem. In C

C is clearly statically typed, but among statically typed language it is quite weakly typed.

[linkmotif]

> Show me a Typescript codebase not using the type 'any'!

Show me a Java project without an unchecked cast... I’m not a CS person but my impression is that sometimes you need these types and they exist in the type system for a reason. No type system is conceptually “perfect” as in there are soundness/expressively tradeoffs. I don’t think using ‘any’ is always bad. Sometimes it’s even right?

[int_19h]

There are type systems that don't have anything like "any" - you find that in languages like OCaml or Haskell.

But in TS, the main reason for "any" is interop with JS.

[linkmotif]

Thanks. So in OCaml/Haskell you can write perfectly sound programs?

[chowells]

Haskell's type system still isn't sound. It just elimates that particular class of errors.

A lack of soundness is closely related to the Turing completeness, especially in languages based on HM. In an ideal world you would want a sound type system and not want Turing completeness, but the tooling doesn't exist to make those choices the most pragmatic right now.

[int_19h]

Well, I mean, you can write perfectly sound programs in Java as well, or in TS. It's rather a question of how hard/easy it is to do so. Technically, any language that has either direct memory manipulation or FFI has the potential to do unsound things about types, but it takes a lot more effort.

[Perseids]

> Writing a good codebase is IMHO a craft and should not depend on the language or a bunch of tooling.

Of course, relative to other code in that language you can write good code in any language and that is a useful and important skill. If you invest enough energy and craft, you can even write code that compares favorably to good code in any language - the Linux code base is a testament to that. Still, it is a fallacy to assume that all languages are created equal. Nowadays, next to nobody would argue that writing code in Assembler is a good idea. And even though it is now possible to write web apps with C (via webassembly) there is no movement by seasoned C programmers to conquer the web.

> If Typescript is way to go, what about Python, Ruby, abandon it, deprecated? Are those inferior languages compared to Typescript? Typescript is just another hype, very smart play by Microsoft btw.

While the truism "use the right tool for the job" is overrated, it applies here. Untyped, quick to write languages are excellent for small projects. When I'm writing Python as glue code, designing nicely typed interfaces is a distraction. Also, Python, Ruby and Javascript have base types with excellent usability. E.g. when you parse time sheet data, it is pleasant to return [(time.parse('9:00'), 'document project X'), (time.parse('10:15'), 'implement feature Y')]. But when projects grow every structure enforced by the language is a guarantee I cherish. You know, there is this special case in your time sheet parser where you return a (time.parse('23:59'), Null) element, instead of using the empty string, which made the code much more elegant. But months later, when you are refactoring the code calling the parser, you have totally forgotten this behavior and introduce a subtle bug. That's the time where I wish I had a robust type system.

TypeScript is great in this regard, as you can ignore all types if you wish and gradually add them later, when the complexity of the code base calls for it. Or you start with complete type coverage from the start if that floats your boat. Or you never introduce types and just consume JavaScript. Because of that, TypeScript is especially valuable for libraries: It gives the consumers of the libraries all choices. And it's also the reason the success of TypeScript is celebrated that much: Each new TypeScript enhanced library increases the effectiveness of the tool (and reduces the amount of `any` crutches).

[bluepnume]

> Show me a Typescript codebase not using the type 'any'!

https://github.com/krakenjs/zoid

Admittedly Flow, not TypeScript -- but 99% the same thing syntax-wise. And yes -- it was difficult to set up and get working comprehensively, but now it's there, it's fairly easy to maintain, and it's invaluable when refactoring, accepting PRs, or adding new features.

Most people using `any` should really be using `mixed` (flow) or `unknown` (ts) which at least force you to check before you use some property of those types.

[ex3ndr]

We are doing backend and frontend in Typescript and have very limited 'any' usage. Mostly for some hacky library for some small isolated need.

I can the same way cast value to an Object in Java of NSObject in Swift.

[ggregoire]

Do you have any experience with static typed languages? All the benefits brought by static typing become obvious & make sense when you actually get to use it.

Also, I'm sorry but you make some weird comparisons. ES6, Coffeescript, TypeScript and Python/Ruby are 4 completely different things. Not sure why you are trying to compare them and choose a winner.