TS has a very complex type system in exchange for relatively weak guarantees about correctness. That's a tradeoff you can choose to take or leave depending on the problem at hand, and holding that position is not the same as believing types have no value.

Unless you're talking about elm or rescript or something then sure sure. But usually when people say things like this they mean typescript.

I still have hopes that Kotlinjs can fix the distribution size and the tooling around binding to js libraries.

Sure it can be an adventure to express something fully in it - but this is true for any type system I've seen.

And I haven't seen another type system that's integrated into a dynamic ecosystem as well (IMO python is 5 years behind in terms of type checking experience) and that lets you chose the level of type sophistication that makes sense.

Static typing, code analysis, automated testing, etc. are all great tools that become counterproductive past a certain point. Where that point is highly depends on what you're doing and typescript is one of the most flexible type systems at letting you make that choice. I'd say a lot of people are terrible at recognizing when they went too far with it for no practical gain.

My only problem with it is that they can't fix the shit JS semantics.

I'm just pointing out that having an opinion about typescript is not the same thing as having an opinion about types. Something I think people are (intentionally?) conflating in these comments.

Too many web developers, basically, I don’t think the conflation is intentional

But all of that makes plenty of sense because in the early days it was rare to work on a real life production JS project that was pure TS from day one in addition to having TS only libraries.

These days it's everywhere and the work has been done to move away from rampant anys in popular libraries. The tooling is also mature and it's rare to find major JS libraries not already packaged with types or a @types import. Turbo moving away from TS was the rare exception.

Well:

  % cat a.ts
  console.log('Hello, world!')

  % time tsc a.ts
  tsc a.ts  2.39s user 0.10s system 232% cpu 1.066 total

esbuild is not an alternative as it doesn't check types.

What I want is "GET /foo.js" to "just" compile TS "on the fly" in dev; it's a simple "just works" kind of setup, but not possible with TS.

Or for a simple system, just "roll your own":

  for f in *.ts; tsc $f >|$f:r.js

  watch-files *.js --run tsc

  (for f in *.ts; tsc $f) | minify >production.js

What exists now is an explosion of complexity to deal with all this and I guess these systems are "mature", kind of, but for a lot of systems it's massive overkill (and even for larger systems it's not particularly great IMO). Besides, it's really a bad fix for more fundamental problems.

Personally I wouldn't call TypeScript mature until compile times are roughly within the range of literally ever other compiler that has ever seen wide-spread adoption. It doesn't need to be fast: just not a huge outlier.

Explosion of complexity and "bad fix for fundamental problems" sounds a lot like you just have an axe to grind.

Many other popular languages have multiple build systems and tools to choose from as well; it isn't a particularly novel challenge.

"You just have an axe to grind!"

Hmkay.

I just want things to compile, with errors, like literally everything else works. It's really not a huge ask. I don't want complex bespoke setups with multiple compilers and background processes and whatnot. The classic JS/TS response is "here is the happy path with all this tooling, but if you want something outside of that then there is something wrong with you".

`tsc --noEmit a.ts` (possibly flipping the position of the flag, I forget if it is sensitive).

That'll check the types without spending unnecessary time compiling with the slower tooling.

From there, esbuild or swc binaries compile the code as desired. They use the same tsconfig file that tsc does, so no need for any extra complexity. They build so fast that you'll not mind having a separate command, I promise.

You could even combine the two into a simple one-liner if you wanted.

Compared to, say, java where you have to fight over maven or Gradle or ant, plus endless config options in XML or groovy or whatever, typescript really isn't much to complain about.

Hell, trying to set up a clojure full stack project is a nightmare of conflicting opinions over tooling between lein and shadowjs or whatever.

Of the big languages, C# is about the only one with a "one true way", and of the smaller ones, they simply haven't yet developed a big enough base to grow contentious enough to have divergent solutions.

The raw output speeds aren't a very good 'practical real world example' as the OP described it.

If anything in dev ESLint (+ Copilot) is the slow ones that I sometimes noticed, but there is already Rust driven replacements maturing in the pipeline as we speak.

I looked in to this some time ago, because I couldn't believe it was this slow, and tsc just has a huge startup cost. Once it gets going it's alright (I think? Don't quote me) but to get started takes a long time. It's actually already improved because not too long ago it was more like 3 seconds (probably because of the parallelisation, which is kind of cheating IMO).

I don't know about Java as I never really used it, but complex build systems are not unique to TS of course, but what they are in TS is mandatory for any reasonable experience because it works around the fact the compiler is so damn slow. That's a huge difference you can get started without too much effort, and you can do "smart" things fairly easily as I mentioned in my earlier comment.

> they simply haven't yet developed a big enough base to grow contentious enough to have divergent solutions.

C, C++, Go, Rust, Python, Ruby, PHP don't have a "big enough base"? Ehhh

And my entire point is that TS LACKS "divergent solutions". Because it's so slow lots of solutions are simply not practical.

IMHO these are markedly different scenarios: the first is essentially just a difference of opinion, the second is a rather myopic attitude.

This applies to much more than static typing as well. Anything built, can be built well or it can be built quickly.

Although I often have to make trade-offs for immediate gain at work, there is a big difference between the quality of my work over time vs the quality of other devs who default to immediate returns. I will say in their defense, they play a role in the team. But I wouldn't want to work on a team where avoiding upfront costs was the expectation rather than the exception.

"I've worked with my fair share of vanilla JS devs who refuse to acknowledge the benefit of testing. Most of them bemoan the upfront cost of testing everything without realizing the benefits of it. I absolutely think less of them as developers."

The really issue with compile-to-Javascript languages is debugging. Have fun stepping through your incomprehensible generated code in dev tools.

(Except Dart which has really good Dev tools support; I guess they can poke the right people to make it work.)