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

181–190 of 422 posts

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

#181

Post by johncolanduoni »

colordrops wrote: post #147
leeoniya wrote: post #141

Earlier quoted context omitted.

ok, assuming your request is not sarcastic: - operating systems - hardware drivers - a networking stack - trading algorithms - fighter jet firmware - ultra low latency DSP - processing data from LHC collisions or imaging satellites. - etc - etc - etc just because webgl enables fast gpu processing (by basically writing a small subset of C that is shader code) doesnt now mean the web platform can be used for evetything…

The implication was applications. But even then, everything on your list is emphatically not true: - operating systems Ironically Linux was one of the first things to ever be compiled to run in the browser using empscripten. - hardware drivers Linux doesn't run without hardware drivers. In this case, the hardware drivers were wrapping JS FFIs. - a networking stack Yes you can. - trading algorithms Why not? - fighter…

You can emulate a network stack and hardware drivers, but your "network stack" can't directly send packets outside of HTTP/Websockets/WebRTC/etc. and your "hardware drivers" just emulate hardware that doesn't actually exist.

Trading algorithms, ultra low latency DSP, "processing data from LHC collisions or imaging satellites" are I think references to performance limitations. WebAssembly requires a fair bit of runtime checks (though some can be pawned off to the hardware if you're clever), and has a number of other quirks that hurt performance, like the fact that most languages end up needing two stacks when compiled for wasm.

The issue is even clearer when you move to processing large data sets because WebAssembly only allows a 32-bit address space at the moment. Add to that the lack of concurrency or native SIMD, and it's pretty clear it is way too early to dance on the graves of native executables.

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

#182

Post by colordrops »

mirsadm wrote: post #171
troncheadle wrote: post #149

Earlier quoted context omitted.

And I would love if my 2001 Honda Accord was compatible with Tesla's autopilot, but I understand it is not a realistic expectation. I'm not sure why you'd expect the web to be a. Mostly text and b. able to render easily on obsolete devices. The web is becoming a robust application delivery platform. That is so, so awesome. Most people do not want to be stuck with shitty looking, text only websites. Moving the platfor…

They may be robust but the user experience still sucks. JS heavy web sites are unresponsive and turn my 3 year old MBP into a vacuum cleaner. Facebook is the best example. I can barely load the web site without the fans spinning. Firefox can't handle it at all. It is unusable for me.

Something is wrong with your MBP.

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

#183

Post by colordrops »

brandonmenc wrote: post #155
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…

> To expect web development to be a perfect monoculture is a failure Except, it's already a monoculture of one language (JS) and one display algorithm (DOM) and everything is just compensating for that. The "runtime" is not general enough .

WebAssembly will remedy that.

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

#184

Post by sharun »

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…

It's like the Engineering teams at Google and Facebook have never heard of Microsoft or Sun or Adobe. There are so many lessons (learnt the hard way) in the evolution of .NET, Java and Flash that these guys seem to be completely oblivious too.

Google, Facebook devs please go spend some time with the language and platform greybeards at Microsoft.

EDIT: Feels like Software Engineering needs a set of Software History textbooks to keep reminding us of what has already been built.

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

#185

Post by colordrops »

johncolanduoni wrote: post #181
colordrops wrote: post #147

Earlier quoted context omitted.

The implication was applications. But even then, everything on your list is emphatically not true: - operating systems Ironically Linux was one of the first things to ever be compiled to run in the browser using empscripten. - hardware drivers Linux doesn't run without hardware drivers. In this case, the hardware drivers were wrapping JS FFIs. - a networking stack Yes you can. - trading algorithms Why not? - fighter…

You can emulate a network stack and hardware drivers, but your "network stack" can't directly send packets outside of HTTP/Websockets/WebRTC/etc. and your "hardware drivers" just emulate hardware that doesn't actually exist. Trading algorithms, ultra low latency DSP, "processing data from LHC collisions or imaging satellites" are I think references to performance limitations. WebAssembly requires a fair bit of runtim…

Concurrency and SIMD support are in the works.

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

#186

Post by amptorn »

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…

> Every year the hot libraries change

Front-end development is fashion.

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

#188

Post by erikpukinskis »

red023 wrote: post #187

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.

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

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

#189

Post by danabramov »

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?

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.

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

#190

Post by johncolanduoni »

colordrops wrote: post #185
johncolanduoni wrote: post #181

Earlier quoted context omitted.

You can emulate a network stack and hardware drivers, but your "network stack" can't directly send packets outside of HTTP/Websockets/WebRTC/etc. and your "hardware drivers" just emulate hardware that doesn't actually exist. Trading algorithms, ultra low latency DSP, "processing data from LHC collisions or imaging satellites" are I think references to performance limitations. WebAssembly requires a fair bit of runtim…

Concurrency and SIMD support are in the works.

I'm aware, but "If you can run a video game engine in the browser you can run anything" isn't exactly hedged on the future is it?
Post reply on HN