You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Indeed, JS engines have no performance benefit from using numbers instead of strings. However, when the enum is ordered, numbers offer an additional benefit: comparison.
Case in point: HTMLMediaElement.readyState. A developer can do:
Therefore, I'm not sure it's the latter we should be recommending. Using ints here seems like a reasonable choice by the API designers.
However, if we change our guidance to be "you can use numbers when the enum is conceptually ordered", doesn't that make the Web Platform inconsistent, when some enums are strings and others are numbers (of course it already is inconsistent anyway, but the point of the design principles is to reduce inconsistency over time, not encourage it).
The text was updated successfully, but these errors were encountered:
We currently have the blanket guidance that all enums should be strings, not numbers.
Indeed, JS engines have no performance benefit from using numbers instead of strings. However, when the enum is ordered, numbers offer an additional benefit: comparison.
Case in point:
HTMLMediaElement.readyState
. A developer can do:With strings, this would look like:
which is far more awkward.
Therefore, I'm not sure it's the latter we should be recommending. Using ints here seems like a reasonable choice by the API designers.
However, if we change our guidance to be "you can use numbers when the enum is conceptually ordered", doesn't that make the Web Platform inconsistent, when some enums are strings and others are numbers (of course it already is inconsistent anyway, but the point of the design principles is to reduce inconsistency over time, not encourage it).
The text was updated successfully, but these errors were encountered: