5 ms·

I'm just excited for https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html https://reactjs.org/blog/2018/03/27/update-on-async-renderin... , and cu

I'm just excited for https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html https://reactjs.org/blog/2018/03/27/update-on-async-renderin... , and curious to see how it works in our code.

globuous 8y ago
Absolutely ! Any news on that btw ?
- swyx 8y ago
  the Suspense PR was merged in for this version (https://github.com/facebook/react/commits/master?after=fa7fa812c70084e139d13437fb204fcdf9152299+69 https://github.com/facebook/react/commits/master?after=fa7fa...) so you can absolutely start trying it out in 16.4. with the requisite warnings that it is still unstable. I keep a repo of all publicly discussed stuff on async react here: https://github.com/sw-yx/fresh-async-react https://github.com/sw-yx/fresh-async-react for people's research convenience.
  - kiliancs 8y ago
    I think these commits were taken out of the release. At least I couldn't find them when I took a quick look: https://github.com/facebook/react/commits/v16.4.0 https://github.com/facebook/react/commits/v16.4.0
    - swyx 8y ago
      it was merged from acdlite's branch. look harder :)
deckard1 8y ago
It's going to be interesting to see how this plays out. It's an enormous effort on their part, and for the users with all the API changes. But Dan's "Beyond React 16" demo simply was not compelling at all for me. With the focus on latency but no mention of bandwidth, it's really hard to understand the full impact on mobile devices. With TCP, throughput decreases as latency increases. Queue up too many requests, and the UI will get more disconnected, not less. Anyone that has had to work on an image gallery knows this all too well. Then you have SSR, and promises from render() that potentially swallow errors... lots of unknowns here. If all these efforts turn into a wash, or at best a subtle improvement at a cost of relearning React... people are going to be asking if it was worth it.

I'm just excited for https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html https://reactjs.org/blog/2018/03/27/update-on-async-renderin... , and curious to see how it works in our code.

globuous 8y ago

Absolutely ! Any news on that btw ?

swyx 8y ago
the Suspense PR was merged in for this version (https://github.com/facebook/react/commits/master?after=fa7fa812c70084e139d13437fb204fcdf9152299+69 https://github.com/facebook/react/commits/master?after=fa7fa...) so you can absolutely start trying it out in 16.4. with the requisite warnings that it is still unstable. I keep a repo of all publicly discussed stuff on async react here: https://github.com/sw-yx/fresh-async-react https://github.com/sw-yx/fresh-async-react for people's research convenience.
- kiliancs 8y ago
  I think these commits were taken out of the release. At least I couldn't find them when I took a quick look: https://github.com/facebook/react/commits/v16.4.0 https://github.com/facebook/react/commits/v16.4.0
  - swyx 8y ago
    it was merged from acdlite's branch. look harder :)

deckard1 8y ago

It's going to be interesting to see how this plays out. It's an enormous effort on their part, and for the users with all the API changes. But Dan's "Beyond React 16" demo simply was not compelling at all for me. With the focus on latency but no mention of bandwidth, it's really hard to understand the full impact on mobile devices. With TCP, throughput decreases as latency increases. Queue up too many requests, and the UI will get more disconnected, not less. Anyone that has had to work on an image gallery knows this all too well. Then you have SSR, and promises from render() that potentially swallow errors... lots of unknowns here. If all these efforts turn into a wash, or at best a subtle improvement at a cost of relearning React... people are going to be asking if it was worth it.