“TurboFan” – Experimental new optimizing compiler for Google's V8 JS engine

&gt; We&#x27;ve reached the point where it&#x27;s better for our development velocity to work in the open on the bleeding edge branch of V8. That&#x27;s also better for our collaborators who are working on ports to more platforms.<p>I wonder who are the collaborators with access to Google&#x27;s private V8 repo and what platforms they&#x27;re porting to. If merging TurboFan to the open repo didn&#x27;t reveal their partners&#x27; proprietary plans now, then why not develop in the open sooner?

It would be nice to understand the goals of this project in terms of both approach as well as the overall performance improvements and how it would compare with the new LLVM-based approach taken by Safari&#x2F;Webkit.

Here&#x27;s something that&#x27;s been bothering me since Chrome dropped the experimental support for `position: sticky` (and CSS Regions before) and I didn&#x27;t find the right place to ask (nor is a submission about the JS engine an appropriate venue for this question, I know), so I&#x27;m going to hijack this thread:<p>We know some properties are <i>expensive</i> and when you use them a few times (or with certain values) you get sub-60fps scrolling — but why are they <i>expensive</i>? Are they inherently hard to optimize (e.g. different GPUs across mobile devices), or is it that nobody got to optimize them yet?