Hacker News Reader

> IMO, until TypeScript gets the following features, it's absolutely not worth using

That doesn't make sense. Browsers are unlikely to add native typescript support in the foreseeable future; whereas meanwhile typescript offers huge benefits compared to untyped javascript when it comes to large codebases and refactorings.

>> that doesn't make sense. Browsers are unlikely to add native typescript support in the foreseeable future;

It's not my fault that browsers are not going to do it. It doesn't change the fact that it is necessary and that TS is useless without it (the cons outweigh the pros).

>> huge benefits compared to untyped javascript when it comes to large codebases and refactorings

I've provided you at least 1 robust argument why this is not the case. You've provided 0.

I can provide another argument against this:

TypeScript only protects the code from compile time type mismatches, it does not prevent every other possible kind of error; it does not even protect the code from runtime type mismatches (for example from JSON objects passed in an HTTP or RPC request).

It also does not protect from race conditions, memory leaks, issues with multiple sources of truth, unexpected asynchronous state mutations, poor choice of abstractions, poor encapsulation of state changes, poorly handled runtime exceptions, poorly handled runtime schema validation errors, bidirectional data flow issues (which lead to glitchy state changes and infinite loops), poor choice of ADTs which lead to inefficient code, poor choice of libraries for the use case, misuse of common programming patterns, and any other major logic errors... At best, it projects code from only 5% of all possible bugs; typically the simplest, most obvious kinds of bugs. Please think about this objectively. TS adds value, but very little value and also it takes away value in other ways.

For the really difficult runtime bugs which take serious debug time, it adds no value; it makes debugging harder because of its reliance on source mapping.

And by the way, instead of down-voting, please try to convince me otherwise because I'm really suffering with the new TS-first reality (I'm on the losing side). I really do want to see the light but I'm not seeing it at all.

I'm seeing masses of people running towards a cliff. I know there is a cliff there because I pulled myself out of it (learned the hard way) and have been walking in the opposite direction for the past few years and I don't see why I should go back there simply because that's the direction where all the cool people are heading.

> I've provided you at least 1 robust argument why this is not the case. You've provided 0.

I can share anecdotal data about my own experience while refactoring: I do rely on the type checker (be it Flow or TypeScript) to alert me when my code changes have introduced type errors. Every time I run the type checker I realise that it would have taken me ages to read through my code and hunt down the type mismatches that might have been introduced.

I can also point you to the famous AirBnB's slide, which says that they estimate that around 40% of their bugs can be prevented with TypeScript [0]

> TypeScript ... does not

Sure. It's not perfect. It's not Haskell, or PureScript, or Scala, or OCaml. But it does protect you from some of the errors. Protection from some of the errors is better than no protection at all, that's my opinion.

As a bonus point, type annotations serve as a living documentation of your code.

> instead of down-voting, please try to convince me otherwise

I did not downvote your post. I do not downvote other people's posts.

[0] - https://twitter.com/remohjansen/status/1093815648566894594?l...

>> I can share anecdotal data about my own experience while refactoring

I totally understand what you're talking about here. I know that TS feeling of being able to just tell the IDE to rename that variable or type anywhere and have that change automatically applied everywhere in the whole codebase. That said, my anecdotal data (having gone back and forth between first AS2 and AS3 for several years and then later between JS and TS multiple times over many years) is that good tests (especially integration tests) even with modest coverage are equally good at finding these sorts of bugs. If I forgot to rename a variable, my tests will fail straight away.

Also, usually I try to keep my classes and functions localized with well defined responsibilities so that any specific kind of data does not need to traverse too many different files; that makes refactoring a lot easier. IMO, not using TS puts more pressure on me to design code in this way and this design approach yields many other benefits.

It takes encapsulation to another level. For example, I don't even believe in the idea of 'cross-cutting concerns' anymore (which is central to the Dependency Injection pattern). For me, the idea of cross-cutting concerns implies a violation of the separation of concern principle (a violation of the cross-cutting kind to be exact). There are almost always ways to avoid these in your code and doing so is always worth it if the programming environment allows it.

>> I can also point you to the famous AirBnB's slide, which says that they estimate that around 40% of their bugs can be prevented with TypeScript

I did read that article when it came out but my point of view on this is that if mostly the same developers rewrite a project (even if they did so in the same language), I would expect at least 40% to 50% fewer bugs. I don't think TypeScript should get the credit there. The reality is that people learn from their mistakes so if they rewrite something, it's going to be better the next time round.

None of those issues are what TS tries to solve. At all.

Compile-time checking is well worth the switch. Refactoring old JS express apps is a nightmare.

You can add TS incrementally, so your argument about "downsides" is not valid. You can use it as strictly as you'd like.

>> None of those issues are what TS tries to solve. At all.

That is exactly my point.

My argument then follows that that these are in fact the most important issues and that they dwarf all other possible issues; not only in terms of being the most difficult ones to debug but also the most common ones.

My argument is then that the problems which TypeScript does solve are so insignificant in the grand scheme of things that it's simply not worth it.

Like putting lipstick on a pig.

You're missing the point of using TypeScript.

How does having native (as in internally having the transpiler embedded) in deno make you suddenly use TS one day? You can use ts-node.

How long do you think all the browsers would agree that TS would totally be the future of JS and implement it natively, let alone wait until everyone out there to start using such browsers that non TS supporting browsers are almost all eliminated for them to be ignored? There's a reason TS can be compiled down to ES5.

And why are you asking TS for performance over raw JS? Seems off topic from TS' point of view. TS and JS use same principle in the runtime environment and not sure how TS can suddenly beat JS by a good margin.

A project that needs multiple minutes for every change sounds like you're doing it wrong. Split the code or use ts-node?

And you want to throw away all the benefits of TS until all of the above which I don't really feel are required are solved? I don't see why.

> - At least 20% performance improvement over plain JavaScript.

How would that work? TS is not an optimizing compiler, it's only a type checker.

Well ActionScript 3 got it to 40% thanks to static type performance optimizations. They did rewrite the engine. That's what it takes unfortunately.

The fact that Microsoft does not want to hire serious compiler engineers and prefers to spend all the money on marketing is not my fault.

ActionScript 3 got a huge improvement because they added a JIT. AVM1 was an interpreter, and a very infamously bad one at that.

You do realize that Anders Hejlsberg is on the TypeScript team? I don't want to imply that he's superhuman or anything, but.. just what is your idea of "serious compiler engineers"?

Well maybe he doesn't get enough leeway. Maybe he knows that he should be building an engine from scratch but management won't let him. This is very common in companies of that size.

Hejlsberg already designed a language with its own runtime from scratch - that was C#.

It is hopefully apparent that the 40% increase (whether it was meant to indicate over leading Javascript engines at the time or over the ActionScript 2 engine) does not in any way indicate there is headroom for a 40% performance increase if static type performance optimizations were applied to a modern Javascript engine.

Many performance improvements come from being able to do code analysis during generation, which is already a trade-off for environments doing in-time interpretation, code generation and optimization.

Large performance increases would most come from removing dynamic language complexity, such as having use of the 'class' feature added in ECMAScript create non-mutable properties by default for function declarations.

I've seen well over 20% improvement in developer velocity which is far more important than performance in most businesses

I've also seen 20% improvement with TypeScript when working with developers in a big corporate environment (especially when no one cares about the project and everyone gets paid hourly).

But when working with senior developers on open source projects (when people don't get paid), I've seen at least 50% drop in developer velocity using TypeScript and lower code quality.

My theory is that developers who are passionate about coding don't need TypeScript to produce high quality code. It mostly just takes the fun out of it.

But I guess if there is no passion to begin with, then I can see how TypeScript can't hurt in that respect. I've worked for a company like this once for 6 months; I had to quit because I enjoy coding too much to spend most of my time writing and renaming type definitions and waiting for the compiler.

Imagine believing this

Most of us hold many opinions that we've formed without any reflection.

More like: Imagine being passionate enough about something to complain about it online, while not even bothering to think it through.