Meeting Notes 2015-06-05

(Paul O’Shannessy) #1



  • removed .type on Types
  • Working on freezing props
    • devtools has a problem, it allows modifying props
      • object.preventextensions?
      • maybe UI level changes


  • way more eslint
    • enabled JSX
    • custom rules


  • colorful moving box for ReactGL
  • perf analysis
  • talk prep
  • next: decoupling isomorphic
  • next: merge hedger’s thing from devtools


  • removed dom wrapper components
  • working on exposing dom nodes as refs
  • next: fragment codemods


  • fbjs
  • also working on build stuff


  • devtools on react native, connecting to chrome
    • will work on rewriting in react


  • we’re slow, let’s get better.
  • we’re not optimized for things, but that is often what we get perf tested against
  • initial mount, large mount swaps


  • auto on, opt out
    • make it opt-in for 0.14


  • beta in 3 weeks
  • $20 on the line for “all umbrella” task. (@sebmarkbage bet @spicyj we would get it all done)

(Joe Wood) #2

ReactGL - is this going to be OSS? Is there anything we can look at?

(axemclion) #3

@zpao - About the perf topic, are there test suites ? Are there certain things you are looking to perf test ?

I was working on a test suite to test perf regressions. It runs scroll tests on DBMonster app for various react versions - Will something like this help ?

(Sophie Alpert) #4

ReactGL is very early stages (just a few files on @sebmarkbage’s computer) and really just a fun experiment for now but if it turns into something real I expect it’ll be publicly released. No near-term plans to use it for anything real, in any case.

(Sophie Alpert) #5

With regards to perf, we would like to set up a solid benchmark suite. I’d imagine that we’re more interested in benchmarking raw JS times than full end-to-end browser perf since most of that time is out of React’s hands but it would be neat to have something like your link or like to track perf over time.

We need to be careful in choosing test cases to make sure we test things we care about. Lots of people write tests to compare React/Ember/Angular/etc that consist of cases like reordering a list with thousands of rows, which are rare in the real world and not what we want to optimize for. We care more about things like initial render perf for real-world component examples and lowering the overhead of adding layers of abstraction (e.g., <RainbowButton> should be minimally slower than a plain <button> in order to encourage people to build good component abstractions). @jimfb was recently looking into extracting an example React component from the Facebook homepage for us to use as a benchmark.

(axemclion) #6

Makes sense. While end to end benchmarks may be too much to run per commit, I think they do make sense to run per release. I agree that comparing frameworks does not really help, I think it makes more sense to compare versions of the same framework to see how performance evolves.

Are you guys planning to build a suite of tests that I could re-use to run these performance test cases? I am currently using DBMonster, but a good, canonical set of test cases that React cares about would be something I could run these tests on, and watch the performance.

I also think these end to end tests could help validate design decisions though.
For example,

  • Tests showed that most of the time in React is spent in the event loop rather than paints. That would actually mean that doing some of this work in a Web worker would make things faster.
  • If any event in the event loop takes more than 60fps, Chrome may not draw it. Javascript-only tests would still indicate 60fps when the browser is actually skipping frames. A design could be only to work on the DOM that is in the visible area of the page/defer other work for later.
  • Inline Styles vs Classes - since the browser renders these, setting any of then in Javascript without the browser may not tell us the real story.