-
> But they admitted namespaces, enums
And decorators. But this was very early on and they won’t ever do it again unless there’s a drastic change on principle and probably a reorg of global proportion. They categorically reject anything with runtime implications now, and to the point of decorators are actively working to align them with the standard as it’s approaching stability.
> and interfaces into the language (the latter becoming more and more confusing as type aliases got more expressive) […] Is "as", "is", or "satisfies" expression-level?
No. All of this is completely separate from the runtime and on a standards course to be treated effectively as comments.
> But the enums!
I’m one of the minority who actually likes TS enums, but I strongly suspect they’ll be deprecated, alongside namespaces, as soon as there’s general consensus around types as comments. The TypeScript team considers these mistakes and would very much like to be able to drop them. I’d welcome that too even though I quite like enums.
The fact is TS has considerable backwards compatibility expectations, and aligning their mistakes with their goals is great on principle but something which would require thousands upon thousands of hours of labor for people to accommodate.
You can snipe all you want, but if you think it’s that easy to resolve maybe I can direct you to https://github.com/microsoft/TypeScript/pulls
I’m not affiliated with the team in any way but I’m almost totally certain they’d welcome a contribution that gets them closer to their stated principles where historical designs are entrenched, without breaking workflows for thousands of people and interrupting releases for millions.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
Also see https://rescript-lang.org/ if you're considering learning Typescript
Looking forward to more great ideas in the future of ways to 'fix' Javascript.
-
Pattern matching is actually being discussed in tc39 for JS as a whole (where TS reps are some of the champions, ofc): https://github.com/tc39/proposal-pattern-matching
The specifics of the proposal will likely shift a bit since it's still stage 1 (2?).
-
-
When you can write a busy beaver machine in the type system, LOC ceases to be a good indicator or how long something should take to typecheck, imo. If you're frustrated with your build, you should use the trace tools on the TS wiki[1] to track down what types are slow to check, so you can attribute the slowness to the appropriate library authors/yourself and decide for yourself if the speed/correctness tradeoff they've made is right for you.
[1]https://github.com/microsoft/TypeScript-wiki/blob/main/Perfo...
-
-
Related posts
-
An approach to optimizing TypeScript type checking performance
-
Node.js adds experimental support for TypeScript
-
Optimising package size for Typescript AWS Lambda functions using serverless-esbuild
-
Building NPM packages for CommonJS with ESM dependencies
-
Mako – fast, production-grade web bundler based on Rust