Comment by Dylan16807 | Hacker News Reader

Comment by Dylan16807 | Hacker News Reader

Parent Full thread

You can disable those fallback implementations if you don't want to use them. Just use the javascript version you have available as the basis for your typescript. The option to look into the future shouldn't be treated as a negative.

And I still don't see how they make "the whole damn runtime" slow. You don't pay the cost for code that isn't using it.

Also I'm pretty sure the class implementation doesn't slow things down. It's a very simple transformation.

> You have a new language with a runtime overhead, that now requires you modify the "core" language to bring in new features, which results in the underlying execution engines (browsers/cpus) becoming more complicated, power hungry, etc....

I think you have this backwards. Typescript doesn't implement new Javascript features until their addition to Javascript itself is imminent.

The only feature Typescript wants to push onto Javascript is a syntax for type annotations, because then you can remove the compilation step entirely. At which point there couldn't even be a runtime overhead.

> non-JS features

To first approximation, there aren't any. The main one is the old enum syntax, which is why I brought them up.

> Typescript doesn't implement new Javascript features until their addition to Javascript itself is imminent.

I guess we want different things from Type systems.

I want rock solid guarantees that code is correct, so that the only thing left to test as much as possible is the business logic. I don't care about the latest programming fads, and I want stable, performant code.

You seem to just want some boilerplate guarantees and backwards compatibility.

If I were writing/creating TypeScript, I would be not implementing new features before JS upgrades, but long after (possibly as support libraries). I understand the goal of "easing" the transition, but IMO those sorts of "upgrades" should be late, not early, in a tool whose primary goal is static type checking, not JS features.

The things you seem to be worried about are configurable in the tsconfig. You can stay as polyfill free as you would like by instructing the Typescript compiler to error out instead of making the glue for you. Aside from the inescapable quirks of runtime JavaScript, Typescript felt pretty intuitive to me when transitioning to a new job from C# previously. Typescript with ESLint is about as solid as you’re going to get with JavaScript. I know that ideally there’d be something better, but in the real world right now this is the best it gets. At some point reality and business constraints are going to slam into ideations and things are going to get a bit dirty.

Aside from that, no matter what you pick, standard Typescript configs are absolutely compiling to JavaScript, not any other step in the interpreting process. It doesn’t matter if it’s taking your async/await and polyfilling it to run on an older browser engine… it’s still producing 100% JavaScript.

It goes Typescript -> JavaScript during the build, and the JS is what gets distributed to clients.

The JavaScript produced by TS is sent to the browser which performs the same JavaScript -> abstract syntax tree -> byte code -> execution, as usual

"standard Typescript configs are absolutely compiling to JavaScript"

You are missing the point. I want zero cost abstractions (for some level of abstraction - I accept e.g. there is a CPU and a browser). I don't care what it is compiling to.

Typescript is not a zero cost abstraction. (Zero cost meaning, here, that any overhead is incurred compile time only).

"The things you seem to be worried about are configurable in the tsconfig"

That's terrible. I want the Z.C.A. to be by-default, not "configure the heck out of the language to make it so".

> That's terrible. I want the Z.C.A. to be by-default, not "configure the heck out of the language to make it so".

Don't you just set target? Is there even a default for target?

Reply on news.ycombinator.com