3 ms·

I like TypeScript's (stage-3) approach to feature adoption.

• svieira 7y ago
  Gating on stage-3 really helps. (I have done the same on projects I work on and it helps) There are times when you need to consider the complexity of the specification and the amount of contention around it (decorators / SIMD for example). IMO, anything below that is effectively a custom macro anyway (for which you may want to consider sweet.js or babel.macro to make it clear that this may change and help you find places you use the feature). Real-world feedback may change anything from syntax to behavior (`flatMap -> flat`, `Object.observe -> Proxy`, `EventEmitter -> Observable -> Emitter?`, and the it-feels-like-dozens-of-options pipeline syntax)
• snek 7y ago
  It wasn't TS's idea, stage 3 exists purely for getting feedback from implementations about implementing and using the feature.
  • WorldMaker 7y ago
    It was TS's 2.0+ idea to stick to Stage 3 like glue. Especially prior to 1.0, but even during 1.x, TS implemented proposals in stages earlier to 3 (or even not yet staged). One of the regrets you sometimes hear from TS devs is that they added decorators way too early (it's still not Stage 3 and increasingly likely if it ever hits Stage 3 it will look very different, and it may never hit Stage 3 because there is a bunch of opposition), even though that is behind an "experimental" flag, there's a huge amount of "Production" code written with decorators in Typescript. (Largely thanks to the Angular ecosystem that became hugely dependent on decorators.)