Hacker News Reader

Comment by maga | Hacker News Reader

Indeed. I remember that, I have been using node since the very early days, and switched to it for precisely that reason--that I could use the same language through my web application. Nevertheless, when we did get those modern web API, Node was slow to change or adapt them, although, it's doing its best now.

In case of Deno, I hope they just stick to following the standards and changing with them. They might not, I cannot vouch for them. On the other hand, I was also skeptical about TypeScript following ECMAScript. I though at some point they'll get too much into conflict and MS will refuse to follow, but so far I've been proven wrong. And from the looks of it, TS even deprecates stuff that is likely to conflict with upcoming ES versions.

View on HN

Overall this is true. And beyond that the TypeScript team is heavily involved in TC39, and quite a lot of TC39 proposals are specifically designed to be enhanced by TS. That said...

There are a few longstanding incompatibilities/footguns. And they’re likely to remain due to widespread use, even though most are controversial. Off the top of my head:

- access control annotations (`private` which is compile time only vs `#`). I’m on the fence on this one. I prefer the TS syntax, but obviously not the behavior.

- Enums. Everyone but me hates them. I use them extensively for personal/internal use but try not to force them on others.

- Decorators. This is the big bad ticking time bomb. Last I checked the TC39 proposal has diverged significantly from the TS implementation. And sure it’s marked “experimental” but it’s used a lot and almost guaranteed to be a future conflict. Putting that toothpaste back in the tube is gonna make a lot of people feel a lot of pain.

> enums [...] everybody but me hates them

Hmm, what did I miss, why do people hate them exactly?

> And sure it’s marked “experimental” but it’s used a lot and almost guaranteed to be a future conflict. Putting that toothpaste back in the tube is gonna make a lot of people feel a lot of pain.

Maybe I'm a bit masochist, but I can't say I feel a lot of compassion for people using experimental features in missing-critical production code.

>Maybe I'm a bit masochist, but I can't say I feel a lot of compassion for people using experimental features in missing-critical production code.

To be fair, decorators are an experimental feature in name only at this point. A lot of libraries force you to use it, including Microsoft's own tsyringe and the beyond popular TypeORM. NestJS is a reasonably popular framework that will codegen services with decorators in them. As the OP of this thread said, the toothpaste is out of the tube now.

Fair point.

the entire angular2+ ecosystem as well

> Hmm, what did I miss, why do people hate them exactly?

They operate in a weird gray-zone between being just compile-time types vs. an actual readonly object in the runtime. I don't think I've seen a use case for them yet that wouldn't have been better accomplished with a union type of string literals and using const string literals in the code.

Say all you need is a fixed set of strings that get reused everywhere. What is better accomplished by defining a union type AND consts literals rather vs creating a single string-based enum and using that everywhere? I feel like I'm misunderstanding...

You don't even need the const literals.

    type Color = "red" | "blue" | "green";

> Hmm, what did I miss, why do people hate them exactly?

In my experience, enums are far less type safe and convenient (usage in switch for instance, combined with a linter) than union types.

The thing is enum and union type have different use cases. Union type cannot be used to check against incoming data. It's a lightweight type level feature. There is no way for compiler to identify the unknown data object from the network. Enum is essentially an object in memory which can be used in this case.

Reply on news.ycombinator.com