The article links to the polyfill... and the polyfill is under es-shims ... but I didn't see a link to the proposal you linked to in the above comment, which I would suggest adding/linking towards the top.
Array.at(index) (proposal) <-- link there
I had searched via google, mozdev and caniuse and wasn't able to find the actual proposal/spec.
edit: https://github.com/es-shims/Array.prototype.at/pull/2
I usually comment with the specific proposal specification on these types of articles as it's usually missing or incomplete. Often, I'll also add the babel transform/polyfill for reference.
WARNING: GPL, do NOT use this for anything that isn't going to be open source. There are lots of virtual DOM options for testing under less restrictive licenses, and for that matter the actual browser DOM has gotten VERY fast, where many frameworks are starting to move away from virtual dom usage which has many down sides outside testing.
The article itself is less about TTFB than it is with initial connection negotiation between HTTP/(1|2|3), HTTPs and other variables.
What's totally missing is DNS negotiation, for first calls, a slow DNS provider and/or the use of too many domains for content/services and raw initial payload response, such as using a static content server with pre-compressed content and/or a cdn.
While a little dated, the content in "High Performance Web Sites" and "Even Faster Web Sites" books is still very relevant.
It's 2021... time to put down jQuery and learn how to leverage JavaScript and the DOM to deal with these things.
There's already Array.prototype.forEach standardized in 2013, and in every browser since IE7. You do *NOT* need jQuery for this. It's also there with Element.prototype.forEach.
For the DOM example...
document.querySelectorAll('#ul_items li')
.forEach(el => {
console.log(el.innerText);
});
Neither the original article, or the polyfill references any proposal to add this to the EcmaScript spec. And there's no reference to this on MozDev.
It's definitely a cool method, that said, I would suggest *NOT* doing a polyfill unless or until this is an actual EcmaScript proposal at Stage 1 at the very least. It's not really a polyfill, because it's not filling any actual spec at any stage. It's a non-standard extension.
--
Edit, would also copy/paste this on the blog itself, but they want permission to "Act on my behalf" in Github which is a non-starter and ridiculous permission to ask for.
Most of the "dependencies" should be "peerDependencies" and/or worked around directly. gh-pages in particular should be a "devDependency" .. your demo/gh-pages should really have its' own directory/package.json and be part of .npmignore so they aren't in the final distribution.
With help from https://stackoverflow.com/a/43438960
window.addEventListener('DOMContentLoaded', (event) => {
document.documentElement.addEventListener('paste', e => {
if (e.target.nodeName.toLowerCase() === 'input') {
e.preventDefault();
var text;
var clp = (e.originalEvent || e).clipboardData;
if (clp === undefined || clp === null) {
text = window.clipboardData.getData("text") || "";
if (text !== "") {
text = text.replace(/[\t\r\n\s]+/g, " ");
document.selection.createRange().pasteHTML(text);
}
} else {
text = clp.getData('text/plain') || " ";
if (text !== "") {
text = text.replace(/[\t\r\n\s]+/g, " ");
document.execCommand('insertText', false, text);
}
}
}
});
});
Note, the regex I'm calling out \t as well as \r\s and \s ... \s is any whitespace, and probably all you want/need adjust ast desired.