
Facebook Announces React Fiber, a Rewrite of Its React Framework - apetresc
https://techcrunch.com/2017/04/18/facebook-announces-react-fiber-a-rewrite-of-its-react-framework/
======
acemarke
I'll repeat the comment I made in the "React 15.5" thread a couple weeks ago
([https://news.ycombinator.com/item?id=14063818](https://news.ycombinator.com/item?id=14063818)):

For those who are interested in some of the details of the work that's going
on, Lin Clark's recent talk on "A Cartoon Intro to Fiber" at ReactConf 2017 is
excellent [0]. There's a number of other existing writeups and resources on
how Fiber works [1] as well. The roadmap for 15.5 and 16.0 migration is at
[2], and the follow-up issue discussing the plan for the "addons" packages is
at [3].

I'll also toss out my usual reminder that I keep a big list of links to high-
quality tutorials and articles on React, Redux, and related topics, at
[https://github.com/markerikson/react-redux-
links](https://github.com/markerikson/react-redux-links) . Specifically
intended to be a great starting point for anyone trying to learn the
ecosystem, as well as a solid source of good info on more advanced topics.
Finally, the Reactiflux chat channels on Discord are a great place to hang
out, ask questions, and learn. The invite link is at
[https://www.reactiflux.com](https://www.reactiflux.com) .

[0]
[https://www.youtube.com/watch?v=ZCuYPiUIONs](https://www.youtube.com/watch?v=ZCuYPiUIONs)

[1] [https://github.com/markerikson/react-redux-
links/blob/master...](https://github.com/markerikson/react-redux-
links/blob/master/react-implementation.md#react-fiber)

[2]
[https://github.com/facebook/react/issues/8854](https://github.com/facebook/react/issues/8854)

[3]
[https://github.com/facebook/react/issues/9207](https://github.com/facebook/react/issues/9207)

~~~
metalliqaz
I admire your exceptional work cataloguing these resources. However, just one
look at that giant horde of links is, to me, a perfect demonstration of why
the front-end development ecosystem is way out of control.

Its amazing to me that the autoconf/automake/libtool system for making write-
once-run-everywhere *nix applications is downright simple by today's
standards.

Every year the hot libraries change, the build tools change, the
metalanguages, the data formats, even the damn paradigms change. Each
generation requires more layers trying to fix up the underlying evil that
nobody who soaks themselves in the matter will admit: the browser is a bad app
platform and javascript is a bad language. Both have been pressed into serving
a purpose for which neither were designed.

~~~
colordrops
I don't know about others but I tire of these comments chiding the "out of
control" front-end ecosystem. The situation has already changed years ago. We
aren't going to get off of your lawn while you continue to beat a dead horse.
The web is built on open standards and there are billions of pages and apps
out there. To expect web development to be a perfect monoculture is a failure
of your imagination and ability to adapt rather than a failure of the
ecosystem.

~~~
paganel
Not the OP, but I expect the web to be a thing where documents (i.e. mainly
text) don't have any issues rendering on my 5-year old phone or on my 8-year
laptop (both of which work very well, still, and which I don't plan to replace
anytime soon).

The recent web practices (I'm talking mostly of the last 2-3 years, since more
and more people have started copying Twitter with its launch of its "every
website needs to be a JS-app" thingie) have practically destroyed how most of
the websites are displayed by the 2 devices I own. Sites like Hacker News or
Wikipedia, which still work perfectly fine, are very far and few between. I
sincerely deplore this.

~~~
acjohnson55
A web limited to textual content is a pretty quaint and uninspiring vision,
IMO.

The web started that way because static documents are relatively easy to
represent, but the future (and present, for that matter) is rich experiences
that can be distributed in the same way.

But there are many steps left to get there, so either buckle up and help build
that future, or get used to an ever-shrinking ecosystem of the purely textual
Web.

I'm personally very excited by the convergence of mobile and web development,
PWAs, improved functionality for layouts, self-hosted app architectures (like
Tent and Sandstorm, language-agnostic runtime via Web Assembly, better serving
performance via HTTP/2, low level multimedia APIs, encapsulation of rich UX
via Web Components, and so on and so on.

Sure, it's bewildering right now, but in the future, this will all be knit
together in a cohesive way.

~~~
taeric
My opinion happens to differ. Textual content is incredibly rich and is likely
a target for all content in the future. Consider, we are literally training
models to accurately caption things today.

Why? Because language is a hell of an abstraction. More, it is approachable
and can often be bounded. Consider, I am not even remotely skilled in art.
However, I can adequately describe, for me, a picture by saying who is in it
and the event. Try doing the same without language. Often "quaint and
uninspiring textual" language.

Do I opine for the what we had in the 90s? Not necessarily. But I do grow
weary of folks reinventing frameworks that merely further complicate the very
abstractions that they created and now require these frameworks.

------
dstaley
> The company hasn’t previously talked about React Fiber

Except, you know, the entire presentation on it at React Conf back in March.

~~~
campuscodi
It's TechCrunch... I won't say anymore because I'm also a member of the
press... but it took me 3 seconds to find this on Google:
[https://gist.github.com/duivvv/2ba00d413b8ff7bc1fa5a2e51c61b...](https://gist.github.com/duivvv/2ba00d413b8ff7bc1fa5a2e51c61ba43)

Somebody forgot to fact-check his article. That's for sure.

~~~
pfarnsworth
Most reporters these days don't appear to fact check anything anymore. It's
too important to get the first story out.

~~~
campuscodi
I always imagined that a company of TechCrunch's size would have interns that
do all the fact-checking... similar to VICE:
[https://motherboard.vice.com/en_us/article/editorial-
intern-...](https://motherboard.vice.com/en_us/article/editorial-intern-
motherboard)

------
conover
[http://isfiberreadyyet.com/](http://isfiberreadyyet.com/)

~~~
majewsky
> This page is rendered with it.

Yep, I can tell from the 5 seconds of blank screen while my phone browser
loads all that JS.

~~~
pygy_
I think it runs the test suite live... It's not meant to be fast, but to
demonstrate compatibility.

~~~
ktta
Are you sure? Because that's a waste of resources. I'd imagine they would
cache the results, which would make the GP's concerns about speed valid.

Edit: Found the github repo -
[https://github.com/tomocchino/isfiberreadyyet](https://github.com/tomocchino/isfiberreadyyet)

Looks like it fetches from the umbrella issue[1]

[https://github.com/facebook/react/issues/7925](https://github.com/facebook/react/issues/7925)

~~~
danabramov
It fetches from GitHub. The website was built in a weekend by our manager to
make the task of a complete rewrite a little more fun for the team. Sorry it’s
not perfect! ;-)

------
mklarmann
React Fiber was beautifully described by Lin on the last reactconf.
[https://www.youtube.com/watch?v=ZCuYPiUIONs](https://www.youtube.com/watch?v=ZCuYPiUIONs)
Congratulations to the release.

~~~
hashhar
It is one of the most accessible talks for someone like me who doesn't even
know anything about React.

------
startupdiscuss
Great. I was waiting for React to stabilize before I learned it.

I've been cleverly waiting since 2006 to learn jquery. Will start next year.

~~~
cheapsteak
Not sure if serious, but this update swaps out the internals without affecting
users/developers, the API is fully backwards compatible

~~~
b34r
It's actually not. There are some lifecycle changes, potential modifications
to setState (async only), etc. That's why it's being released as a new major
version.

~~~
cheapsteak
I think we may be splitting hairs over the definition of API compatibility

~~~
antjanus
it's one of those 99% compatible except for a few small quirks that only
developers using it on large applications will notice.

The React devs have also been great with releasing codemods for breaking APIs.

------
mattbillenstein
Lin Clark's talk makes this sound like they implemented a scheduler in React
-- basically JS is single-threaded, so they're implementing their own
primitives and a scheduler for executing those on that main thread.

Sounds neat, but it also seems like an explosion in complexity -- perhaps
there will be a bunch of weird scheduler bugs the operating system folks more
or less figured out a long time ago?

~~~
acemarke
New code certainly carries risks that old, known code doesn't. And yes, this
does carry over towards OS scheduler territory.

That said, the early feedback from others in the React community is that the
Fiber implementation is simpler overall and easier to work with than the
"React Stack" implementation. Fiber is also explicitly built to support
additional renderers on top of the core reconciler, while building renderers
on the Stack implementation apparently required some levels of monkey-patching
or reaching into internals.

~~~
toxicFork
I'm an author of a custom renderer and yes it's so much easier to make a
renderer to work with fiber :) I'll do a write-up on it eventually but I'm
sure others with more time will beat me to it.

------
askjdlkasdjsd
... that was pretty uninformative. The first 4 paragraphs the author is just
talking about nothing.

React Fiber is nothing new. It's more than an year old. Facebook has talked
about it many times. Anyone who uses React would know this.

Shouldn't we prefer official sources instead of articles written by third
party content writers that are clearly not that knowledgeable? Seriously, this
article looks like the author was being paid by character count and not
quality.

------
nkkollaw
See, Google should learn from Facebook: total API compatibility with the
previous version.

They saw what happened with Angular and Angular 2—which Google named the same
despite it being a totally different framework—and made a smart move.

~~~
gkoberger
That's a luxury you only get when your API is good. With Angular, the problem
_was_ the API.

~~~
component
Angular 1.x was never meant to be an MVC initially. It was mainly for
_templating_ then they started adding stuff to it (services, directives,
digest cycle, dependency injection...) leading to API bloat

By the time Angular 2 was released, Ember, Vue and React have devoured the
market

------
FLGMwt
Is this the rewrite of the diffing engine that we've known about for a good
while?

~~~
lacker
Yep - if you are interested in learning more technical details, check out
[https://github.com/acdlite/react-fiber-
architecture](https://github.com/acdlite/react-fiber-architecture) .

------
xeromal
Is this as big a change as Angular 2 for you react devs?

~~~
zackify
Not at all, nothing incompatible changes on the surface. There are more
features and no breaking changes. It's mostly all under the hood!

There will be new public api's to build your own custom rendering engine, ex
how there is react-dom for browsers, react-native for mobile, and it will get
easier to target new platforms thanks to fiber.

~~~
amccloud
For those who have side-effects in their component lifecycle methods might
have some problems when they turn on async fibers.

~~~
oliyoung
Which, in Facebook's defense, they've explicitly and often warned against

------
kuon
I've been working with react for a bit more than a year, and I am trying elm.
I think elm is the best thing that happened to the web in general. It's really
daunting at first, but I highly encourage you to try it.

~~~
crusso
Elm blows me away. It's everything I saw that React was trying to do, but
bound up in an actual language that has strong Haskell-ish types, is fully
functional, and mind-bendingly fun to learn.

Elm really could be the future of bullet-proof web development. It has
everything it needs except for runaway popularity.

~~~
roguecoder
"Mind-bending" being presented as a feature could possibly explain the lack of
popularity.

~~~
kuon
I dismissed elm about 10 times. But once I tried it, it was great. The pure
functional approach of elm is like solving an equation. Once it is solved,
it's done, you can go home. In the sense of that you write elm code only once,
if it work, it will always work. And if it doesn't work, it won't compile
anyway.

------
huehehue
Neither the comments nor the article mention this, so I figure I'd ask here --
the React team has been promising performance improvements for stateless
functional components (I think because they require less/no overhead +
lifecycle management) for some time now, but I don't think it's moved beyond
that.

Does Fiber introduce any of those optimizations, or nah?

~~~
bunkat
Not yet. Seems like there is a loose plan to start implementing some of those
optimizations once fiber lands in React 16.

------
foota
I'm excited for relay's new core api to be released, as well.

~~~
spicyj
Me too! More info is available in that blog post:
[https://news.ycombinator.com/item?id=14142196](https://news.ycombinator.com/item?id=14142196).

------
shouldbworking
Anyone have a link to some benchmarks? As much as I enjoy the hype train
sometimes, I'm not finding hard data on how much faster this is than the
current React/Preact/Inferno .

So much hype and no words about performance... I'm wondering if it's slower.

~~~
danabramov
Please see my reply in
[https://news.ycombinator.com/item?id=14144042](https://news.ycombinator.com/item?id=14144042).

Regarding benchmarks, you might enjoy reading this:
[https://medium.com/@localvoid/how-to-win-in-web-framework-
be...](https://medium.com/@localvoid/how-to-win-in-web-framework-
benchmarks-8bc31af76ce7)

------
danappelxx
Sorry, it wasn't entirely clear to me from the article. Is React Fiber going
to be a completely new project, or is it just a name for the new release? It
seems like the latter to me since there's no API changes...

~~~
acemarke
It's a rewrite of the internals, particularly the diffing/reconciliation
algorithm. React Fiber involves effectively re-implementing the JS call stack
using a data structure called "fibers" to track work that needs to be done.

~~~
apetresc
The question still stands; will we be bumping a version number, or changing a
package name?

~~~
acemarke
It's a major version release. v15.5 added deprecation warnings, v15.6 will add
a few more warnings and fixes, and v16.0 will be a major release that includes
the Fiber internals turned on. (This release path is described in the issues I
linked in my earlier comment, particularly
[https://github.com/facebook/react/issues/8854](https://github.com/facebook/react/issues/8854)
).

------
carlosdp
They "announced" this ages ago, didn't they?

~~~
scarlac
Yes.

------
amelius
So they have created a kind of map/reduce system to distribute computation
over a tree, except everything still runs in the same Javascript main thread.

~~~
b34r
Not at all. Fiber is a method of divvying up the work the reconciler is doing
so the main thread can process higher priority updates ahead of ones that
matter less. There are other benefits, but this is the central one.

~~~
amelius
UI updates seem to be only possible in the main thread

~~~
talldan
My understanding is that it's a prioritisation system. If all of the UI
changes can't be completed before the next render, the lowest priority changes
are deferred to the next render.

It should help with things where perceived lag is undesirable, like typing in
an input field.

------
lightblade
Correct me if I'm wrong, but Fiber sounds like a micro tasker for React? Ember
had been doing this for years through Backburner run loop

~~~
danabramov
With the ability to pause large updates in the middle without committing them
to UI, doing some higher priority updates, and then "rebasing" lower priority
updates on top of them and continuing the work. So it's a bit more
sophisticated.

~~~
lightblade
Does Fiber yield control back to the js engine when doing the "rebasing"? Or
are all of these synchronous in one frame?

~~~
danabramov
Yea, it does. We are using requestIdleCallback to do the work "while we can",
and then yield the control back. Again, this won't be a part of React 16, but
it's part of the bigger picture we are moving towards.

Relevant code if you're curious:
[https://github.com/facebook/react/blob/233195cb6bc632ade61a8...](https://github.com/facebook/react/blob/233195cb6bc632ade61a8f64569b4d94061860d6/src/renderers/shared/fiber/ReactFiberScheduler.js#L815-L818)

~~~
lightblade
Interesting...

Since requestIdleCallback leaves the scheduling out of your hand, how do you
ensure nodes are still updated when you need it? Like tests?

------
pcmaffey
This is great news. Definitely merging css animations with React prop/state
changes has been the biggest friction point with React (ie managing DOM state
from 2 different sources).

------
jadbox
Feels like every month they [re]announce React Fiber... there's no reason why
this needs to be repeated again and again. And every time it shoots up to #1
on HN.

~~~
spicyj
Sorry! Definitely no intention to bombard you with the same news. It's true
that we had a couple talks at last month's React Conf but Facebook's
conference F8 is this week which comes with a wide publicity push. Hopefully
the next time you hear about it will be the final open source release later
this year!

------
undershirt
any news on bundle size? and maybe Closure Compiler compatibility for dead
code elimination?

~~~
spicyj
No final numbers yet, but we recently switched to Rollup for our own builds
which will be part of 16.0, and we'll do some more work on file size in the
next few months.

For DCE, we've started splitting some features like createClass out of the
main package
([https://facebook.github.io/react/blog/2017/04/07/react-v15.5...](https://facebook.github.io/react/blog/2017/04/07/react-v15.5.0.html))
which will reduce the bundle size for anyone not using them, regardless of how
they compile their JS.

~~~
kuschku
What bundle size range can we expect?

Many mobile users are on throttled connections, due to low data caps, and
research has shown users stop loading a site usually after 1 second of loading
time.

That means with a throttled connection, less than 8KiB overall CSS, JS and
HTML can be transmitted, and with a 1Mbps connection, 128KiB can be
transmitted.

How many minutes will users have to wait with React Fiber? And can it be
improved in any way to get below a few seconds? Or will I have to continue to
write vanilla JS to get responsive apps?

~~~
kuschku
Answering @vote-for-pedro: Yes, currently, a working React installation takes
around 6-10 seconds to load on dialup or throttled internet, without caching.
Which is pretty good.

But React Fiber is doing a lot more than legacy react, so it'd be interesting
to know how much larger it will get - and if it would still be performant
enough.

------
Mayzie
Will React Fibre be utilising WebAssembly for a performance increase,
particularly for their virtual DOM? (falling back to JavaScript when possible,
of course)

~~~
untog
WebAssembly isn't some magic bullet that's going to make every piece of code
faster. Anything strongly connected to the DOM is still going to be slow,
because the DOM slows things down a lot more than JavaScript does.

------
maelito
> It’s already in use on Facebook.com today

What's preventing us from using it in our apps then ? Do they limit the use of
the API to what's implemented in Fiber in some parts of the website ?

~~~
k__
As far as I know the server side rendering isn't done yet.

~~~
danabramov
Server rendering is missing, and a few other things. (You can check React 16
umbrella issue in
[https://github.com/facebook/react/issues/8854.](https://github.com/facebook/react/issues/8854.))

------
modularfurnitur
Is fiber similar to what glimmer is to ember? Is it a big enough improvement
to reconsider using react instead? (I was stoked on the glimmer stuff).

~~~
batmansmk
React is mostly an API contract (React.Component) and it didn't change. If you
didn't like it for this reason, you won't like more.

If you left React for performance reasons especially related to real-time
updates or animations, well this version is better.

------
amelius
Good to read that React is faster now.

Can we write an efficient rich text editor like Google Docs in React? Or would
it still be too slow?

------
TheSmoke
how this will affect react native?

~~~
Sancty
Looks like it will be a big help to RN. However, I can't confirm that it's a
drop in replacement.

[https://facebook.github.io/react/contributing/codebase-
overv...](https://facebook.github.io/react/contributing/codebase-
overview.html#fiber-reconciler)

------
pixel67
Awesome sauce

------
red023
How does it compare with vue.js? I never worked with any modern JS framework
like this but on paper I did not like writing CSS in javascript and vue.js had
a normal way to write CSS and to me it looked superior in other ways as well.

~~~
erikpukinskis
What was your objection to writing CSS in JS? It would seem like a fairly
trivial syntactic transition to go from one to the other? It's just selectors
with a dictionary of properties right​?

~~~
girishso
Writing CSS in Javascript brings back memories of pre-2000 web development,
table based layouts and more horribly inline styles inside HTML tags. CSS was
a breath of fresh air, it meant separation of concerns.. HTML the content and
CSS the visual representation. With the advent of jQuery it allowed separation
of behavior as well.

With frameworks like React these days, content+behavior is in JavaScript
already, and with writing CSS in JavaScript, we've gone back 1.5 decades I
think.

~~~
justsee
I had this same initial reaction, but concluded as others have that this
architectural approach was not actually a separation of concerns but merely an
unwieldy separation of technologies: [http://blog.andrewray.me/youre-missing-
the-point-of-jsx/](http://blog.andrewray.me/youre-missing-the-point-of-jsx/)

When you start thinking in components it becomes much nicer to have the
styling, logic and layout all in one file, isolated from the rest of the
application and easy to edit, move around and apply to any page.

The previous 'best practice' of having these coupled aspects in separate files
now seems quaint and tedious.

There are of course trade-offs, and CSS-in-JS has not triumphed yet, but if
you've held off from considering this approach simply because you've had
'separation of technologies' drummed into you in the past you might be missing
out.

------
frik
Building your project upon an framework means abstraction, idoms on top of the
programming language one has to learn and the pending migration-horror when
the framework changes the API or gets deprecated.

Often it makes sense to think at least about alternative solutions like using
libraries instead of a framework. Libraries are a different concept that is
more flexible. In any case stable API is prefered to moving targets. A real
probem is when project move so fast that one has to update to every new minor
version of the framework/library, if he skips one he might be left out of the
supported upgrade path (frameworks) - lot's of maintanance work that could be
spent elsewhere (coding new features, etc).

------
jbmorgado
Does this mean something for someone starting in React Native or the changes
in that regard are just under the hood?

~~~
flukus
The maturity of the code base has been reset.

------
FridgeSeal
Another day another JS Framework.

~~~
nuggien
another day another dude that didn't read the article in the link, and also
didn't read the link title.

------
oldgun
Does it the Frontend ecosystem has yet another new framework? Do we have to
retire the old one and learn the new one all over again?

~~~
madeofpalk
No, because React Fibre is more or less a rewrite of the internals with no API
changes.

------
andr3w321
No thanks I'll stick with plain html and jquery for the frontend of my small
projects. Plain javascript works perfectly fine as long as you namespace your
functions and separate them into different files. All these frameworks end up
creating much more problems than they solve.

~~~
mod
As someone who has worked on a truly large React project, I can assure you
this is not true.

I cannot _imagine_ the shitshow that project would be using jQuery to track
the state.

Nearly as soon as you progress from 'backend rendering html' to single-page-
app, it behooves you to use React.

~~~
rocky1138
What's the major advantage of moving from "backend rendering html" to single-
page-app?

~~~
mod
There are trade-offs. In very broad terms, single-page-apps are better for
something that behaves more like an application (has a lot of user interaction
or real-time behavior) than something that behaves more like a website (a page
is loaded and the user views that now-static page for a period of time).

I try to fit the more traditional paradigm when I'm allowed to architect an
app myself. I like rendering a page on the backend.

Anyway, you can read arguments by smarter people than myself:
[http://stackoverflow.com/questions/21862054/single-page-
appl...](http://stackoverflow.com/questions/21862054/single-page-application-
advantages-and-disadvantages)

That's just one thread of many.

------
suyash
React will die by the weight of the frameworks and libraries that have
duplicated effort and created more confusion and divide amongst the developer
community.

~~~
sergiotapia
It's made my life infinitely easier writing front end apps that need to keep
state and update when the data changes. Remember the old days of backbone and
marrionette? Remember even older, having horrible jquery sprinkled around
everywhere?

~~~
vlunkr
jQuery is just a library, it never told you how to write code.

------
fowlerpower
Everyone working on JavaScript right now lives in a bubble. Take a look at how
back end languages have evolved and that's your future, you can try to deny it
but your going to go the way C did and Java did. You can cite openness and the
web and all these other things that make some kind of sense but history is
against you.

In reality those arguments don't hold water. In reality our field is 30 years+
old and there is some maturity in the way things are done. All this crazy shit
of rewrite everything all the time will just eventually tire people out and
people will cut this redo an entire framework just because out.

JavaScript is one of the most important languages around right now and pretty
soon the adults are going to be taking it away from the kids. Just as an FYI,
this is another example of that. Too many important decisions are happening
without much thought about what's there already.

I don't know maybe I'm wrong and maybe this time will be different but I've
been around long enough. I learned the ins and outs of angular only to be told
"fuck that" shortly after. It all seems very wrong too me but maybe you can
tell me otherwise?

