Hi All,
Just wanted to humbly ask for reconsideration of GitHub - tc39/proposal-enum: Proposal for ECMAScript enums. I've been using NodeJS v24 recently and I am loving the typescript stripping. But enums are a pain. You gave us syntactic sugar for class and async/await ... how about enum please - it will reduce much heartache.
Thanks
Neither class and async/await are purely syntactic sugar, fwiw.
They have almost equivalents with functions+WeakMaps & Promises though. Maybe you need to smooth some edges but I don't think there are inherent capabilities gained?
For class, extending builtins installs internal slots, a previously unavailable capability, and private fields is also very much a new capability (altho true, it's mostly sugar for a closed-over WeakMap, which wasn't available prior to class being available); for await, the amount of runtime code you need to emulate generators in order to support await inside a loop (regenerator-runtime) is sufficiently prohibitive that i don't think "sugar" really holds.
Either way, enum isn't "rejected" or anything, so it doesn't require "reconsideration" - just a champion with the time to do the work to drive it forward.
it will reduce much heartache.
Can you give an example?
From my experience, I've learnt to reject enums a while ago and embrace type unions, which give you the same type safety, but with less verbosity, and they vanish in the final bundle.
Enums have been born as a mnemonic and semantic way to describe special values, that assume special meaning in some contexts but are often represented with integers due to memory or performance constraints. But that's hardly a problem in 2025. What's your use case for enums today?
The proposal you've linked doesn't sound very charming IMO: you can do most of that stuff with classic object literals. It shows its most interesting parts in the "future" additions. But they hardly resemble "classic" enums at that point.
well i think you hit the nail on the head there:
they vanish in the final bundle
enum in ecmascript advantages, if adopted, could be:
I've learnt to reject enums a while ago and embrace type unions
Sure, out of necessity probably. But does it need to be that way?
Enums have been born as a mnemonic and semantic way to describe special values, that assume special meaning in some contexts but are often represented with integers due to memory or performance constraints
Already mentioned above, one good use case for enums with integer values is bitmasking. mapping with other systems and integers is another one.
but with less verbosity
I struggle to see how enum could be considered verbose. you might save a character or 2 with type union.
it just occurs to me that, considering the utility of enum, instead of asking "why", we should be asking "why not".
Yes, and that would be handy while debugging. I think it's the only reason: for the rest, it's all up to the JS engine, which doesn't care about that (on the contrary, it surely does less work if it saves a value lookup).
Not with Ron Buckton's proposal. Lookup by key is the same as POJOs, while IDEs will autocomplete just fine with type unions.
It can be done with type unions too (e.g. in VS Code use Rename symbol).
Yes. But then again, why are you using bitwise masking now?
Of course, there could be niche applications for that. It's just that IMO they don't seem to be a necessity that big among JS developers, given that objects can do the same just fine.
Again, not a very strong argument, given that JS developers have drifted away from the usual Java patterns that were so common during the first years.
Because first you have to type the enum name, then the key. Consider the following:
enum FilterType {
Substring = 0,
Range = 1,
Multiple = 2
}
interface Filter {
value: string;
type: FilterType;
}
const filter: Filter = {
value: '',
type: FilterType.Substring
};
vs
type FilterType = 'substring' | 'range' | 'multiple';
interface Filter {
value: string;
type: FilterType;
}
const filter: Filter = {
value: '',
type: 'substring'
};
You just have to type the value (with the help of the IDE, again). And it's not just 2 characters. Also the final bundle would weigh less.
Because you don't add to something to JavaScript's API surface on a whim. For everything that's being added, you create possible security risks, performance penalties and confusing patterns for something with scarce developer sentiment.
Thanks for replying. You mentioned
don't add to something to JavaScript's API surface on a whim.
I don't feel that it is a whim. The proposal is quite serious and my contention considers "the utility of enum" and the pain it will solve (the initial point of my post). However I am willing to recognize the subjectivity regarding the utility of it. Although I would also point out there is also subjectivity when you mention "scarce developer sentiment".
Earlier in your reply you demonstrate the admittedly terse example of the union type:
type FilterType = 'substring' | 'range' | 'multiple';
For reasons I am not privy to the proposal has removed "AutoInitializers" because of concerns from some TC39 delegates. That is strange to me and I would hope that, as the proposal might move through the stages, this would be reconsidered. But, taken as it is, it appears to be difference of possibly a few characters over a longer list. With your example it appears they line up. If we can reconsider the exclusion of "AutoInitializers" then you might have to admit that it is even less verbose than your example:
enum FilterType { Substring=0, Range=1, Multiple=2 }
Responding to another of my statements you mentioned:
Again, not a very strong argument, given that JS developers have drifted away from the usual Java patterns that were so common during the first years.
I don't use Java but, correct me if I am wrong, you seem to be referring to OO (by mentioning Java). One of the things I love about JS is how it straddles paradigms. At our disposal we have functional-style programming, reactivity, and, I would say, quite elegant encapsulation in OO form. It allows me to apply the best patterns for the task at hand in, what I think is, a very elegant and legible manner. I would point to the explosive popularity of typescript to counter and suggest that there is a clear swing back to OO and typing.
You also asked:
why are you using bitwise masking now?
That comes up on occasion when i have a data structure that is conducive to bitwise flags and i can get some nice savings when transferring, storing and comparing that data in a very small footprint (an integer). It's just a tool in the toolbox that I would like to keep. Admittedly, it doesn't come out of the toolbox that often but I like my tools and can become a little defensive if I perceive someone wants to take them away :)
Yes, I've scattered "IMO"s in my answers for that reason. It's about my experience and perception.
I haven't a clear idea why, one should dig into the prior discussion on the matter - and honestly I'm not willin to do that 
As long as there are just "concerns" and not "blockers" so far, the feature could be reconsidered indeed. That would surely help in terms of DX.
Not just OO, but many patterns - like enums - that are still very common in Java. Many JS and (especially) web APIs implement enums, mainly as static properties of classes (e.g. Number.MAX_SAFE_INTEGER, Event.AT_TARGET or Node.COMMENT_NODE) or global objects (e.g. Math.LN10). They're all numeric enums and in some cases (like Node.DOCUMENT_POSITION_*) actually bitmasks.
But basically all new APIs don't define new enums anymore: they just use a value, either in the form of a string or an option objects, like in the many Intl.* constructor or the new Temporal API. They reflect the general sentiment of developers, who don't understand why el.nodeType should be 1 instead of "element".
I beg to differ. That could have been true 10 years ago, when TypeScript first implemented interfaces and enums to make developers used to strong typings feel comfortable when developing for the web.
But nowadays TypeScript has shown its strong functional programming capabilities and many other patterns have opened for JS developers. It should also be noted that Node's ingenuous support to TypeScript (it basically strips all the types, replacing them with spaces to not mess with source maps) has led the TS team to add the new --erasableSyntaxOnly flag which explicitly prevents the usage of enum (among other things).
(Node has also the flag --experimental-transform-types which would allow enums, but disallows source maps.)
I would also point out how TypeScript itself is now a solid constraint when developing a new syntax or API for JavaScript. You simply cannot use TypeScript's syntax, unless you make it 100% compatible, both constraining JavaScript and TypeScript in all of its behaviors. It has already happened for private properties, for example. It could have happened to decorators, if it wasn't that, technically, TypeScript's decorators are still "experimental".
So, they'll probably have to conceive another syntax, with all the confusion that might arise from developers (already happening for decorators).
That's alright - but I still fail to see why an object wouldn't be enough for you. Given that, from time to time, I still do (and, admittedly, have fun) with bitwise operations, I normally use constants or, at most, something like this:
const Arrow = { UP: 1, RIGHT: 2, DOWN: 4, LEFT: 8 } as const;
type Arrow = typeof Arrow[keyof typeof Arrow];
const key: Arrow = Arrow.RIGHT;
This is the pain I am referring to (unpleasant work-arounds). Were there not this to deal with then I wouldn't find enough reason to try to help resurrect enum in ecmascript and just accept an object in place to perform double-duty. And object doesn't really behave like a real enum without freezing it. A type union would resolve that but it doesn't distinguish key and value.
Honestly, I'd just like to be able to use enums where they make sense. I'm ok with forgetting about namespaces in favor of modules. But enums seem like a relatively small amount of syntactic sugar that I don't think changes the character of ecmascript and, I'd expect adds a negligible performance hit. But I get your point, it's not an absolutely needed feature in ecmascript. However it's inclusion would certainly reduce friction with typescript. Would it hurt ecmascript were it included in the language? Do you seen no value at all in enum as a syntax construct? Wouldn't reducing this friction be a relatively easy win?
I looked at the proposal. This definitely looks like sugar for object definitions, providing essentially nothing to the table except new syntax to remember, implement, and test for. Also consider that it will not be usable for likely many years as we wait for all browsers to implement and all users to update. I am not a fan of this proposal, and would probably be even less of a fan if it was my job to bring it to implementation.