const data = await fetch('/my/url').then(r => r.json());
Mind that in this example the then is a little nicer only by chance that the continuation is quite trivial. If you'd need something more complex than the single function call it is annoying and if you do any later change to this code, you likely have to change this as well.
I typically go to the multiple lines, but wanted to show that there is a kind-off suffix await.
I am not used to suffix await, as i like to spot the places where i jump out of the coroutine easily. But maybe that would change if I'd use languages with suffix await more :)
In the past, I believe that most or all browser implementations used array-like structures to do various things like this, and so removing the first element entailed shifting all the remaining elements, whereas popping from the end doesn’t require shifting any elements.
More recently, I believe that most or all browser implementations have shifted to linked-list-like structures, with bad patterns like this being a cited reason. (I don’t know the full story by any means, but I’m inclined to be disappointed by the switch, because for most access patterns arrays aren’t a problem at all, and use less memory, sometimes even being a smidgeon faster. But although I suspect they’d have better typical performance and certainly better memory size, they have vastly worse worst-case performance, being approximately O(n) instead of O(1) for some operations.)
Remember also when talking of NodeList like this that it’s a type for JavaScript to consume; what browsers use internally for representing their DOM is an implementation detail. A leaky one, certainly, in performance details like this and types like HTMLCollection and NodeList (especially live NodeLists), but an implementation detail nonetheless.
Some use a bad technique; e.g. “Empty” removes the first child repeatedly, which is O(n²) in many environments, rather than removing the last child repeatedly, which is O(n), or `el.innerHTML = ""` which is shorter and more efficient in general)
Some suffer because they’re supporting IE which no one should do any more (fite me); e.g. “JSON” is long because it’s using XMLHttpRequest, but the Fetch API would make it vastly shorter (`data = await (await fetch('/my/url')).json()`—as an aside, suffix await like Rust settled on is so much nicer: `data = fetch('/my/url').await.json().await`); and “Each” should use `document.querySelectorAll(selector).forEach((el, i) => …)`; and “Matches Selector” is just `el.matches('.my-class')` now.
Also some look bad because jQuery optimised an operation that isn’t terribly common or should generally not be done, such as most of the width/height things (most uses of measuring element dimensions in JS are unnecessary, bad or wrong; aim to use CSS most of the time), “Index” (needing to know that an element is the nth child element is decidedly esoteric), “Type” (if you use this, you’re almost certainly doing the wrong thing), and “Parse HTML” (picture me running away, screaming in horror; this method is practically a primed security grenade). And remember, jQuery having optimised these things means you’re paying to ship that stuff that you’re not using.
And finally some seem more complex because they’re matching some unnecessary jQuery complexity, e.g. in “Set Height” (and alike in “Set Width”), $(el).height(…) takes a string, a number, or a function that returns a string or a number—but you’d be wiser to write `el.style.height = string;` or `el.style.height = number + 'px';` rather than being unnecessarily flexible.
Most people that use jQuery use a tiny subset of its functionality. The site is about showing that most uses of jQuery could actually dispense with it at little cost, if they’re the sort that value performance and such and want to ship less unnecessary code.