the typescript project continues to set the bar extremely high in terms of changelog and clear communication. love you so much, drosenwasser and co!!
> Decorators are an upcoming ECMAScript feature that allow us to customize classes and their members in a reusable way.
huh. i thought this was a bit early to do this but i checked (https://github.com/tc39/proposal-decorators) and looks like they've moved to stage 3. curious how this is going to change library/api design in the long term.
> To enable experimental support for decorators, you must enable the experimentalDecorators compiler option either on the command line or in your tsconfig.json
https://www.typescriptlang.org/docs/handbook/decorators.html
> ..the current decorators proposal, which is a work in progress
https://github.com/tc39/proposal-decorators
Oh, but I see that the proposal is now at Stage 3, which means the specs and syntax are stable ("completely described") and ready for browsers to implement.
On further digging, it seems decorators will be a standard feature included in TypeScript 5.0 planned for release on March 14th.
TypeScript 5.0 Iteration Plan - https://github.com/microsoft/TypeScript/issues/51362
- [0] https://github.com/tc39/proposal-decorators - [1] https://tc39.es/process-document/
Worth noting that compiling new syntax to old is also not new — anybody remember CoffeeScript? I’d say if there’s a new part, it’s the prevalence of implementations of standards and of polyfills for them in both TypeScript and core-js via Babel such that you can confidently write code in new syntax knowing you wouldn’t have to rewrite it later. Nobody remembers CoffeeScript or sees it today because it was generally all converted to JS long ago — it wasn’t a syntax we could build on top of. Arguably, if it was, you’d still see projects using it today, but it’s hard to modify syntax in an unambiguous way (for parsers I mean) while also simplifying the syntax as CoffeeScript did. Implementing standards are safer, though until implemented and shipped in multiple browsers, anything could still change. There are a few places where TypeScript has to be changed or will be changed due to changes in the JS standard...
To illustrate how messed up standards can still be though, I’d present “decorators” —- seemingly a solved problem in Babel or TS but apparently very hard to implement as a standard: https://github.com/tc39/proposal-decorators I’m beginning to think JSX will ship in browsers before decorators do ;-)
That said if there’s something the web community learned from ECMAScript 4 and XHTML2 it’s that usage, what people want to use and working code, always wins out over arbitrary standards. If two options are good enough, the one folks implement and use will win when it comes to standards. To this end, I’m pretty sure future standards required 2 independent implementations to actually graduate and become standards instead of remaining proposals. Not sure how that will change if Chrome ever becomes a larger monoculture than it already is... maybe web developers will have to vote with their codebases as standards bodies write and distribute polyfills to encourage their spec to “win”.
1. Decorators are currently TC39 Stage 2. [1]
2. Because of its unusual status, TypeScript lists decorators as "experimental, subject to change". Once the EcmaScript proposal advances, TS will ensure it is compatible with the ES standard and then remove the experimental sticker.
3. If it doesn't affect runtime, then you shouldn't expect JS to have the feature. TS private members are no different than public members at runtime; there is no need for JS to have that feature. (Note that TypeScript deliberately chooses not to name-mangle members.)
4. Sure call it a "feature and syntactic superset", but that doesn't make TS any less beholden to JS. Dedicated adherence to that property commits them to support every feature and syntax that JS adds; future-proofing means they can't really add anything that JS doesn't have or is going to have.
5. Note that TS abandoned having a standard long ago. The behavior and validity of TypeScript program is determined by "whatever tsc does" and the ES standard.
6. Again, if you need convincing that TS effectively only implements JS features, refer the linked pipeline issue, locked as "waiting for TC39."
You could even have a method decorator (https://github.com/tc39/proposal-decorators) that emulates Java's "synchronized" keyword.
I am really hoping for private properties and compiler support of class properties (it supports the syntax, I think, but doesn't compile them down from what I understand).
I also hope they update their decorator support to be in line with https://github.com/tc39/proposal-decorators
I know its stage 2 (and it was stage 3, I think) but I think the reasoning behind the major(ish) changes are solid ones.
Thats pretty much it. Now tc39 just needs to acceept Reflect.metadata :)
There is no decorator feature in the ES7 (ES2016) spec.
However, there is a proposal for decorators that it is not finalized yet.
Almost all Angular2 projects, that claim to be using ES6, are in fact using ES6 + Babel Legacy Decorator plugin https://github.com/loganfsmyth/babel-plugin-transform-decora... . The legacy plugin adds syntactic sugar on top of ES6. This is no better than TypeScript in the first place.