Deno has the advantage that they are starting from a clean slate without the burden of legacy APIs, but how long will that hold for?
So I strongly doubt the next 10 years will be anywhere near as tumultuous as the past 10. It's very possible that right now is just a much better time to be establishing a JS runtime.
But it had limitations, chiefly that imports/exports were not static. Things got imported at runtime when they got reached, etc. This meant that things like browserify were fudging the semantics in some ways, and it also made it impossible to properly do tree-shaking. The stricter semantics of ES modules are better IMO, despite the pain of transitioning.
Either way, if Deno is one day replaced by something else, say 'Done' to keep the naming convention, that won't refute the use everyone will have gotten out of Deno in the mean time, in the same way that Deno doesn't refute the use everyone has already gotten out of Node.
Node never implemented any of the essential browser APIs like XMLHttpRequest or later fetch, localStorage, etc.
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.
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.
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.
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.
In my experience, enums are far less type safe and convenient (usage in switch for instance, combined with a linter) than union types.
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.
type Color = "red" | "blue" | "green";I don't know the history of Node... but why would there need to be a diversion?