Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Facebook Announces React Fiber, a Rewrite of Its React Framework

techcrunch.com

Post reply on HN
Print view View original

161–170 of 422 posts

Re: Facebook Announces React Fiber, a Rewrite of Its React Framework

#161

Post by acemarke »

mattbillenstein wrote: post #152

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?

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.

Re: Facebook Announces React Fiber, a Rewrite of Its React Framework

#162

Post by danabramov »

acemarke wrote: post #62
davnicwil wrote: post #48

Earlier quoted context omitted.

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! :-/

Several relevant pointers: - https://github.com/facebook/react/issues/7671 - https://twitter.com/dan_abramov/status/790590733468241920 - https://www.reddit.com/r/reactjs/comments/5fg7iq/why_should_... - 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…

To be clear this is irrelevant to React 16 which works in sync mode for compatibility. We'll share more about any changes when we start enabling the async mode in Facebook products and figure out the best migration strategy.

Re: Facebook Announces React Fiber, a Rewrite of Its React Framework

#163

Post by austincheney »

metalliqaz wrote: post #36
acemarke wrote: post #11

I'll repeat the comment I made in the "React 15.5" thread a couple weeks ago ( 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 m…

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 too…

> a perfect demonstration of why the front-end development ecosystem is way out of control.

The answer to this is simple but horribly disappointing. In the military we describe this behavior as "justifying your existence". There are three separate causes to this problem.

First, solving valid problems is hard in any environment. Dicking around with tooling and configuration is easy. This includes frameworks, abstraction libraries, and so forth. Real problems are often tied to products, services, or end-user problems (opposed to these invented developer problems).

Second, writing open source software takes initiative and discipline. It is easier to have the energy for hard problems when people are telling you what to work on and you are getting paid. In this case failing to complete the hard problems bring retribution and eventually termination. When you are on your own or volunteering your time you have to really want it, which completely compounds the first point.

Third, there is a low barrier to entry to do front-end work. You can copy paste some code from the internet into your browser console and watch it do stuff. You don't need a compiler, special environment to get started, or any kind of fancy software. This problem is compounded in the legacy corporate world where web technologies are still viewed as inferior child's play for incompetent weak-minded children. After all real developers write ALL of their web related code in Java 6 (sarcasm).

Re: Facebook Announces React Fiber, a Rewrite of Its React Framework

#164

Post by danabramov »

oakesm9 wrote: post #12
xeromal wrote: post #8

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

Not in terms of it being a breaking change. It's meant to be a big speed improvement but the API is largely the same I believe.

Please note that Fiber is not meant to be a “big speed improvement”. (React is already pretty fast, and most speed improvements you can do in this space are marginal for most apps.)

Fiber is a rewrite that makes it easier for us to add new features to React (and it adds some). It also adds the foundation for enabling better perceived performance in the future releases thanks to async pre-rendering and more control over scheduling. That part is still work in progress and won't be enabled in React 16 by default.

So we do think eventually it’ll enable us to build more responsive apps, but we’re still working out the details and experimenting with what it can do. Don’t expect any drastic changes on this front in React 16.

Re: Facebook Announces React Fiber, a Rewrite of Its React Framework

#165

Post by mnutt »

modularfurnitur wrote: post #82

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

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

Re: Facebook Announces React Fiber, a Rewrite of Its React Framework

#166

Post by mickael-kerjean »

andr3w321 wrote: post #57

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.

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

there's no such things as the best approach for all needs. React brings you load of advantage but it assumes stuff you might not be ok with:

- spend time maintaining your project over time fixing stuff on version change that won't bring any direct value to your project

- you're ok with the licence and with the company maintaining it.

- hard to debug stack trace

- ship code that you have no control over, increasing the payload size (at least for small to medium size projects)

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

First nobody force you to use jquery. Manipulating the Dom isn't what it was when people had to maintain stuff on ie6. Dealing with the Dom directly isn't a "shit show" anymore and if you understand the concept of redux you can use those general concept and apply it in your project to manage the state. Plain Js simply assume the Dom isn't a magical piece of software, it just has prototype and stuff people usually don't like around here but hey, if you're coding stuff for the web, it's better to know how to deal with it than denying it

Es6 brings lot of great features you can use today, you don't need react for that

Re: Facebook Announces React Fiber, a Rewrite of Its React Framework

#167

Post by cubano »

cies wrote: post #129
colordrops wrote: post #43

Earlier quoted context omitted.

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…

> I don't know about others but I tire of these comments chiding the "out of control" front-end ecosystem Old people also get tired by all these "apps" wining for your attention; they want "just a phone". Young people grew up with it. Note to self: I'm getting old. Old people were used to buying development toolset (compiler+tools+IDE), usually including a physical book, with which they can create software. Young peo…

I'd be careful of making such generalized statements, whipper-snapper...some of us senile old devs actually pieced together some "wild and free" C-libs (i think we used duct tape and hairpins, but im losing my memory in my advanced age) and even used dynamic-loading (DLLs of course) back in the day.

Re: Facebook Announces React Fiber, a Rewrite of Its React Framework

#168

Post by danabramov »

k__ wrote: post #136
maelito wrote: post #58

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

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

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

Re: Facebook Announces React Fiber, a Rewrite of Its React Framework

#170

Post by ng12 »

segphault wrote: post #154
ng12 wrote: post #125

Earlier quoted context omitted.

It was never intended to be supported natively by browsers -- it's syntactic sugar for the React.createElement API. That's what I mean when I say JSX is Javascript. That issue you linked to is 4 years old and is clearly a reflection of the poster being unfamiliar with React/JSX. The community has since unambiguously decided to avoid inserting more control flow in JSX. Also, I'm not entirely sure what the do/while plu…

> That issue you linked to is 4 years old and is clearly a reflection of the poster being unfamiliar with React/JSX And yet the underlying issues still remain unaddressed. There aren't better ways to handle the cases raised in that issue, which is why people resort to adding additional non-standard syntax to work around the warts. > Also, I'm not entirely sure what the do/while plugin has to do with JSX. The "do" key…

Ah, sorry I misunderstood the plugin. But to the point -- people do all kinds of crazy things in all kinds of languages with all kinds of tools. That doesn't mean there's anything fundamentally broken about them. Now that I know about the existence of the Do plugin I can also definitively say I have no use for it. It's a band-aid for bad code, not a bad framework.

> I don't think you really understand how template literals work

I absolutely do. I use them to internationalize my apps. They're a powerful tool that is not comparable to React/JSX. JSX is not just a template engine which is what you seem to be implying.

Post reply on HN