[jillesvangurp]

I recently spent some time introducing typescript to a javascript code base. My background is mostly backend/JVM, so I wasn't the perfect person to be doing this obviously. But as there was nobody else and I needed to own this stuff, I put in the work and got things done.

My impressions are mostly positive in the sense that if you are doing JS, you are better off doing TS. The tooling is great and you can start with simple changes that almost immediately start giving clear benefits in terms of typing related warnings and other improvements. Typescript is minimally intrusive in the sense that all js is valid ts and you can gradually improve it by adding type annotations and addressing warnings.

The benefits are a vastly improved safety net at a very minimal cost, smarter tools, and more confidence that a given piece of code will not break with some entirely preventable error (like an NPE). Excluding whole categories of bugs is a good thing. For new code, I consider it a no brainer. Most new projects seem to default to using typescript so I guess more people have come to the same conclusion. Lots of upsides, no real downsides that I know off. You'd have to be pretty stubborn to opt out at this point. For older code that you still care about, migrating is a good investment as well: you will improve the code. Any other code you probably need to get rid off anyway.

That being said, I believe typescript is merely a gateway drug. Typescript is great and you definitely should use the strict mode. But even in the strict mode it still inherits a lot of cruft from javascript and this makes life needlessly hard. Other languages don't have this problem and the progression from the js/ts ecosystem to other things is very obvious with some younger full stack engineers I've known for a few years. Go and Rust seem particularly popular lately. And even Kotlin seems to be well liked (big fan myself).

Better still, a lot of these languages are coming to the browser (via WASM or transpilation). Inevitably, some projects will start moving away from defaulting to the js/ts ecosystem for frontend work. Right now you'd be a very early adopter but things are improving rapidly and there are some early adopters. I played a bit with kotlin-js recently and while it still has lots of rough edges, it actually works quite well. Not quite a drop-in replacement for typescript just yet but most of that is related to consuming javascript from kotlin; which I'd argue is short term needed but long term undesirable and likely to become less important as native kotlin frameworks emerge (e.g. kvision is a popular one). Tip, parcel recently added kotlin support; works without extra configuration even.

[untog]

I absolutely agree on TypeScript, I love that it's opinionated and simply versioned. Every time I have to step back into a codebase that uses Babel and X number of different plugins it just tires me. Typescript is just Typescript, and the compiler works fantastically well.

> Better still, a lot of these languages are coming to the browser (via WASM or transpilation)

I think this has always been a concern - CoffeeScript had its moment in the sun, then the good parts got merged into JS and it died out. We'll see if that happens again.

WASM concerns me, though, because of the utility you outline, which doesn't actually serve the end-user in any way shape, or form. Much like we're seeing tiny webapps made with React (and requiring browsers to download and parse the accompanying runtime), I worry we're going to see sites using e.g. Kotlin in WASM simply because that's the developer preference, totally ignoring the fact that it means every user is going to have to download a Kotlin runtime and garbage collector despite there being a perfectly good JavaScript one sitting right there.

[battletested]

> CoffeeScript had its moment in the sun, then the good parts got merged into JS

No. Some good parts have been merged, but so many good parts will never get to ESxx or Typescript. Most dev's just don't see it because they do not know Coffeescript well enough. Compared to Coffeescript, Babel is a total mess with all it's options/plugs config etc..

I rarely have type issues in JS, Python or Coffescript. I do have type issues in Typescript though. I fix that with 'any', just like my collegues. A Typescript codebase is about 2x bigger than a Coffeescript codebase, that means about 2 times more chance for bugs. But it's totally amazing to see the Typescript proponents considering the language to be a godsend. I moved from C/C++ to Javascript to get rid of static typing, it's part of my love for JS, but now that joy is being destroyed by static type enthusiasts.

I've never worked in a pretty Typescript codebase ever, same with JS, so many bad constructs, bad naming, bad architecture, etc, etc.. IMAO the real problems with codebases cannot be fixed with Typescript, the problems are way too big and complex for that.

I still don't understand why JS dev's that crave for types don't do Elm or Purescript instead of Typescript.

[untog]

> A Typescript codebase is about 2x bigger than a Coffeescript codebase, that means about 2 times more chance for bugs

That's pretty obviously not true. If that extra code is adding type annotations then it is removing potential bugs because the code won't compile if you accidentally combine incompatible types.

[jillesvangurp]

All these issues are being worked on. If you use kotlin-js, the output is javascript. There are no GC issues, you use the javascript GC.

WASM is currently indeed bottlenecked on the lack of GC. This is being worked on. I expect a lot of progress over the next two years that will gradually remove most of the obstacles on this and other fronts. None of these are fundamental issues; it's just a matter of things not being perfect yet. Despite this, there's already a lot of early adoption. But I agree that Kotlin on WASM is short term not ideal. In the same way C#/Blazor currently only makes sense for enterprise application where download size is less of a concern. Rust does not really need GC, which is why is a popular language for this already.

As far as bloat is concerned; react is actually pretty horrible. I've seen simple react applications go over 1 MB for no good reason. I'd say the react ecosystem is actually a main driver for people wanting to have some alternatives. I actually prefer more lean approaches. Vue.js seems nice and I'm aware of a few nice lightweight dom abstractions (e.g. redom is nice).

[untog]

I'd recommend taking a look at Svelte as well, it compiles down to "raw" JavaScript with very little client-side bloat.

[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.