[deckard1]

The problem with JavaScript is that it's a terrible example of a dynamically typed language.

> The benefits are a vastly improved safety net at a very minimal cost, smarter tools

That's entirely subjective. As far as tooling, I get the impression from my coworkers and what I've seen online that people that love TypeScript love big bloated IDEs. They love having their IDE tell them what to do. And, personally, I find their usage of IDEs to be a crutch that prevents them from transitioning from a plateau of mediocrity to being a great developer. They don't understand the code. They merely throw things together that match the types that their IDE tells them, like LEGOs. Then they spend hours trying to figure out why their code doesn't work.

As far as the cost goes, my experience has been vastly different than yours. TypeScript is killing my organization. For no real benefit. The warnings it produces are for theoretic bugs rather than actual bugs. The warnings TypeScript produces are incomprehensible to most developers. And when they finally quiet TypeScript down, they don't realize they have the wrong types! No one seems to fully realize how easy it is to get TypeScript wrong. Your code gets littered with ts-ignore and "any" types and suddenly you have a mountain of tech debt. Code becomes ugly and difficult to read with type annotations. It's hard to imagine anyone actually winning in this war of attrition between clean, simple, readable code and TypeScript.

If you're doing TypeScript and having an easy time of it, you're most likely doing it wrong. TypeScript is incredibly nuanced.

Management loves TypeScript though. It's a shield for responsibility. When bugs happen (and they still will with TypeScript), they can point to TypeScript as something they tried. They didn't fail the organization, their technology failed them.

[jillesvangurp]

The safety net thing is absolutely factual. Typescript will tell you "this is a type error, fix it". Javascript will not and fail at run time for the same error. So, one is an error that is stopped from happening, the other is a preventable error that your safety net (or lack of one) fails to catch. That was only excusable as long as there was no feasible safety net. Now that there is one, deliberately opting out from it is simply unprofessional and irresponsible.

This in a nutshell is why world + dog is introducing typescript to their codebases. It obviously won't catch all bugs but it will catch more of them. The alternative of not using it simply inexcusable and the people arguing against it tend to not have a very solid case and indeed focus on what arguably is highly subjective like e.g. your claim that it is "ugly". IMHO JS without types is ugly (opinion) and less safe (fact).

I agree typescript is not perfect; I agree it is super sloppy, actually. Even the strict mode still allows a lot of stuff that you should probably should not do (like slapping the any type all over the place). That's why I call it a gateway drug. If you like the little that typescript does, there are other languages that are better.

If typescript is "killing your organization", you should consider leaving. There are all sorts of reasons for organizations to become dysfunctional. The problem always boils down to people, not technology. I'd argue that given your statements, you are possibly part of the problem and not the solution here.

[z3t4]

Personally I'm a fan of sprinkling the code with manual checks, conversions, and early friendly error messages. Rather then spraying it with type annotations. Practically when developing and there's an error, you add a check as early as possible, that would catch the bug, like at the beginning of the function, throwing a human readable error with some added debug data. For example, lets say you have done some detective work to locate the source of a bug, and figured out the earliest possible place to detect it is in the foo() function, where the bug was caused by a missing "baz" property ...

    function foo(bar) {
      if(foo.baz == undefined) throw new Error("foo need to have a baz! foo.baz=" + foo.baz + " foo=" + JSON.stringify(foo, null, 2));
    }

Typescript could probably detect the bug in the first place if you had used interface or what not, and typed everything. Static typing (and also tests) can however slow you down when you are quickly iterating and re-writing. And at the end of the day when you have a working prototype/MVP, and have added a few manual checks that will throw early if there's a bug. Are you gonna spend your time type annotating it all (or writing tests) or are you going to spend that time marketing ?

If the product receive continuous work there will however be a tipping point where tests are needed. And the checks you added will be of help as errors will come early. But when you have tests in place, is it really worth it to spray-paint the code with annotation and make it static ? There are already tools today that can infer most types, and give you auto-completion already.

[CuriouslyC]

I don't want to have to remember the properties of every object, or the arguments to every function, or a myriad of other things. I could be using that time and energy to work on other things that are more important.

[deckard1]

It's not about knowing the interface to a blackbox. It's about semantics. It's about knowing what an object or function is doing.

> I could be using that time and energy to work on other things that are more important.

As a developer, it's your job to know how your code works. There really isn't anything more important than that.