3 ms·

Interesting. So even though the const form isn’t affected by the same runtime considerations, you do still prohibit it because of the potential conflict with a

Interesting. So even though the const form isn’t affected by the same runtime considerations, you do still prohibit it because of the potential conflict with a future use of the enum keyword by JS? I can understand the reasoning there, particularly at the scale you’re operating at. I wonder how likely it is that ECMAScript would introduce its own incompatible form of enum now that TS has become so popular. With static type checking as in TS, enums are very useful, but in the more dynamic environment of JS, the benefit is much smaller. So even if there’s nothing wrong with ECMAScript using its reserved keyword in principle, it feels like a bad idea to introduce a potential source of confusion and maybe subtle bugs when so many developers now use both languages.

robpalmer 6y ago
I would never say never for any potential ECMAScript feature. Each time people say "JS will never do x", a few years later it does. Brendan Eich has a slide on this. https://www.slideshare.net/BrendanEich/jslol-9539395/110-Always_bet_on_JS_First https://www.slideshare.net/BrendanEich/jslol-9539395/110-Alw... In terms of whether JS will introduce things that conflict with TS, it's hard to say. TypeScript team themselves are active participants in TC39, championing recent features such as Optional Chaining and Nullish Coalescing. So if there were any conflicts, or even opportunities for confusion, it would all be managed way ahead of time. Several TC39 delegates are users of TypeScript so there is no risk of accidents here (in my opinion).
- Chris_Newton 6y ago
  I would never say never for any potential ECMAScript feature. Sure, and again, at the scale in your organisation, taking an absolute position on this makes a lot of sense and I can respect the principled stance. On the other hand, the trade-off in this case is giving up a tool that is widely useful immediately in exchange for a potential/hypothetical benefit later. For other development teams, perhaps those alternatives would be weighted differently. And then that in turn might affect how any future changes were viewed by the relevant language committees, who as you say would surely be aware of the implications. Anyway, thanks for sharing your insights, both here and in the original article. It’s somehow reassuring to me that I’m not the only person in the world who wants their front-end code to continue working for more than five minutes, when it seems like a lot of the front-end community would consider that a pretty good working lifetime for code these days!
  - robpalmer 6y ago
    That's a very real trade-off and something we have to carefully make a judgement call on every time. In this specific case the decision is made a lot easier due to the fact that string unions are often a simpler alternative. type Color = "red" | "green" | "blue"; Glad to hear you appreciated the article!

robpalmer 6y ago

I would never say never for any potential ECMAScript feature. Each time people say "JS will never do x", a few years later it does. Brendan Eich has a slide on this. https://www.slideshare.net/BrendanEich/jslol-9539395/110-Always_bet_on_JS_First https://www.slideshare.net/BrendanEich/jslol-9539395/110-Alw... In terms of whether JS will introduce things that conflict with TS, it's hard to say. TypeScript team themselves are active participants in TC39, championing recent features such as Optional Chaining and Nullish Coalescing. So if there were any conflicts, or even opportunities for confusion, it would all be managed way ahead of time. Several TC39 delegates are users of TypeScript so there is no risk of accidents here (in my opinion).

Chris_Newton 6y ago
I would never say never for any potential ECMAScript feature. Sure, and again, at the scale in your organisation, taking an absolute position on this makes a lot of sense and I can respect the principled stance. On the other hand, the trade-off in this case is giving up a tool that is widely useful immediately in exchange for a potential/hypothetical benefit later. For other development teams, perhaps those alternatives would be weighted differently. And then that in turn might affect how any future changes were viewed by the relevant language committees, who as you say would surely be aware of the implications. Anyway, thanks for sharing your insights, both here and in the original article. It’s somehow reassuring to me that I’m not the only person in the world who wants their front-end code to continue working for more than five minutes, when it seems like a lot of the front-end community would consider that a pretty good working lifetime for code these days!
- robpalmer 6y ago
  That's a very real trade-off and something we have to carefully make a judgement call on every time. In this specific case the decision is made a lot easier due to the fact that string unions are often a simpler alternative. type Color = "red" | "green" | "blue"; Glad to hear you appreciated the article!