Facebook Announces React Fiber, a Rewrite of Its React Framework • Hacker News Board

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

#351

Post by vote-for-pedro » Wed, Apr 19, 2017, 9:35 AM UTC

kuschku wrote: post #156

spicyj wrote: post #29

Earlier quoted context omitted.

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... ) which will reduce the bundle size for anyone not using them, regardless of how they compile the…

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…

> 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

[2] https://unpkg.com/react-dom@15/dist/react-dom.min.js

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

#352

Post by lightblade » Wed, Apr 19, 2017, 9:46 AM UTC

danabramov wrote: post #346

lightblade wrote: post #229

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

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.

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

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

#353

Post by whostolemyhat » Wed, Apr 19, 2017, 9:50 AM UTC

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…

Would you rather have less documentation and fewer tutorials? I wouldn't call four links about a new library excessive.

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

#354

Post by EugeneOZ » Wed, Apr 19, 2017, 9:57 AM UTC

mattnewton wrote: post #96

EugeneOZ wrote: post #65

Earlier quoted context omitted.

Rust, PHP had simple af builds/packaging. So no, not everything is complex, just old dinosaurs AND web.

I would never want to use php's "just recompile it with the new dependencies" approach ever again. It's a complete mess as soon as you go off the rails of what's included by default.

I will never believe people recompile PHP binaries every day.

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

#355

Post by whostolemyhat » Wed, Apr 19, 2017, 9:59 AM UTC

douche wrote: post #312

ng12 wrote: post #308

Earlier quoted context omitted.

Angular 1 is 7 years old. And guess what? It's still a perfectly valid framework to build a web application with. There is no "curve".

Of course it's a valid framework. But the cool kids have all moved onto Angular2, or React, or some other thing I'm too stuck in the mud to even know about.

But why does that matter? Does your Angular 1 application work? Does Angular 2 existing prevent it from working?

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

#356

Post by EugeneOZ » Wed, Apr 19, 2017, 9:59 AM UTC

eropple wrote: post #92

EugeneOZ wrote: post #65

Earlier quoted context omitted.

Rust, PHP had simple af builds/packaging. So no, not everything is complex, just old dinosaurs AND web.

PHP's packaging was only "simple af" until you had a binary dependency that wasn't part of your operating system. Complicated things exist.

Yeah, you can recompile PHP 2-3 times per year, and it's just long line of args, nothing more. And you can compare it with every-time compilation of modern js apps. What an equation! And you forgot to mention Rust, but let's pretend it's normal way of arguing.

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

#357

Post by Bombthecat » Wed, Apr 19, 2017, 10:14 AM UTC

nightski wrote: post #50

acemarke wrote: post #40

Earlier quoted context omitted.

Your comment seems to be a bit of a non-sequitur. Application development is complex, period. Posix development is complicated. Qt is big and complicated. Makefiles are complicated. Autotools is complicated. Big Java server apps are complicated. C++ is complicated. We've just hit the point where people are trying to do the same thing in a browser. Would you prefer to build your application using Make, Scons, Waf, CMa…

The benefits you acknowledge (distribution) are not because of the tech but in spite of it. At the end of the day all it would take is one of the 3 major browser vendors to offer an alternative. That alternative could be distributed to a large percentage of desktops in a relatively quick manner saving billions if not trillions of dollars in wasted productivity. It will never happen though. * EDIT: This comes from som…

Dart is shipped with chrome, or not? I don't see any huge success :)

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

#358

Post by Horusiath » Wed, Apr 19, 2017, 10:20 AM UTC

iamaelephant wrote: post #287

vning93 wrote: post #115

Earlier quoted context omitted.

Completely agree here. I think many people realize this and have built awesome tooling to be able to manage different ecosystems and environments. One that I've been particularly keen on over the last year is GraphQL. If you're interested in simplifying frontend development while giving it more power and control to dictate the data that it needs for each component / view, you should check out GraphQL. I know what you…

GraphQL existed a decade ago, it was called OData and it wasn't as revolutionary as everyone thought it would be at the time.

OData - which was essentially LINQ over URL - was nice (but incomplete) idea with terrible realization. We've used it in two projects in the past and we've fallen back from using it in both cases:

- OData never got wider adoption outside (and even inside) MS. GraphQL is already adopted on every major platform.

- OData had shitton of documentation and format changes with every version. Backward compatibility not included. GraphQL has clear specification which is pretty stable since its first publication.

- OData queries had no validation. You could send almost every query just to get runtime response that your framework/library doesn't support that functionality - even if it was developed by Microsoft itself. On the contrary all major GraphQL server implementations have full feature support.

- Thanks to Introspection API GraphQL has self-descriptive metadata model, which is great for tooling and compile time query verification. Also versioning, schema and documentation are all included into GraphQL from start.

- And finally GraphQL focuses on exposing capabilities of your service into well defined format understood by frontend, not on exposing subset of your database to the user - like OData did.

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

#359

Post by jerryszczerry » Wed, Apr 19, 2017, 10:24 AM UTC

cubano wrote: post #172

ZenoArrow wrote: post #94

Earlier quoted context omitted.

>"At the end of the day all it would take is one of the 3 major browser vendors to offer an alternative." You mean like Dart? Besides, languages that target WebAssembly are almost certainly going to evolve to fit that space.

I have serious doubts that WebAssembly is really going to come to dominate the web the way many people here seem to believe it will. The idea that all of sudden there is going to be a rush to push compiled/closed sites after so many very successful years of using free-and-open stacks seems rather non-logical to me. Time will tell.

> The idea that all of sudden there is going to be a rush to push compiled/closed sites after so many very successful years of using free-and-open stacks seems rather non-logical to me.

Well, then we have minified JS that isn't exactly readable. Similarly with multiple-compiled JSX-to-ES6-to-ES5/JS code.

Also, there's a number of JS obfuscators, whose main purpose is to smuggle a piece of closed code into those theoretically “free-and-open” stacks.

Thus, I think, after wasm becomes generally supported, there will be more incentive to write code in your language of choice and compile it to a common platform, than to write code in JS or one of its derivatives and minify/compile it anyway.

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

#360

Post by Lyren » Wed, Apr 19, 2017, 10:24 AM UTC

red023 wrote: post #322

erikpukinskis wrote: post #188

Earlier quoted context omitted.

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?

My objection is. I already learned how to write less and then later switched to SCSS. I like the syntax because its basically CSS and I do even avoid heavy nesting taking bootstrap as a good example. I use atom and scss-lint (now deprecated but still works great) to live lint my SCSS in Atom and spot errors and that includes order! Can I do this in CSS that is embedded into stupid react files that mix JS logic with t…

The style I like to use is the css/scss webpack loader. Basically, you import a .scss file into your .jsx. The scss is compiled and at the same time imported into .jsx as a hashmap where the key is your scss class-name & the value is the compiled class-name. I think this sounds like what you're looking for since it keeps jsx & css in their respective files but still being coupled into their own component which is easier to reason about.

http://javascriptplayground.com/blog/2016/07/css-modules-web...