mathias

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.

Author of the referenced article here.

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. ️

Thanks :) Glad to see people appreciate simplicity (and the performance that comes with it).

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.

The article links to the explanation by the proposal champions: https://github.com/tc39/proposal-class-fields/blob/master/PR...

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.

You can view the implementation status of the various features here: https://kangax.github.io/compat-table/es2016plus/#test-RegEx...

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.

That’s not very JavaScript-y. Where else in ECMAScript are constants used like this?

That would be a Chromium feature. V8 only implements ECMAScript and WebAssembly.

The article is two years old but still up-to-date. The links to the relevant browser bugs are in the document, and the Edge bug is still unresolved. https://wpdev.uservoice.com/forums/257854-microsoft-edge-dev...

> In older browsers, useCapture is NOT an optional parameter

Which browsers are those?

> 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?

That’s not equivalent though — in the article’s example, imagine `element` is `undefined`, for example. `then()` wouldn’t be called in that case.

Correct. By Stage 3, the proposal is supposed to be stable enough to start shipping it in stable browsers.

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

Present tense: https://domenic.github.io/streams-demo/

Replace `test` with `example.com` et voila.

+1. Still, code screenshots in Notepad?!

Nowhere in the blog post does Wright say “this is the proof I’m Satoshi”. The entire write-up reads like he’s just giving an example. Why does everyone think it’s some kind of proof?