Comment by arp242 | Hacker News Reader

Comment by arp242 | Hacker News Reader

Parent Full thread

> The tooling is also mature these days

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

More than a second to compile a "hello, world" (or 2.4s in CPU time) is orders of magnitudes slower than any other compiler or interpreter that I know of. It's a ridiculous start-up time.

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

Doesn't need to be shell, can be a simple JS script or whatever. You really shouldn't need millions of lines to call a compiler even in simple scenarios.

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 (and with that I don't mean "parallelize to 32 cores so my threadriper over 9000 can compile things in 0.1s). It doesn't need to be fast: just not a huge outlier.

You might want to look into ReScript (https://rescript-lang.org/). It has strong static typing with type inference, and it is very fast.

Yep, Rescript is nice, but also comparatively obscure. It's okay for personal projects; in company setting: maybe? It's certainly more complex.

You can still use tsc for type checking via editor language server and quality gates (with the noEmit flag) and get stupid fast compilation with swc or esbuild.

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.

Points out real-world practical problems

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

I guess the "axe" that I'm "grinding" is that I'm having a lot of difficulty using TS in a way that fits with my sensibilities and preferences. e.g. I don't like errors in my editor and prefer to explicitly call the compiler (for any environment). I suppose I could get all of this to work how I want it to with wrapper scripts or whatnot: but it's complex, time-consuming, and isn't needed for anything else.

Based on previous conversations about this at least one person will say something along the lines of "zomg what kind of crusty old backend unix beard doesn't use VSCode and want errors in their editor, you just need to get with the times as you're stuck in the past!!!1" but again: it works for literally everything else (including other compile-to-JS tools), and is not that "obscure" of a work-flow, IMHO, and we're back to a few paragraphs ago: "move outside the happy path and you're screwed".

I mentioned using tsc with the noEmit flag for quality gating, which is the same workflow you would use.

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

Yep almost every (serious) TS dev only uses --noEmit for development by default because they use VSCode/IDEs as their typechecking engines and then have something like esbuild for delivering the content to the browser locally. I've never had performance issues with either step and I use both daily.

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.

The performance of "tsc --noEmit a.ts" is identical, and it makes no difference vs. just typing "tsc a.ts", and it doesn't really solve "compile on demand" (with type checks) in any case.

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.

Reply on news.ycombinator.com