Did you know that “old” Chrome Headless (2017–2023) was a separate, alternate browser implementation that just happened to be shipped as part of the same Chrome binary? It doesn’t share any of the Chrome browser code in //chrome.
--headless=new in Chrome 112 on the other hand works the way you'd expect.
The article includes a working polyfill that includes old IE support, so I’m not sure what you’re complaining about.
Also, saying “jsvu is the justification for the polyfill” doesn’t make much sense. jsvu is just how I happen to test in various standalone JavaScript engines. There are other, non-jsvu ways of getting such binaries, e.g. compiling one yourself, and there are JS engine binaries that jsvu doesn’t provide (Rhino, Ringo, Nashorn). jsvu usage does not correspond to anything you seem to be talking about, and comparing its download count with IE10 usage is one of the more extreme apples-to-oranges comparison I’ve seen. ️
We do indeed measure improvements against more than one website. We wouldn’t want to improve website X while regressing the rest of the internet. See https://v8.dev/blog/real-world-performance (from 2016):
> We now monitor changes against a test suite of approximately 25
> websites in order to guide V8 optimization. In addition to the
> aforementioned websites and others from the Alexa Top 100, we selected
> sites which were implemented using common frameworks (React, Polymer,
> Angular, Ember, and more), sites from a variety of different geographic
> locales, and sites or libraries whose development teams have
> collaborated with us, such as Wikipedia, Reddit, Twitter, and webpack.
> We believe these 25 sites are representative of the web at large and
> that performance improvements to these sites will be directly reflected
> in similar speedups for sites being written today by JavaScript
> developers.
I mean, they have been solved. With the exception of String#matchAll (which is currently a Stage 3 proposal), all these features are part of ES2018 and shipping in Chrome. Other browsers implement some of them already and are working on shipping more.
I make sure to keep the article up-to-date. It correctly states the status for each of the features. They’re all part of ES2018 with the exception of String#matchAll which is currently at Stage 3.
Hey, I’m the author of the article. Despite its age, it’s still accurate and up-to-date.
> these features aren't entirely new
Depends on what you mean by that. These features are still not universally supported by all modern browsers, for example, so I can imagine they’re still new to a lot of developers.
Chrome supports all these features (except for String#matchAll, which is currently at Stage 3). Other browsers don’t yet support the full set, but they’re all working on getting there.
> Which means you can’t practically use the new form without feature detection.
That does not follow.
`{ capture: true }` works in both, since it’s an object, and thus truthy.
There’s no need for feature detection in the case you describe.
Sadly, that’s the whole premise of this article.
It’s only a problem if you want `capture: false` combined with other options — since you’d need to pass in an object, that would be truthy in the old implementations expecting a boolean instead. But then again, the additional options wouldn’t be supported in those old implementations either.
I’m confused — what’s the actual use case that’s breaking here?
Wondering what a given legacy HTML color value (as seen in `bgcolor`, `text`, `link`, `vlink`, and `alink` attribute values) looks like? This tool (which I made for a presentation years ago) shows you: https://mothereff.in/bgcolor#mathiasbynens
--headless=new in Chrome 112 on the other hand works the way you'd expect.