24 ms·

Facebook Announces React Fiber, a Rewrite of Its React Framework

851 points by apetresc 10y ago

FLGMwt 10y ago
Is this the rewrite of the diffing engine that we've known about for a good while?
- lacker 10y ago
  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 .
- deleted 10y ago
  [deleted]
mklarmann 10y ago
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.
- draw_down 10y ago
  Yes, this presentation is so good.
- hashhar 10y ago
  It is one of the most accessible talks for someone like me who doesn't even know anything about React.
carlosdp 10y ago
They "announced" this ages ago, didn't they?
- scarlac 10y ago
  Yes.
dstaley 10y ago
> The company hasn’t previously talked about React Fiber Except, you know, the entire presentation on it at React Conf back in March.
- majc2 10y ago
  Or on twitter, or on github :)
  - vmasto 10y ago
    Or the dedicated website on Fiber's progress. http://isfiberreadyyet.com/ http://isfiberreadyyet.com/
- campuscodi 10y ago
  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/2ba00d413b8ff7bc1fa5a2e51c61ba43 https://gist.github.com/duivvv/2ba00d413b8ff7bc1fa5a2e51c61b... Somebody forgot to fact-check his article. That's for sure.
  - mi100hael 10y ago
    > Somebody forgot to fact-check his article. That's for sure. I think that's just called "research," and it's usually step #1 for this kind of article...
  - pfarnsworth 10y ago
    Most reporters these days don't appear to fact check anything anymore. It's too important to get the first story out.
    - campuscodi 10y ago
      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-motherboard https://motherboard.vice.com/en_us/article/editorial-intern-...
xeromal 10y ago
Is this as big a change as Angular 2 for you react devs?
- cprecioso 10y ago
  No, this is mostly an internal change, the API is not changing.
  - xeromal 10y ago
    Thanks.
  - vmasto 10y ago
    Some of the API semantics are changing, e.g. componentWillMount can't be trusted any more (it can fire many times) but they're going to be pretty small.
    - davnicwil 10y ago
      Whoah, hang on, really? Do you have a source on this or somewhere I can find out more details? This will completey break a lot of libraries, components, etc that rely on the React lifecycle contracts.. Certainly doesn't feel like a small change! :-/
      - acemarke 10y ago
        Several relevant pointers: - https://github.com/facebook/react/issues/7671 https://github.com/facebook/react/issues/7671 - https://twitter.com/dan_abramov/status/790590733468241920 https://twitter.com/dan_abramov/status/790590733468241920 - https://www.reddit.com/r/reactjs/comments/5fg7iq/why_should_ajax_requests_go_in_componentdidmount/ https://www.reddit.com/r/reactjs/comments/5fg7iq/why_should_... - https://daveceddia.com/where-fetch-data-componentwillmount-vs-componentdidmount/ https://daveceddia.com/where-fetch-data-componentwillmount-v... Also see Lin Clark's "React Fiber" talk, linked upthread. Basically, pieces of work can start and be interrupted, and then be restarted, which will mean that `componentWillMount` can be called several times before the component _actually_ mounts.
acemarke 10y ago
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/react-implementation.md#react-fiber https://github.com/markerikson/react-redux-links/blob/master... [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
- virtuexru 10y ago
  Your link [1] seems to be broken (https://github.com/markerikson/react-redux-links/blob/master.. https://github.com/markerikson/react-redux-links/blob/master...) just a heads up.
  - acemarke 10y ago
    Whoops, that's what I get for literally copying and pasting my comment :) Fixed - thanks!
- metalliqaz 10y ago
  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.
conover 10y ago
http://isfiberreadyyet.com/ http://isfiberreadyyet.com/
- majewsky 10y ago
  > 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_ 10y ago
    I think it runs the test suite live... It's not meant to be fast, but to demonstrate compatibility.
    - ktta 10y ago
      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 10y ago
        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! ;-)
  - mambodog 10y ago
    This app was written by a manager, don't read into it too much ;)
- dkarl 10y ago
  God, that page makes me want to drop everything and work to make tests pass. My team needs that.
foota 10y ago
I'm excited for relay's new core api to be released, as well.
- spicyj 10y ago
  Me too! More info is available in that blog post: https://news.ycombinator.com/item?id=14142196 https://news.ycombinator.com/item?id=14142196.
danappelxx 10y ago
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 10y ago
  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 10y ago
    The question still stands; will we be bumping a version number, or changing a package name?
    - acemarke 10y ago
      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 ).
  - truncate 10y ago
    It seems like what HopJS does to handle tail calls[1]. It is essentially a trampoline if I understood the docs correctly. [1] https://pdfs.semanticscholar.org/d10d/aba5df8b4c563b62fd01a3042f1ad58fecb0.pdf https://pdfs.semanticscholar.org/d10d/aba5df8b4c563b62fd01a3...
jadbox 10y ago
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 10y ago
  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 10y ago
any news on bundle size? and maybe Closure Compiler compatibility for dead code elimination?
- spicyj 10y ago
  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.0.html https://facebook.github.io/react/blog/2017/04/07/react-v15.5...) which will reduce the bundle size for anyone not using them, regardless of how they compile their JS.
  - bostonvaulter2 10y ago
    I'm excited! React-dom is currently one of the heaviest libraries that I'm using.
  - kuschku 10y ago
    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?
    - vote-for-pedro 10y ago
      > 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. I'd be surprised if most users could find the stop button and manage to tap it in 1 second, so I'm going to have to call BS on that research. > 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? The current version of React[1] is ~21k (~8k gz) and ReactDOM[2] is ~126k (~39k gz) so either you're over-exaggerating, I'm hopeless at basic math or you're just misinformed. [1] https://unpkg.com/react@15.5.4/dist/react.min.js https://unpkg.com/react@15.5.4/dist/react.min.js [2] https://unpkg.com/react-dom@15/dist/react-dom.min.js https://unpkg.com/react-dom@15/dist/react-dom.min.js
kuon 10y ago
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 10y ago
  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 10y ago
    "Mind-bending" being presented as a feature could possibly explain the lack of popularity.
    - crusso 10y ago
      Mind-bending in a good way, like the way that Haskell lets you express constructs that you may never really have used in other languages.
    - kuon 10y ago
      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.
- girishso 10y ago
  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.
suyash 10y ago
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 10y ago
  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 10y ago
    jQuery is just a library, it never told you how to write code.
- oliyoung 10y ago
  “React will die” [Looks at facebook.com] [Looks back at statement] [Keeps building in React]
- nperez 10y ago
  If you don't understand how it works and how it can be combined with tools like Redux to create a highly debuggable and predictable app, it certainly looks like a bunch of newfangled framework stuff for the sake of nothing.
jbmorgado 10y ago
Does this mean something for someone starting in React Native or the changes in that regard are just under the hood?
- danabramov 10y ago
  Under the hood. (We'll update RN to use it soon.)
- flukus 10y ago
  The maturity of the code base has been reset.
andr3w321 10y ago
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.
- robertfw 10y ago
  > All these frameworks end up creating much more problems than they solve. For small projects, sure, they might. But working at larger scale falls apart using plain html and jquery.
  - andr3w321 10y ago
    I assume by scale you mean many pages and not many visitors. For something like hackernews plain html and jquery would work perfectly fine.
    - mod 10y ago
      Yeah, I didn't mean scaling to users. Scale was a poor choice of words. Front-end complexity is a better metric, and in particular complexity which relies on manipulating state.
- mod 10y ago
  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 10y ago
    What's the major advantage of moving from "backend rendering html" to single-page-app?
    - 10y ago
maelito 10y ago
> 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 ?
- awinograd 10y ago
  Not limited at all! You can install react@next from npm and use fiber today. It's just not released as a production ready version.
- k__ 10y ago
  As far as I know the server side rendering isn't done yet.
  - danabramov 10y ago
    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.)
    - deleted 10y ago
      [deleted]
modularfurnitur 10y ago
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 10y ago
  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.
- mnutt 10y ago
  Since Glimmer is implemented as a bytecode VM, they were able to go ahead and pull in many of the improvements that Fiber brings to React: https://thefeedbackloop.xyz/designing-and-implementing-glimmer-like-a-programming-language/ https://thefeedbackloop.xyz/designing-and-implementing-glimm...
startupdiscuss 10y ago
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.
- alcasa 10y ago
  > Great. I was waiting for React to stabilize before I learned it. But once it's stable, it's outdated.
  - b34r 10y ago
    It's been stable for more than a year now.
    - akerro 10y ago
      Best practices will come out in 2025!
- cheapsteak 10y ago
  Not sure if serious, but this update swaps out the internals without affecting users/developers, the API is fully backwards compatible
  - flukus 10y ago
    No API changes doesn't mean that your code will work 100% as it was before.
  - b34r 10y ago
    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 10y ago
      I think we may be splitting hairs over the definition of API compatibility
TheSmoke 10y ago
how this will affect react native?
- Sancty 10y ago
  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-overview.html#fiber-reconciler https://facebook.github.io/react/contributing/codebase-overv...
deleted 10y ago
[deleted]
amelius 10y ago
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 10y ago
  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 10y ago
    UI updates seem to be only possible in the main thread
    - talldan 10y ago
      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.
pcmaffey 10y ago
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).
nkkollaw 10y ago
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 10y ago
  That's a luxury you only get when your API is good. With Angular, the problem was the API.
  - appleflaxen 10y ago
    what does that have to do with whether or not to completely change the name of the re-write?
  - bunkat 10y ago
    Unfortunately that is also the case with Angular v2. The API surface is enormous.
  - component 10y ago
    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
- TP4Cornholio 10y ago
  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.
FridgeSeal 10y ago
Another day another JS Framework.
- nuggien 10y ago
  another day another dude that didn't read the article in the link, and also didn't read the link title.
mattbillenstein 10y ago
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 10y ago
  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 10y ago
    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.
- danabramov 10y 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.
oldgun 10y ago
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 10y ago
  No, because React Fibre is more or less a rewrite of the internals with no API changes.
- pitaj 10y ago
  This is much like the Glimmer announcement. They're simply optimizing and refactoring the rendering engine, with the API not changing, unlike with Angular.
red023 10y ago
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 10y ago
  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?
  - ww520 10y ago
    It's another new proprietary syntax/api for CSS.
  - girishso 10y ago
    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 10y ago
      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.
lightblade 10y ago
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 10y ago
  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 10y ago
    Does Fiber yield control back to the js engine when doing the "rebasing"? Or are all of these synchronous in one frame?
    - danabramov 10y ago
      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/233195cb6bc632ade61a8f64569b4d94061860d6/src/renderers/shared/fiber/ReactFiberScheduler.js#L815-L818 https://github.com/facebook/react/blob/233195cb6bc632ade61a8...
      - lightblade 10y ago
        Interesting... Since requestIdleCallback leaves the scheduling out of your hand, how do you ensure nodes are still updated when you need it? Like tests?
askjdlkasdjsd 10y ago
... 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.
Mayzie 10y ago
Will React Fibre be utilising WebAssembly for a performance increase, particularly for their virtual DOM? (falling back to JavaScript when possible, of course)
- untog 10y ago
  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.
- danabramov 10y ago
  No, there are no plans to use WebAssembly in the next few releases although we'd like to explore this eventually.
fowlerpower 10y ago
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?
huehehue 10y ago
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 10y ago
  Not yet. Seems like there is a loose plan to start implementing some of those optimizations once fiber lands in React 16.
- spicyj 10y ago
  Yes, functional components take a separate, simpler code path that should be faster.
shouldbworking 10y ago
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 10y ago
  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-benchmarks-8bc31af76ce7 https://medium.com/@localvoid/how-to-win-in-web-framework-be...
frik 10y ago
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).
medisyskart 10y ago
we bet #React fiber is faster than any web framework in market now.
amelius 10y ago
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?
deleted 10y ago
[deleted]
pixel67 10y ago
Awesome sauce

851 points by apetresc 10y ago

FLGMwt 10y ago

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

lacker 10y ago
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 .
deleted 10y ago
[deleted]

mklarmann 10y ago

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.

draw_down 10y ago
Yes, this presentation is so good.
hashhar 10y ago
It is one of the most accessible talks for someone like me who doesn't even know anything about React.

carlosdp 10y ago

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

scarlac 10y ago
Yes.

dstaley 10y ago

> The company hasn’t previously talked about React Fiber Except, you know, the entire presentation on it at React Conf back in March.

majc2 10y ago
Or on twitter, or on github :)
- vmasto 10y ago
  Or the dedicated website on Fiber's progress. http://isfiberreadyyet.com/ http://isfiberreadyyet.com/
campuscodi 10y ago
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/2ba00d413b8ff7bc1fa5a2e51c61ba43 https://gist.github.com/duivvv/2ba00d413b8ff7bc1fa5a2e51c61b... Somebody forgot to fact-check his article. That's for sure.
- mi100hael 10y ago
  > Somebody forgot to fact-check his article. That's for sure. I think that's just called "research," and it's usually step #1 for this kind of article...
- pfarnsworth 10y ago
  Most reporters these days don't appear to fact check anything anymore. It's too important to get the first story out.
  - campuscodi 10y ago
    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-motherboard https://motherboard.vice.com/en_us/article/editorial-intern-...

xeromal 10y ago

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

cprecioso 10y ago
No, this is mostly an internal change, the API is not changing.
- xeromal 10y ago
  Thanks.
- vmasto 10y ago
  Some of the API semantics are changing, e.g. componentWillMount can't be trusted any more (it can fire many times) but they're going to be pretty small.
  - davnicwil 10y ago
    Whoah, hang on, really? Do you have a source on this or somewhere I can find out more details? This will completey break a lot of libraries, components, etc that rely on the React lifecycle contracts.. Certainly doesn't feel like a small change! :-/
    - acemarke 10y ago
      Several relevant pointers: - https://github.com/facebook/react/issues/7671 https://github.com/facebook/react/issues/7671 - https://twitter.com/dan_abramov/status/790590733468241920 https://twitter.com/dan_abramov/status/790590733468241920 - https://www.reddit.com/r/reactjs/comments/5fg7iq/why_should_ajax_requests_go_in_componentdidmount/ https://www.reddit.com/r/reactjs/comments/5fg7iq/why_should_... - https://daveceddia.com/where-fetch-data-componentwillmount-vs-componentdidmount/ https://daveceddia.com/where-fetch-data-componentwillmount-v... Also see Lin Clark's "React Fiber" talk, linked upthread. Basically, pieces of work can start and be interrupted, and then be restarted, which will mean that `componentWillMount` can be called several times before the component _actually_ mounts.

acemarke 10y ago

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/react-implementation.md#react-fiber https://github.com/markerikson/react-redux-links/blob/master... [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

virtuexru 10y ago
Your link [1] seems to be broken (https://github.com/markerikson/react-redux-links/blob/master.. https://github.com/markerikson/react-redux-links/blob/master...) just a heads up.
- acemarke 10y ago
  Whoops, that's what I get for literally copying and pasting my comment :) Fixed - thanks!
metalliqaz 10y ago
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.

conover 10y ago

http://isfiberreadyyet.com/ http://isfiberreadyyet.com/

majewsky 10y ago
> 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_ 10y ago
  I think it runs the test suite live... It's not meant to be fast, but to demonstrate compatibility.
  - ktta 10y ago
    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 10y ago
      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! ;-)
- mambodog 10y ago
  This app was written by a manager, don't read into it too much ;)
dkarl 10y ago
God, that page makes me want to drop everything and work to make tests pass. My team needs that.

foota 10y ago

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

spicyj 10y ago
Me too! More info is available in that blog post: https://news.ycombinator.com/item?id=14142196 https://news.ycombinator.com/item?id=14142196.

danappelxx 10y ago

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 10y ago
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 10y ago
  The question still stands; will we be bumping a version number, or changing a package name?
  - acemarke 10y ago
    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 ).
- truncate 10y ago
  It seems like what HopJS does to handle tail calls[1]. It is essentially a trampoline if I understood the docs correctly. [1] https://pdfs.semanticscholar.org/d10d/aba5df8b4c563b62fd01a3042f1ad58fecb0.pdf https://pdfs.semanticscholar.org/d10d/aba5df8b4c563b62fd01a3...

jadbox 10y ago

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 10y ago
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 10y ago

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

spicyj 10y ago
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.0.html https://facebook.github.io/react/blog/2017/04/07/react-v15.5...) which will reduce the bundle size for anyone not using them, regardless of how they compile their JS.
- bostonvaulter2 10y ago
  I'm excited! React-dom is currently one of the heaviest libraries that I'm using.
- kuschku 10y ago
  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?
  - vote-for-pedro 10y ago
    > 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. I'd be surprised if most users could find the stop button and manage to tap it in 1 second, so I'm going to have to call BS on that research. > 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? The current version of React[1] is ~21k (~8k gz) and ReactDOM[2] is ~126k (~39k gz) so either you're over-exaggerating, I'm hopeless at basic math or you're just misinformed. [1] https://unpkg.com/react@15.5.4/dist/react.min.js https://unpkg.com/react@15.5.4/dist/react.min.js [2] https://unpkg.com/react-dom@15/dist/react-dom.min.js https://unpkg.com/react-dom@15/dist/react-dom.min.js

kuon 10y ago

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 10y ago
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 10y ago
  "Mind-bending" being presented as a feature could possibly explain the lack of popularity.
  - crusso 10y ago
    Mind-bending in a good way, like the way that Haskell lets you express constructs that you may never really have used in other languages.
  - kuon 10y ago
    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.
girishso 10y ago
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.

suyash 10y ago

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 10y ago
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 10y ago
  jQuery is just a library, it never told you how to write code.
oliyoung 10y ago
“React will die” [Looks at facebook.com] [Looks back at statement] [Keeps building in React]
nperez 10y ago
If you don't understand how it works and how it can be combined with tools like Redux to create a highly debuggable and predictable app, it certainly looks like a bunch of newfangled framework stuff for the sake of nothing.

jbmorgado 10y ago

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

danabramov 10y ago
Under the hood. (We'll update RN to use it soon.)
flukus 10y ago
The maturity of the code base has been reset.

andr3w321 10y ago

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.

robertfw 10y ago
> All these frameworks end up creating much more problems than they solve. For small projects, sure, they might. But working at larger scale falls apart using plain html and jquery.
- andr3w321 10y ago
  I assume by scale you mean many pages and not many visitors. For something like hackernews plain html and jquery would work perfectly fine.
  - mod 10y ago
    Yeah, I didn't mean scaling to users. Scale was a poor choice of words. Front-end complexity is a better metric, and in particular complexity which relies on manipulating state.
mod 10y ago
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 10y ago
  What's the major advantage of moving from "backend rendering html" to single-page-app?
  - 10y ago

maelito 10y ago

> 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 ?

awinograd 10y ago
Not limited at all! You can install react@next from npm and use fiber today. It's just not released as a production ready version.
k__ 10y ago
As far as I know the server side rendering isn't done yet.
- danabramov 10y ago
  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.)
  - deleted 10y ago
    [deleted]

modularfurnitur 10y ago

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 10y ago
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.
mnutt 10y ago
Since Glimmer is implemented as a bytecode VM, they were able to go ahead and pull in many of the improvements that Fiber brings to React: https://thefeedbackloop.xyz/designing-and-implementing-glimmer-like-a-programming-language/ https://thefeedbackloop.xyz/designing-and-implementing-glimm...

startupdiscuss 10y ago

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.

alcasa 10y ago
> Great. I was waiting for React to stabilize before I learned it. But once it's stable, it's outdated.
- b34r 10y ago
  It's been stable for more than a year now.
  - akerro 10y ago
    Best practices will come out in 2025!
cheapsteak 10y ago
Not sure if serious, but this update swaps out the internals without affecting users/developers, the API is fully backwards compatible
- flukus 10y ago
  No API changes doesn't mean that your code will work 100% as it was before.
- b34r 10y ago
  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 10y ago
    I think we may be splitting hairs over the definition of API compatibility

TheSmoke 10y ago

how this will affect react native?

Sancty 10y ago
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-overview.html#fiber-reconciler https://facebook.github.io/react/contributing/codebase-overv...

deleted 10y ago

[deleted]

amelius 10y ago

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 10y ago
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 10y ago
  UI updates seem to be only possible in the main thread
  - talldan 10y ago
    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.

pcmaffey 10y ago

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).

nkkollaw 10y ago

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 10y ago
That's a luxury you only get when your API is good. With Angular, the problem was the API.
- appleflaxen 10y ago
  what does that have to do with whether or not to completely change the name of the re-write?
- bunkat 10y ago
  Unfortunately that is also the case with Angular v2. The API surface is enormous.
- component 10y ago
  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
TP4Cornholio 10y ago
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.

FridgeSeal 10y ago

Another day another JS Framework.

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

mattbillenstein 10y ago

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 10y ago
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 10y ago
  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.
danabramov 10y 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.

oldgun 10y ago

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 10y ago
No, because React Fibre is more or less a rewrite of the internals with no API changes.
pitaj 10y ago
This is much like the Glimmer announcement. They're simply optimizing and refactoring the rendering engine, with the API not changing, unlike with Angular.

red023 10y ago

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 10y ago
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?
- ww520 10y ago
  It's another new proprietary syntax/api for CSS.
- girishso 10y ago
  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 10y ago
    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.

lightblade 10y ago

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 10y ago
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 10y ago
  Does Fiber yield control back to the js engine when doing the "rebasing"? Or are all of these synchronous in one frame?
  - danabramov 10y ago
    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/233195cb6bc632ade61a8f64569b4d94061860d6/src/renderers/shared/fiber/ReactFiberScheduler.js#L815-L818 https://github.com/facebook/react/blob/233195cb6bc632ade61a8...
    - lightblade 10y ago
      Interesting... Since requestIdleCallback leaves the scheduling out of your hand, how do you ensure nodes are still updated when you need it? Like tests?

askjdlkasdjsd 10y ago

... 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.

Mayzie 10y ago

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

untog 10y ago
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.
danabramov 10y ago
No, there are no plans to use WebAssembly in the next few releases although we'd like to explore this eventually.

fowlerpower 10y ago

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?

huehehue 10y ago

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 10y ago
Not yet. Seems like there is a loose plan to start implementing some of those optimizations once fiber lands in React 16.
spicyj 10y ago
Yes, functional components take a separate, simpler code path that should be faster.

shouldbworking 10y ago

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 10y ago
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-benchmarks-8bc31af76ce7 https://medium.com/@localvoid/how-to-win-in-web-framework-be...

frik 10y ago

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).

medisyskart 10y ago

we bet #React fiber is faster than any web framework in market now.

amelius 10y ago

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?

deleted 10y ago

[deleted]

pixel67 10y ago

Awesome sauce