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 . 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 .
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.
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?
This is a valid concern, and we'll do our best not to screw up. :-)
It's not as hard because there is no parallelism (at least now) and any mutations of the internal data structures happen in two or three tightly controlled places. But yea, debugging these is harder during development (for us) and we'll need to make sure our testing story is rock solid before shipping the asynchronous mode by default.
One thing that really helps here is we test all updates on Facebook which uses React in many places and has a giant user base. So regressions that lead to a drop in metrics (e.g. a crash or a race condition) automatically get reported to us, and this adds a second line of defense after unit and integration tests.
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.
... 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.
Facebook's motto is "move fast and break stuff." I'm glad they didn't follow this when making React Fiber. I suspect they learned from Angular 2's failure.
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.
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.
Elm is amazing! If you have all the pieces in place aka model, view and update; once you get it compiled successfully.. it just works, it's mind blowing. This also makes refactoring a joy.
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?
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.
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...
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.
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.
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).
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.
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!
[+] [-] acemarke|9 years ago|reply
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 . 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 .
[0] https://www.youtube.com/watch?v=ZCuYPiUIONs
[1] https://github.com/markerikson/react-redux-links/blob/master...
[2] https://github.com/facebook/react/issues/8854
[3] https://github.com/facebook/react/issues/9207
[+] [-] metalliqaz|9 years ago|reply
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.
[+] [-] catpolice|9 years ago|reply
[+] [-] chairmanwow|9 years ago|reply
[+] [-] virtuexru|9 years ago|reply
[+] [-] dstaley|9 years ago|reply
Except, you know, the entire presentation on it at React Conf back in March.
[+] [-] campuscodi|9 years ago|reply
Somebody forgot to fact-check his article. That's for sure.
[+] [-] YCode|9 years ago|reply
http://isfiberreadyyet.com/
[+] [-] majc2|9 years ago|reply
[+] [-] wingerlang|9 years ago|reply
[+] [-] conover|9 years ago|reply
[+] [-] mklarmann|9 years ago|reply
[+] [-] hashhar|9 years ago|reply
[+] [-] draw_down|9 years ago|reply
[+] [-] startupdiscuss|9 years ago|reply
I've been cleverly waiting since 2006 to learn jquery. Will start next year.
[+] [-] alcasa|9 years ago|reply
But once it's stable, it's outdated.
[+] [-] cheapsteak|9 years ago|reply
[+] [-] mattbillenstein|9 years ago|reply
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?
[+] [-] danabramov|9 years ago|reply
It's not as hard because there is no parallelism (at least now) and any mutations of the internal data structures happen in two or three tightly controlled places. But yea, debugging these is harder during development (for us) and we'll need to make sure our testing story is rock solid before shipping the asynchronous mode by default.
One thing that really helps here is we test all updates on Facebook which uses React in many places and has a giant user base. So regressions that lead to a drop in metrics (e.g. a crash or a race condition) automatically get reported to us, and this adds a second line of defense after unit and integration tests.
[+] [-] acemarke|9 years ago|reply
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.
[+] [-] askjdlkasdjsd|9 years ago|reply
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|9 years ago|reply
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|9 years ago|reply
[+] [-] TP4Cornholio|9 years ago|reply
[+] [-] FLGMwt|9 years ago|reply
[+] [-] lacker|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] xeromal|9 years ago|reply
[+] [-] kuon|9 years ago|reply
[+] [-] crusso|9 years ago|reply
Elm really could be the future of bullet-proof web development. It has everything it needs except for runaway popularity.
[+] [-] girishso|9 years ago|reply
[+] [-] huehehue|9 years ago|reply
Does Fiber introduce any of those optimizations, or nah?
[+] [-] bunkat|9 years ago|reply
[+] [-] spicyj|9 years ago|reply
[+] [-] foota|9 years ago|reply
[+] [-] spicyj|9 years ago|reply
[+] [-] shouldbworking|9 years ago|reply
So much hype and no words about performance... I'm wondering if it's slower.
[+] [-] danappelxx|9 years ago|reply
[+] [-] carlosdp|9 years ago|reply
[+] [-] scarlac|9 years ago|reply
[+] [-] amelius|9 years ago|reply
[+] [-] lightblade|9 years ago|reply
[+] [-] danabramov|9 years ago|reply
[+] [-] pcmaffey|9 years ago|reply
[+] [-] jadbox|9 years ago|reply
[+] [-] spicyj|9 years ago|reply