proposal-relative-indexing-method VS reify

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

The benefits are clear when working with huge libraries like @material-ui/icons, you can read more details in the PRs. 1, 2

Nested imports