natorion

Playwright is shipping patched browsers. They take the open source version of the browser and patch in e.g. CDP support or other things that make automation "better. Playwright does not work with a "normal" Safari for example.

You would be surprised how much we talked about that . New/old are just relevant for the transition period.

It's real Chromium, not emulating a Chromium browser. "Old" Headless was merely pretending to be a Chromium browser, the "New" Headless is a Chromium browser. "Old" Headless requires a parallel/duplicate implementation of features, which leads to subtle behavior differences or infeasability to support certain features e.g. extensions proper.

Here are two of them: -Test reproducibility -Automated configuration rollouts in enterprise environments

We regularly get feature requests for Headless to provide a field or property that can be polled by JS frameworks to detect if Headless is active e.g. windows.isBot.

Well, Headless is open source, which means anybody could build a Headless version with such a property set to "I am a human, trust me!" and employ such a modified binary ... ;-)

I fail to see the connection. Can you elaborate?

What rumors? Can you provide any links or context?

PM working on Headless here. Masking bots is not the reason why the new Headless mode was created. The goal is to provide an headless browser that can be used in web tests. The original Headless is essentially a separate browser implemented in parallel to "proper" Chromium. That results in all sorts of subtle reproducibility problems for developers using Headless for their tests.

I am the PM working on Headless. Feel free to ask questions in this thread and I will try to answer them if I can.

Edit: Please also note that we have not released New Headless yet. We "merely" landed the source code.

Can you please file a bug report on crbug.com?

You might also know this as PERT (https://de.wikipedia.org/wiki/Program_evaluation_and_review_...)

I used it in the past and I think it is a good framework to discover uncertainty and make it more visible, because it makes you talk about optimistic and pessimistic cases.

The estimates are also good enough to come up with a draft schedule.

Google in Germany is hiring quite alright.

You can enable it on Firefox nightly. I think the config name is something with shared_mem.

Yes, atomics and SABs are tied to SI being active.

C++

Devs need to do feature detection like with any other feature e.g. for the presence of atomics and sharedarraybuffers.

Indeed. X64 and ia32 support vor Liftoff will be in 69.

It is progressing quite nicely. We still don't know yet when it is ready to graduate from Canary/Dev though. Lot's of stuff to do!

Great summary with a few nits!

I am not aware that Edge is "stupidly fast" on startup. Safari though, is indeed currently leading the field.

As you correctly outlined, V8 is indeed transitioning to a world with an interpreter+optimizing compiler only. If you are using Chrome Canary, there is a chance that you are already using the new pipeline :-).

Full disclosure: I work on the V8 team.

There are tools with more depths: You can try about:tracing or the heap visualizer mentioned in the article.

According to tests it doesn't. The heap memory optimization will only trigger on mobile devices <512MB ram. The zone memory improvements shouldn't have a negative effect.

It would be interesting to get feedback how much this helped Electron.

Keep in mind that this blog post is talking about V8 memory and not Chrome memory. The percentage for Chrome is obviously lower.

V8 recently introduced the flag --minimal which only uses Ignition. The intention behind the flag is to bootstrap porting though.

That sums it up quite well.

Try/catch/finally is handled by TurboFan (one of V8's optimizing compilers) - see https://groups.google.com/forum/#!topic/v8-users/maH60gh_a8s for more detail. There is a certain set of features which go through TurboFan instead of CrankShaft (the other optimizing compiler).

Disclaimer: I work on the V8 team.

ES2015 TCO is in 5.1 but hidden behind a flag. We are preferring the explicit approach championed by Mozilla and Microsoft (https://github.com/tc39/proposal-ptc-syntax) because it makes the debugging and error analysis story better.

ES2015 modules do not take HTML/host environment into consideration. There is still some spec work missing there.

See https://groups.google.com/a/chromium.org/forum/#!searchin/bl... for more information.

The reason is simply 'legacy'. Maybe we will change our version numbers to something without major.minor versions.

Correct.

Major versions make more sense when you create a release based on the content. V8 is creating its releases based on time (~6 week cadence). So a 'major' version is nothing special anymore. In 4.9 we greatly expanded our ES2015 support which was huge but only incremented the minor version because of the same reason.

Disclaimer: I work on the V8 team.

const/let in particular does not prevent optimization. You just need to use "use strict" in order to use them.