Reason, ClojureScript are separate languages with their own computation models and conventions. They are designed to have their own ecosystems rather than integrate smoothly with the JS ecosystem.

TypeScript integrates with the JS ecosystem, often major JS libraries include typescript definitions in the box, or are even written in typescript.

Flow has been obsolete for a while now (yes I said it).

I only have experience with ClojureScript, there the npm ecosystem support is good thanks to recentish improvements, at least for consuming, and we routinely use libraries from there. Usually encapsulated by some ClojureScript shim to keep functional interfaces (and kebab case!).

ClojureScript (and the other mentioned languages) really are in a different category than TypeScript. You can think of TypeScript as a linter for JavaScript that you help by adding some annotations to your JS, rather than an entirely different language. Deno merely strips those annotations for you before executing the remaining JavaScript.

The TS language semantics would seem to preclude a stripping based implementation, no? Eg generics seem to be a whole new area of semantics [1].

I agree that TS is closer to JS than ClojureScript is, but it seems to me to be its own compiled language with code generation targeting JS.

[1] https://www.typescriptlang.org/docs/handbook/2/generics.html

Generics in typescript do not affect codegen, they are only visible to the typechecker.

The main typescript features that require specialist codegen for ESNext targets are enums (especially const enums) and namespaces. These were added in the past when typescript was less strict about adding features that affect codegen, if proposed today they would not be accepted as typescript now has a policy of waiting for JavaScript to implement features first.

What about this article, which says the type level programming features constitute a turing complete system: https://mjj.io/2021/03/29/type-level-programming-in-typescri...

Edit: ok, it says it affects whether the program will typecheck, so it's consistent with not affecting code generation.

(More Turing completeness discussion at https://github.com/Microsoft/TypeScript/issues/14833)

Then there are other features that have no equivalent in JS. For example enums. And the handbook talks about what kind of JS they "compile to".

See the last paragraph of zarzavat's comment :) They wouldn't be added today, and they aren't widely used any more (they have non-codegen alternatives now). In other words, breaking changes in semantics shouldn't be a worry any more, since the TS team has consciously decided to attempt to avoid them a few years ago.

> Not to mention the majority of Node and FE developers who continue to use JS.

I don't think this is true any more. According to https://2020.stateofjs.com/en-US/technologies/javascript-fla... 78% of JS devs actively use TypeScript

I've never used TypeScript. I've also never heard of this survey before, and I certainly didn't fill it out. I don't think these two facts are unrelated—according to their data, the vast plurality (48%, almost a majority) of the people who filled out that survey did so because they were on the mailing list for it. It's by no means a random or representative sample of the community. People who are more interested in surveys & new technology and are more likely to sign up to answer future surveys.

Meanwhile, the StackOverflow 2020 survey, which reached twice as many JS developers (54k vs 23k), saw that only half of JS developers reported using TypeScript. (not counting any developers that reported using TS but not JS, which would drive the percentage further down). Again though—people who are more likely to fill out random surveys are going to be more plugged in to new technologies and more likely to adopt them.

I've never used Typescript, and I don't plan to. I don't care about static typing. It's nice occasionally, but I don't find that the structural problems I need to solve day to day when working on large codebases are the sorts best solved by static typing. When working on hobby projects, I don't use JS compilers at all, the set of JS supported by modern browsers is already very expressive and iterating very quickly.

I’m curious on how you manage large code bases without some kind of static typing and other checks that typescript provides, like object properties, etc.

Personally I find hard and scary to change things in js and being confident that it would work without breaking anything, with typescript I have that, some function rename, change parameter type, add/remove/rename object fields etc.

I found a couple of times when migrating some files to typescript misspelled names that would be hard to catch and passed the code reviews, that’s and easy task for the computer but harder for the developers, also using tools that makes your code reviews easy its great.

I have used TS in the past and want to use it more in the future, so I'm probably counted in that 78%... but for the vast majority of projects I'm not using it. Based on most comments, questions, examples in lib code, etc. I'd say that the number of people using TS is waaaay less than 78%.

It supports typescript, but you're not required to use it.