SebastianVerified account

I think you need @bmeurer, for the v8/JS side of things. For other stuff, not sure who's in charge.

I don't @v8js is significant part of the problem here. But I'm also not sure what counts as part of "the DOM rendering lifecycle". This probably needs attention from experts. cc @addyosmani @jaffathecake @samccone @slightlylate

My understanding is that there is a decent portion of this, although in theory a lot of it could be detected and optimized with a fallback to the slow path if you go off the guard rails. But that's hard to implement and teach. So...

... one path forward is allowing you to specify policies for your page ahead of time saying "you have permission to make these APIs work differently/disappear" and then the browser can optimize this new fast mode.

Hm, if we could start again I'd want to add specific style & layout read/write phases. Remove the footgun of layout thrashing.

Do you think there would be any value in someone writing a browser optimally, from scratch, at any point? Or will improvements in hardware (and potentially an upper limit of 120fps) allow us to ignore the issues with the old architecture indefinitely?

I talked to someone at Chrome Developer Summit on the dev team that they did a prototype on version of chrome that disabled a lot of checks and got huge speedups. Idea is could opt into these speedups.