<div dir="ltr"><div><div>Thank you Mike for the huge piece of work. Also thank you to the code reviewers and people who helped make this happen.<br></div>This was indeed very much worth the time, considering the performance gains.<br><br></div>Cross-posting to the devtools mailing list too.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 13, 2018 at 2:31 PM, Michael (work) <span dir="ltr"><<a href="mailto:mratcliffe@mozilla.com" target="_blank">mratcliffe@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>A few weeks back the Developer Tools team upgraded from React
15.6.1 to React 16.2.0.<br>
<br>
To complete this upgrade we had to make a large number of changes
to many of our Developer Tools. There was a decent amount of work
we had to do across all of our GitHub repos but the majority of
the work can be seen in this dependency graph:<br>
<a href="https://bugzilla.mozilla.org/showdependencytree.cgi?id=1416824&hide_resolved=0" target="_blank">https://bugzilla.mozilla.org/<wbr>showdependencytree.cgi?id=<wbr>1416824&hide_resolved=0</a><br>
<br>
We have both the production and development versions of React but
the development versions are only used, or exist, when
`ac_add_options --enable-debug-js-modules` is set in `.mozconfig`
or at least that will be the case when <a href="https://bugzil.la/1440609" target="_blank">https://bugzil.la/1440609</a>
lands.<br>
<br>
<b>React worked fine before so why the upgrade?</b><br>
<br>
The speed increases we have seen as a result of the React upgrade
have been impressive averaging around 6-7% speed increase in
reported by our DAMP tests and up to 30% increase in some tools!<br>
<br>
If you add to this that many of the speed increases in React 16
are perceived performance it is obvious that user's speed increase
perception is going to be much higher.<br>
<br>
The React team have managed to accomplish this by completely
rewriting their rendering engine so that it now chooses paths,
called fibres, through the render tree and will hold off
refreshing branches of the tree if it would otherwise be rendered
multiple times.<br>
<br>
Another thing that makes things faster is that React now makes
good use of the requestIdleCallback API to ensure that components
are only rendered when the browser is not busy.<br>
<br>
Because React is now using this method we are ready for the next
big change, which Dan Abramov spoke about in JSConf Ireland 2018:<br>
<a href="https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-16.html" target="_blank">https://reactjs.org/blog/2018/<wbr>03/01/sneak-peek-beyond-react-<wbr>16.html</a><br>
<br>
He explains it clearly:<br>
<br>
"We’ve built a generic way for components to suspend rendering
while they load async data, which we call suspense. You can pause
any state update until the data is ready, and you can add async
loading to any component deep in the tree without plumbing all the
props and state through your app and hoisting the logic.<br>
<br>
On a fast network, updates appear very fluid and instantaneous
without a jarring cascade of spinners that appear and disappear.
On a slow network, you can intentionally design which loading
states the user should see and how granular or coarse they should
be, instead of showing spinners based on how the code is written.
The app stays responsive throughout."<br>
<br>
So in a nutshell, we will be able to add a property to components
that allow them to render asynchronously. This could potentially
result in even higher performance increases... watch this space.<br>
<br>
/Mike Ratcliffe<br>
</p>
</div>
<br>______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/firefox-dev</a><br>
<br></blockquote></div><br></div>