3 ms·

“ Those have semantics that go beyond how enumerations work in most languages and implementing them in the underlying JS is going to introduce some runtime cost

“ Those have semantics that go beyond how enumerations work in most languages and implementing them in the underlying JS is going to introduce some runtime cost.” Do you think this runtime cost will make much of a difference compared to everything else that goes on in the code? My impression that in the last few years the pure code performance is so fast that it almost doesn’t matter much anymore. Of course unless you manage to do incredibly stupid things.

robpalmer 6y ago
For our purposes, the primary problem with enums is not the runtime overhead. The runtime code for TS enums is a little verbose but it's not huge. The semantics are a little wacky as described in Axel Rauschmeyer's article: https://2ality.com/2020/01/typescript-enums.html https://2ality.com/2020/01/typescript-enums.html The primary problem is the potential conflict with future ECMAScript. Multiple TypeScript team members have talked about how this feature is now regretted. The article features Orta's famous meme-slide communicating why runtime features (specifically calling enum) should not really be in the TypeScript language. Anders talked about it three weeks ago during the Q&A session at TSConf: https://www.youtube.com/watch?v=vBJF0cJ_3G0 https://www.youtube.com/watch?v=vBJF0cJ_3G0 enum is highly unlikely to be removed from TypeScript because of the strong commitment to backwards compatibility. But that doesn't mean we should encourage proliferation. Especially when many use-cases can be served more simply by string unions. type Color = "red" | "blue" | "green";
Chris_Newton 6y ago
Do you think this runtime cost will make much of a difference compared to everything else that goes on in the code? Perhaps not. It’s hard to imagine a program that you’d write in a language like JS in the first place where the small overhead of a look-up would be significant even for a feature as commonly used as enums. However, there is a wider issue here than just whether to use one specific TS language feature or not. If you’re establishing principles that are going to affect thousands of developers working on thousands of different programs, which appears to be the case at Bloomberg from what I can see, then erring on the side of caution is a reasonable position to take. It’s difficult to objectively evaluate risk at that scale, whether from individually small but pervasive runtime performance hits or from potential future (in)compatibility with JS.

robpalmer 6y ago

For our purposes, the primary problem with enums is not the runtime overhead. The runtime code for TS enums is a little verbose but it's not huge. The semantics are a little wacky as described in Axel Rauschmeyer's article: https://2ality.com/2020/01/typescript-enums.html https://2ality.com/2020/01/typescript-enums.html The primary problem is the potential conflict with future ECMAScript. Multiple TypeScript team members have talked about how this feature is now regretted. The article features Orta's famous meme-slide communicating why runtime features (specifically calling enum) should not really be in the TypeScript language. Anders talked about it three weeks ago during the Q&A session at TSConf: https://www.youtube.com/watch?v=vBJF0cJ_3G0 https://www.youtube.com/watch?v=vBJF0cJ_3G0 enum is highly unlikely to be removed from TypeScript because of the strong commitment to backwards compatibility. But that doesn't mean we should encourage proliferation. Especially when many use-cases can be served more simply by string unions. type Color = "red" | "blue" | "green";

Chris_Newton 6y ago

Do you think this runtime cost will make much of a difference compared to everything else that goes on in the code? Perhaps not. It’s hard to imagine a program that you’d write in a language like JS in the first place where the small overhead of a look-up would be significant even for a feature as commonly used as enums. However, there is a wider issue here than just whether to use one specific TS language feature or not. If you’re establishing principles that are going to affect thousands of developers working on thousands of different programs, which appears to be the case at Bloomberg from what I can see, then erring on the side of caution is a reasonable position to take. It’s difficult to objectively evaluate risk at that scale, whether from individually small but pervasive runtime performance hits or from potential future (in)compatibility with JS.