proposal-relative-indexing-method VS proposal-object-freeze-seal-syntax

If you want to learn more, check out the MDN reference for it. You can also read the original proposal for it.

Just like every other array method, it’s type coerced. It’s a problem with all built ins, best not fracture this more in JS without a very good reason. https://github.com/tc39/proposal-relative-indexing-method/issues/40

.at()

.at() .at() method on all the built-in indexables.

For a proposal to be finalized, it needs "Two compatible implementations which pass the acceptance tests" (source). This can mean browsers but also includes transpilers like babel. Chrome - which also includes other browsers now like Edge and Opera - will often release stage 3 features publicly before finalized, and Firefox isn't usually far behind, or sometimes even first, as was the case with the currently stage 3 at() method for arrays. Safari is probably the one you have to worry about the most. They tend to be further behind, I think mostly due to their release cadence being longer. Safari, for example, doesn't yet support private methods whereas the other browsers have supported them for some time now. While private methods are stage 4, they are expected to be part of ES2022 which hasn't been published yet - the current being ES2021.

Soon we’ll get this nicer version (proposal):

Proposal hosted on GitHub explains the reasoning behind it https://github.com/tc39/proposal-relative-indexing-method

https://github.com/tc39/proposal-relative-indexing-method#rationale

Object freeze and seal syntax: {# ... #} or {| ... |}

There has been a proposal for frozen/sealed syntax for object literals which would make this a lot more concise in that context, but this is the same syntax being proposed for the record/tuple proposal, so I doubt that's going anywhere anytime soon.